Как браузер проверяет ssl сертификат

Обновлено: 07.07.2024

Как именно это сделано?
А как насчет процесса делает его невосприимчивым к атакам «человек посередине»?
Что мешает случайному человеку настроить собственную службу проверки для использования в атаках типа «человек посередине», чтобы все «выглядело» защищенным?

Вот очень упрощенное объяснение:

Ваш веб-браузер загружает сертификат веб-сервера, который содержит открытый ключ веб-сервера. Этот сертификат подписан закрытым ключом доверенного центра сертификации.

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

Сертификат содержит имя домена и / или IP-адрес веб-сервера. Ваш веб-браузер подтверждает в центре сертификации, что адрес, указанный в сертификате, является тем, к которому он имеет открытое соединение.

Обратите внимание, что центр сертификации (ЦС) имеет важное значение для предотвращения атак «человек посередине». Однако даже неподписанный сертификат не позволит пассивно прослушивать ваш зашифрованный трафик, поскольку у него нет возможности получить доступ к вашему общему симметричному ключу.

На шаге 1.5 сервер также «подписывает» что-то с помощью закрытого ключа, связанного с его сертификатом. Это объединяется с проверкой имени / IP, чтобы гарантировать, что только сайт-владелец сертификата представляет его. Я не знал, что мой браузер установлен с открытыми ключами всех основных центров сертификации. Теперь я знаю, как мои SSL-сертификаты проверяются без риска MITM :). Спасибо! Сервер должен запросить сертификат у CAuthority, поэтому он отправляет запрос на него. Как CA может быть уверен, что сервер действителен?

Стоит отметить, что помимо покупки сертификата (как уже упоминалось выше), вы также можете создать свой собственный бесплатно; это называется «самоподписанный сертификат». Разница между самоподписанным сертификатом и купленным сертификатом проста: купленный сертификат был подписан центром сертификации, о котором ваш браузер уже знает. Другими словами, ваш браузер может легко проверить подлинность приобретенного сертификата.

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

Если вы надежно распространяете самозаверяющий сертификат (или сертификат CA, как предложил bobince) и устанавливаете его в браузерах, которые будут использовать ваш сайт , он будет таким же безопасным, как и купленный, и не будет уязвим для человека-посредника. нападения и подделка сертификатов. Очевидно, это означает, что это возможно только в том случае, если только несколько человек нуждаются в безопасном доступе к вашему сайту (например, внутренние приложения, личные блоги и т. Д.).

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

1. Как механизмы проверки статуса сертификатов реализованы в современных Веб-браузерах?
2. ~~Кто виноват?~~ Почему они реализованы именно так?
3. ~~Что делать~~? Какие есть перспективы?

Эта статья будет полезна тем, кому интересно разобраться в применяющихся на практике механизмах проверки статуса сертификатов.

Проверки статуса сертификатов, реализованные в Веб-браузерах

Механизмы проверки статуса сертификатов, реализованные в современных Веб браузерах, представляют собой комбинацию описанных ранее базовых механизмов (CRL, OCSP, OCSP stapling) и их модификаций. Комбинирование базовых механизмов осуществляется с целью обеспечения резервирования: если один из источников информации о статусе сертификата становится недоступным, то используется резервный. Например, в качестве основного механизма проверки статуса сертификатов может использоваться протокол OCSP, однако в случае недоступности или отказа OCSP-сервера будет выполнена более трудоёмкая для клиента загрузка CRL.

Для понимания основной проблемы проверок статуса сертификатов, реализованных в современных браузерах, достаточно рассмотреть следующий сценарий атаки «человек посередине».

Закрытый ключ сервера был скомпрометирован. Владелец сервера отозвал сертификат скомпрометированного ключа, сгенерировал новую пару ключей и получил новый сертификат.
Нарушитель завладел отозванным закрытым ключом и сертификатом сервера. В данном сценарии мы намеренно не говорим, каким образом он это осуществил: в результате компрометации самого сервера или в результате компрометации удостоверяющего центра (УЦ). Это сделано для того, чтобы продемонстрировать, как браузеры поведут себя в обеих ситуациях.

