id: Гость   вход   регистрация
текущее время 06:27 06/12/2019
Владелец: SATtva (создано 06/08/2010 18:40), редакция от 06/08/2010 18:40 (автор: SATtva) Печать
Категории: криптография, управление ключами, стандарты, x.509, ssl
https://www.pgpru.com/Новости/2010/ИнфраструктураУдостоверяющихЦентровX509ПатологоанатомическийОсмотр
создать
просмотр
редакции
ссылки

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 из них были аннулированы.

Источник: filehttp://www.eff.org/files/DefconSSLiverse.pdf


 
На страницу: 1, 2 След.
Комментарии [скрыть комментарии/форму]
— Гость (07/08/2010 00:31)   <#>
Многие УЦ заверяют зарезервированные адреса. Например, 192.168.1.2.
УЦ должен заверять доменное имя, разве нет? Как он может заверять IP-адрес?

Имя, заверенное наибольшее количество раз — "localhost" (шесть тысяч уникальных сертификатов).
Я плохо представляю, что будет делать браузер. увидев что сайт предъявляет серт, в то время как подпись была выдана не на доменное имя, а на "какой-то localhost". Разве не будет ругани? Или там вместо человека в УЦ сертификаты подписывает сертификатоподписочная машинка?

В базах браузеров присутствуют два [доверенных наравне с прочими] сертификата с 512-битовыми модулями RSA. Их ещё не факторизовали?
Я бы, будучи на месте хакер0в, обеспокоился бы такой ситуацией :) Интересно, насколько сложно факторизовать (в днях на кластере среднего пошиба)?

OpenSSL в Debian генерировал неслучайные ключи, но УЦ об этом, похоже, не знают: 530 таких ключей используются в SSL-сертификатах. Лишь 73 из них были аннулированы.
Т.е. такие бажные ключи используются в качестве сертификатов конечных сайтов или сертификатов самих УЦ? Если второй вариант, то это совсем ололо.
— Гость (07/08/2010 01:16)   <#>
Там несколько интересных графиков. Намекают на то, что всего 10% УЦ подписывают 99% всех сайтовых сертификатов? Ещё на слайдах пишут, что есть серьёзные подозрения в том, что ряд УЦ генерят сертификаты сообща, т.е. не являются независимыми. Интересно, конечно, было бы узнать что скажет это исследование по поводу злоупотреблений сертификатами и прослушки, но на этот счёт там молчок :(
— sentaus (07/08/2010 12:14)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
УЦ должен заверять доменное имя, разве нет? Как он может заверять IP-адрес?

Нет, он может удостоверять любые данные.

Разве не будет ругани?

Будет ругань о несоответствии доменного имени и записи в сертификате.


Или там вместо человека в УЦ сертификаты подписывает сертификатоподписочная машинка?

Вполне. Многие УЦ выдают сертификаты в течение нескольких минут. Едва ли это вручную делается.
— sentaus (07/08/2010 12:15)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Т.е. такие бажные ключи используются в качестве сертификатов конечных сайтов или сертификатов самих УЦ?

В базах браузеров содержатся именно сертификаты УЦ.
— SATtva (07/08/2010 17:53, исправлен 07/08/2010 19:56)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Я плохо представляю, что будет делать браузер. увидев что сайт предъявляет серт, в то время как подпись была выдана не на доменное имя, а на "какой-то localhost". Разве не будет ругани?

Один сертификат может содержать несколько альтернативных имён — поле subjectAltName. То есть в CommonName может значиться какое-нибудь johnsmith.com, а в subjectAltName — localhost. В обоих случаях браузер посчитает сертификат достоверным.


Или там вместо человека в УЦ сертификаты подписывает сертификатоподписочная машинка?

Вполне. Многие УЦ выдают сертификаты в течение нескольких минут. Едва ли это вручную делается.

Я бы даже сказал, только сертификатоподписочная машинка. Разве что для EV-сертификатов (Extended Validation) процедура более обстоятельная. Формально.


Интересно, насколько сложно факторизовать (в днях на кластере среднего пошиба)?

Неделя-месяц, плюс-минус.


Т.е. такие бажные ключи используются в качестве сертификатов конечных сайтов или сертификатов самих УЦ?

В базах браузеров содержатся именно сертификаты УЦ.

В данном случае речь о сертификатах сайтов. Ололо заключается в том, что УЦ заверяют такие сертификаты, то есть кагбэ поручаются в их надёжности,* при том, что они совершенно ненадёжны. И даже если допустить, что какие-то из них были заверены больше двух с лишним лет назад (увы, в презентации об этом не говорится), как видите, аннулировано только 13%. Кстати, не менее интересно, было ли аннулирование инициировано удостоверяющими центрами или же самими владельцами, решившими обновить свои потенциально скомпрометированные сертификаты.


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

— Гость (08/08/2010 04:31)   <#>
УЦ должен заверять доменное имя, разве нет? Как он может заверять IP-адрес?
Нет, он может удостоверять любые данные.
Вопрос не в том, что он может заверить, а в том, что он должен заверить, чтобы не было ругани от браузера.

В данном случае речь о сертификатах сайтов. Ололо заключается в том, что УЦ заверяют такие сертификаты, то есть кагбэ поручаются в их надёжности
Я имел в виду нет ли сейчас такой ситуации, когда какой-то из самих сертификатов УЦ уязвим, что позволило бы злоумышленнику быстро вычислить "приватный ключ" и самому нагенерить сертификатов под любой наперёд заданный сайт, безоговорочно принимаемых любым браузером, что потцнеиально могло бы вообще порушить всю инфраструктуру SSL. В такого ололо нет? Апогеем было бы именно это, наглядней и не придумать :)

