Як використовується інфраструктура SSL-сертифікатів в домені .ru? Я тут недавно спробував подивитися, у вихідні. Для чого зібрав сертифікати з вузлів, на які показують домени .ru. Деякі попередні результати - в цій замітці, але так як там досить довгий опис з числами, то ховаю його під "читати повністю". Взагалі, цікаво буде робити регулярний моніторинг. Напевно, щомісяця. І дивитися, що змінюється.
Отже, SSL-сертифікати і домен .RU.
Так що це не найсуворіше дослідження. Але, тим не менш, ситуацію ілюструє. Строгість будемо вводити на наступних етапах.
85 тис.). Більше тому, що багато серверів використовують проміжні сертифікати, видані УЦ, для підтвердження ланцюжка до свого власного сертифікату. Це звичайна практика.
Обчислювальні ресурси заощаджувалися, тому валідації зібраних сертифікатів я не проводив. Або так: поки що не проводив, перевірка планується. Але вже зараз зрозуміло, що більшість сертифікатів - свідомо невалидность з точки зору типового браузера (див. Нижче).
Зібрані сертифікати "пропускалися" через утиліту openssl для вилучення даних (самий логічний варіант обробки, так). І вже результати, видані openssl, оброблялися / підраховувалися.
Отже, результати дослідження зони .ru на предмет використання SSL-сертифікатів:
Всього сертифікатів: 87176
"Самоподпісанного" (Issuer == Subject): 52173
Випущених (в тій чи іншій формі) для localhost. 5998
"Виданих" УЦ Snake Oil. тисяча сорок дві
(Примітка: Snake Oil - це такі явні і грубі сліди прямого використання на сервері тестової конфігурації mod_ssl або іншого інструментарію. Так, адмін просто не потрудився налаштувати сервер. Буває. Всього-то близько 1000 вузлів. Мало. Надалі підрахунку Snake Oil не враховується .)
Лідери серед "умовних УЦ" (це всього лише значення поля CN, якщо воно заповнене, з Issuer, без угруповання за реальними УЦ, яку, очевидно, не мало сенсу робити, так як валідність сертифікатів не перевіряв; дано число виявлених сертифікатів):
0. (* localhost * очікувано всіх перемагає з результатом = 5998)
Лідери серед "засвідчених" (а це значення поля CN з Subject, тобто поля, що позначає той "об'єкт", який засвідчує сертифікат; localhost - вилучено, бо він знову на нульовому місці):
Серед лідерів виявився сертифікат від Plesk. Передвстановлюють на хостинг, як я розумію. Тобто, число свідчить про популярність даного хостінгового інструментарію. Приблизно та ж історія і з LLC SCS Sovintel CA - сотні копій відповідного сертифіката видно на самих різних серверах.
Другий список, як і перший, заповнений згадками загальновідомих засвідчувальних центрів. Це очікувано: у вибірці не виділялися проміжні сертифікати, що віддаються серверами, саме їх ми і бачимо в більшості випадків. Взагалі, ці імена і числа вказують на рівень популярності реселерів послуг західних УЦ. (Наприклад, thawte Primary Root CA.)
З SSL-сертифікатами пов'язані такі криптографічні поняття, як довжина використовуваного ключа і шифрующая експонента. Існують добре обґрунтовані рекомендації щодо вибору і довжини ключа, і значення експоненти, але я їх не стану тут приводити. Втім, ключ довжиною 512 і менше біт (мова про RSA) - в наш час не вважається досить стійким. Хороші довжини ключів - 1024, 2048 біт. Велика довжина - це надмірне рішення. Експоненту зараз прийнято вибирати рівний 65537.
Статистика за зібраними сертифікатами для зони .ru виглядає цілком собі буденно:
Довжина ключа, біт (число сертифікатів для кожної довжини):
Особливо цікаво виглядають 11 сертифікатів з довжиною ключа 1021 біт. Але, в цілому, все в рамках сучасної традиції: переважна більшість сертифікатів використовують ключі в 1024 і 2048 біт. Аномальні ключі - поодинокі. Ймовірно, це просто помилки.
Експоненти (значення експоненти - зліва, число сертифікатів - праворуч):
Знову ж таки, все виявилося очікувано: 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 шт.
Повсюдний доступ по https - прикмета безпечного Інтернету. На жаль, прикмета ця поки чисто теоретична. В "дикій природі", всередині зони .ru, переважають самоподпісанного сертифікати з тестових наборів, що входять в системні дистрибутиви. За https доступна лише мала частина сайтів. При цьому, без впровадження додаткових заходів, самоподпісанного сертифікати в принципі не годяться на роль засобу підвищення безпеки.
Схожі записки:
Далі - думки і дискусії
(Повідомлення нижче додаються читачами сайту, через форму, розташовану в кінці сторінки.)
це - загальна тенденція, або російська специфіка?
Я юзаю їх безкоштовні сертифікати, правда (1) на xmpp-серверах (2) не в зоні .ru
Що стосується специфіки - по-моєму, особливої специфіки тут немає, SSL всюди реалізують як доведеться.
Про StartSSL: я так розумію, це StartCom. Такі зустрічаються досить часто:
[StartCom Certification Authority]
720 сертифікатів, [StartCom Class 1 Primary Intermediate Server CA]
моя імха вважає, що для того, щоб прикрити канал від зовсім вже халявного вилову паролів і т.п. вистачить і самопали.
"Підтверджувати справжність" з урахуванням можливої компрометації СА - якось воно того ...
да, зрозуміло, що мен-ін-зе-мідл ефективно херіт саморобки, але незрозуміло, як оцінювати ризики.