Проблемы SSL связаны с самим API, а не с языком, на котором он реализован. Следовательно, уязвимы программы на любом языке. Протокол HTTPS (HTTP поверх SSL) в этом отношении надежнее, чем сам SSL, поскольку в нем аутентификация производится обязательно, а не оставлена на усмотрение разработчика. Таким образом, HTTPS возлагает ответственность за принятие решения на пользователя.

SSL – это протокол с установлением соединения (хотя рабочая группа по развитию Интернет (IETF) обещает скоро выпустить версию, не требующую соединения). Основное назначение SSL – обеспечить передачу сообщений по сети между двумя сторонами, каждая из которых настолько, насколько это возможно, уверена в том, с кем общается (разумеется, полную гарантию дать затруднительно), и при этом гарантировать, что сообщения не сможет ни прочитать, ни модифицировать противник, имеющий доступ к сети.

Прежде чем начать сеанс защищенной передачи произвольных данных по протоколу SSL, обе стороны должны аутентифицировать друг друга. Почти всегда клиент должен аутентифицировать сервера. Сервер может согласиться на общение с анонимным пользователем, возможно, для того чтобы зарегистрировать его. В противном случае сервер сам аутентифицирует клиента. Обе процедуры могут происходить одновременно (взаимная аутентификация). Или сервер может затребовать аутентификацию (например, путем ввода пароля) позже, когда защищенный канал уже будет создан. Но легитимность аутентификации сервера зависит от качества аутентификации клиента. Если клиент не убедился, что общается с нужным ему сервером, то место сервера может занять противник, который будет получать от клиента данные и потом передавать их серверу (эта атака относится к типу «человек посередине»). Так может произойти, даже если клиент посылает серверу правильный пароль.

В протоколе SSL принята модель «клиент–сервер». Зачастую клиент и сервер аутентифицирую друг друга, пользуясь разными механизмами. Для аутентификации сервера обычно применяют инфраструктуру открытого ключа (Public Key Infrastructure – PKI). В ходе организации канала сервер создает сертификат, который содержит открытый ключ для нового сеанса, а также дополнительные данные (имя сервера, дату истечения срока действия сертификата и т. д.). Все эти данные криптографически связаны друг с другом и с ключом. Но клиент должен быть уверен, что сертификат действительно выпущен данным сервером.

PKI – это механизм, который позволяет проверить, что сертификат принадлежит серверу, поскольку он подписан доверенной третьей стороной – удостоверяющим центром (УЦ) (Certification Authority – СА). (Технически может существовать цепочка промежуточных УЦ на пути от сертификата к корневому УЦ.) Для контроля подлинности сертификата нужно проделать немало работы. Прежде всего у клиента должна быть какая–то основа для проверки подписи УЦ. В общем случае вместе с клиентом устанавливаются сертификаты хорошо известных корневых УЦ, например VeriSign или сертификат корпоративного УЦ. Последнее позволяет развертывать SSL в масштабе одного предприятия. Коль скоро открытый ключ УЦ известен, клиент может проверить цифровую подпись и тем самым убедиться, что сертификат не изменился с момента подписания его УЦ.

Обычно сертификат действует только в течение некоторого времени, у него, как и у кредитной карточки, есть даты начала и окончания срока действия. Если сертификат недействителен, клиент не должен принимать его. Теоретическое обоснование этого ограничения состоит в том, что чем дольше существует сертификат и соответствующий ему закрытый ключ, тем выше шансы, что этот ключ мог быть похищен. Кроме того, по истечении срока действия сертификата УЦ уже не обязан следить, был ли скомпрометирован ассоциированный с ним закрытый ключ.

На многих платформах предустановлен единый список корневых сертификатов, пригодных для установления степени доверия. Библиотеки могут предоставлять средства для контроля всей цепочки доверия на пути к корневому сертификату, хотя это и необязательно. Могут также предоставляться или не предоставляться средства для проверки истечения срока действия сертификата. При использовании HTTPS библиотека обычно все это делает, так как спецификация HTTPS явно этого требует (а чтобы отключить проверку, вы сами должны будете написать некий код). В остальных случаях вам, возможно, придется программировать проверки своими силами.

Даже если используемая вами библиотека для поддержки SSL делает все, что нужно, есть еще ряд аспектов, вызывающих вопросы. Например, хотя описанная выше процедура контролирует цепочку доверия и гарантирует, что срок действия сертификата не истек, вы все равно не можете быть уверены, что на другом конце находится сервер, с которым вы готовы обмениваться данными. Предположим, что вы хотите обращаться к службе на машине example.com. Вы устанавливаете SSL–соединение, получаете сертификат, проверяете, что он не истек и подписан известным УЦ. Но вы не проверили, выпущен ли этот сертификат от имени example.com или attacker.org. Если противник подсунул свой сертификат, как вы об этом узнаете?

Это реальная проблема, поскольку противник без труда может получить сертификат из доверенного источника, оставаясь анонимным. И для этого не нужно красть чужие верительные грамоты, можно обойтись и законными методами, поскольку некоторые входящие в иерархию доверия УЦ предъявляют очень либеральные требования к аутентификации физического лица. (Автор получал сертификаты в центре, который проверял лишь регистрационную информацию, связанную с доменом, а ее саму нетрудно сфабриковать.) К тому же в большинстве случаев системы, которые не знают, как правильно выполнять контроль, скорее всего, не сохраняют сертификаты после использования и не протоколируют информацию, необходимую для уличения преступника, а потому, используя собственный сертификат, противник мало чем рискует. Да и предъявление чужого сертификата может сработать.