Как распознать поддельные сертификаты SSL?

TL; DR резюме:

срок действия сертификата сервера устанавливается:

• проверка имени хоста
• проверка подписей всей цепочки сертификатов
• выполнение дополнительных проверок метаданных для каждого сертификата
• проверка состояния отзыва каждого из задействованных сертификатов
• проверка самоподписанный корневой сертификат в цепочке между сертификаты, которым доверяют по умолчанию

объяснение

предположим, вы хотите подключиться к https://mail.google.com (Вы можете попробовать это в своем браузере!).

(реальный) сервер ответит сертификатом, который выдается mail.google.com, т. е. в поле "Тема" сертификата вы найдете общее имя (CN) 'mail.google.com-cf. RFC 5280 для получения подробной информации о полях сертификатов. Дело в том, что субъект ссылка на URL-адрес сайта очень важна для безопасности всей модели, и она активно проверяется вашей реализацией TLS ("проверка имени хоста"), потому что в противном случае было бы место для атак "человек в середине". Т. е. кто-то может получить действительный сертификат и выдать себя за mail.google.com без твоего внимания.

в дополнение к проверке имени хоста ваша реализация TLS также проверит "действительность" сертификата. Этот вся процедура довольно сложна и включает в себя проверку достоверности сертификата, но дополнительно будет проверено много других вещей, более того, через минуту.

Если вы просмотрите сертификат Google Mail в своем браузере, вы заметите, что на самом деле три сертификаты показали:

• mail.google.com
• Thawte и ЮГК СА
• Класс 3 Основной Центр Сертификации (Компания VeriSign)

модель заключается в том, что есть несколько (Ну, к сожалению, уже не так мало) доверенных корневых центров сертификации ("root CAs"), которые вы можете выбрать самостоятельно или (что более вероятно), которые предварительно настроены с вашим программным обеспечением (например, браузер), которым слепо доверяют. Эти доверенные органы формируют якоря всей модели доверия " PKI " (инфраструктура открытого ключа). Основная идея заключается в том, что доверенные лица могут выдавать сертификаты другим органам и предоставить им разрешение на повторную выдачу сертификатов (эти органы называются промежуточными центрами сертификации). Промежуточный ЦС может снова рекурсивно применять эту процедуру до определенного момента, количество промежуточных ЦС между фактическим сертификатом конечной сущности и корневым сертификатом ЦС обычно ограничено.

в какой-то момент промежуточный ЦС выдаст сертификаты " конечной сущности "("mail.google.com" в нашем примере). Теперь процесс выдачи сертификат фактически означает, что сторона, запрашивающая сертификат, сначала создаст пару открытого и закрытого ключей и использует их для проверки подлинности запроса сертификата, отправленного в центр сертификации. Центр выдачи создает сертификат для подчиненного объекта (промежуточного ЦС или конечного объекта) путем "подписания" этого сертификата с использованием собственного закрытого ключа с использованием асимметричного алгоритма, такого как RSA, и путем дополнительного включения открытого ключа запрашивающей стороны в вновь созданный сертификат. Корневой ЦС обладает так называемым самозаверяющим сертификатом, т. е. корневой ЦС является единственным органом, который может подписывать собственный сертификат и включать собственный открытый ключ. Конечно, закрытый ключ всегда остается скрытым.

рекурсивный характер процесса выдачи сертификата подразумевает, что для каждого конечного сертификата сущности существует уникальный способ создания "цепочки" сертификатов, которая ведет к корневому центру сертификации. Теперь, когда вы при попытке подключения к сайту, защищенному TLS, предоставляется сертификат конечной сущности. следующая процедура будет применяться рекурсивно до тех пор, пока вы не получите корневой сертификат CA:

• найдите сертификат органа, выдавшего сертификат для проверки (Подробнее см. RFC 5280). Если ничего не найдено: выход с ошибкой.
• возьмите открытый ключ сертификата выдачи и проверьте подпись сертификата, который должен быть проверен, используя это открытый ключ.
• проверьте много дополнительных вещей, таких как, не истек ли срок действия сертификата, или он еще не действителен, "ограничения политики", "ключевые обычаи", "расширенные ключевые обычаи"... (опять же, кровавые детали находятся в RFC).
• статус отзыва сертификата (подробнее об этом позже)

Если все проверки были положительными, вы в конечном итоге получите самозаверяющий сертификат, т. е. где субъект также является эмитентом (например, VeriSign сертификат в нашем примере). Теперь последнее, что вам нужно проверить, является ли этот сертификат среди тех, которым вы слепо доверяете: если это так, все хорошо, и соединение будет успешным, если это не так, попытка подключения будет отклонена.

как будто это было недостаточно сложно, описанные до сих пор проверки не обрабатывают случаи, когда однажды действительные сертификаты внезапно становятся изгоями, примерами являются случаи, когда сертификат украден или закрытые ключи скомпрометированы (думаю, Comodo и DigiNotar, и). В этих случаях обычной процедурой является "отзыв" этих сертификатов, которые испортились, то есть вы хотите пометить их как недействительные, начиная с определенного момента времени (они все равно истекут в какой-то момент, но в течение оставшейся части этого периода они уже будут отмечены как недействительные). Для этих случаев CAs имеют возможность выдавать CRLs (каталог сертификатов, объявленных недействительными) или ответы OCSP (информация для одного или в редких случаях набор сертификаты), который предоставляет клиентам информацию о том, был ли данный сертификат помечен как недействительный или нет. Состояние отзыва необходимо проверить для всех сертификатов в цепочке, если один из них помечен как недопустимый, то сертификат конечного объекта не может быть доверенным, и соединение также должно быть отклонено.

любой поддельный сертификат вы создаете будет самоподписанный сертификаты.

браузер будет отображать большие страшные предупреждения при подключении к сайту с самозаверяющим сертификатом _{который пользователь будет быстро игнорировать.}

чтобы избежать предупреждений, вам нужен сертификат, подписанный центром сертификации, которому браузер доверяет, например VeriSign.
Эти компании будут ^{надеюсь} убедитесь, что вы действительно владеете домен для сертификата, который они подписывают.

Re:редактировать: создать несамозаверяющий сертификат можно только в том случае, если он подписан доверенным центром сертификации.
Они откажутся подписать сертификат на другой предмет.

сертификаты работают, потому что они следуют цепи доверия. Сертификаты имеют цепочку из одного или нескольких эмитентов, которым доверяют; эта цепочка является основой того, почему она вообще работает. Браузеры и почти все библиотеки сертификатов SSL делают эту проверку цепочки или, по крайней мере, предоставляют возможность.

самозаверяющие сертификаты (или те, которые выдаются цепочками, которые заканчиваются самозаверяющим сертификатом) не пройдут эту проверку.