Отчет о прогнозе изменений отношений в сети при условии широкого внедрения ct




Скачать 222.65 Kb.
Дата04.05.2016
Размер222.65 Kb.
Итоговый отчет о прогнозе изменений отношений в сети при условии широкого внедрения CT

Certificate transparency


Введение


Для обеспечения безопасного обмена данными в сети Интернет широко применяется протокол TLS (RFC 5246). Являясь развитием протокола SSL (первая спецификация относится к 1996 году), протокол призван решать следующие задачи:

  1. Аутентификацию участников коммуникации (по крайней мере сервера, аутентификация клиента применяется гораздо реже)

  2. Организацию защищенного (зашифрованного) канала между участниками коммуникации

  3. Верификацию целостности передаваемых данных (MAC)

Протокол TLS допускает применение разнообразных методов аутентификации участников коммуникации. Наиболее распространенным является метод с использованием X.509-сертификатов. Сертификаты выпускаются удостоверяющим центром (УЦ), который обязан при выпуске сертификата убедиться, что у стороны, подающей заявку на выпуск сертификата, подтверждающего аутентичность того или иного интернет-ресурса (веб-сайта, сервиса) есть полномочия выступать от имени владельца этого ресурса. Способы удостовериться начинаются от контроля за служебным email-адресом в домене (admin, root) и могут предусматривать предъявление документов о праве на распоряжение ресурсом (Extended Validated Certificates).

При использовании этого метода предполагается, что программное обеспечение (ПО), используемое при осуществлении коммуникаций в сети Интернет, проверяет, что X.509-сертификат аутентифицируемого ресурса выпущен одним из явно перечисляемых тем или иным способом удостоверяющих центров. В случае если X.509-сертификат аутентифицируемого ресурса выпущен стороной, не являющейся одним из явно указанных в качестве доверенного удостоверяющих центров, то аутентификация сторон не произойдет. Правильно написанное ПО в такой ситуации прервет установление соединения, и коммуникация не устанавливается (Hard fail). ПО, работающее интерактивно (браузеры) имеет возможность выдать предупреждение пользователю и предложить ему принять решение о продолжении работы (Soft fail). Статистика показывает, что большинство пользователей воспринимает предупреждение как досадную помеху при доступе к запрошенной им информации.

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

