Самый лучший способ удостовериться в подлинности сертификата – проверять все без исключения поля, а особенно доменное имя. Оно может находиться в двух полях: DN (distinguished name – отличительное имя) и в поле subject AltName типа dnsName. Отметим, что в этих полях, помимо имени хоста, содержится и другая информация.

Хорошо, все это вы прилежно выполнили. Значит ли это, что все опасности SSL позади□ Отнюдь. Исключив самые серьезные и наиболее распространенные опасности (подсовывание противником сертификата, не подписанного известным УЦ или содержащим некорректные данные), вы даже не приблизились к опушке леса. Что, если закрытый ключ, ассоциированный с сертификатом, был похищен□ Предъявив такое удостоверение, противник может притвориться сервером, и никакой из рассмотренных выше способов контроля об этом не узнает, даже если администратор настоящего сервера обнаружил факт компрометации и сменил верительные грамоты. Даже протокол HTTPS уязвим в этой ситуации, несмотря на строгий подход к обеспечению безопасности по SSL.

Необходим какой–то способ сообщить, что сертификат сервера соответствует недействительным верительным грамотам. Таких способов два. Первый – это список отозванных сертификатов (CRL). Идея в том, что УЦ ведет список всех плохих сертификатов, и вы можете загрузить его: по протоколу HTTP или LDAP (Lightweight Directory Access Protocol – облегченный протокол службы каталогов). Но у CRL несколько проблем:

□ между кражей закрытого ключа и моментом загрузки CRL может пройти значительное время. Ведь факт кражи нужно еще обнаружить и сообщить об этом УЦ. Затем УЦ должен добавить ассоциированный с украденным ключом сертификат в CRL и опубликовать новую версию списка. Пока все это будет тянуться, противник успеет притвориться каким–нибудь популярным Web–сайтом;

□ проверить, что сертификат находится в CRL, не очень просто, поскольку эта процедура плохо поддержана. Библиотеки для работы с SSL обычно включают неполную поддержку (или вообще никакой). Если же библиотека все–таки поддерживает CRL–списки, то обычно нужно написать много кода, чтобы загрузить их и проверить. К тому же УЦ не всегда четко информируют о том, где искать CRL–список (предполагается, что адрес должен быть прописан в самом сертификате, но в большинстве случае это не так). Некоторые УЦ обновляют свои CRL редко, а есть и такие, что вообще не публикуют их.

Другую возможность предоставляет протокол онлайнового запроса статуса сертификата (OCSP – Online Certificate Status Protocol). Его назначение – уменьшить промежуток времени, в течение которого сервер уязвим, за счет внедрения онлайновой службы, у которой можно запросить статус сертификата. Но, как и в случае CRL, этот протокол не слишком хорошо поддерживается. (Вопреки требованиям стандарта IETF многие УЦ и библиотеки для работы с SSL не поддерживают его вовсе, а в тех, которые поддерживают, этот режим, скорее всего, по умолчанию отключен.) Кроме того, есть проблемы, присущие только OCSP. Самая очевидная из них – в том, что необходим доступ по сети к службе, отвечающей на запросы. Поэтому при реализации OCSP нужно считать сертификат недействительным в случае недоступности службы или хотя бы реализовать второй эшелон обороны: загружать и проверять CRL, причем отказываться принимать сертификат, если CRL последний раз обновлялся слишком давно.

Основные проблемы SSL мы описали, но есть еще кое–что, заслуживающее хотя бы краткого упоминания. Во–первых, в предыдущих версиях SSL были просчеты, как серьезные, так и не очень. Мы рекомендуем пользоваться последней версией TLS, а не устаревшими. Особенно это относится к версиям SSLv2 и РСТ. Это может оказаться нелегко, поскольку библиотеки по умолчанию часто в ходе установления сеанса соглашаются на любую версию протокола, поддерживаемую другой стороной. Не применяйте шифры, не обладающие достаточной криптографической стойкостью. Особенно избегайте семейства шифров RC4. Этот шифр известен своим быстродействием, поэтому к нему часто прибегают в надежде повысить производительность приложения, хотя при использовании SSL этот выигрыш не так заметен. Но RC4 криптографически нестоек, есть данные в пользу того, что его можно вскрыть при наличии достаточно большого объема зашифрованных данных, даже если следовать всем рекомендациям. А вообще–то узкое место для большинства приложений – это операции с открытым ключом во время начальной аутентификации, а не последующее шифрование (если, конечно, вы не пользуетесь шифром 3DES).

Родственные грехи

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

По сути дела наша основная трудность – это частный случай гораздо более широкой проблемы, заключающейся в том, что две стороны хотят выработать общий криптографический ключ, но делают это небезопасным способом. Эта проблема будет рассмотрена в грехе 17.

Помимо того, некоторые библиотеки повышают риск, выбирая неудачные ключи. Причина – в использовании случайных чисел недостаточно высокого качества. Это тема греха 18.

Есть несколько мест, на которые следует обратить внимание, и прежде всего это недостаточно тщательная проверка подлинности сертификата. Ищите места, где:

□ используется SSL или TLS;

□ не используется HTTPS;

□ ни библиотека, ни приложение не проверяют, что сертификат выпущен известным УЦ;

□ ни библиотека, ни приложение не контролируют важные поля в сертификате сервера.

Если приложение не удовлетворяет этим требованиям, то проверять, отозван ли сертификат, обычно не имеет смысла, так как есть проблемы, куда более серьезные, чем похищенные верительные грамоты.

Если же с указанными выше задачами приложение справляется, то следует обратить внимание на вопросы, связанные с CRL:

□ используется SSL или TLS;

□ не проверяется, был ли похищен закрытый ключ сервера и не отозван ли сертификат.