06.08 // Инфраструктура удостоверяющих центров X.509: патологоанатомический осмотр
Фонд электронных границ (EFF) готовит к публикации данные исследования EFF Observatory. В рамках инициативы была собрана полная коллекция всех публичных SSL-сертификатов веб-сайтов, доступных в Сети. Фонд обещает предоставить данные всем заинтересованным исследователям для дальнейшей работы (как в исходном виде, так и в виде базы SQL), но ряд увлекательных выводов можно сделать уже сейчас.
- 16 миллионов хостов в IP-адресном пространстве слушают порт 443. SSL поддерживают 10.8 миллионов. Из них, 4.3 миллиона используют УЦ-заверенные сертификаты. Таким образом, большинство SSL-сертификатов — самоподписанные.
- Помимо безусловного доверия огромному числу корневых УЦ, каждый браузер наследует от них доверие к столь же доверяемым промежуточным УЦ, принадлежащим коммерческим фирмам и правительственным организациям (например, Министерству внутренней безопасности США, Форду и Гуглу). Windows и Firefox наследуют доверие к 1482 таким сертификатам (651 организация).
- Многие УЦ заверяют зарезервированные адреса. Например, 192.168.1.2.
- Имя, заверенное наибольшее количество раз — "localhost" (шесть тысяч уникальных сертификатов). Многие УЦ подписывали его по несколько раз, явственно свидетельствуя, что не прочь выдавать дубликатные сертификаты (к тому же на локальные имена).
- В базах браузеров присутствуют два [доверенных наравне с прочими] сертификата с 512-битовыми модулями RSA. Их ещё не факторизовали?
- OpenSSL в Debian генерировал неслучайные ключи, но УЦ об этом, похоже, не знают: 530 таких ключей используются в SSL-сертификатах. Лишь 73 из них были аннулированы.
Источник: http://www.eff.org/files/DefconSSLiverse.pdf
Я плохо представляю, что будет делать браузер. увидев что сайт предъявляет серт, в то время как подпись была выдана не на доменное имя, а на "какой-то localhost". Разве не будет ругани? Или там вместо человека в УЦ сертификаты подписывает сертификатоподписочная машинка?
Я бы, будучи на месте хакер0в, обеспокоился бы такой ситуацией :) Интересно, насколько сложно факторизовать (в днях на кластере среднего пошиба)?
Т.е. такие бажные ключи используются в качестве сертификатов конечных сайтов или сертификатов самих УЦ? Если второй вариант, то это совсем ололо.
комментариев: 1060 документов: 16 редакций: 32
Нет, он может удостоверять любые данные.
Будет ругань о несоответствии доменного имени и записи в сертификате.
Вполне. Многие УЦ выдают сертификаты в течение нескольких минут. Едва ли это вручную делается.
комментариев: 1060 документов: 16 редакций: 32
В базах браузеров содержатся именно сертификаты УЦ.
комментариев: 11558 документов: 1036 редакций: 4118
Один сертификат может содержать несколько альтернативных имён — поле subjectAltName. То есть в CommonName может значиться какое-нибудь johnsmith.com, а в subjectAltName — localhost. В обоих случаях браузер посчитает сертификат достоверным.
Я бы даже сказал, только сертификатоподписочная машинка. Разве что для EV-сертификатов (Extended Validation) процедура более обстоятельная. Формально.
Неделя-месяц, плюс-минус.
В данном случае речь о сертификатах сайтов. Ололо заключается в том, что УЦ заверяют такие сертификаты, то есть кагбэ поручаются в их надёжности,* при том, что они совершенно ненадёжны. И даже если допустить, что какие-то из них были заверены больше двух с лишним лет назад (увы, в презентации об этом не говорится), как видите, аннулировано только 13%. Кстати, не менее интересно, было ли аннулирование инициировано удостоверяющими центрами или же самими владельцами, решившими обновить свои потенциально скомпрометированные сертификаты.
* С формальной точки зрения, они заверяют тот факт, что сертификат принадлежит владельцу данного домена, однако, подобный формализм не даёт им права заверять (или не аннулировать) сертификат, когда есть основания подозревать его компрометацию.
Я имел в виду нет ли сейчас такой ситуации, когда какой-то из самих сертификатов УЦ уязвим, что позволило бы злоумышленнику быстро вычислить "приватный ключ" и самому нагенерить сертификатов под любой наперёд заданный сайт, безоговорочно принимаемых любым браузером, что потцнеиально могло бы вообще порушить всю инфраструктуру SSL. В такого ололо нет? Апогеем было бы именно это, наглядней и не придумать :)
Не уверен. Как раз, согласно формализму, они заверяют, что сертификат предоставлен владельцем домена, а есть ли какие-то проблемы со стойкостью сертификата — не должно их волновать, бо то — головная боль владельца. Иначе это является наделением УЦ несвойственными ему полномочиями "для общего блага". Чисто технически УЦ будет обязан ставить какой-то спецсофт и проверять, не является ли предъявляемый серт уязвимым — т.е. дополнительные сложности.
комментариев: 11558 документов: 1036 редакций: 4118
Браузер (или любое другое приложение, принимающее аттестации УЦ) сверяет поля CommonName/subjectAltName с содержимым адресной строки (или как там данная конкретная программа адресует хоста). Если они совпадают, то что ещё должно волновать? Технически, нет никаких проблем, чтобы получить сертификат на 217.16.21.152 вместо pgpru.com. Если пользователь будет заходить на сайт именно по IP-адресу, браузер не скажет ни слова.
Конкретно с бажными ключами из Debian — не знаю, на слайдах об этом не говорится. А 512 битовый модуль RSA Вас не волнует? Вроде как целиком подпадает под Ваш вопрос, разве что потратить придётся не долю секунды, а несколько больше.
Ещё раз прочтите, что я написал: дело не в стойкости, а в основаниях подозревать компрометацию. Verisign ведь спустя неделю (sic) всё же аннулировал сертификат Realtek, которым был подписан Stuxnet, причина ровно та же.
Есть такая вещь, как best practices. Попробуйте передать на подпись УЦ сертификат со 128-битовым открытым ключом.
Кстати, действительно, могут найтись УЦ, которые и 128-битовый открытый ключ подпишут, и кого не волнует, что ключ находится в чёрном списке 260 тыс. Debian-ключей... если в нормативной документации УЦ говорится, что их волнует только соответствие CommonName. Весь идиотизм ситуации заключается в том, что такие УЦ доверяемы в той же самой мере, как и те, которые действительно делают что-то для обеспечения безопасности.
комментариев: 11558 документов: 1036 редакций: 4118
Как прикрыть? Создать новый корневой сертификат, обновить его во всех браузерах и заставить всех пользователей обновить браузеры? Интересно, почему они этого до сих пор не сделали?
Ну да, тех, знает, что такое УЦ и SSL-сертификат. Много ли таких (не на этом сайта)?
комментариев: 9796 документов: 488 редакций: 5664
Взлом 512-RSA в ходе научных исследований был продемонстрирован в 1999 году на большом кластере за семь месяцев.
В 2009 году 512-битовый ключ RSA был факторизован одиночкой с помощью публичного доступного ПО за 73 дня на одном десктопном компьютере:
Подробности здесь
Так может затем и деражат УЦ с 512битовыми сертами, чтобы государства при надобности прослушки факторизовывали сами ключ и подписывали им всё что хотели? Более странно то, что разработчики браузеров не ввели функционал "ругаться, если длина ключа УЦ меньше некоторой". А если я сам сделаю для себя УЦ с 64битным сертом, смогу ли я такой серт импортировать в браузер без ругани?
[/параноя mode]
комментариев: 9796 документов: 488 редакций: 5664
И это лишь один из множества способов.
Риторический вопрос в том, почему вообще им пользуются, а не признают официально мёртвым и закопают? А то патологоанатомы негодуют.
Ну или хотя бы объявят открытое проектирование нового стандарта.
комментариев: 11558 документов: 1036 редакций: 4118
Из слайдов:
Список CA в браузере отсортировал по алфавиту и вручную выбрал то, что начинается с "Equifax" и "Thawte", сертификатов с такими отпечатками нету. Не так ищу?
FF 3.5.8, Ubuntu 9.10 :-[
А быстро обновить список сертификатов у значительной части пользователей реально – Firefox апдейтится, не спрашивая пользователя, Google Chrome тоже (кстати, видали их установщик-в-один-клик? "Превращаем ваш компьютер в конфетку. Откиньтесь на спинку кресла и ни о чём не думайте. *На базе Android". А пользователи, небось, в восторге), MS может IE обновлять через Windows Update. Если броузер не обновляется, то он в любом случае уязвим для более серьёзных атак.