Проект компаний
 
 
 
 
RU|SSl-сертификаты,обзор

SSL-сертификаты в Рунете

Введение

Пользователи Интернета наиболее часто сталкиваются с технологией обеспечения безопасного обмена данными, которая называется TLS - Transport Layer Security (также часто используется синонимичное название, SSL - Secure Sockets Layer). Один из распространённых протоколов, использующих TLS - защищённая версия основного транспорта веба - HTTPS. Изначально созданный для защиты коммерческих транзакций в вебе, HTTPS обрёл в современном Интернете гораздо более широкое применение и, в той или иной степени, знаком едва ли не каждому интернет-пользователю.

Одним из ключевых понятий современной реализации TLS в применении к HTTPS является SSL-сертификат. Сертификат - это "электронный документ", другими словами, файл данных особого формата. Он служит для решения одной задачи: подтверждения соответствия некоторого криптографического ключа некоторому сетевому имени. Такое подтверждение проводится при помощи криптографических алгоритмов - электронной подписи. В качестве сетевого имени в большинстве случаев выступает доменное имя, например: nic.ru. SSL-сертификаты используются при установлении соединений с адресами вида https://nic.ru/.

Предметом настоящего исследования, ориентированного на анализ присутствия инструментов защиты информации в веб-разработке, стали SSL-сертификаты, доступные на TLS-серверах Рунета, поддерживающих протокол HTTPS. Под "Рунетом" мы понимаем интернет-узлы, адресуемые доменами .RU.

Методика

Согласно проведённым нами ранее наблюдениям за зоной .RU, большинство (>75%) веб-серверов, адресуемых доменами .RU, откликаются как по адресу с префиксом www., так и без этого префикса. Поэтому для формирования множества опрашиваемых TLS-серверов использовались узлы, адресуемые доменами (строго говоря - именами хостов) второго уровня вида name.tld (примеры таких адресов: test.ru, nic.ru, spb.ru). Для веб-сервисов, работающих по HTTPS, не редким является размещение под "специальными" адресами третьего уровня. Примеры таких адресов: intra.test.ru, mail.test.ru, corp.test.ru, portal.test.ru, stat.test.ru и т.п. Хотя нам известна большая часть этого перечня имён, мы, по ряду причин, не опрашивали подобные адреса в рамках настоящего исследования.

TCP-cоединение с TLS-сервером устанавливается по IP-адресу. При этом, из-за особенностей протокола, в ряде случаев сервер не может определить имя хоста, с которым пытается соединиться по HTTPS клиент, до того момента, когда будет установлено защищённое соединение. Поэтому для работы веб-сервера по HTTPS рекомендуется использовать выделенный IP-адрес. Отметим, что большинство современных браузеров поддерживают специальное расширение TLS - SNI (Server Name Indication), позволяющее использовать общий IP-адрес для нескольких имён хостов. SNI поддерживается и на хостингах, в том числе, в Рунете. Тем не менее, расширение SNI также осталось за рамками настоящего исследования: мы опрашивали узлы без указания поля SNI в запросе. Поддержка SNI запланирована в одной из следующих версий.

Для всех делегированных доменов .RU второго уровня была сделана попытка получить значение А-записи. Собранные значения сформировали исходное множество IP-адресов. На этапе подготовки, из них, путём сетевого сканирования, выбрано подмножество узлов, доступных по TCP/443. 443 - стандартный порт протокола HTTPS. С узлов из этого подмножества, при помощи корректной имитации начала TLS-соединения, были загружены SSL-сертификаты, которые и сформировали базу данных для исследования.

Опросы узлов проводились с некоторой регулярностью, в течение года, что позволило провести наблюдения за динамикой данного рынка. Регулярная статистика будет опубликована в специальном разделе сайта.

Для сбора и обработки сертификатов мы использовали программное обеспечение, построенное на базе пакета SSL Observatory EFF.

Валидация сертификатов

Важным аспектом анализа SSL-сертификатов является проверка их валидности - то есть, соответствия некоторым требованиям обработки электронных подписей, присутствующих в сертификатах. С точки зрения рядового пользователя, просматривающего сайты по HTTPS, валидный сертификат, представленный TLS-сервером, это такой сертификат, который не вызывает предупреждений системы безопасности браузера. Этот, на первый взгляд простой момент на практике связан со сложным клубком технических проблем. Несмотря на то, что существуют «стандартные» сборки браузеров, содержащие стандартные наборы корневых сертификатов, валидация в каждом конкретном случае может отличаться от «стандарта». Классический пример: встраивание в браузер дополнительных корневых сертификатов, принадлежащих корпоративному окружению. Отметим, впрочем, что большинство пользователей не меняют настроек браузера по умолчанию.

