Стали известны дополнительные подробности причин экстренного обновления черных списков SSL-сертификатов в Firefox (http://www.opennet.me/opennews/art.shtml?num=29998), Chrome/Chromium (http://googlechromereleases.blogspot.com/2011/03/stable-and-... и других web-браузерах. По данным (https://blog.torproject.org/blog/detecting-certificate-autho... из блога разработчиков проекта Tor злоумышленникам удалось получить восемь валидных HTTPS-сертификатов для ряда известных web-ресурсов, среди которых сайты Facebook, Skype, Google, Microsoft и Mozilla (реально, поддельных сертификатов может быть больше, в трафике сети Tor было выявлено 8).
Предполагается, что подобное стало возможным в результате компрометации центра сертификации Comodo (CA (http://ru.wikipedia.org/wiki/%D0%A6%D0%B.... Используя данные сертификаты злоумышленники могут...URL: https://blog.torproject.org/blog/detecting-certificate-autho...
Новость: http://www.opennet.me/opennews/art.shtml?num=30010
>одного из центров сертификацииКакого именно, не известно? Если неизвестно, то почему, можно ведь отследить цепочку подписей?
Написано же:> Предполагается, что подобное стало возможным в результате компрометации
> центра сертификации Comodo (CA).
> центра сертификации Comodo (CA).Да, вижу, что теперь уже написали.
Ну, Comodo - оно и есть Comodo. Плохо, что существующая система с глобальными интернет-нотариусами может привести к таким последствиям.
> Да, вижу, что теперь уже написали.Представь себе, и об этом:
> Плохо, что существующая система с глобальными интернет-нотариусами может привести к таким последствиям.
- этот самый "разработчик Tor" ioerror "уже написал". Длинно и разнообразно.
> может быть больше, 8 выявлено в трафике сети Tor.Разработчик Tor анализирова открытые источники (списки отозванных сертификатов по "интернетам") в поисках "очернённых" броузеростроителями _серийных _номеров сертификатов. Нашёл 8, по ним -- выдавший ЦА, перепродавца Комодовского "авторитета".
Никакого "трафика сети Tor", совсем.
Максимум: сказал, что аналогичные блэклисты-затычки для Tor ещё в разработке.
Все равно никакого "трафика Tor"....>> получить поддельные SSL-сертификаты
И кстати, про $SUBJ: сертификаты-то настоящие B) , их "просто" удалось получить "кому-то не тому", насколько я ничего не понимаю.
я тоже именно так непонял
>В худшем случае данный инцидент может поставить >под угрозу сам принцип организации иерархии >удостоверяющих центров.Принцип то гнилой,давно пора.
Принцип не гнилой. Гнилой сам подход к его реализации в некоторых клиентских программах и браузерах, когда по умолчанию сертификаты ПРОХОДЯТ проверку при отсутствии доступа к серверу OCSP (серверу, содержащими список отозванных сертификатов). В частности, в Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к серверу OCSP. В настройках Дополнительные -> Шифрование -> Настройки OCSP можно изменить это злосчастное умолчание, если взвести галочку "При ошибке соединения с сервером OCSP, рассматривать сертификат как недействительный". ;)
Принцип гнилой ? А сам протокол ? Я так понимаю если соединение устанавливается по открытому каналу, и на клиенте изначально нет секретного ключа, то сев на канал в момент установки соединения можно снять все исходные данные для дальнейшей расшифровки.
Ты того ... матчасть вначале изучи а потом уж на пол-мира позорься :)
Правильно, что разлогинился перед тем, как такой бред писать :) Почитай как работает ассиметричное шифрование.- Клиент скачивает с сервера сертификат (открытый ключ).
- Потом клиент генерирует сеансовый ключ,
- Зашифровывает его открытым ключом (сертификатом). Расшифровать сеансовый ключ может ТОЛЬКО сервер (ибо только у него есть закрытая часть ключа).
- Сеансовый ключ отсылается серверу (отсылается он ЗАШИФРОВАННЫЙ открытым ключом).Потом соединение шифруется уже сеансовым ключ. Итого, закрытый/открытый ключ нужен только для того чтоб обменяться сеансовым ключом
> Правильно, что разлогинился перед тем, как такой бред писать :) Почитай как
> работает ассиметричное шифрование.
> - Клиент скачивает с сервера сертификат (открытый ключ).
> - Потом клиент генерирует сеансовый ключ,
> - Зашифровывает его открытым ключом (сертификатом). Расшифровать сеансовый ключ может
> ТОЛЬКО сервер (ибо только у него есть закрытая часть ключа).
> - Сеансовый ключ отсылается серверу (отсылается он ЗАШИФРОВАННЫЙ открытым ключом).
> Потом соединение шифруется уже сеансовым ключ. Итого, закрытый/открытый ключ нужен только
> для того чтоб обменяться сеансовым ключомМожет быть он наслушался про MIM и неправильно себе представляет эту атаку?
Дык читал, и дырку вижу, хотя может просто чего то и недопонял, вы не кипешуйте так, если объясните в чем я не прав и чего не понимаю то буду вам весьма благодарен.Мы посередине. Значит в начале можем вместо сертификата сервера подсунуть клиенту свой (самоподписанность также обходится), и соответственно расшифровать его запрос, т.к. алгоритм формирования сеансового ключа известен и закрытая часть ключа у нас есть. Далее расшифровав клиентский запрос мы формируем и отправляем серверу свой запрос, как будто мы изначальный клиент, и далее действуем как прокси, ну и собственно все.
А-а-, дак вы имеете в виду Man-In-the- Middle атаку. Ну дак и в чем тут гнилость протокола? Если вы предоставили клиенту КОРРЕКТНЫЙ сертификат, подменили DNS-запись, то какие претензии к протоколу то? Может это DNS гнилой? :) Или ARP? :) По-вашему получается гнилое все ассиметричное шифрование, как класс.
Все так. Поэтому и существуют CA, чьи сертификаты распространяются вместе с браузером и которые подтверждают аутентичность сертификата сервера.
В чем гнилость протокола и какие есть еще варианты?
сценарий такой только при использовании rsa; возможен также вариант с diffie-hellman
напомнило http://community.livejournal.com/ctrlaltdel_rus/427626.html
Недавно отказался от получения сертификата от COMODO и видать правильно, если их корневой сертификат был скомпрометирован.
Доходчиво и ясно: http://habrahabr.ru/blogs/infosecurity/116084/
wow! даже микрософты подсуетились и выпустили секурапдейт
http://go.microsoft.com/fwlink/?LinkId=214214viva la microsofta!
Вот мне интерестно почему у Comodo не вызвало подозрение то, что ВНЕЗАПНО одновременно гуглу, яху, скайпу и мозилле понадобились сертификаты?
Они же не вручную создаются.
Пришёл заказ -> снялись деньги -> поставилась подписьЛюди обычно смотрят когда что-то стопорится, идёт не так.
Это понятно, но система же должна реагировать как-то, когда на домен, для которого есть существующий и действенный сертификат хотят получить новый. Тут должна происходить какая-то подстраховка.
ну ничего ж не мешает Comodo иметь blacklist`ы