OCSP всё?
Google УЦ Let«s Encrypt предупредил, что намерен «как можно скорее» прекратить поддержку протокола проверки статуса TLS-сертификата Online Certificate Status Protocol (OCSP) и впредь поддерживать только Certificate Revocation Lists (CRLs).
Certificate Revocation Lists (CRL, список отозванных сертификатов) появился в 1999 году в RFC2585. Принцип его работы прост до безобразия: агент пользователя с некоторой периодичностью загружает списки отозванных TLS-сертификатов у известных ему удостоверяющих центров (УЦ) и сверяет по ним сертификаты, предъявляемые сайтами для защиты соединения.
В конце XX века кто бы мог подумать, что количество сайтов будет измеряться миллионами и значительная их часть, если не большинство, станут защищать соединение с собой, что подразумевает использование TLS-сертификата. А сертификаты по разным причинам отзывают, а сайтов миллионы, а списки пухнут, а трафик и нагрузка на сервера УЦ растут экспоненциально… В общем, вы понимаете масштаб проблемы с CRL к середине третьего десятка лет XXI века.
Одновременно с CRL появился Online Certificate Status Protocol (OCSP, протокол онлайн [проверки] статуса сертификата). Агент пользователя получает от сайта TLS-сертификат и запрашивает у выдавшего его УЦ статус оного сертификата: айс или не айс? Современно, «бюджетно», молодежно; казалось бы, что могло пойти не так? Но кто в конце XX века задумывался о privacy, интернет-слежке, цифровых отпечатках и вот этом вот всем? Авторы RFC2560 точно не задумывались и зевнули деликатный момент: при запросе статуса сертификата чувствительная информация неизбежно раскрывается третьей стороне — УЦ, которому агент пользователя рапортует, на какой сайт зашел этот самый пользователь.
Есть у OCSP и другие недостатки, например, если сайт УЦ недоступен, проверить статус предъявленного TLS-сертификата невозможно. Кроме того, OCSP подвержен той же уязвимости, что и CRL: поскольку запрос статуса сертификата как правило производится через незащищенное соединение (HTTP), цена ответу на этот запрос — грош, да и тот ломаный. OCSP хотя бы пытался в HTTPS, а CRL не умеет by design.
Впрочем, основные проблемы OCSP решались его расширением Certificate Status Request, более известным как OCSP Stapling (сшивание [ответов] OCSP). Сайт, с которым агент пользователя устанавливал защищенное соединение, отправлял в дополнение к TLS-сертификату свежую «справку» от УЦ: сертификат не отозван. Справка «подшивалась» к сертификату и заверялась все тем же открытым ключом выдавшего ее и сертификат УЦ.
Таким образом, посетители сайта не устанавливали еще одно соединение — с сайтом УЦ, его недоступность в данный момент роли не играла, сайт УЦ не дергали постоянно десятки, тысячи, миллионы посетителей окормляемых УЦ сайтов (а только сами эти сайты, и то куда реже), чувствительная информация никуда не утекала, и все это ценой незначительного в масштабах Вселенной Интернета увеличения размера «рукопожатия» при установлении защищенного соединения. Опциональный флаг в сертификате «OCSP Must Staple» рекомендовал агенту пользователя считать предъявленный TLS-сертификат сайта недействительным, если к нему не прилагалась свежая «справка».
Мечта? Мечта, но в эту мечту поверили чуть более чем никто и OCSP Stapling до настоящего времени не стал популярным. За все время существования нашего проекта «Монитор госсайтов» мы встречали сертификаты с поддержкой OCSP Stapling хорошо если на каждом десятом исследуемом сайте (причем, на сайтах региональных госорганов они используются заметно чаще, чем федеральных).
Вот и сказочке конец: год назад CA/Browser Forum решил, что поддержку OCSP его члены могут обеспечивать по настроению левой пятки, тогда как CRL — в обязательном порядке. Google Let«s Encrypt уже обогнала паровоз, пригрозив в обозримой перспективе вовсе дропнуть поддержку OCSP, вся надежда на Microsoft, которая не входит в CA/Browser Forum и могла бы состроить Корпорации Злого Бобра козью морду, включив требование поддержки OCSP Stapling в условия участия в Microsoft Trusted Root Program. Как думаете, разразится эта битва якодзун?