В нашем исследовании мы проводим валидацию обнаруженных сертификатов без использования браузера, а лишь путём проверки подписей относительно браузерных наборов корневых и промежуточных сертификатов средствами пакета OpenSSL. Этот метод ни в коей мере не может быть признан эквивалентным браузерной валидации, однако он даёт хорошее приближение. В большинстве случаев, сертификат, отмеченный нами как валидный, будет таковым и в представлении браузера. Однако использование такого метода валидации означает, что число сертификатов, валидных с точки зрения распространённых браузеров, может отличаться от соответствующего числа, указанного в настоящем исследовании. Эмпирическая оценка погрешности - 10%. Особо подчеркнём, что на настоящем этапе исследований не проводится проверка отзыва обнаруженных сертификатов каким-либо способом.

Инфраструктура

В ноябре 2013 года с 93169 узлов удалось загрузить 124753 сертификата. В это число входят все полученные сертификаты, включая множественные копии одних и тех же сертификатов. Уникальных сертификатов в ноябре - 62295. Тот факт, что на один узел приходится около 1,3 сертификата, имеет простое объяснение: в ряде случаев, TLS-серверы отдают цепочку сертификатов, включающую как минимум один, а иногда - несколько промежуточных сертификатов. Это стандартная практика. Узлов, вернувших тот или иной валидный сертификат - 20978, что составляет лишь около 22% от общего числа опрошенных узлов. А узлов, вернувших валидный серверный сертификат - ещё меньше: 18833.

За шесть месяцев число узлов, потенциально доступных по протоколу HTTPS и адресуемых доменами второго уровня .RU, выросло на 6044: 87125 узлов в мае против 93169 - в ноябре. Прирост общего числа сертификатов за тот же период - 11265 (113488 сертификатов было загружено в мае 2013 года). Эти числа показывают, что проникновение технологий защищённого веба растёт с небольшим опережением роста хостинга сайтов в целом. Так, согласно нашим наблюдениям за рынком CMS, число веб-узлов за период май-ноябрь выросло примерно на 6%, рост же числа узлов, доступных по HTTPS, составил около 7%. Прослеживается тенденция к увеличению популярности HTTPS, что подтверждается развитием рынка коммерческих SSL-сертификатов (см. ниже), однако пока эта тенденция слаба. Отметим, для сравнения, что за тот же период (май-ноябрь) число доменов .RU выросло на 335712.

Технологии

Традиционно, большая часть обнаруженных сертификатов - самоподписанные (то есть, значения полей Issuer и Subject совпадают): 43045 таких уникальных сертификатов обнаружено в ноябре. Отметим, что корневые сертификаты являются самоподписанными, однако они не могут использоваться в качестве серверных. Всякий серверный самоподписанный сертификат - не валиден. Уникальных сертификатов, выпущенных для localhost (в разных видах) - 2968, валидных среди них не обнаружено. Интересно, что число подобных сертификатов демонстрирует хорошую стабильность, плавая возле условной «константы настройки по умолчанию» - 3000 сертификатов. Например, в январе 2013 года число упомянутых сертификатов составляло 2923, в мае - 3066. Такая стабильность данного показателя прослеживается нами с 2011 года.

Другой показатель, не менее традиционный, это сертификаты, выпущенные УЦ, в наименовании которого содержится подстрока Snake Oil. Этим именем обозначаются сертификаты, входящие в тестовую SSL-конфигурацию некоторых модулей веб-серверов. Snake Oil медленно теряет позиции, в мае соответствующих сертификатов было найдено (всего) 561, из них - 52 уникальных, а в ноябре уже - 409 (43 уникальных). Два года назад общее число наблюдаемых сертификатов Snake Oil превышало тысячу. Впрочем, данный показатель свидетельствует не о росте аккуратности системных администраторов, а лишь о том, что меняется используемый ими инструментарий.

Домены и криптографические свойства

Перейдём к валидным сертификатам. Итак, в ноябре нами получено с серверов Рунета 62295 уникальных сертификата. Из них валидных - 12349. Несмотря на то, что узлы для анализа мы выбираем, исходя из структуры зоны .RU, далеко не все валидные сертификаты выпущены для адресов в домене .RU. В ноябре таких сертификатов обнаружено 4071. Прочие сертификаты относятся к доменам в самых разнообразных зонах, включая .COM (2805 сертификатов), .DE (355 сертификатов), редкие имена .IO (4 сертификата) и даже такую экзотику (с точки зрения TLS/SSL), как .TK (один сертификат).

Подавляющее большинство (около 99%) обнаруженных нами валидных сертификатов используют для электронной подписи алгоритм RSA в сочетании с хэш-функцией SHA-1 (sha1WithRSAEncryption). Это, опять же, стандартная практика и вполне ожидаемый результат.

Одним из важных криптографических параметров, связанных с SSL-сертификатом, является длина используемого ключа RSA. Рекомендуемый показатель - 2048 бит. В ноябре обнаружены сертификаты, использующие следующие длины ключей (в порядке возрастания популярности): 512, 4096, 1024, 2048 бит (в список не входят единичные случаи использования «аномальных» ключей, имеющих, например, длину 1023 бита). 512-битный ключ RSA сейчас не является достаточно криптостойким, и такие ключи не были обнаружены в валидных сертификатах. 1024 бита - эти ключи не рекомендуются к применению, хотя достоверных сведений об их массовом «взломе» в открытой литературе нет. Тем не менее, ключи длиной в 1024 бита выводятся из обращения и не должны присутствовать в новых валидных сертификатах. Эта рекомендация работает на практике: если в январе 2013 года мы видели на опрашиваемых TLS-серверах 288 экземпляров валидных сертификатов с 1024-битным ключом, то в ноябре таких сертификатов всего 91, правда, некоторые из них выпущены со сроком действия до 2016 года. Напротив, ключи длиной 2048 бит встречаются всё чаще: в январе они обнаружены в 6178 валидных сертификатах, а в ноябре - в 11585, рост почти в два раза.

Всего в ноябре обнаружено 41545 уникальных ключей в серверных сертификатах. Это число несколько меньше, чем число уникальных серверных сертификатов (42240), то есть, в ряде случаев один и тот же ключ использовался в разных сертификатах. Это известный дефект, связанный, в основном, с некорректным тиражированием образов виртуальных машин и настроек веб-серверов.

Другим характерным криптографическим параметром является шифрующая экспонента: практически все ( > 95%) валидные сертификаты используют значение 65537 (2^16+1), лишь около тысячи экземпляров включают значение 3; другие числа - единичны, например, обнаружен один промежуточный сертификат признаваемого браузерами УЦ, использующий экспоненту 44243.

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

Удостоверяющие центры

Как было указано выше, для того, чтобы сертификат был признан валидным, он должен быть выпущен тем или иным признаваемым производителями браузеров удостоверяющим центром, возможно, через ряд специальных промежуточных сертификатов. Под термином «выпущен» мы понимаем генерацию удостоверяющим центром электронной подписи, с использованием того или иного секретного (закрытого) ключа. Для каждого валидного сертификата можно построить цепочку электронных подписей, ведущую к корневому сертификату, входящему в список дистрибутива браузера. Логическую основу этой цепочки составляют поля Subject и Issuer сертификата. Первое из них обозначает «субъект», для которого выпущен данный сертификат, второе - выпустившую сертификат организацию или другой «административный объект». В валидной цепочке поле Subject удостоверяющего сертификата соответствует полю Issuer удостоверяемого. Исключение, как отмечено выше, составляют корневые сертификаты УЦ - они являются самоподписанными, то есть, Subject=Issuer. Это не составляет проблемы, так как корневые сертификаты находятся на «вершине» цепочек валидации, а их экземпляры встроены в браузер. Второй конец цепочки - это серверный сертификат, соответствующий тому TLS-серверу, с которым устанавливается соединение.

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

Одному и тому же удостоверяющему центру, рассматриваемому как административная единица, как организация, может соответствовать несколько различных корневых сертификатов и ещё большее количество промежуточных. Например, промежуточные сертификаты могут выпускаться для партнёров УЦ, предоставляющих услуги по продаже сертификатов конечным пользователям под своим собственным брендом. То есть, проекция записей из полей Subject и Issuer на реальную административную структуру достаточно сложна. Более того, исключительно путём анализа полей сертификатов, собранных с TLS-серверов, определить с полезной точностью административную структуру невозможно. Все эти аспекты необходимо учитывать, изучая статистику, которая опубликована ниже.

Мы приводим значения полей Issuer для серверных сертификатов, обнаруженных в Рунете, в ноябре 2013 года. Для каждого значения указано число обнаруженных валидных сертификатов. Это число всех экземпляров, то есть, оно отражает количество узлов, при опросе которых встречены указанные сертфикаты, или, другими словами, степень распространённости сертификатов данного УЦ.

Таблица 1. Топ-17 УЦ (полей Issuer) сертификатов, выпущенных для доменов .ru

IssuerЧисло
C=US, O=Thawte, Inc., CN=Thawte SSL CA1064
C=US, O=GeoTrust, Inc., CN=RapidSSL CA922
C=US, O=Thawte, Inc., OU=Domain Validated SSL, CN=Thawte DV SSL CA627
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=PositiveSSL CA 2515
C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 1 Primary Intermediate Server CA413
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=EssentialSSL CA248
C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=07969287241
C=RU, O=RBC Hosting Center, CN=RBC HC High Assurance Services CA217
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO High-Assurance Secure Server CA202
C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 2 Primary Intermediate Server CA158
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO SSL CA156
C=RU, O=JSC Regional Network Information Center, OU=IT, CN=RU-CENTER High Assurance Services CA117
C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA106
C=US, O=thawte, Inc., OU=Terms of use at https://www.thawte.com/cps (c)06, CN=thawte Extended Validation SSL CA61
C=US, O=GeoTrust Inc., OU=Domain Validated SSL, CN=GeoTrust DV SSL CA47
C=US, ST=Arizona, L=Scottsdale, O=Starfield Technologies, Inc., OU=http://certificates.starfieldtech.com/repository, CN=Starfield Secure Certification Authority/serialNumber=1068843537
C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance CA-336

Таблица 2. Топ-17 УЦ (полей Issuer) для всех обнаруженных в Рунете валидных сертификатов

IssuerЧисло
C=US, O=GeoTrust, Inc., CN=RapidSSL CA3087
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=PositiveSSL CA 21966
C=US, O=Thawte, Inc., CN=Thawte SSL CA1737
C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 1 Primary Intermediate Server CA1389
C=US, O=Thawte, Inc., OU=Domain Validated SSL, CN=Thawte DV SSL CA1216
C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=079692871141
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO SSL CA1132
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO High-Assurance Secure Server CA977
C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=PositiveSSL CA973
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=EssentialSSL CA542
OU=Alpha CA, O=Alpha, CN=Alpha CA530
C=US, O=GeoTrust, Inc., CN=GeoTrust SSL CA494
C=IL, O=StartCom Ltd., OU=Secure Digital Certificate Signing, CN=StartCom Class 2 Primary Intermediate Server CA475
C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert High Assurance CA-3432
O=AlphaSSL, CN=AlphaSSL CA - G2367
C=RU, O=RBC Hosting Center, CN=RBC HC High Assurance Services CA235
C=US, O=GeoTrust Inc., OU=Domain Validated SSL, CN=GeoTrust DV SSL CA226

Рынок SSL-сертификатов в Рунете

Наблюдение за свойствами заказов сертификатов конечными клиентами показывает, что доменам второго уровня в зоне .RU (включая префикс www.) соответствуют далеко не все приобретаемые сертификаты. Как мы уже указывали, большая часть заказывается для специальных адресов третьего уровня. Кроме того, конечные клиенты на российском рынке заказывают сертификаты для имён в других зонах - .COM, .NET и т.д. Эти зоны мы не рассматривали в рамках настоящего исследования. Однако сравнение показателей по реализации услуг SSL-сертификатов и статистики опроса TLS-серверов позволяет предположить, что доменам второго уровня .RU соответствует лишь примерно 20% заказываемых на российском рынке сертификатов.

Таким образом, можно дать примерную оценку количеству заказываемых конечными клиентами сертификатов, поделив число обнаруженных в рамках исследования сертификатов на их долю от общего числа: 4071/0.2=20355 сертификатов. Заметим, что эти сертификаты имеют разные сроки действия. Так, среди всех валидных сертификатов, собранных в ноябре, срок действия один год имели 7187 сертификатов, два года — 2739, более двух лет - 2171. За десять месяцев 2013 года число обнаруженных нами валидных сертификатов для доменов .RU выросло на 1782 сертификата (на 78%). Рост не замедляется. Можно предположить, что к концу следующего, 2014, года число приобретённых клиентами сертификатов вырастет в два раза.

Итоги

Защита информации приобретает всё большее значение в веб-технологиях. На практике это выражается в росте числа TLS-серверов, используемых веб-проектами, а также в тенденции перехода от «самоподписанных сертификатов» к стандартным, поддерживаемым браузерами. Отмеченные факторы пока нельзя назвать определяющими: до момента, когда хотя бы половина веб-серверов Рунета будет поддерживать защищённый протокол HTTPS - ещё очень далеко. Положительная динамика заметна не только в изменении количества TLS-серверов, но и в том, как они настроены и используются: увеличивается доля корректно настроенных узлов, уменьшается число потенциально нестойких ключей.

На протяжении нескольких месяцев мы обработали сотни тысяч экземпляров SSL-сертификатов и выполнили миллионы запросов к TLS-серверам. На этой достаточно большой выборке пока не удалось выявить каких-то серьёзных отклонений в практической реализации в Рунете общей для Интернета инфраструктуры открытых ключей. Это достаточно позитивный результат.