подобный формализм не даёт им права заверять (или не аннулировать) сертификат, когда есть основания подозревать его компрометацию.
Не уверен. Как раз, согласно формализму, они заверяют, что сертификат предоставлен владельцем домена, а есть ли какие-то проблемы со стойкостью сертификата — не должно их волновать, бо то — головная боль владельца. Иначе это является наделением УЦ несвойственными ему полномочиями "для общего блага". Чисто технически УЦ будет обязан ставить какой-то спецсофт и проверять, не является ли предъявляемый серт уязвимым — т.е. дополнительные сложности.
— SATtva (08/08/2010 12:12)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Вопрос не в том, что он может заверить, а в том, что он должен заверить, чтобы не было ругани от браузера.

Браузер (или любое другое приложение, принимающее аттестации УЦ) сверяет поля CommonName/subjectAltName с содержимым адресной строки (или как там данная конкретная программа адресует хоста). Если они совпадают, то что ещё должно волновать? Технически, нет никаких проблем, чтобы получить сертификат на 217.16.21.152 вместо pgpru.com. Если пользователь будет заходить на сайт именно по IP-адресу, браузер не скажет ни слова.

Я имел в виду нет ли сейчас такой ситуации, когда какой-то из самих сертификатов УЦ уязвим, что позволило бы злоумышленнику быстро вычислить "приватный ключ" и самому нагенерить сертификатов

Конкретно с бажными ключами из Debian — не знаю, на слайдах об этом не говорится. А 512 битовый модуль RSA Вас не волнует? Вроде как целиком подпадает под Ваш вопрос, разве что потратить придётся не долю секунды, а несколько больше.

Не уверен. Как раз, согласно формализму, они заверяют, что сертификат предоставлен владельцем домена, а есть ли какие-то проблемы со стойкостью сертификата — не должно их волновать

Ещё раз прочтите, что я написал: дело не в стойкости, а в основаниях подозревать компрометацию. Verisign ведь спустя неделю (sic) всё же аннулировал сертификат Realtek, которым был подписан Stuxnet, причина ровно та же.

Иначе это является наделением УЦ несвойственными ему полномочиями "для общего блага". Чисто технически УЦ будет обязан ставить какой-то спецсофт и проверять, не является ли предъявляемый серт уязвимым — т.е. дополнительные сложности.

Есть такая вещь, как best practices. Попробуйте передать на подпись УЦ сертификат со 128-битовым открытым ключом.

Кстати, действительно, могут найтись УЦ, которые и 128-битовый открытый ключ подпишут, и кого не волнует, что ключ находится в чёрном списке 260 тыс. Debian-ключей... если в нормативной документации УЦ говорится, что их волнует только соответствие CommonName. Весь идиотизм ситуации заключается в том, что такие УЦ доверяемы в той же самой мере, как и те, которые действительно делают что-то для обеспечения безопасности.
— Гость (08/08/2010 12:30)   <#>
А 512 битовый модуль RSA Вас не волнует? Вроде как целиком подпадает под Ваш вопрос, разве что потратить придётся не долю секунды, а несколько больше.
Волнует, но по этому поводу я уже высказался выше. В том-то и дело, что здесь "не долю секунды, а несколько больше", т.е. нужны определённые ресурсы и время, и пока оно будет вычисляться дыру могут и прикрыть. P.S.: Certificate Patrol всех спасёт :)
— SATtva (08/08/2010 12:34)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
В том-то и дело, что здесь "не долю секунды, а несколько больше", т.е. нужны определённые ресурсы и время, и пока оно будет вычисляться дыру могут и прикрыть.

