dxdt.ru: занимательный интернет-журнал

Как используется инфраструктура SSL-сертификатов в домене .ru? Я тут недавно попробовал посмотреть, в выходные. Для чего собрал сертификаты с узлов, на которые показывают домены .ru. Некоторые предварительные результаты – в этой заметке, но так как там довольно длинное описание с числами, то прячу его под “читать полностью”. Вообще, интересно будет делать регулярный мониторинг. Наверное, ежемесячно. И смотреть, что изменяется.

Итак, SSL-сертификаты и домен .RU.

Методика

Для делегированных доменов .ru делалась попытка определить адрес (A-запись) по следующей схеме: прежде всего запрашивался адрес для строки вида www.test.ru (то есть с www.), если соответствующей записи из DNS не удавалось извлечь, то делалась попытка определить адрес для test.ru. В результате, по состоянию на 05.10.11, удалось найти 182858 уникальных IP-адресов, на которые, соответственно, указывают имена третьего уровня www.* и имена второго уровня вида test.ru. (Для этого “резолвились” 2640639 доменов .ru. То есть, в среднем получается примерно 14 доменов на IP-адрес. Кстати, встречаются IP-адреса, на которые указывают десятки тысяч доменов. Рекорд тут принадлежит сервису парковки Sedo – более 130 тыс. доменов. Но это другая история. К тому же, известная.)

Далее, каждый из 182858 адресов cилами стандартного инструмента Nmap проверялся на предмет коннективности по порту 443. Это порт для соединений https. “Открытых” серверов (узлов) набралось 85219. То есть, около 47% серверов, хостящих сайты .ru, потенциально доступны по https. Обратите внимание: это не означает, что соответствующие веб-сайты действительно работают по https. На следующем шаге, с помощью слегка модифицированного скрипта из состава полезного проекта SSL observatory, с этих 47% узлов, обозначенных просканированными IP-адресами, были собраны SSL-сертификаты. А точнее, для каждого узла делалась попытка получить сертификат (сертификаты), открывая сессии TLS.

Тут нужно отметить несколько моментов. Во-первых, если говорить о веб-сайтах, то https так устроен, что на этапе установления соединения, в большинстве случаев хостинга, нельзя определить, к какому именно веб-сайту следует обращение. Поэтому для полноценной поддержки https сайту нужен отдельный IP-адрес. Естественно, на практике такое встречается не всегда. Так как мы исследуем серверы по IP-адресам, то к каждому из них будем приходить за сертификатами один раз, несмотря на то, что на данном конкретном узле могут находиться тысячи веб-сайтов (как и бывает в случае с виртуальным хостингом) – всю тысячу проверять смысла нет. (Хотя, некоторые серверы отвечают разными сертификатами на разные запросы. Но таких мало.)

Во-вторых, понятно, что “безопасные” веб-сайты (или какие-то другие сервисы, SSL/TLS используется не только для веба) могут быть размещены под доменами с другими названиями, отличными от выбранной схемы (www.site.tld или site.tld). Наиболее очевидные варианты: secure.site.tld, или mail.site.tld (для почтовых сервисов). Эти варианты адресации в рамках данного небольшого исследования не проверялись. (Наверное, нужно записать в список улучшений для следующих итераций.)

В-третьих, часть серверов, очевидно, была недоступна на момент обработки доменов или на момент сбора адресов, другая часть находилась в процессе обновления, или там ещё что-то с ними могло приключиться досадное. Это понятно. И тем не менее, повторного сбора данных по всему массиву пока что не проводилось. Но выборочно результаты проверялись.

Так что это не самое строгое исследование. Но, тем не менее, ситуацию иллюстрирует. Строгость будем вводить на следующих этапах.

Результаты

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

В итоге, 22.10.11, собрано 87176 SSL-сертификатов. Больше, чем опрошенных IP-адресов (~85 тыс.). Больше потому, что многие серверы используют промежуточные сертификаты, выданные УЦ, для подтверждения цепочки к своему собственному сертификату. Это обычная практика.

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

Собранные сертификаты “пропускались” через утилиту openssl для извлечения данных (самый логичный вариант обработки, да). И уже результаты, выданные openssl, обрабатывались/подсчитывались.

Итак, результаты исследования зоны .ru на предмет использования SSL-сертификатов:

Всего сертификатов: 87176

Из них:

“Самоподписанных” (Issuer == Subject): 52173
Выпущенных (в той или иной форме) для localhost: 5998
“Выданных” УЦ Snake Oil: 1042

(Примечание: Snake Oil – это такие явные и грубые следы прямого использования на сервере тестовой конфигурации mod_ssl или другого инструментария. Да, админ просто не потрудился настроить сервер. Бывает. Всего-то около 1000 узлов. Мало. В дальнейшем подсчёте Snake Oil не учитывается.)

Лидеры среди “условных УЦ” (это всего лишь значения поля CN, если оно заполнено, из Issuer, без группировки по реальным УЦ, которую, очевидно, не имело смысла делать, так как валидность сертификатов не проверялась; дано число обнаруженных сертификатов):

0. (*localhost* ожидаемо всех побеждает с результатом = 5998)

1. [plesk/emailAddress=info@plesk.com] = 4188
2. [AddTrust External CA Root] = 2909
3. [UTN-USERFirst-Hardware] = 2717
4. [Thawte Premium Server CA/emailAddress=premium-server@thawte.com] = 1875
5. [GeoTrust Global CA] = 1712
6. [LLC SCS Sovintel CA] = 1650
7. [thawte Primary Root CA] = 1619
8. [RapidSSL CA] = 1567
9. [http://www.valicert.com//emailAddress=info@valicert.com] = 1498
10. [PositiveSSL CA] = 1303
11. [Thawte SSL CA] = 1019

Лидеры среди “удостоверенных” (а это значения поля CN из Subject, то есть поля, обозначающего тот “объект”, который удостоверяет сертификат; localhost – изъят, потому что он опять на нулевом месте):

1. [plesk/emailAddress=info@plesk.com] = 4188 (да, “самоподписанные”)
2. [UTN-USERFirst-Hardware] = 1776
3. [thawte Primary Root CA] = 1332
4. [RapidSSL CA] = 1181
5. [PositiveSSL CA] = 1034
6. [Thawte SSL CA] = 989
7. [Go Daddy Secure Certification Authority/serialNumber=07969287] = 796
8. [GeoTrust Global CA] = 763
9. [http://www.valicert.com//emailAddress=info@valicert.com] = 685
10. [Parallels Panel/emailAddress=info@parallels.com] = 657
11. [testnrgdebian5.ru/emailAddress=webmaster@testnrgdebian5.ru] = 619

Среди лидеров оказался сертификат от Plesk. Предустанавливается на хостинг, как я понимаю. То есть, число свидетельствует о популярности данного хостингового инструментария. Примерно та же история и с LLC SCS Sovintel CA – сотни копий соответствующего сертификата видны на самых разных серверах.

Второй список, как и первый, заполнен упоминаниями общеизвестных удостоверяющих центров. Это ожидаемо: в выборке не выделялись промежуточные сертификаты, отдаваемые серверами, именно их мы и видим в большинстве случаев. Вообще, эти имена и числа указывают на уровень популярности реселлеров услуг западных УЦ. (Например, thawte Primary Root CA.)

Если удалить промежуточные сертификаты, то вполне ожидаемо на первые места по распространённости вылезают wildcard-сертификаты для доменных зон (интересно, что здесь уже лидирует .com – ситуация объясняется тем, что на тех же самых серверах размещаются и ресурсы, адресуемые доменами .ru, но сертификатов для них нет):

1. [*.bluehost.com] = 320
2. [*.hostgator.com] = 315
3. [*.hostmonster.com] = 261
4. [*.justhost.com] = 258
5. [*.hosting.reg.ru] = 219
6. [*.opentransfer.com] = 196
7. [*.timeweb.ru] = 192
8. [*.kasserver.com] = 156
9. [*.hc.ru] = 136
10. [*.gridserver.com] = 126
11. [*.home.pl] = 117

Криптографические свойства

С SSL-сертификатами связаны такие криптографические понятия, как длина используемого ключа и шифрующая экспонента. Существуют хорошо обоснованные рекомендации по выбору и длины ключа, и значения экспоненты, но я их не стану тут приводить. Впрочем, ключ длиной 512 и менее бит (речь про RSA) – в наше время не считается достаточно стойким. Хорошие длины ключей – 1024, 2048 бит. Большая длина – это избыточное решение. Экспоненту сейчас принято выбирать равной 65537.

Статистика по собранным сертификатам для зоны .ru выглядит вполне себе буднично:

Длина ключа, бит (число сертификатов для каждой длины):

1024: 49829
2048: 35529
4096: 983
512: 679
1021: 11
768: 9
3072: 8
1022: 8
8192: 6
1030: 5
1020: 5
1023: 5
1019: 3
1018: 3
2922: 2
1028: 2
2024: 2
2084: 2
1536: 2
4196: 1
3600: 1
511: 1
4069: 1
2047: 1
1031: 1
2943: 1
2056: 1
1017: 1
4048: 1

Особенно занятно смотрятся 11 сертификатов с длиной ключа 1021 бит. Но, в целом, всё в рамках современной традиции: подавляющее большинство сертификатов используют ключи в 1024 и 2048 бит. Аномальные ключи – единичны. Вероятно, это просто ошибки.

Экспоненты (значение экспоненты – слева, число сертификатов – справа):

65537: 86119
3: 881
17: 54
47: 40
35: 4
59: 3
19: 1
65535: 1

Опять же, всё оказалось ожидаемо: 65537 – свыше 95% сертификатов.

Занимательности

Нашлось около 400 самоподписанных сертификатов (среди них много копий), в описаниях которых указан Bitrix и Bitrixsoft. Встречаются на разнообразных веб-сайтах, естественно, работающих под управлением CMS “1С-Битрикс“. Это следы дистрибутива “Битрикса”, поставляемого в виде образа для виртуальной машины со всем набором программного обеспечения внутри. Выходит, что около 400 серверов (беглая проверка показала, что это, скорее всего, как раз виртуальные выделенные серверы одного из хостеров), работают с “битриксовой” виртуальной машиной, поддерживающей и https.

*

Четыре сертификата в поле Subject содержат следующую подстроку: “NOT SECURE!!!/emailAddress=INSTALL YOUR OWN CERTIFICATE”. Очевидно, не помогает.

*

В “диком виде” обнаружились сертификаты (две штуки найдено – на серверах, относящихся к litres.ru и euroset.ru), выпущенные Yandex Money Issuing CA. Процессинг платежей. (Корневой сертификат Yandex Money Root CA, SHA1: A0:2A:33:93:8B:FD:9B:FB:64:74:1C:D3:74:5F:9C:ED:39:AB:B8:D6).

Сертификатов, выпущенных YandexExternalCA – 20 шт.

*

Сертификаты от Google Internet Authority встречены на 6 серверах, связанных с зоной .ru, во всех случаях это сертификат для *.google.com. То есть, он часто используется “криво” (а что ещё ожидать от wildcard?). Например, этот сертификат предъявляет сервер, отвечающий по https://www.youtube.ru/. В других случаях на сервера Google указывают какие-то домены .ru, с “Гуглом” не связанные.

Итоги

Повсеместный доступ по https – примета безопасного Интернета. К сожалению, примета эта пока чисто теоретическая. В “дикой природе”, внутри зоны .ru, преобладают самоподписанные сертификаты из тестовых наборов, входящих в системные дистрибутивы. По https доступна лишь малая часть сайтов. При этом, без внедрения дополнительных мер, самоподписанные сертификаты в принципе не годятся на роль средства повышения безопасности.

Адрес записки: https://dxdt.ru/2011/10/26/4168/