Шрифт:
В–третьих, необходимо контролировать, что загруженный CRL–список действительно опубликован соответствующим УЦ (для этого нужно проверить цифровую подпись).
И наконец, проверяя каждый предъявленный сертификат, следует убедиться, что ни один из сертификатов в цепочке доверия не внесен в имеющиеся CRL–списки. Если какой–то сертификат отозван, то соединение устанавливать нельзя.
В CRL заносятся просто идентификаторы сертификатов. Чтобы сверить сертификат с CRL–списком, нужно извлечь поле ID и посмотреть, есть ли оно в этом списке.
Таблица 10.1. Адреса точек распространения CRL–списков для популярных УЦ
Дополнительные защитные меры
В идеале, помимо описанных в этой главе проверок, надо бы проверять и другие критические расширения сертификата Х.509. При этом вы должны ясно понимать смысл всех критических расширений. Тогда вы не спутаете, например, сертификат для подписания кода с SSL–сертификатом. Вообще говоря, такие проверки могут представлять интерес, но обычно они не настолько важны, как может показаться.
Чтобы снизить риск кражи верительных грамот, после чего сертификат придется отозвать, можно рассмотреть возможность применения специального оборудования для ускорения работы с SSL. Большинство таких продуктов хранят секретные данные в аппаратуре и не показывают их компьютеру ни при каких обстоятельствах. Таким образом, хакер, взломавший вашу машину, ничего не добьется. Некоторые устройства оборудованы также средствами против физического вмешательства, так что даже физическая атака становится затруднительной.
И наконец, если вас пугает сложность дотошной проверки SSL–сертификатов, а ваше приложение общается только с небольшим числом серверов, то можете зашить в код все действительные сертификаты и сличать все байты. Такой подход на основе списков допустимых сертификатов можно дополнить собственной схемой PKI, но в долгосрочной перспективе это окажется более дорогостоящим и трудоемким делом, чем реализация корректной проверки с самого начала.
Другие ресурсы
□ RFC по протоколу HTTPS: www.ietf.org/rfc/rfc2818.txt
□ Документация по Java Secure Socket Extension (JSSE) API: java.sum.com/products/jsse
□ Документация по программированию SSL и TLS на базе библиотеки OpenSSL: www.openssl.org/docs/ssl/ssl.html
□ Информационный центр компании VeriSign по вопросам SSL: www.signiocom/products–services/security–services/ssl/ssl–information–center/
□ Информация по SslStream:(en–us,vs.80). aspx
Резюме
Рекомендуется
□ Пользуйтесь последней версией SSL/TLS. В порядке предпочтительности: TLS 1.1, TLS 1.0hSSL3.
□ Если это имеет смысл, применяйте списки допустимых сертификатов.
□ Прежде чем посылать данные, убедитесь, что сертификат партнера можно проследить до доверенного УЦ и что его срок действия не истек.
□ Проверяйте, что в соответствующем поле сертификата партнера записано ожидаемое имя хоста.
Не рекомендуется
□ Не пользуйтесь протоколом SSL2. В нем имеются серьезные криптографические дефекты.
□ Не полагайтесь на то, что используемая вами библиотека для работы с SSL/TLS надлежащим образом выполнит все проверки, если только речь не идет о протоколе HTTPS.
□ Не ограничивайтесь проверкой одного лишь имени (например, в поле DN), записанного в сертификате. Кто угодно может создать сертификат и вписать туда произвольное имя.
Стоит подумать
□ О применении протокола OCSP для проверки сертификатов в цепочке доверия, чтобы убедиться, что ни один из них не был отозван.
□ О загрузке свежей версии CRL–списка после окончания срока действия текущего и об использовании этих списков для проверки сертификатов в цепочке доверия.
Грех 11. Использование слабых систем на основе паролей