19 смертных грехов, угрожающих безопасности программ

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

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

Самый лучший способ удостовериться в подлинности сертификата – проверять все без исключения поля, а особенно доменное имя. Оно может находиться в двух полях: 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;

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

Выявление ошибки на этапе анализа кода

Прежде всего найдите все точки входа в приложение из сети. Для каждой точки входа определите, используется ли протокол SSL. API сильно зависит от библиотеки и языка, но поиска по словам «SSL» и «TLS» без учета регистра обычно хватает. Если вы пользуетесь старыми библиотеками Windows, ищите слово «РСТ» (Private Communication Technology – технология защищенной связи), это устаревшая версия предшественника SSLv3, разработанная Microsoft. Если некоторая точка входа не защищена SSL, может возникнуть серьезная проблема!