По оценкам современного состояния рынка, сейчас существует от 250 до 700 организаций, выпускающих SSL-сертификаты. Эти организации расположены в 57 странах мира (http://queue.acm.org/detail.cfm?id=2673311). 75% выпускаемых сертификатов (их количество оценивается в диапазоне в 1,5 – 2 миллиона ежегодно) выпускаются УЦ, принадлежащими компаниям Symantec, GoDaddy и Comodo, которые владеют рядом брендов.



Одним из ключевых недостатков текущей инфраструктуры доверия в Интернете является то, что любой УЦ может выпустить сертификат, удостоверяющий подлинность любого ресурса. Это означает, что компрометация любого УЦ ставит под сомнение безопасность всей системы доверия в интернете в целом. Кроме того, появляется возможность относительно легко организовать атаки Man-in-the-Middle (MITM).

Атака Man-In-the-Middle

Общее описание


Одна из типичных угроз в случае работы по защищенному протоколу TLS – атака «Man-In-the-Middle» (MITM, https://ru.wikipedia.org/wiki/%D0%A7%D0%B5%D0%BB%D0%BE%D0%B2%D0%B5%D0%BA_%D0%BF%D0%BE%D1%81%D0%B5%D1%80%D0%B5%D0%B4%D0%B8%D0%BD%D0%B5). В случае реализации этой атаки посредник, встраиваясь в коммуникационную цепочку в процессе установления соединения, имперсонирует вторую сторону коммуникации (как правило, сервер), предоставляя правдоподобно выглядящий сертификат. В случае, если сертификат находится в списке доверенных (подписан одним из доверенных удостоверяющих центров, встроенных в систему или добавленных туда злоумышленниками), или пользователь, получив предупреждение от интерактивного ПО, проигнорировал его, злоумышленник получает доступ ко всей коммуникации с выбранным интернет-ресурсом.

Типичные сценарии организации атаки MITM


  1. Некорректно реализованный механизм проверки и построения цепочки доверия. (По данным исследователей, порядка 40% банковских приложений под iOS и Android подвержены уязвимости такого рода).

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

  3. Использование уязвимостей в протоколе (это одна из причин выхода из употребления протокола SSLv2, см. http://tools.ietf.org/html/rfc6176 ) и слабых алгоритмов аутентификации и защиты.

  4. Игнорирование пользователем предупреждений безопасности (http://lorrie.cranor.org/pubs/sslwarnings.pdf ).

Распространение


Атака MITM достаточно трудно отслеживается клиентом и практически не отслеживается сервером. Исследование, проведенное по заказу компании Facebook (https://www.linshunghuang.com/papers/mitm.pdf), использовало для этого специально разработанный Flash Plugin, присылавший на сервер сертификат, полученный при установлении соединения. Из примерно 7 000 000 соединений удалось проверить примерно 3 500 000, сертификат не соответствовал сертификатам Facebook в 6500 случаев (примерно 0,2%), из них бОльшая часть приходилась на легитимные случаи (антивирусное ПО, DLP-системы, системы родительского контроля). При этом трудно сказать, насколько этими результатами можно оперировать в применении к другим, более привлекательным для злоумышленников, ресурсам, например, сайтам банков и электронной коммерции.

Описание инцидентов


Статистика инцидентов за период c 2001 года доступна по адресу http://wiki.cacert.org/Risk/History. За это время произошел по крайней мере один крупный инцидент, связанный с компрометацией доверенного УЦ – голландской компании DigiNotar (https://en.wikipedia.org/wiki/DigiNotar ), более 10 компрометаций партнеров регистраторов (последняя – в 2014 году с индийской компанией, http://googleonlinesecurity.blogspot.com.es/2014/07/maintaining-digital-certificate-security.html ) и была доказана практическая применимость атак на алгоритм MD5 (http://www.win.tue.nl/hashclash/rogue-ca/ ) для создания сертификатов, пригодных для организации атаки MITM. Кроме того, был по крайней мере один случай выпуска доверенным УЦ сертификата, предназначенного для развертывания DLP-системы (http://blog.spiderlabs.com/2012/02/clarifying-the-trustwave-ca-policy-update.html).

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

Вышеперечисленные инциденты показывают актуальность задачи защиты от атаки MITM. Кроме того, принципиальная схема работы инфраструктуры PKI не предусматривает защиты от выпуска любым CA сертификата для любого ресурса.

Описание предлагаемых способов защиты


В настоящий момент существует понимание недостатков текущей инфраструктуры доверия в интернете (изложение, например, по ссылке http://queue.acm.org/detail.cfm?id=2673311),а также предпринимаются попытки решения системных проблем.

Для предотвращения атаки MITM предложено некоторое количество решений. Наиболее распространенные перечислены в этом разделе.



  1. X.509-расширение nameConstraints

  2. DANE и CAA

  3. Certificate Pinning

  4. Accountable Key Infrastructure

  5. Sovereign Keys

X.509-расширение nameConstraints


X.509 extension nameConstraints (http://tools.ietf.org/html/rfc5280#section-4.2.1.10), явным образом перечисляющее, в каких именно доменах могут быть ресурсы, подписанные конкретным УЦ. Это расширение не поддержано в наиболее популярной реализации протокола TLS, библиотеке openssl (http://rt.openssl.org/Ticket/Display.html?id=3502 ), хотя, например, поддерживается браузером Mozilla Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=394919 ).

Эта защита представляется недостаточной для предотвращения атаки MITM, так как не решает проблему принципиально, лишь несколько ограничивая набор сертификатов УЦ для выбора атаки.


DANE и CAA


DANE (http://tools.ietf.org/html/rfc6698 ) и CAA(http://tools.ietf.org/html/rfc6844 ) рассчитаны на совместное использование с инфраструктурой DNSSec. Эти решения специфицируют новые типы DNS-записей, предназначенных для размещения сертификата ресурса:

  1. RFC 6698 специфицирует TLSA-запись, содержащую сертификат, который идентифицирует конкретный интернет-ресурс.

  2. RFC 6844 специфицирует CAA-запись, содержащую сертификат УЦ, которым может быть подписан сертификат, который идентифицирует конкретный интернет-ресурс.

Эта защита представляется ограниченно применимой из-за недостаточного распространения DNSSec и отсутствия встроенной поддержки в браузерах. Кроме того, оператор DNS-зоны (хостер или регистратор) может управлять соответствующими DNS-записями необнаружимо для неквалифицированного клиента, что также позволяет организовать атаку MITM.

Certificate Pinning


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

В браузере Google Chrome хранится информация о том, какие сертификаты могут подписывать сервисы, предоставляемые компанией Google. Существует также плагин Certificate Patrol (http://patrol.psyced.org/ ) для браузера Mozilla Firefox. Начиная с версии FireFox 32 в браузере дублируется список сертификатов из Chrome, который будет дополняться.

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

Прочие схемы


Заслуживают упоминания предложения Sovereign Keys (https://www.eff.org/sovereign-keys ) и Accountable Key Infrastructure (AKI, http://www.cs.cmu.edu/~xia/resources/Documents/kim-www13.pdf ).

В спецификации Sovereign Keys описываются append-only журналы сертификатов, так что этот проект можно считать в некотором смысле идейным предшественником Certificate Transparency.

Спецификация AKI предполагает возможность подписи сертификата сразу несколькими УЦ, что требует существенной переработки текущей инфраструктуры PKI. Это вряд ли может быть достигнуто в разумные сроки.

Еще некоторое количество проектов по обеспечению безопасности можно найти в уже упоминавшемся обзоре http://queue.acm.org/detail.cfm?id=2673311 . Там отмечается, что все предлагаемые решения характеризуются одними и теми же общими свойствами:



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

  2. Все предложения призваны сократить информационную асимметрию между УЦ и приобретателями сертификатов, предоставляя информацию о подозрительных сертификатах, выпускаемых различными УЦ.

  3. Все предложения специфицированы как опирающиеся на текущую инфраструктуру PKI, и не предполагают ее демонтаж.

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

  5. Все предлагаемые решения требуют поддержку со стороны клиентского ПО, в первую очередь браузеров.

Описание Certificate transparency


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

История проекта


Проект Certificate Transparency был представлен публично в 2012 году (http://www.nature.com/nature/journal/v491/n7424/pdf/491325a.pdf ) статьей Бена Лори (Ben Laurie) и Кори Доктороу (Cory Doctorow), известных экспертов в области информационной безопасности.

Официальный сайт проекта: http://www.certificate-transparency.org/

В июне 2013 выпущено RFC 6962 (http://tools.ietf.org/html/rfc6962 ), отмеченное как экспериментальное. В нем содержалась начальная спецификация предлагаемых изменений в инфраструктуру PKI.

В 2014 году была создана рабочая группа IETF, задачей которой является усовершенствование спецификации CT. Страница группы: http://datatracker.ietf.org/wg/trans/documents/ . Рабочая группа функционирует в соответствии с принципами организации IETF. Целью рабочей группы является выработка новой версии спецификации CT к декабрю 2014 года (http://datatracker.ietf.org/wg/trans/charter/ ). В настоящий момент к спецификации сделано более 50 уточнений и замечаний. Выпущена 4 уточняющая версия (IETF draft) спецификации.


Изменения в инфраструктуру PKI и процесс верификации


Certificate Transparency предполагает введение дополнительных сущностей в процесс верификации сертификатов клиентским ПО. Это

  1. Лог-серверы

  2. Мониторы

  3. Аудиторы

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

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

В данный момент спецификация gossip-протокола не проработана. Без точной спецификации gossip-протокола работоспособность CT в качестве решения для предотвращения атаки MITM существенно понижается.

Gossip-протокол должен учитывать следующие проблемы:



  1. В процессе обмена информацией может быть нарушено privacy конечных пользователей.

  2. Необходимо определить, кто обменивается информацией: клиенты, мониторы, прочие субъекты CT.

  3. Gossip-протокол должен быть устойчив к попыткам ограничения трафика между клиентами.

  4. Протокол должен быть приспособлен к наличию некоторой доли узлов коммуникации, подконтрольных злоумышленникам.

Лог-серверы


Лог-серверы – специально выделенные серверы, ведущие журнал выданных сертификатов. Каждый лог-сервер работает с сертификатами, выданными определенным набором УЦ и их реселлеров. Лог-сервер выполняет следующие действия:

  1. Прием от клиента сертификата или цепочки сертификатов.

  2. В случае если лог-сервер не может построить корректную цепочку доверия, начинающуюся от одного из УЦ, обработка прекращается.

  3. Лог-сервер выдает криптографическую метку, подписанную своим секретным ключом (Signed Certificate Timestamp, SCT). Метка представляет собой обещанный момент включения полученного сертификата в журнал.

  4. Не реже чем в оговоренное время (с задержкой не больше, чем на Maximum Merge Delay) все накопленные сертификаты включаются в журнал, из которого не может быть удалена ни одна запись.

Для хранения сертификатов и обеспечения целостности подписанного дерева используется технология Merkle Tree (http://en.wikipedia.org/wiki/Merkle_tree ).

Мониторы


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

  1. Избыточные возможности (например, возможность подписывать сертификаты, выступая в роли сертификата УЦ)

  2. Наличие нестандартных расширений (X.509 Extensions)

  3. Несоответствие выпущенных сертификатов рекомендациям (например, слишком короткая длина ключа).

Предполагается, что сервисы мониторинга будут поддерживаться существующими УЦ. Мониторы будут фактически зеркалами лог-серверов.

Аудиторы


Аудиторы проверяют корректность логов, принимая во внимание следующие аспекты:

  1. Корректность внесения сертификатов в лог.

  2. Гарантия того, что все сертификаты попадают в лог.

  3. Корректность ведения логов: консистентность, отсутствие ветвления.

  4. Корректность подписи под логом.

Задача аудиторов – проверка, что текущее состояние лога, доступное по запросу, не противоречит предыдущему сохраненному состоянию. Функции аудиторов могут выполняться как стандартным клиентским ПО, так и специальным ПО, установленным на выделенных серверах.

Серверы TLS


Серверы TLS должны обеспечить передачу криптографических меток (SCT) клиентам в процессе установления соединения. На данный момент предусматривается, что SCT может передаваться одним из трех способов:

  1. Метка, встроенная в сертификат. Встраивание меток в сертификат требует смены технологических циклов УЦ, но не требует перенастройки или апгрейда серверного ПО.

  2. Метка, передаваемая как TLS Extension. Этот вариант требует существенной переработки используемого ПО (для веб-сервера apache доступны патчи).

  3. Метка, передаваемая как часть ответа на запрос по протоколу OCSP. Это наименее надежный способ транспорта, так как при отсутствии связи с OCSP-сервером выбор сводится либо к отказу от установления соединения, либо к отсутствию проверки.

Клиенты TLS


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

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


Текущее состояние проекта


Текущему состоянию проекта посвящен ряд публикаций разработчиков. Необходимо отметить сентябрьскую статью Бена Лори, описывающую общее состояние и принципы построения системы (http://queue.acm.org/detail.cfm?id=2668154).

В презентации для IETF (http://www.ietf.org/proceedings/90/slides/slides-90-trans-2.pdf) также отражено текущее состояние спецификации проекта и перечислены нерешенные вопросы.

Некоторые сложности в стандартизации вызваны тем, что практика регулирования УЦ определяется участниками CA/Browser Forum (http://cabforum.org), при том, что практика IETF не предусматривает ссылки на эти документы. Кроме того, технические стандарты не являются сами по себе обязательными к реализации в прикладном ПО, в то время как реализация мер безопасности в браузерах в некоторой степени регулируется рекомендациями CA/Browser forum. Это создает организационные препятствия для полнофункциональной реализации проекта.

Поддержка в ПО


В данный момент спецификация CT поддерживается как минимум следующим ПО:

  1. Google Chrome под Windows поддерживает отображение информации о переданных в процессе установления соединения с сайтом SCT и просмотр меток.

  2. OpenSSL поддерживает CT начиная с версии 1.0.2 (сейчас в статусе beta-версии).

  3. Для веб-сервера Apache существует патч, обеспечивающий передачу SCT в формате TLS extension (предоставлен разработчиками Certificate Transparency).

  4. Для веб-сервера Apache разработка mod_ssl_ct (http://httpd.apache.org/docs/trunk/mod/mod_ssl_ct.html), предназначенная для автоматического получения SCT с лог-серверов и их верификации.

Существует несколько независимых реализаций компонентов системы (лог-серверы, мониторы, аудиторы) с открытым кодом.

Поддержка Certificate Transparency удостоверяющими центрами


В связи с тем, что начиная с сертификатов, выпущенных после 1 февраля 2015 года в браузере Google Chrome для индикации того, что информация о владельце подвергнута дополнительной проверке (Extended Validation), будет необходимо наличие SCT-меток (см. Extended Validation in Google, http://www.certificate-transparency.org/ev-ct-plan ), по данным Google, 94% УЦ по объему выпуска EV-сертификатов будут поддерживать CT, включая SCT в свои сертификаты.

После успешного развертывания системы для EV-сертификатов планируется расширение системы для всех TLS-сертификатов.


Лог-серверы


В данный момент работают 2 лог-сервера, поддерживаемых Google. Кроме того, планы по запуску лог-серверов есть у Akamai, ISOC и ряда УЦ.

Критика проекта


Нам удалось обнаружить только одну содержательную статью с критикой проекта (http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/) за авторством Грега Слепака (Greg Slepak). В статье справедливо отмечается, что предлагаемое решение не обеспечивает моментального обнаружения атаки MITM. Предложенная в статье модель угроз требует контроля злоумышленника не только за УЦ, как сейчас, но и за лог-сервером. В статье также упоминается, что, в отсутствие реализации gossip-протокола возможна атака, при которой лог-сервер предоставляет разные Merkle Tree различным подмножествам клиентов.

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


Планы развития проекта


До стандартизации новой версии RFC6962-bis преждевременно говорить о перспективах развития проекта.

Бен Лори и Эмилия Каспер (Emilia Kasper) опубликовали черновик спецификации Revocation Transparency (http://www.links.org/files/RevocationTransparency.pdf). Это offline-система, которая предназначена для агрегации CRL с возможностью проверки не-включения сертификата в список отозванных. Текущие материалы не представляют возможности оценить перспективы внедрения этой системы.


Требования к клиентскому ПО для поддержки CT


Текущая спецификация оставляет открытым вопрос, как именно организуется настройка и обновление клиентского ПО для поддержки CT.

Предполагается, что будет возможно конфигурирование по крайней мере следующих настроек:



  1. Список признаваемых лог-серверов. Включает в себя идентификаторы лог-серверов, а также их открытые ключи.

  2. Будет возможно «тонкое» конфигурирование (какие лог-серверы признаются для каких доменов и т.п.)

Особенности применения Certificate transparency в России


Важной особенностью российского криптографического рынка является требование использования алгоритмов электронной подписи и защиты информации (хеш-функции), специфицированных как ГОСТ России. В настоящее время в таком качестве должны использоваться электронная подпись и хеш-функция по ГОСТ Р 34.10-2012 и 34.11-2012 соответственно, которые, в свою очередь, заменяют предыдущие версии стандартов, ГОСТ Р 34.10-2001 для электронной подписи и ГОСТ Р 34.11-94 для хеш-функции. Предполагается, что коммуникации по протоколу TLS должны использовать российские алгоритмы для всех криптографических преобразований.

По изложенному во введении, использование российских криптографических алгоритмов не защищает от атаки компрометации доверенного УЦ. Более того, значительная часть сертифицируемых СКЗИ, помимо прочего, добавляет поддержку российских алгоритмов в ПО общего назначения (браузеры, почтовые клиенты). При этом, так как поставляемые по умолчанию корневые сертификаты УЦ остаются среди доверенных, контроля над любым из таких УЦ будет достаточно для организации атаки, описанной во введении, с использованием сертификатов на алгоритмах, несертифицированных для применении в России. Для неподготовленного пользователя эта атака технически необнаружима. В условиях, когда СКЗИ используется отдельно от ПО общего назначения, технически возможно ограничить набор доверенных корневых сертификатов только доверенными корневыми сертификатами российских УЦ, что снижает риск этой атаки.

Для использования Certificate Transparency для защиты в том числе и российских ресурсов, использующих алгоритмы ГОСТ в том числе в X.509-сертификатах и для защиты канала, целесообразно адаптировать RFC 6962 и его программные реализации следующим образом:


  1. Использовать российские хеш-функции в качестве базовых алгоритмов для построения Merkle Tree и создания меток фиксации в логе (SCT) для российского лог-сервера.

  2. Использовать российские криптографические алгоритмы для подписей SCT для российского лог-сервера.

  3. При конфигурировании ПО для работы с CT необходимо прописывать лог-сервер, сконфигурированный в соответствии с пп. 1-2

  4. Российские УЦ должны взаимодействовать с лог-сервером, описанным в п.3, направляя туда подписанные сертификаты для логирования.

Необходимость адаптации спецификации Certificate transparency под условия применимости в России обсуждалась на личной встрече с авторами стандарта и разработчиками в марте 2014 года в Лондоне, а также в списках рассылки IETF, посвященных Certificate transparency, и наша аргументация была встречена с пониманием.

Изменения в технических процессах удостоверяющих центров в случае распространения Certificate transparency


В связи с тем, что процесс развертывания CT предполагается плавным и безболезненным, а также в связи с тем, что в настоящий момент большинство клиентских браузеров (Google Chrome, Mozilla Firefox, Opera) обновляются автоматически, в отличие от серверного ПО, для которого характерны только обновления с исправлением ошибок, но не с добавлением новой функциональности, то оптимальной для обеспечения плавности перехода представляется модификация внутренних технологических процессов УЦ, поскольку УЦ существенно меньше, и они могут быть мотивированы внешними воздействиями (в частности, в рамках CA/Browser Forum). Об этом свидетельствует и интерес, проявляемый крупными УЦ (Comodo, Symantec) к проекту.

Требованиям минимизации изменений серверного ПО лучше всего удовлетворяет механизм внедрения SCT в качестве X.509-extension-ов непосредственно в сертификат. В этом случае поддержка CT на стороне сервера появляется автоматически при плановом перевыпуске сертификата (обычно раз в 1 год).



Внедрение SCT непосредственно в сертификат подразумевает модификацию существующего технологического процесса УЦ, в котором заявка, пришедшая от клиента, преобразовывается в подписанный одним из промежуточных сертификатов УЦ клиентский сертификат. Возможны следующие варианты действий УЦ:

  1. УЦ выпускает сертификат по стандартному процессу (не содержащий SCT), направляет его в лог-сервис, и получает SCT. Далее УЦ повторно проходит по технологической цепочке, добавляя полученный SCT в качестве расширения. Результат второго прохода по технологической цепочке предоставляется клиенту в качестве сертификата.

  2. УЦ использует предусмотренный RFC 6962, раздел 3.1 механизм пресертификатов. В этом случае технологическая цепочка подразумевает модификацию с тем, чтобы на выходе получился заведомо неверифицируемый стандартными клиентами (содержащий специфицированное расширение X.509) пресертификат, приемлемый, однако, для лог-сервиса. Полученный от лог-сервиса SCT при этом встраивается в рамках стандартной цепочки в сертификат, который и оказывается итоговым клиентским. При этом для подписания пресертификатов и итоговых сертификатов используются разные ключи, что позволяет, в частности, гарантировать идентичность идентификаторов (поля Serial) сертификата и пресертификата.

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

  1. Существующие крупные УЦ используют Hardware Security Modules (HSM) для выпуска сертификатов. Согласно рекомендациям IETF, серийные номера сертификатов должны быть случайными. Таким образом переход на выпуск пресертификатов и сертификатов с одним и тем же серийным номером технически крайне затруднителен.

  2. Текущий технологический процесс не дает возможности выпуска двух сущностей, аналогичных сертификатам, с одной и той же парой Issuer-Serial, также такое требование нарушает RFC 5280.

В данный момент в рабочей группе рассматривается несколько вариантов решения этой проблемы: смена формата пресертификатов, использование CertTemplates (RFC 4211) для передачи лог-сервисам информации о пресертификатах, смена процедуры внесения пресертификата в лог.

Аспекты, требующие дальнейших исследований


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

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

  2. В силу принципиальных свойств логов, не предусматривающих удаления однажды внесенных записей, скомпрометированные сертификаты проходят все процедуры верификации средствами CT. Следовательно, они могут использоваться для организации MITM-атаки даже при полностью развернутой инфраструктуре CT. Решение этой проблемы средствами CT невозможно, поэтому в модели угроз предполагается корректное использование других средств верификации (CRL, OCSP).

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

  4. Текущая спецификация предполагает, что логированы будут только сертификаты, подписанные определенным набором УЦ. Это означает, что за пределами наблюдения оказываются сертификаты, размещенные в TLSA-записях DNS, подмена которых также может позволить организацию атаки Man-In-The-Middle.

  5. Не специфицирован gossip-протокол, который имеет принципиальную важность для проверки корректности функционирования логов.

  6. Недостаточно специфицировано поведение клиентского ПО. В процессе выполнения работы нами предложена формулировка для включения в следующую версию спецификации, которая призвана дать четкие указания по процедуре верификации SCT средствами клиентского ПО.


Заключение


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

Необходимо понимать, что внедрение CT в практику не гарантирует избавления от атак MITM, хотя и существенно затрудняет их организацию. При этом внедрение CT позволяет обнаруживать факты организации атак постфактум и упрощает поиски УЦ, тем или иным способом причастных к организации подобных атак.

Производители браузеров, отличных от Google Chrome, не высказывались на тему внедрения поддержки CT в своих продуктах. Исключением является корпорация Mozilla, которая предварительно высказала желание поддержать CT в будущих версиях браузера (https://wiki.mozilla.org/PKI:CT), но при этом планируется, что поддержка будет по умолчанию выключена.

Мы не ожидаем, что поддержка CT как основного решения станет неотъемлемой частью правильно работающего ПО ранее 2017 года.


Приложение

Оценка нагрузки на лог-серверы


Для оценки сверху нагрузки на лог-сервер мы делаем следующие предположения:

  1. Нагрузка направлена на один лог-сервер

  2. Ежедневно выпускается примерно 5000 TLS-сертификатов, преимущественно с годичным сроком действия (l).

  3. Оценка количества пользователей Интернет (b) – 3 миллиарда (по данным http://www.internetworldstats.com/stats.htm ).

  4. Среднее число посещаемых клиентом сайтов за месяц (v) оценивается в 90 (http://www.creditloan.com/blog/how-the-world-spends-its-time-online/) .

  5. Предполагается, что все сайты посещаются по TLS.

  6. Клиентское ПО кеширует результаты проверки.

Нагрузка на лог-серверы создается добавлением сертификатов в лог, аудиторами и мониторами.

Нагрузка, связанная с добавлением сертификатов в лог, пренебрежимо мала (менее 1 запроса в секунду). Нагрузка, создаваемая мониторами, того же порядка.

Получим оценку нагрузки, создаваемой аудитом. Для верификации каждого сертификата по текущей спецификации API требуется 3 обращения: получить STH, проверить консистентность STH, проверить, что сертификат был включен лог-сервером. Объем передаваемого лог-сервером трафика на эти 3 обращения составляет примерно 3 килобайта.

Получаемая оценка дает нам 3 * b * v / l, что примерно равно 26000 запросов в секунду (возможно сокращение количества запросов в 3 раза, до 8500, оптимизировав API). Итоговая оценка трафика – 200 мегабит в секунду.

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

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


Предлагаемая спецификация поведения клиента


Нами была предложена спецификация поведения клиентского ПО, действующего в соответствии с логикой CT, при проверке соединения.

Предполагается, что клиентское ПО располагает информацией о лог-серверах и их открытыми ключами, необходимыми для проверки подписей под SCT. Предложенная спецификация описывает дополнительные шаги по валидации цепочки доверия, кроме предписанных в RFC 5280.



  1. Если при установлении соединения сервер не предъявил ни одной SCT, клиент должен прервать соединение.

  2. Клиент должен игнорировать все SCT, относящиеся к неизвестным ему логам.

  3. Клиент должен игнорировать все SCT, относящиеся к будущему времени.

  4. Если после выполнения пп.2-3 не осталось ни одной SCT, клиент должен прервать соединение. Все прочие проверки выполняются только для SCT, которые не проигнорированы.

  5. Если подпись хотя бы под одной из SCT невалидна, клиент должен прервать соединение.

  6. Клиент может сделать проверку включения сертификата в журнал, подписавший SCT. Если сертификат не включен в лог, клиент должен прервать соединение.

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


База данных защищена авторским правом ©ekonoom.ru 2016
обратиться к администрации

    Главная страница