Как прикрыть? Создать новый корневой сертификат, обновить его во всех браузерах и заставить всех пользователей обновить браузеры? Интересно, почему они этого до сих пор не сделали?

Certificate Patrol всех спасёт

Ну да, тех, знает, что такое УЦ и SSL-сертификат. Много ли таких (не на этом сайта)?
— Гость (08/08/2010 12:44)   <#>
Создать новый корневой сертификат, обновить его во всех браузерах и заставить всех пользователей обновить браузеры?
Ну да. Никого же не удивляет, что винда по умолчанию обновляет сама себя без спроса пользователя, к примеру. Может и сертификат обновить. Можно поднять шум в прессе и добиться того, что число уязвимых браузеров уменьшится в сотни раз. Пока ключ будет пол года вычисляться, эффективность атаки в итоге может упать до невыгодной. Хотя в любом случае интригующе, да. Фишеры должны прыгать от счастия :)
— unknown (09/08/2010 12:49, исправлен 09/08/2010 12:53)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
т.е. нужны определённые ресурсы и время, и пока оно будет вычисляться дыру могут и прикрыть.

Взлом 512-RSA в ходе научных исследований был продемонстрирован в 1999 году на большом кластере за семь месяцев.


В 2009 году 512-битовый ключ RSA был факторизован одиночкой с помощью публичного доступного ПО за 73 дня на одном десктопном компьютере:

dual-core Athlon64 at 1900 MHz. Just under 5 gigabytes of disk was required and about 2.5 gigabytes of RAM for the sieving process.

Подробности здесь

— Гость (09/08/2010 21:54)   <#>
[параноя mode]
Так может затем и деражат УЦ с 512битовыми сертами, чтобы государства при надобности прослушки факторизовывали сами ключ и подписывали им всё что хотели? Более странно то, что разработчики браузеров не ввели функционал "ругаться, если длина ключа УЦ меньше некоторой". А если я сам сделаю для себя УЦ с 64битным сертом, смогу ли я такой серт импортировать в браузер без ругани?
[/параноя mode]
— unknown (10/08/2010 11:46)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Так может затем и деражат УЦ с 512битовыми сертами, чтобы государства при надобности прослушки факторизовывали сами ключ и подписывали им всё что хотели?


И это лишь один из множества способов.

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

Ну или хотя бы объявят открытое проектирование нового стандарта.
— SATtva (10/08/2010 18:05)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Боюсь, что моё предположение прозвучит слишком банально и пошло, но причина — деньги. Ни одна индустрия, продающая воздух, в здравом уме не откажется от своего положения. Посмотрите на контент-индустрию как пример: все понимают, что три миллиарда нарушителей закона — это абсурд (пора менять закон, раз статус-кво настолько изменился), но статус-кво слишком выгоден.
— Гость (17/08/2010 22:22)   <#>
Что-то не могу найти эти 512-битовые сертификаты CA в Firefox'е.

Из слайдов:
Signed by Equifax and Thawte
Valid under Mozilla and Microsoft’s trust roots
Fingerprints:
B4:21:9E:89:24:29:41...
7B:BB:1B:CF:FD:6A:1A...


Список CA в браузере отсортировал по алфавиту и вручную выбрал то, что начинается с "Equifax" и "Thawte", сертификатов с такими отпечатками нету. Не так ищу?
FF 3.5.8, Ubuntu 9.10 :-[

А быстро обновить список сертификатов у значительной части пользователей реально – Firefox апдейтится, не спрашивая пользователя, Google Chrome тоже (кстати, видали их установщик-в-один-клик? "Превращаем ваш компьютер в конфетку. Откиньтесь на спинку кресла и ни о чём не думайте. *На базе Android". А пользователи, небось, в восторге), MS может IE обновлять через Windows Update. Если броузер не обновляется, то он в любом случае уязвим для более серьёзных атак.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3