JEP draft: Certificate Transparency

Аннотация

Поддержать Certificate Transparency (CT) в JSSE в соответствии с RFC 6962 и разделом 4.4.2.1 RFC 8446.

Критерии успеха

Критерии успеха для функции CT различаются для клиента и сервера:

• клиент: клиент JSSE должен уметь получать и проверять Signed Certificate Timestamps (SCT, подписанные метки времени сертификатов) при всех трёх способах доставки: SCT, встроенные в серверный сертификат TLS, SCT, переданные в TLS-расширении signed_certificate_timestamp, и SCT, включённые в прикреплённые (stapled) ответы OCSP. Проверка должна включать как позитивные, так и негативные тесты.
• сервер: сервер должен уметь принимать запросы от клиентов, поддерживающих CT, и доставлять SCT через серверный сертификат TLS, через прикреплённый ответ OCSP или через TLS-расширение.

Мотивация

Certificate Transparency решает задачу обнаружения ошибочно выпущенных сертификатов. Цепочки сертификатов добавляются в публичные журналы. Владельцы сертификатов могут проверять эти журналы, чтобы убедиться, что все последующие сертификаты, записанные в журнал для интересующих их доменов, легитимны. RFC 6962 описывает применение CT для серверных сертификатов TLS, выпущенных публичными удостоверяющими центрами (CA).

На сегодняшний день поддержку CT реализовало большинство браузеров, и большинство библиотек TLS поддерживают проверку SCT как минимум на стороне клиента, а некоторые и на стороне сервера. Проверка данных SCT во время TLS-рукопожатия — полезная функция безопасности для TLS, и JSSE следует реализовать её, чтобы не отставать от других реализаций TLS.

Описание

Эта функция будет предоставлена в реализации TLS SunJSSE. Задачи по реализации поддержки CT будут различаться для клиентской и серверной ролей:

Сторона клиента:

Клиент JSSE должен уметь принимать SCT всеми тремя способами, описанными в спецификации. Это:

1. из расширения signed certificate timestamp list, встроенного в серверный сертификат TLS X.509;
2. из расширения signed certificate timestamp list в прикреплённом ответе OCSP. Для этого способа доставки требуется, чтобы для TLS-рукопожатия было включено прикрепление OCSP (OCSP stapling) (подробнее об OCSP stapling см. JEP 249);
3. из TLS-расширения, которое заявляется в сообщении ClientHello и доставляется клиенту либо в ServerHello (для версий TLS <= TLSv1.2), либо в сообщении Certificate (TLSv1.3).

SCT могут доставляться из нескольких источников и будут собраны до проверки подписей меток времени. Критерии прохождения проверки SCT (например, число требуемых действительных/доверенных SCT и т. д.) пока не определены. Если клиент не достигает минимального порога для прохождения проверки SCT, будет отправлено оповещение TLS (alert) и соединение будет закрыто. Мы можем решить пропускать проверки SCT, если сервер предъявляет старые сертификаты TLS, выпущенные до определённой даты отсечения. Разрешать ли такой пропуск и какой будет дата отсечения для него, пока не определено. Мы также можем решить не применять требования проверки SCT для непубличных удостоверяющих центров.

Хранение и загрузка доверенных журналов: по умолчанию журналы не являются доверенными и обычно предоставляют ключи RSA или ECC, которыми подписываются SCT. Эти ключи должны быть известны клиенту, и нужно определить механизм их хранения. Это может быть сделано через расширения класса Keystore, класса X509ExtendedTrustManager или каким-либо другим способом. Пока это не определено.

Наконец, на клиенте всю функцию можно включить или отключить с помощью системного свойства jdk.tls.client.enableCertTransparency. По умолчанию для клиента оно будет иметь значение true.

Сторона сервера:

Серверы JSSE автоматически поддерживают доставку SCT через сертификаты X.509, и для этого способа изменения в JSSE не требуются. Точно так же на сервере уже есть поддержка OCSP stapling, поэтому для доставки SCT через прикреплённые ответы OCSP изменения не требуются. Мы можем решить поддержать TLS-расширение signed_certificate_timestamp на стороне сервера. Для этого потребуются изменения в коде рукопожатия: обработка расширения в ClientHello и размещение расширения либо в сообщении ServerHello (версии <= TLSv1.2), либо в сообщении Server Certificate (TLSv1.3). Нам также нужно будет исследовать способ кэширования SCT, чтобы их можно было эффективно получать по мере необходимости. Наконец, будет системное свойство jdk.tls.server.enableCertTransparency, по умолчанию true, которое позволяет включить или отключить поддержку TLS-расширения. Его отключение не помешает доставке SCT клиенту через OCSP stapling или через предъявление сертификата X.509.

Тестирование

Чтобы убедиться, что функция работает правильно, следует провести обширное тестирование. Некоторые виды тестов, которые нужно выполнить, перечислены ниже:

Сторона клиента

• Проверка правильной работы при включённой функции:
  • Заявление расширения signed_certificate_timestamp в сообщении client hello
  • Завершение рукопожатия при предоставлении действительных меток времени SCT
  • Оповещение (alert) и закрытие рукопожатия, если проверки действительности SCT не пройдены
  • Проверка соединения, при котором данные SCT не предоставлены вовсе (должно завершиться неудачей).
  • Проверка загрузки и кэширования доверенных журналов CT
  • Проверка правильного сбора SCT из следующих источников:
    • Сертификат X.509v3
    • Прикреплённые ответы OCSP
    • Данные расширения в TLS Server Hello
• Опускает ли клиент signed_certificate_timestamp в ClientHello при отключённой функции
• Отправляет ли клиент оповещение при отключённой функции, если signed_certificate_timestamp заявлено в сообщении ServerHello? (TLS 1.2 и более ранние версии)

Сторона сервера

• Если реализована функция доставки через TLS-расширение:
  • Проверка ServerHello: signed_certificate_timestamp должно заявляться, только если его заявляет клиент (TLS 1.2 и более ранние версии)
  • Проверка кэширования и загрузки данных SCT: правильно ли закодированы данные в ServerHello?
  • Для TLS 1.3: предоставляются ли SCT в сообщении Server Certificate?

Риски и допущения

Certificate Transparency Version 2.0 — переработанная и улучшенная версия CT. Она всё ещё находится на стадии черновика, но процесс работы над ней далеко продвинулся. Предполагается, что к моменту завершения этого JEP она ещё не успеет стать стандартом. При проектировании классов и интерфейсов для этого JEP следует учитывать архитектуру и требования CT v2.0.

Что не является целью

Некоторые вопросы, связанные с Certificate Transparency, выходят за рамки клиента и сервера JSSE и в рамках этого JEP рассматриваться не будут.

• Реализация монитора журналов CT
• Реализация сервера журналов CT