Нарушитель, «человек посередине», контролирует весь трафик, идущий от клиента. Он может перехватывать или блокировать этот трафик, может пытаться отвечать клиенту от имени других сетевых сервисов.

Веб-браузер клиента при попытке установки TLS-соединения с сервером подключается к «человеку посередине». «Человек посередине» представляется сервером, используя отозванный сертификат без прикреплённого OCSP-ответа (a.k.a. OCSP stapling). Нарушитель блокирует запросы, идущие от клиента ко всем OCSP-серверам и точкам распространения CRL (a.k.a. CDP). Также нарушитель блокирует попытки клиента обновить Веб-браузер или его компоненты (например, чёрные списки «CRLSets» или «OneCRL», речь о которых пойдёт позже).

Блокирование «человеком посередине» запросов ко всем OCSP-серверам и точкам распространения CRL, во-первых, поддерживает начальное условие, согласно которому нарушитель мог скомпрометировать, как сервер, так и УЦ, и, во-вторых, наиболее полно демонстрирует проверки статуса сертификатов, выполняемые современными браузерами.

Ниже приводится описание проверок статуса сертификатов, выполняемых различными Веб-браузерами под Windows. Для других платформ детали проверок могут незначительно отличаться.

Mozilla Firefox

Поведение браузера Mozilla Firefox версии 54 (наиболее актуальной на момент написания статьи) при такой атаке отличается в зависимости от типа сертификата сервера: DV или EV. Выпуская DV-сертификат (domain validated), УЦ лишь подтверждает, что владелец ключа, указанного в сертификате, контролирует указанный в сертификате домен. Большинство сертификатов являются DV. EV-сертификат (extended validation) подтверждает не только владение доменом, но и личность владельца домена. Такие сертификаты требуют дополнительных проверок со стороны УЦ, потому они значительно дороже и встречаются реже.

Проверка статуса DV-сертификатов, выполняемая Firefox, описывается следующей диаграммой:

Итак, браузер проверяет статус цепочки сертификатов сервера (сертификатов промежуточных УЦ и сертификата самого сервера). Для проверки статуса сертификатов промежуточных УЦ используется хранящуюся локально на клиенте черный список «OneCRL», содержащий информацию об отозванных сертификатах, собранную из различных точек распространения CRL. Актуальность состояния чёрного списка поддерживается с помощью агрегатора CRL, отдельного удалённого сервиса, работающего следующим образом:

1. Агрегатор периодически опрашивает некоторый набор точек распространения CRL.
2. Из полученных CRL выбирает наиболее критичную информацию об отозванных сертификатах (например, сертификаты, отозванные из-за компрометации закрытого ключа).
3. Обновляет на основе этой информации в чёрные списки в браузерах.

Агрегатор CRL и, как следствие, содержимое чёрного списка «OneCRL» контролируется Mozilla. «OneCRL» не покрывает все отозванные сертификаты, а лишь сертификаты некоторых промежуточных УЦ и небольшое количество сертификатов серверов. Это делается с целью сокращения размера чёрного списка. Текущий список «OneCRL» можно посмотреть тут.

Важно, что если ни один из источников информации о статусе сертификата не доступен, то сертификат не считается отозванным. Иначе говоря, проверка осуществляется в режиме soft fail. Таким образом, атака «человек посередине» проходит успешно. При этом не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.

В дополнение стоит отметить, что клиентская часть протокола OCSP, реализованная в Firefox, не поддерживает одноразовые случайные коды (nonce) и, следовательно, OCSP-ответы не защищены от атак повторного воспроизведения.

Аналогичная ситуация возникает и при проверке EV-сертификатов. Разница заключается лишь в том, что браузер дополнительно выполняет OCSP-запросы и для сертификатов промежуточных УЦ:

Изменить поведение браузера и включить режим hard fail (т.е., запрет установки TLS-соединения в случаях, когда информация о статусе сертификата недоступна) можно, установив в настройках браузера («about:config») параметр «security.OCSP.require» в значение «true»:

Следует отметить, что данная настройка не активирует использование протокола OCSP для сертификатов промежуточных УЦ в случаях, когда сервер предъявляет DV-сертификат.

Для конечного пользователя hard fail в Firefox выглядит так:

Отметим, что атака «человек посередине» всё ещё возможна. Нарушителю требуется провести атаку повторного воспроизведения OCSP-ответа, переслав «старый» OCSP-ответ, сгенерированный ещё до того, как сертификат был отозван. Однако проводить эту атаку можно только до тех пор, пока срок действия «старого» OCSP-ответа не истечёт. При этом срок действия OCSP-ответа может быть достаточно велик. Нередко он бывает равен неделе.

Microsoft Internet Explorer/Edge

Браузеры Microsoft Internet Explorer версии 11 и Microsoft Edge версии 40 ведут себя одинаково для DV- и EV-сертификатов:

Проверка также выполняется в режиме soft fail. Таким образом, атака «человек посередине» также проходит успешно и также не имеет значения, чей ключ был скомпрометирован изначально, ключ самого сервера или УЦ.

Изменить поведение Internet Explorer возможно, например, установив значение ключа реестра «HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Internet Explorer \ Main \ FeatureControl \ FEATURE_WARN_ON_SEC_CERT_REV_FAILED \ iexplore.exe» равным 1. Тогда при отсутствии информации о статусе сертификата соединение всё равно будет разрешено, однако в адресной строке будет появляться небольшое предупреждение:

Для Edge подобных настроек не нашли.

Google Chrome/Cromium

Браузеры Google Chrome и Chromium версии 59 при проверке DV-сертификатов ведут себя следующим образом:

Проверки, выполняемые Chrome похожи, на те, что выполняет Firefox, с тем исключением, что в Chrome вообще отказались от выполнения OCSP-запросов при проверке DV-сертификатов. «CRLSets» в Chrome является аналогом «OneCRL» в Firefox (строго говоря, механизм «CRLSets» появился даже раньше) и обладает теми же проблемами неполноты и неподконтрольности конечному пользователю.

OCSP-запросы используются при проверке EV-сертификатов (тут картина становится практически идентичной той, что мы наблюдали для Firefox):

Изменить поведение Chrome и Chromium возможно внесением изменений в групповую политику (инструкция здесь) и включением следующих опций:

Эквивалентная настройка возможна и под Linux (здесь).

Прочие браузеры и платформы

Для других популярных браузеров и платформ ситуация такая же: везде проверки статуса сертификатов выполняются в режиме soft fail, либо не выполняются вовсе. Подробнее можно почитать тут или тут.

Почему сейчас всё работает именно так?

Об этом хорошо написано в блоге Адама Лэнгли. Отсутствие hard fail и отказ от явного выполнения OCSP-запросов на стороне клиента обусловлены следующими факторами:

Какие есть перспективы?

Очевидный вывод из всего сказанного ранее: проверки статуса сертификатов в браузерах не работают, и это не новость. При этом просто взять и перейти на hard fail нельзя по объективным причинам.

Есть ли применимое на практике решение данной проблемы? Проанализировав и собрав воедино множество уже предложенных частичных решений данной проблемы (в частности расширение сертификатов «TLS feature», сертификаты с коротким сроком действия, агрегаторы CRL и др., о чём подробно будет рассказано ниже), предлагаем вашему вниманию наше представление о том, как проверка статуса сертификатов должна происходить на практике.

В основе лежит утверждение о том, что не для всех сервисов требуется онлайн-проверки статуса сертификатов. Для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски, связанные с атакой «человек посередине» с использованием отозванных сертификатов. Иначе говоря, с точки зрения проверки статуса сертификатов, сервисы делятся на два типа:

1. Меньшинство, для которого будут проводиться строгие онлайн-проверки статуса сертификатов в режиме hard fail.
2. Большинство, для которого онлайн-проверки статуса сертификатов не будут выполняться вовсе (будут предприниматься другие меры по защите).

Браузеры могут различать такие сервисы по наличию специального расширения в сертификате сервера. В зависимости от типа сервиса клиент либо будет выполнять «параноидальную» проверку статуса сертификатов, либо не будет выполнять её вовсе. Теперь подробнее о каждой из этих двух схем.

Параноидальная схема проверки статуса сертификатов для меньшинства

В 2015 году вышла спецификация нового расширения сертификатов стандарта X.509, называемого «TLS feature» (на ранних этапах разработки стандарта также известное, как «OCSP must staple»). Это расширение сертификата позволяет зафиксировать в сертификате те опции протокола TLS, которые TLS-сервер, предъявляющий данный сертификат, обязуется поддерживать. Такой опцией протокола TLS в частности являются прикреплённые OCSP-ответы. Пример сертификата с таким расширением схематически изображён ниже:

В сертификате присутствует расширение «TLS Feature» (выделено красным), сообщающее о том, что TLS-сервер обязан поддерживать прикреплённые OCSP-ответы, специфицированные в RFC 6066 («Status Request (Version 1)»), и более новую версию данной опции («Status Request (Version 2)»), специфицированную в RFC 6961 — множественные прикреплённые OCSP-ответы. Новая версия данной опции протокола TLS позволяет прикреплять OCSP-ответы и для сертификатов промежуточных УЦ.

Поскольку мы строим «параноидальную» схему проверки статуса сертификатов, то в дополнение к использованию сертификатов с расширением «TLS Feature», следует также отметить следующее:

1. Прикреплённые OCSP-ответы должны быть защищены от атаки повторного воспроизведения (должны использоваться случайные одноразовые коды). Даже при использовании сертификатов с таким расширением у нарушителя остаётся окно для атаки, определяемое сроком действия OCSP-ответа: всё ещё возможно провести атаку повторного воспроизведения и прислать клиенту старый OCSP-ответ, полученный ещё до того как сертификат был отозван.
2. Должна использоваться опция «Status Request (Version 2)». Эта опция позволяет прикреплять OCSP-ответы для всех сертификатов в цепочке, а не только для сертификата сервера. Это позволяет вовсе отказаться от явного выполнения OCSP-запросов на стороне клиента и всех присущих ему и описанных ранее недостатков.

Итак, в сухом остатке, «параноидальная» схема проверки статуса сертификатов основана на следующем:

TLS-сервер использует сертификат с расширением «TLS Feature», обязывающем сервер поддерживать опции протокола TLS «Status Request (Version 1)» и «Status Request (Version 2)»;
TLS-клиент и TLS-сервер должны использовать прикреплённые OCSP-ответы, защищённые случайными одноразовыми кодами от атаки повторного воспроизведения;
если TLS-клиент поддерживает опцию «Status Request (Version 1)», но не поддерживает опцию «Status Request (Version 2)», то получив от сервера сертификат с расширением «TLS Feature», он должен явно выполнить OCSP-запросы (с использованием случайных одноразовых кодов) для сертификатов промежуточных УЦ в режиме hard fail.

увеличение нагрузки на OCSP-серверы УЦ;
уязвимость к DDoS атакам на серверы УЦ.

В качестве решения второй проблемы на сервере можно попеременно использовать несколько сертификатов, выпущенных независимыми УЦ. В таком случае пока OCSP-серверы одного УЦ будут «лежать» из-за DDoS, TLS-сервер будет использовать альтернативный сертификат, выпущенный другим УЦ, не находящимся под атакой. Использование нескольких сертификатов также позволит балансировать нагрузку между УЦ.

Для того, чтобы оценить, насколько клиентская сторона (под Windows) готова к переходу в светлое будущее, можно взглянуть на следующую таблицу:

Схема для большинства

Как было сказано ранее, для большинства сервисов накладные расходы, связанные с обеспечением строгих онлайн-проверок статуса сертификатов в режиме hard fail, не окупают риски связанные с атакой «человек посередине» с использованием отозванных сертификатов. В таком случае лучше не защищаться от данной атаки, а максимально сократить временной промежуток, в течение которого проведение данной атаки будет возможным. Для этого используются сертификаты с коротким сроком действия (например, 1-2 дня).

Таким образом, большинство сервисов будет использовать сертификаты без расширения «TLS Feature», но с коротким сроком действия. Для таких сертификатов онлайн-проверки статуса сертификатов не будут выполняться вовсе. Вместо этого будет проводиться частое обновление быстро устаревающих сертификатов.

Добавим, что использование сертификатов с коротким сроком действия эквивалентно использованию сертификатов с расширением «TLS Feature», обязывающим использовать прикреплённые OCSP-ответы, вместе с прикреплёнными OCSP-ответами, не защищёнными от атаки повторного воспроизведения (т.е. OCSP-ответами, кэшируемыми на стороне TLS-сервера). При этом сертификаты с коротким сроком действия чуть более эффективны с точки зрения экономии трафика и количества операций, необходимых для проверки сертификата.

Подход с использованием сертификатов с коротким сроком действия обладает целым рядом достоинств, однако малопригоден для сертификатов УЦ. Для проверки статуса таких сертификатов можно использовать периодически обновляемые чёрные списки аналогичные «CRLSets» и «OneCRL», но предоставляющие пользователям больший контроль на агрегаторами CRL. Пользователи, например, должны иметь возможность добавлять новые опрашиваемые точки распространения CRL. Это важно, поскольку некоторые организации разворачивают собственные не публичные УЦ для внутреннего использования. Решением может стать возможность использования приватных агрегаторов CRL. При этом понадобится разработать открытый протокол взаимодействия клиента и агрегатора CRL, обеспечивающий совместимость клиентов и агрегаторов различных вендоров.

Итог

Что ж, пока что всё не очень хорошо: проверки статуса сертификатов в современных браузерах действительно не работают.

Однако свет в конце тоннеля всё же есть, и ситуация постепенно, хотя и медленно, движется к лучшему.

Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.

Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.

/ Flickr / David Goehring / CC-BY

SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.

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

Рукопожатие

Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.

Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.

Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.

Алгоритмы шифрования

Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.

Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.

Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.

Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.

DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.

ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.

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

Хеш и MAC

Цель хеш-алгоритма — преобразовывать все содержимое SSL-сертификата в битовую строку фиксированной длины. Для шифрования значения хеша применяется закрытый ключ центра сертификации, который включается в сертификат как подпись.

В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.

Сертификаты бывают разные

Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.

Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.

Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.

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

Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.

Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.

> спасибо. а можно в двух словах суть? верно ли что сертификаты от
> центров нужны только чтобы удостовериться что DNS выдал верный IP и
> мы попали на реальный сайт, а не фишинговый?
Cертификат выдает не Центр. Сертификат выдает сервер (который ДО этого получил сертификат у CA - за определенные деньги), клиент же, получив сертификат, шлет запрос одному из CA (который указана в сертификате) на получение подтверждения, что сервер, который выдал сертификат является именно тем, за кого себя выдает. Собственно, на этом построен бизнес этих самых CA. На одном из таких (Thawte) небезызвестный Шаттлворт сделал очень большие деньги. Потом он продал бизнес не менее известной VeriSign. Простите за оффтоп.
Думаю, так. :) Или надо еще подробнее? Более подробнее - не интересовался. На всякий случай замечу, что есть еще самоподписанные сертификаты. Сгенерированные на самом сервере и не подписанные CA. Доверять им или нет - личное дело пользователя.

> это я все знаю, это и так понятно. вопрос как технически это
> происходит? в чем защита? ведь клиент не получает закрытого ключа, он
> получает данные доступные любому, кто зашел на сайт, и если сайт
> поддельный то он даст те же данные сертификата, и браузер запросив
> подтверждение у CA так же получит положительный ответ.
> В же чем защита?
Уже всё разъяснили, попробую ещё проще.
Сервер присылает свой сертификат, в котором помимо своего открытого ключа есть цифровая подпсь CA, где закрытым ключем CA зашифровано: "Верь, Вася. Это в самом деле ключ сайта pupkin.ru"
Клиент в своей базе находит открытый ключ CA и расшифровывает эту сигнатуру.

>> спасибо. а можно в двух словах суть? верно ли что сертификаты от
>> центров нужны только чтобы удостовериться что DNS выдал верный IP и
>> мы попали на реальный сайт, а не фишинговый?
> Cертификат выдает не Центр. Сертификат выдает сервер (который ДО этого получил
> сертификат у CA - за определенные деньги), клиент же, получив сертификат,
> шлет запрос одному из CA (который указана в сертификате) на получение
> подтверждения, что сервер, который выдал сертификат является именно тем, за кого
> себя выдает.
ну и зачем вводить в заблуждение?
Клиент, получив сертификат, используя имеющуюся у себя базу корневых сертификатов, проверяет валидность сертификата. Валидность - это степень доверия, определяется, действительно ли подписан ли полученный сертификат корневым или нет. Если подписан, то тогда "типа да, доверяем".
Кроме этой проверки, есть еще проверка на отозванность сертификата, которая да, осуществляется путем отправки запроса на получение списка CRL - certificate revocation list-а, т.е. списка отзыва сертификатов. При этом полученный сертификат не должен быть отозван, отозван - значит не действителен, не доверяем.
> Собственно, на этом построен бизнес этих самых CA.
Кроме денег за выдачу, ЦА может брать деньги за отзыв сертификата (за размещение в CRL) =)

> На одном из таких (Thawte) небезызвестный Шаттлворт сделал очень большие деньги. Потом
> он продал бизнес не менее известной VeriSign. Простите за оффтоп.
> Думаю, так. :) Или надо еще подробнее? Более подробнее - не интересовался.
> На всякий случай замечу, что есть еще самоподписанные сертификаты. Сгенерированные на
> самом сервере и не подписанные CA. Доверять им или нет -
> личное дело пользователя.

> ну и зачем вводить в заблуждение?
> Клиент, получив сертификат, используя имеющуюся у себя базу корневых сертификатов, проверяет
> валидность сертификата. Валидность - это степень доверия, определяется, действительно
> ли подписан ли полученный сертификат корневым или нет. Если подписан, то
> тогда "типа да, доверяем".
Я правильно понял Вашу мысль? То есть - клиент ВООБЩЕ не обращается к CA, у которого запрашивает достоверность полученного сертификата? А сравнивает с некой своей базой сертфикатов, хранящихся у самого клиента (в браузере)? По-моему, Вы не правы. Но спорить не буду - просто не интересовался подробностями.

>> ну и зачем вводить в заблуждение?
>> Клиент, получив сертификат, используя имеющуюся у себя базу корневых сертификатов, проверяет
>> валидность сертификата. Валидность - это степень доверия, определяется, действительно
>> ли подписан ли полученный сертификат корневым или нет. Если подписан, то
>> тогда "типа да, доверяем".
> Я правильно понял Вашу мысль? То есть - клиент ВООБЩЕ не
> обращается к CA, у которого запрашивает достоверность полученного сертификата? А сравнивает
> с некой своей базой сертфикатов, хранящихся у самого клиента (в браузере)?
> По-моему, Вы не правы.
сначала проверяет по внутренней базе.
а иначе откуда он будет знать, как обратиться к СА ?
> Но спорить не буду - просто не интересовался подробностями.
обращается за проверкой по CRL.

> сначала проверяет по внутренней базе.
> а иначе откуда он будет знать, как обратиться к СА ?
Список CA есть в каждом браузере - называются CTL - Certificate Trust Lists. Оттуда и знает. Кроме того - имя CA есть в самом сертификате, который посылает сервер на этапе хэндшейкинга (первичной фазы SSL-сеанса).
> обращается за проверкой по CRL.
CRL - проверка не действенность (неотозванность) сертификата - всего лишь одна из фаз проверки. В описании выше я о ней не указал - согласен. :) Просто забыл.

Дядь Федор.
Открытые ключи CA общеизвестны и хранятся локально в браузере и/или ОС, поэтому для проверки подписи CA обращаться к нему лично нет необходимости и браузеры обычно этого не делают. Тобиш, SSL будет работать, даже если сам CA недоступен.

Остается упомянутый выше механизм CRL. ;) Вот тут уж никуда без запроса.

Читайте также: