Удостоверяющие центры TLS-сертификатов Рунета

По состоянию на декабрь 2019 года для веб-узлов Рунета более 80% TLS-сертификатов (HTTPS) выпущены всего двумя удостоверяющими центрами (УЦ): Let’s Encrypt и Cloudflare Inc. Соответствующую статистику TLS можно посмотреть на сайте проекта Statdom.ru (да, там тоже сертификат Let’s Encrypt).

Лидерство этих УЦ – довольно интересный показатель. Доля Let’s Encrypt, предоставляющего бесплатные сертификаты, уже более двух лет находится в интервале 61 — 68%, а вот Cloudflare – набрали почти 15% примерно за год. Конечно, в случае Cloudflare, это просто переход от одного названия к другому – ранее они использовали сертификаты УЦ Comodo, а потом перешли на собственное имя, – но это никак не отменяет достижений.

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

Означает ли это, что наступила некая “сверхцентрализация” и почти все HTTPS-узлы – захвачены? И да, и нет. Дело в том, что в выборе TLS-сертификатов и УЦ участвует несколько сторон, а определяющую роль играет браузер и операционная система. То есть, чтобы УЦ смог выпускать доверенные сертификаты, корневые ключи этого УЦ должны попасть в перечень доверенных браузера (либо операционной системы – зависит от конкретной среды, но в нашем случае это не важно). То есть, говорить о “сверхцентрализации” рано – теоретически, браузеры могут исключить, например, Let’s Encrypt из списка доверенных (прецеденты известны). Другое дело, что данный УЦ стал слишком большим, чтобы его просто так взяли и исключили: даже в случае существенных обстоятельств – такое исключение будет проводиться постепенно (если вообще будет проводиться).

Можно ли говорить, что эти УЦ теперь имеют доступ к данным почти всех HTTPS-сайтов, потому что там установлены их сертификаты? Нет, так говорить нельзя. Хотя и тут есть тонкости. Let’s Encrypt вообще не получает, при штатном способе выпуска сертификата, доступа к секретным ключам сервера (эти ключи просто не нужны УЦ для выпуска сертификата), соответственно, как-то расшифровать и перехватить данные этот УЦ не может. А вот у Cloudflare доступ к данным веб-узла с их сертификатом, конечно, есть, но совсем по другим причинам, не связанным с работой УЦ: основная услуга Cloudflare – проксирование соединений, предоставление веб-фронтенда; соответственно, они и так имеют доступ к трафику своих клиентов, вне зависимости от того, какой сертификат установлен на узле. (Интересно, что Cloudflare первыми массово внедрили технологию, позволяющую клиенту не передавать провайдеру копию секретного ключа для осуществления проксирования HTTPS-запросов. Addon /07.02.2020/: точнее, они первыми внедрили такую технологию на своём массовом сервисе, но не факт, что она получила большое распространение – это нужно смотреть отдельно.)

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

Да, в случае каких-то глобальных проблем – сайты смогут перейти на сертификаты других УЦ. Вряд ли переход будет быстрым и простым, но он возможен. А сайты, использующие Cloudflare, так или иначе полностью зависят от работоспособности данного провайдера, поэтому для них использование сертификатов “карманного” УЦ вообще не создаёт существенных дополнительных рисков. Но всё же: 80% узлов – это четыре пятых всех сайтов с HTTPS. С другой стороны, распространённых браузеров тоже всего два.

Адрес записки: https://dxdt.ru/2020/02/04/8862/

Похожие записки:



Далее - мнения и дискуссии

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

Комментарии читателей блога: 6

  • 1. 4th February 2020, 23:06 // Читатель beldmit написал:

    > Интересно, что Cloudflare первыми массово внедрили технологию, позволяющую клиенту не передавать провайдеру копию секретного ключа для осуществления проксирования HTTPS-запросов.

    А они её массово внедрили? У меня сложилось впечатление, что они на этом отпиарились, а внедрений по факту у них было очень мало, если вообще были, и по факту они её тихо похоронили.

  • 2. 6th February 2020, 12:38 // Читатель dmt.obd написал:

    > Интересно, что Cloudflare первыми массово внедрили технологию, позволяющую клиенту не передавать провайдеру копию секретного ключа для осуществления проксирования HTTPS-запросов.

    О какой технологии идет речь?

  • 3. 7th February 2020, 12:02 // Александр Венедюхин:

    > А они её массово внедрили?

    Вообще, да, не факт, что массово. Я тут имел в виду, что внедрили саму возможность на массовом сервисе (сейчас добавлю примечание в текст).

  • 4. 7th February 2020, 12:06 // Александр Венедюхин:

    > О какой технологии идет речь?

    О Keyless SSL: https://www.cloudflare.com/ssl/keyless-ssl/

  • 5. 4th May 2020, 09:48 // Читатель Z.T. написал:

    Я думаю, что Keyless SSL используется очень редко. Это негативно сказывается на производительности, потому что устройство клиента должно подписывать каждое новое соединение, и это наносит ущерб задержке, потому что каждое новое соединение должно получать подпись от источника, а не от точки присутствия.
    Я полагаю, что это был способ привлечь клиентов, которые по правилам обязаны иметь физический контроль над своими ключами TLS. Это позволяет тем клиентам подчиняться букве, если не духу правила. Конечно, контроль над ключом и предоставление всех данных Cloudflare – это не то, что имел в виду регулятор, но если правила не были обновлены – это дешевый способ получить защиту от DDoS, WAF, кеширование и т. Д.

    Когда вы пишете, что есть только два популярных браузера, какой из Firefox и Safari вы считаете не популярным?

  • 6. 5th May 2020, 00:04 // Александр Венедюхин:

    > какой из Firefox и Safari вы считаете не популярным?

    Считаю Safari.

Написать комментарий

Ваш комментарий:

Введите ключевое слово "D13UD" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.