С правом подписи

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

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

Часть проблем связаны уже с этим — предоставить секретный ключ крупного банка пусть даже респектабельному CDN с филиалами во всех странах мира (а если задуматься о политических последствиях — то в особенности с филиалами во всех странах мира) как-то не кажется разумным, а иногда это просто запрещено. Попыткой решить эту проблему был предложенный компанией Cloudflare сервис Keyless SSL, но он не был достаточно востребован. Компания попробовала ещё один подход — Geo Key Manager, при котором клиенты могли сами решать, в какие страны уедут их приватные ключи, но это несколько нивелирует сам принцип CDN, когда контент доставляется за минимальное время.

Компрометация ключа, учитывая недостаточное удобство решений в этой области — как списков отзыва (CRL, Certificate Revocation Lists) так и онлайн-проверки статуса (OCSP, Online Certificate Status Protocol), создаёт дополнительные проблемы. Поэтому хочется на случай компрометации ограничить срок действия реквизитов доступа, чтобы злоумышленники были ограничены во времени. Однако чтобы выпустить короткоживущий сертификат для каких-то проектов, опять же надо обращаться в удостоверяющий центр.

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

Чтобы решить обе проблемы разом, была предложена концепция «делегированных реквизитов» (delegated credentions, DC) и разработан документ, позволяющий владельцу ресурса самостоятельно в пределах контролируемых доменов выпускать временные ключи, устанавливать на них удобное время действия и самостоятельно принимать решения о допустимых алгоритмах. При этом УЦ по-прежнему выпускает исходный сертификат, но добавляет в него указание на то, что его владелец волен выпускать свои — нет, не полноценные сертификаты, но, тем не менее, криптографически верифицированные объекты — для угодного ему применения. Срок действия устанавливается не более 7 дней, но можно и меньше. Невозможно отозвать выпущенные реквизиты явным образом — но предполагается, что риски в любом случае меньше, чем в случае полноценной компрометации ключа. Не нужно обращаться к УЦ для временных сертификатов, не происходит перегрузка журналов сертификатов в рамках программы Certificate Transparency — в общем, ситуация на практике должна стать куда безопаснее.

Разработка документа продолжается уже больше двух лет, и осенью 2019 года проект был признан достаточно созревшим для того, чтобы попробовать использовать его на практике. Разработчики — а авторы документа включают легендарного Эрика Рескорлу (Eric Rescorla) и Ричарда Барнса (Richard Barnes) из Mozilla, Ника Салливана (Nick Sullivan) из Cloudflare, представителя Фейсбука Субодха Янгара (Subodh Iyengar) — решили попробовать внедрить предлагаемый стандарт в практику своих компаний.

В публикации в блоге Cloudflare описываются преимущества DC по сравнению с Keyless SSL: нет требований к ключевому серверу, который в режиме Keyless SSL должен быть доступен в режиме 24 на 7, не возникает дополнительная пауза для обмена данными с этим сервером — а значит, улучшается время отклика. Можно применять современные алгоритмы на кривых Эдвардса при установлении соединения. Можно ставить эксперименты с постквантовой криптографией — тема, которая будоражит специалистов по информационной безопасности последние несколько лет.

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

Разумеется, что бы ни пытались делать разработчики решений на стороне сервера, им не обойтись без браузера для поддержки их решений. Естественно, партнёром стала компания Mozilla. Публикация в их блоге рассказывает о том, как поддержка DC организована в браузере (пока только в «ночных» сборках), и как её включить. Для этого необходимо набрать в адресной строке about:config, найти параметр security.tls.enable_delegated_credentials и разрешить использование DC, после чего нужно перейти на специальный поддомен на сайте Mozilla. Аналогично придётся действовать и для выключения DC, если такое желание возникнет.

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

Вероятно, обнаружатся и другие узкие места — в конце концов, именно для этого и организуется опытная эксплуатация. Нельзя забывать, что новое решение предусмотрено только для протокола TLS 1.3, который пока развёрнут примерно на 20% серверов. Но после устранения всех недостатков дорога к превращению рабочего документа IETF в полноценный RFC будет открыта, и мы увидим поддержку DC у всех игроков.


Автор:  Дмитрий Белявский (ТЦИ)

Возврат к списку