The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

23.03.2011 17:04  Злоумышленникам удалось получить поддельные SSL-сертификаты (дополнено)

Стали известны дополнительные подробности причин экстренного обновления черных списков SSL-сертификатов в Firefox, Chrome/Chromium и Internet Explorer. По данным из блога разработчиков проекта Tor злоумышленникам удалось получить девять валидных HTTPS-сертификатов для ряда известных web-ресурсов, из которых подтвержден только поддельный сертификат для addons.mozilla.org, название остальных сайтов неизвестно.

Предполагается, что подобное стало возможным в результате компрометации центра сертификации Comodo (CA). Используя данные сертификаты злоумышленники могут сформировать поддельный сайт, который будет неотличим от настоящего и будет содержать не вызывающий подозрение SSL-сертификат. Перенаправить пользователя на подобные сайты можно организовать используя, например, атаки man-in-middle или отравление DNS-кэша. Подробности случившегося пока не сообщаются, возможно сертификаты получены через официальные каналы обманным путем, используя методы социальной инженерии. В худшем случае данный инцидент может поставить под угрозу сам принцип организации иерархии удостоверяющих центров.

Дополнение: Компания Comodo, спустя восемь дней с момента обнаружения проблемы, опубликовала заявление в котором обобщила суть произошедшего инцидента. Подробнее о случившемся и возможных последствиях инцидента можно прочитать здесь.

  1. Главная ссылка к новости (https://blog.torproject.org/bl...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: cert, security, ssl
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Marbleless (?), 17:17, 23/03/2011 [ответить] [показать ветку] [···]    [к модератору]
  • –1 +/
    >одного из центров сертификации

    Какого именно, не известно? Если неизвестно, то почему, можно ведь отследить цепочку подписей?

     
     
  • 2.2, User294 (ok), 17:21, 23/03/2011 [^] [ответить]    [к модератору]
  • +2 +/
    Написано же:

    > Предполагается, что подобное стало возможным в результате компрометации
    > центра сертификации Comodo (CA).

     
  • 1.3, Marbleless (?), 17:38, 23/03/2011 [ответить] [показать ветку] [···]    [к модератору]
  • +2 +/
    > центра сертификации Comodo (CA).

    Да, вижу, что теперь уже написали.

    Ну, Comodo - оно и есть Comodo. Плохо, что существующая система с глобальными интернет-нотариусами может привести к таким последствиям.

     
     
  • 2.5, Andrey Mitrofanov (?), 17:45, 23/03/2011 [^] [ответить]    [к модератору]
  • +1 +/
    > Да, вижу, что теперь уже написали.

    Представь себе, и об этом:

    > Плохо, что существующая система с глобальными интернет-нотариусами может привести к таким последствиям.

    - этот самый "разработчик Tor" ioerror "уже написал". Длинно и разнообразно.

     
  • 1.4, Andrey Mitrofanov (?), 17:41, 23/03/2011 [ответить] [показать ветку] [···]    [к модератору]
  • +1 +/
    > может быть больше, 8 выявлено в трафике сети Tor.

    Разработчик Tor анализирова открытые источники (списки отозванных сертификатов по "интернетам") в поисках "очернённых" броузеростроителями _серийных _номеров сертификатов. Нашёл 8, по ним -- выдавший ЦА, перепродавца Комодовского "авторитета".

    Никакого "трафика сети Tor", совсем.
    Максимум: сказал, что аналогичные блэклисты-затычки для Tor ещё в разработке.
    Все равно никакого "трафика Tor"....

    >> получить поддельные SSL-сертификаты

    И кстати, про $SUBJ: сертификаты-то настоящие B) , их "просто" удалось получить "кому-то не тому", насколько я ничего не понимаю.

     
     
  • 2.10, angel_il (ok), 19:10, 23/03/2011 [^] [ответить]    [к модератору]  
  • +/
    я тоже именно так непонял
     
  • 1.11, xz (??), 19:27, 23/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +3 +/
    >В худшем случае данный инцидент может поставить >под угрозу сам принцип организации иерархии >удостоверяющих центров.

    Принцип то гнилой,давно пора.

     
     
  • 2.21, iZEN (ok), 10:00, 24/03/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    Принцип не гнилой. Гнилой сам подход к его реализации в некоторых клиентских программах и браузерах, когда по умолчанию сертификаты ПРОХОДЯТ проверку при отсутствии доступа к серверу OCSP (серверу, содержащими список отозванных сертификатов). В частности, в Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к серверу OCSP. В настройках Дополнительные -> Шифрование -> Настройки OCSP можно изменить это злосчастное умолчание, если взвести галочку "При ошибке соединения с сервером OCSP, рассматривать сертификат как недействительный". ;)
     
  • 1.12, Аноним (-), 22:06, 23/03/2011 [ответить] [показать ветку] [···]     [к модератору]  
  • –11 +/
    Принцип гнилой А сам протокол Я так понимаю если соединение устанавливается ... весь текст скрыт [показать]
     
     
  • 2.14, Аноним (-), 01:10, 24/03/2011 [^] [ответить]    [к модератору]  
  • +2 +/
    Ты того ... матчасть вначале изучи а потом уж на пол-мира позорься :)
     
  • 2.15, Vitaly_loki (ok), 05:55, 24/03/2011 [^] [ответить]    [к модератору]  
  • +4 +/
    Правильно, что разлогинился перед тем, как такой бред писать :) Почитай как работает ассиметричное шифрование.

    - Клиент скачивает с сервера сертификат (открытый ключ).
    - Потом клиент генерирует сеансовый ключ,
    - Зашифровывает его открытым ключом (сертификатом). Расшифровать сеансовый ключ может ТОЛЬКО сервер (ибо только у него есть закрытая часть ключа).
    - Сеансовый ключ отсылается серверу (отсылается он ЗАШИФРОВАННЫЙ открытым ключом).

    Потом соединение шифруется уже сеансовым ключ. Итого, закрытый/открытый ключ нужен только для того чтоб обменяться сеансовым ключом

     
     
  • 3.19, zazik (ok), 09:46, 24/03/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    > Правильно, что разлогинился перед тем, как такой бред писать :) Почитай как
    > работает ассиметричное шифрование.
    > - Клиент скачивает с сервера сертификат (открытый ключ).
    > - Потом клиент генерирует сеансовый ключ,
    > - Зашифровывает его открытым ключом (сертификатом). Расшифровать сеансовый ключ может
    > ТОЛЬКО сервер (ибо только у него есть закрытая часть ключа).
    > - Сеансовый ключ отсылается серверу (отсылается он ЗАШИФРОВАННЫЙ открытым ключом).
    > Потом соединение шифруется уже сеансовым ключ. Итого, закрытый/открытый ключ нужен только
    > для того чтоб обменяться сеансовым ключом

    Может быть он наслушался про MIM и неправильно себе представляет эту атаку?

     
  • 3.24, Аноним (-), 11:17, 24/03/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    Дык читал, и дырку вижу, хотя может просто чего то и недопонял, вы не кипешуйте ... весь текст скрыт [показать]
     
     
  • 4.25, Vitaly_loki (ok), 11:36, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    А-а-, дак вы имеете в виду Man-In-the- Middle атаку. Ну дак и в чем тут гнилость протокола? Если вы предоставили клиенту КОРРЕКТНЫЙ сертификат, подменили DNS-запись, то какие претензии к протоколу то? Может это DNS гнилой? :) Или ARP? :) По-вашему получается гнилое все ассиметричное шифрование, как класс.
     
  • 4.28, filosofem (ok), 12:31, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Все так. Поэтому и существуют CA, чьи сертификаты распространяются вместе с браузером и которые подтверждают аутентичность сертификата сервера.
    В чем гнилость протокола и какие есть еще варианты?
     
  • 3.29, . (?), 13:24, 04/04/2011 [^] [ответить]    [к модератору]  
  • +/
    сценарий такой только при использовании rsa; возможен также вариант с diffie-hellman
     
  • 1.13, alltiptop (ok), 23:52, 23/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    напомнило http://community.livejournal.com/ctrlaltdel_rus/427626.html
     
  • 1.16, CHERTS (??), 08:49, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Недавно отказался от получения сертификата от COMODO и видать правильно, если их корневой сертификат был скомпрометирован.
     
  • 1.18, iZEN (ok), 09:24, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Доходчиво и ясно: http://habrahabr.ru/blogs/infosecurity/116084/
     
  • 1.20, Аноним (-), 09:54, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    wow! даже микрософты подсуетились и выпустили секурапдейт
    http://go.microsoft.com/fwlink/?LinkId=214214

    viva la microsofta!

     
  • 1.22, Аноним (-), 10:22, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Вот мне интерестно почему у Comodo не вызвало подозрение то, что ВНЕЗАПНО одновременно гуглу, яху, скайпу и мозилле понадобились сертификаты?
     
     
  • 2.23, vadiml (ok), 10:39, 24/03/2011 [^] [ответить]    [к модератору]  
  • +2 +/
    Они же не вручную создаются.
    Пришёл заказ -> снялись деньги -> поставилась подпись

    Люди обычно смотрят когда что-то стопорится, идёт не так.

     
     
  • 3.27, TiGR (?), 11:57, 24/03/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    Это понятно, но система же должна реагировать как-то, когда на домен, для которого есть существующий и действенный сертификат хотят получить новый. Тут должна происходить какая-то подстраховка.
     
  • 1.26, misterex (?), 11:39, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ну ничего ж не мешает Comodo иметь blacklist'ы
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor