Принцип работы протокола SSL/TLS основан на криптографии с открытым ключом. Одна или обе стороны взаимодействия обладают сертификатами и соответствующими закрытыми ключами. Это позволяет производить аутентификацию и шифрование трафика.

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

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

Производить криптографические операции для осуществления аутентификации и шифрования можно было бы имея только ключевую пару. Но тогда возникают трудности с распространением открытых ключей и доверием к ним. Каждая сторона взаимодействия будет вынуждена как-то убедиться, что определенный открытый ключ соответствует конкретному субъекту. То есть нужно получить ключ по доверенному каналу, иначе как убедиться, что перед нами не злоумышленник? Тут на помощь приходят сертификаты. Они представляют собой подписанный электронной подписью набор данных, в том числе информацию о субъекте и его открытый ключ. Самое важное, что делает сертификат — удостоверяет, что его владелец (субъект) обладает парой к открытому ключу — закрытым ключом.

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

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

Сертификат для домена

Владельцы доменов получают сертификаты для того, чтобы их веб-сайт был доступен пользователям по HTTPS, что позволяет пользователям быть уверенными в защите трафика до веб-сервера и в том, что веб-сервер не является мошенническим. В качестве удостоверяющего центра, выпускающего сертификат, выбирается такой, который является доверенным для большинства браузеров. Тогда у посетителей сайта не будет предупреждений безопасности. Перед подписью сертификата удостоверяющий центр проверяет, что к нему обращается владелец домена. Для этого УЦ может отправить ссылку на технический email для этого домена или, например, попросить разместить на веб сервере определенный файл. Более строгая проверка владельца домена требуется для сертификатов с расширенной проверкой — Extended Validation Certificate.

Проблемы выпуска сертификатов

Существуют примеры, когда удостоверяющие центры выпускали сертификаты для доменов без разрешения владельцев этих доменов:

• IT-менеджер из Финляндии зарегистрировал такие алиасы к своему почтовому ящику: hostmaster@live.fi, security@live.fi и hostmaster@hotmail.fi. Позже ему удалось получить сертификат для домена live.fi.
• Удостоверяющий центр CNNIC выдал сертификат промежуточному центру сертификации, который использовал его для организации man-in-the-middle в локальной сети. Генерация валидных сертификатов для посещаемых веб-сайтов происходила на лету.
• При проведении внутреннего тестирования Symantec выпустил сертификаты для нескольких доменов, в том числе для google.com и www.google.com

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

Имея на руках сертификат (и закрытый ключ) от чужого домена, можно организовать атаку man-in-the-middle и не привлекать внимания всякими сообщениями об ошибках, ведь сертификат для домена хоть и нелегальный, но с точки зрения браузера — действительный и не вызывает подозрения.

Certificate Transparency

Итак, мы подошли к тому, что владелец домена не всегда в курсе какие сертификаты выпущены для его домена. Проект Certificate Transparency (CT) призван избавиться от этого недоразумения.

Certificate Transparency – экспериментальный открытый IETF стандарт и open source проект, инициатором которого является Google.

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

При использовании Certificate Transparency, информация о каждом выпущенном сертификате записывается в лог (Certificate log) доступный только для записи и открытый для публичного аудита. Этот лог не позволяет менять или удалять записи, а допускает только их добавление. Любой может получить доступ к логу и получить информацию о выпущенных сертификатах. На данный момент уже существует несколько таких логов. Постоянный мониторинг этих логов позволит отследить выпуски всех сертификатов для домена и не пропустить ошибочный. Чтобы лог был доступен только на добавление записей, используется древовидное хэширование, иначе называемое дерево Меркла. Это позволяет проверить, что любая более новая версия лога включает в себя любую предыдущую версию. Сам лог должен быть подписан электронной подписью, точнее подписывается хэш корня дерева Меркла для лога.

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

Существует три разных способа сообщить клиенту о подписанном штампе времени:

• Добавление штампа времени в расширении X.509v3 сертификата. В таком случае веб-сервер не требует каких-либо изменений. Удостоверяющий центр отправляет так называемый пре-сертификат на лог сервер, получает в ответ подписанный штамп времени и только после этого выпускает сертификат. Хотя сам по себе пре-сертификат благодаря специальному расширению не может пройти валидацию на клиенте, его выпуск удостоверяющим центром означает обещание выпустить реальный сертификат. Поэтому некорректный выпуск пре-сертификата приравнен к некорректному выпуску сертификата.
• Передача штампа времени в расширении TLS signed_certificate_timestamp. Тогда на веб-сервере требуются изменения, чтобы он начал поддерживать такое расширение.
• Через механизм OCSP Stapling. Для этого удостоверяющий центр выпускает сертификат и одновременно с передает его в лог-сервер. Затем веб-сервер делает OCSP-запрос и получает от удостоверяющего центра ответ с подписанным штампом времени.

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

Еще одна роль в Certificate Transparency – аудитор (Certificate auditor). Он берет частичную информацию о логе и проверяет, что эта информация соответствует другой имеющейся частичной информации, то есть убеждается в правильном поведении лога и его криптографической последовательности. Вторая задача аудитора — убедиться, что конкретный сертификат появился в логе. Аудитором может быть как браузер клиента, так и сторонний сервис. Функции аудита может выполнять и наблюдатель.


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

С начала 2015 года браузер Chrome требует поддержку CT для EV-сертификатов. Так, например, сейчас выглядит адресная строка для одного и того же домена в Firefox и Chrome.


Если посмотреть детали соединения, то видно, что для этого сертификата нет CT информации.
В браузере Firefox также планируется поддержка технологии Certificate Transparency. А вот Microsoft идет своим путем и развивает другую технологию. Начиная с IE11 встроенный фильтр SmartScreen собирает информацию о сертификатах, посещенных веб-страниц. Эти данные могут быть использованы для поиска необычных сертификатов, например:

• Веб-сайт использует сертификат, предназначенный для подчиненного удостоверяющего центра
• Неожиданное использование другого сертификата для посетителей определенного региона
• Существенные изменения в полях сертификатов, выпускаемых определенным удостоверяющим центром. Например, изменение или отсутствие ссылки на OCSP.

В общем, подход Microsoft более закрытый, во многом направленный на своих пользователей. Не буду особо его комментировать, так как тема не об этом.

Заключение

Хотя стандарт пока еще экспериментальный, это не мешает его постепенному применению. Как удостоверяющие центры, так и производители браузеров уже частично начали поддерживать Certificate Transparency или хотя бы заявили о своем участии. Компании получат инструмент за контролем над удостоверяющими центрами и смогут быстро выявить «нехорошие» сертификаты. Удостоверяющие центры будут еще более ответственно подходить к выпуску сертификатов. Не стоит полагаться на Certificate Transparency как на панацею, но усложнить деятельность злоумышленников определенно удастся.