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

Спустя примерно месяц, я вновь собрал SSL-сертификаты с серверов, на которые указывают домены .ru. Методика описана в прошлой записке по этой теме. Кратко повторю основные моменты: на первом этапе делается попытка определить адрес сервера (A-запись) для каждого из делегированных доменов (учитывая www.) в зоне .ru; из найденных серверов с уникальными IP выбираются те, у которых открыт 443-й порт (https); на заключительном этапе каждый из отобранных серверов опрашиваются на предмет SSL-сертификатов путём открытия https-сессии; собранные сертификаты разбираются при помощи OpenSSL.

В результатах “много цифр”, поэтому прячу под “Читать полностью”.

Итак, доменов, для которых удалось извлечь из DNS IP-адреса узлов, в этот раз набралось 2762616 против 2640639 в прошлом исследовании, прирост 121977 доменов (по состоянию на 09.11.11). Уникальных IP, соответствующих этим доменам – 187331 против 182858, прирост 4473 IP-адреса.

86334 – столько серверов оказались потенциально доступны по 443 порту (по состоянию на 27.11.11! тут получился заметный перерыв между опросом зоны и проверкой серверов). В прошлый раз доступных серверов обнаружилось 85219. Можно было бы предположить, что прирост составил 1115 узлов. Но, строго говоря, это не так. Доступность узлов в выборке (~187 тыс.) заметно меняется (+/- ~1000) даже на интервалах времени масштаба нескольких часов, и понять, какое число точное, затруднительно. Но это не так важно, потому что колебания не превышают одного процента от числа опрашиваемых узлов. Поэтому просто примем, что примерно 1000-1500 узлов добавилось.

Результаты

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

(В скобках – результат прошлого месяца и прирост).

Всего удалось собрать сертификатов: 91601 (87176; +4425)
Из них:

самоподписанные (issuer == subject): 54310 (52173; +2137)
localhost (в разных видах): 6118 (5998; +120)
snake oil (это удобный маркер тестовых конфигураций): 1032 (1042; -10)

Нужно заметить, что в двух последних случаях прирост находится за пределами погрешности, то есть, реальных изменений тут скорее всего просто нет. Можно предположить, что число совсем криво настроенных серверов растёт медленно.

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

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

(*0 – вне конкурса идёт localhost – 6118)

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

Уменьшилось число предустановленных сертификатов Plesk и LLC SCS Sovintel, все остальные – выросли. То есть, рынок прирастает коммерческими сертификатами. Но не только ими, как показывает рост числа самоподписанных сертификатов.

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

1. [plesk/emailAddress=info@plesk.com] = 3957 (4188)
2. [UTN-USERFirst-Hardware] = 1806 (1776)
3. [thawte Primary Root CA] = 1445 (1332)
4. [RapidSSL CA] = 1338 (1181)
5. [PositiveSSL CA] = 1078 (1034)
6. [Thawte SSL CA] = 1072 (989)
7. [GeoTrust Global CA] = 919 (763)
8. [Go Daddy Secure Certification Authority/serialNumber=07969287] = 868 (796)
9. [http://www.valicert.com//emailAddress=info@valicert.com] = 761 (685)
10. [Parallels Panel/emailAddress=info@parallels.com] = 727 (657)
11. [testnrgdebian5.ru/emailAddress=webmaster@testnrgdebian5.ru] = 681 (619)

Все выросли, кроме предустановленных “Plesk-ов”, что опять косвенно подтверждает наше довольно-таки очевидное предположение об увеличении доли коммерческих сертификатов.

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

Скопирую сюда пояснение из предыдущего исследования:

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

Длина ключа (слева – количество бит ключа; справа – число сертификатов; в скобках результат прошлого месяца):

1024: 51621 (49829)
2048: 38043 (35529)
4096: 1046 (983)
512: 718 (679)
1022: 12 (8)
1021: 12
768: 12
1023: 9
3072: 7
1020: 7
8192: 6
1030: 5
1019: 4
2922: 2
1028: 2
2064: 2
1018: 2
2024: 2
2084: 2
1536: 2
4196: 1
511: 1
4069: 1
1031: 1
2943: 1
2056: 1
1048: 1
1017: 1
4048: 1

Экспонента:

65537: 90361 (86119)
3: 1050 (881)
17: 54 (54)
47: 50
59: 5
35: 4
65535: 1

Всё вполне себе буднично. Прирост сосредоточен в области с добротными параметрами, аномальные значения так и остались редкими (например, администратор одного сервера не исправляет “уникальный” сертификат с 4048-битным ключом, который, к тому же, закончил действовать в октябре).

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

Два сертификата выписаны с датой окончания в 9999 году. А 62 закончили своё действие ещё в 1903 (впрочем, это сертификаты, которые специально сделаны невалидными, но, тем не менее, видны всему Интернету).

*

Найдено несколько сертификатов, выпущенных WatchGuard (Firebox/Firewire). Это сертификаты, которые использует одноимённый программно-аппаратный комплекс мониторинга трафика внутри корпоративных сетей (для инспекции https-трафика). В принципе, если этот самый WatchGuard настроен правильно, то его внутренние сертификаты должны не торчать наружу, а ограничиваться локальным прокси-сервером. Тем не менее, в реальности встречаются ошибки. Занятно, что следов других корпоративных инструментов мониторинга в рунетовских SSL-сертификатах пока найти не удалось. То ли используют редко, то ли настраивают хорошо.

Итоги

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

Адрес записки: https://dxdt.ru/2011/12/02/4280/