The OpenNET Project / Index page

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

24.03.2011 09:28  Взлом аккаунта в удостоверяющем центре Comodo привёл к генерации 9 обманных SSL-сертификатов

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

По данным Comodo, 9 обманных сертификатов злоумышленникам удалось сгенерировать в результате взлома пользовательского аккаунта в одном из доверенных регистрирующих центров (RA, Registration Authority). Инфраструктура удостоверяющего центра (CA) и первичные сертификаты, хранимые в HSM-модулях (Hardware Security Modules), не были скомпрометированы. Сертификаты были выписаны для следующих сайтов: mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org, login.live.com. Также был создан не привязанный доменам сертификат "глобального доверия" ("global trustee"). Все выписанные обманным путем сертификаты были сразу отозваны и занесены в черные списки web-браузеров Firefox, Chrome/Chromium и Internet Explorer.

В связи с инцидентом критике подверглась используемая в настоящее время методика отзыва сертификатов, базирующаяся на оценке состояния списка отозванных сертификатов (CRL) или проверке статуса конкретных сертификатов с помощью протокола OCSP. Данные проверки выполняются путем обращения к специальному online-сервису, поддерживаемому каждым центром сертификации. Основная проблема связана с тем, что в случае невозможности осуществить проверочный запрос, браузеры не в состоянии определить отозван сертификат или нет, поэтому, в конечном счете, в случае сбоя проверки считают сертификат валидным.

В ситуации когда злоумышленник в состоянии вклиниться в трафик жертвы и подменить содержимое сайта, он с тем же успехом может блокировать проверочные CRL/OCSP запросы. Более того, такой инструмент перехвата и подмены SSL-трафика как sslstrip уже включает в себя поддержку подобного рода атак. Поэтому, в ситуации появления обманных SSL-сертификатов, производители браузеров вынуждены обновлять локальный черный список. В качестве одного из вариантов решения проблемы называется создание производителями браузеров собственных кэширующих OCSP-серверов, способных выполнить проверку в случае недоступности OCSP-сервера удостоверяющего центра, а также пересмотр подхода к выводу предупреждений в случае проблем с выполнением проверки.

В случае, если бы злоумышленникам удалось получить закрытый ключ для сертификата UserTrust (UTN-USERFirst-Hardware) удостоверяющего центра Comodo, под угрозой оказалась бы безопасность более чем 85 тыс. сайтов, владельцам которых пришлось бы заново получать сертификаты. При таком развитии событий производители браузеров были бы поставлены перед непростой дилеммой: поместить в черный список все сертификаты скомпрометированного центра сертификации, нарушив нормальную работу десятков тысяч сайтов, или игнорировать проблему, сделав данные сайты потенциально уязвимыми.

Подобное развитие событий не исключено в силу неумеренного разрастания сети центров сертификации. Например, в настоящее время насчитывается уже около 1500 CA-сертификатов, контролируемых примерно 650 разными организациями. При каждом HTTPS/TLS-сеансе пользователь изначально доверяет всем имеющимся центрам сертификации, компрометация одного из CA приведет к коллапсу всей системы. В качестве одного из способов защиты от такого развития событий называется разработка и внедрение методов перекрёстной сертификации.

  1. Главная ссылка к новости (http://www.comodo.com/Comodo-F...)
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: cert, security, ssl
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 12:11, 24/03/2011 [ответить] [показать ветку] [···]     [к модератору]
  • +3 +/
    Для защиты от подмены сертификатов есть хорошее расширение для Firefox - Certifi... весь текст скрыт [показать]
     
     
  • 2.7, Аноним (-), 12:32, 24/03/2011 [^] [ответить]    [к модератору]  
  • –1 +/
    Вы думаете народ при этом станет звонить в ЦС и уточнять правда ли у них изменился сертификат ? И это не защищает от подмены сертификата при изначальном его получении.
     
     
  • 3.11, Аноним (-), 13:01, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Звонить не обязательно. К примеру было бы видно, что гугловский сертификат выдан вместо thawte теперь comodo. Этого достаточно чтобы забеспокоиться.
     
     
  • 4.13, Аноним (-), 13:07, 24/03/2011 [^] [ответить]    [к модератору]  
  • –5 +/
    Дык там же что угодно написать можно, он же не оригинальный а подмененный, челом сидящим на вашем канале.
     
     
  • 5.49, Одмин (?), 00:33, 25/03/2011 [^] [ответить]    [к модератору]  
  • +/
    нельзя, в сертификате от комодо будет написано что он от комодо.
     
     
  • 6.50, Аноним (-), 00:40, 25/03/2011 [^] [ответить]    [к модератору]  
  • –3 +/
    на заборе тоже много че написано, а в реальности есть косяки, читайте ниже
     
     
  • 7.57, Michael Shigorin (ok), 21:14, 25/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Где именно ниже, а то уже много?  Ну и написанное на заборе не валидируется по прибитому в браузере. (хотя... смотря как родители воспитали :)
     
  • 2.33, Комментатор (?), 19:01, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Будет интересней, если поломают просроченные сертификаты которые необходимы Windows.
    http://support.microsoft.com/kb/293781
    :))
     
  • 1.2, Аноним (-), 12:12, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Полезная ссылка на описание того, как люди из "Tor project" разбирались с этой проблемой.
    https://blog.torproject.org/blog/detecting-certificate-authority-compromises-a
     
  • 1.3, Аноним (-), 12:15, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Открытая децентрализованная p2p валидация. Систему можно будет свалить только при условии внедрения взломанного кода в бОльшую часть узлов сети, что гораздо сложнее в условиях открытости кода.
     
     
  • 2.10, Аноним (-), 12:42, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    + соединение по изначально защищенному каналу, т.е. хранить на клиенте закрытый ключ а получать его первично по др. каналу.
     
     
  • 3.15, Анонимиус (?), 13:40, 24/03/2011 [^] [ответить]     [к модератору]  
  • –1 +/
    Выше отпостившим авторам и по тексту новости Вам не кажется, что немного теряет... весь текст скрыт [показать]
     
     
  • 4.18, Аноним (-), 14:00, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Так и есть С одной стороны понятно что идеальной защиты все равно не добиться, ... весь текст скрыт [показать]
     
  • 4.63, Aleksey Salow (ok), 23:25, 27/03/2011 [^] [ответить]    [к модератору]  
  • +/
    сертификаты используются не только в web-е, а и много где за пределами. Так зачем ломать рабочую инфраструктуру, да и проблема то не в сертификатах.
     
  • 1.4, Аноним (-), 12:17, 24/03/2011 [ответить] [показать ветку] [···]     [к модератору]  
  • –9 +/
    Если злоумышленник в состоянии вклинится в трафик жертвы, в самом начале, когда ... весь текст скрыт [показать]
     
     
  • 2.27, Аноним (-), 17:12, 24/03/2011 [^] [ответить]    [к модератору]  
  • –3 +/
    Че минусовать то ? Неужели не очевидно что ключи, даже открытые, надо охранять ?
     
     
  • 3.62, Aleksey Salow (ok), 23:23, 27/03/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    Школоло в криптографии не разбирается. Откуда им знать что против mitm работают только схемы с третьим доверенным лицом.
     
  • 1.5, Иван Иванович Иванов (?), 12:27, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    А о скольки таких breach'ах мы ещё не знаем, интересно?

    Ведь пока один разработчик не раскопал эту проблему, просматривая commit'ы в Firefox/Chrome, никто даже и не заикнулся о проблеме.

     
     
  • 2.22, Аноним (-), 15:24, 24/03/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    О многих А зачем Вам об этом знать А для специалиста или интересующихся соверш... весь текст скрыт [показать]
     
  • 1.6, Александр (??), 12:30, 24/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    Может кто-нибудь пояснить как сочитаются:

    "В ситуации когда злоумышленник в состоянии вклинится в трафик жертвы и подменить содержимое сайта, он с тем же успехом может блокировать проверочные CRL/OCSP запросы"

    "В качестве одного из вариантов решения проблемы называется создание производителями браузеров собственных кэширующих OCSP-серверов"

    Если злоумышленик в состоянии блокировать проверочные CRL/OCSP запросы, то какая разница сколько серверов блокировать? Ну создадут собственный кэширующий сервер, а злоумышленик и его заблокирует, где смысл?

     
     
  • 2.8, Аноним (-), 12:38, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Смысл в усложнении, устроить злоумышленнику больший гемор, но в принципе в данном случае он конечно не особо большим получается.
     
     
  • 3.9, Александр (??), 12:40, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    я бы даже сказал, совсем не получается.
     
  • 2.12, Аноним (-), 13:07, 24/03/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    Смысл в том, что у некоторых CA OCSP-сервисы безбожно глючат и в их временной не... весь текст скрыт [показать]
     
     
  • 3.14, Аноним (-), 13:21, 24/03/2011 [^] [ответить]     [к модератору]  
  • –2 +/
    Про предупреждение справедливости ради там ничего не сказано Да хоть и так, во ... весь текст скрыт [показать]
     
     
  • 4.20, К.О. (?), 15:02, 24/03/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    То, что CRL тоже подписан ключом, которого у Тебя нет?
     
     
  • 5.24, Аноним (-), 16:43, 24/03/2011 [^] [ответить]     [к модератору]  
  • –2 +/
    В том то и дело что есть, сессионный ключ которым все шифруется получается злоум... весь текст скрыт [показать]
     
     
  • 6.30, Аноним (-), 18:54, 24/03/2011 [^] [ответить]     [к модератору]  
  • +2 +/
    Кроме подписи на CRL сертификате, которая делается секретным ключом удостоверяющ... весь текст скрыт [показать]
     
     
  • 7.36, Аноним (-), 19:32, 24/03/2011 [^] [ответить]     [к модератору]  
  • –3 +/
    Ничего там секретным ключом не шифруется, он используется только для расшифровки... весь текст скрыт [показать]
     
     
  • 8.40, Аноним (-), 22:38, 24/03/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    Божежтымой почитайте описание TLS Там НЕСКОЛЬКО секретных ключей, сертифик... весь текст скрыт [показать]
     
     
  • 9.45, Аноним (-), 23:24, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Не все вшито в браузер. Не может он быть сразу раскрыт, проверка в удостоверяющем центре может вообще не осуществляться, либо может быть отложена, либо заблокирована.
     
  • 6.64, Aleksey Salow (ok), 23:53, 27/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Вы о чём У сервера есть его pub priv ключи и сертификат с pub ключём подписанны... весь текст скрыт [показать]
     
  • 3.17, iZEN (ok), 13:44, 24/03/2011 [^] [ответить]     [к модератору]  
  • +2 +/
    Если OCSP-сервисы безбожно глючат, то нету никакой уверенности в достоверности с... весь текст скрыт [показать]
     
     
  • 4.23, Аноним (-), 16:31, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    А вот интересно что мешает устроить MITM атаку при обращении к OCSP?
     
     
  • 5.25, Аноним (-), 16:56, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Если обмен первичными ключами идет по открытому каналу то ничто не мешает А вот... весь текст скрыт [показать]
     
     
  • 6.29, Frank (ok), 18:51, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Получить открытый ключ что сервера, что клиента, просто и бесполезно Пакеты,... весь текст скрыт [показать]
     
     
  • 7.34, Аноним (-), 19:12, 24/03/2011 [^] [ответить]     [к модератору]  
  • –2 +/
    Приблизительно так, но проще Во первых закрытыми ключами ничего не шифруют, нет... весь текст скрыт [показать]
     
     
  • 8.37, iZEN (ok), 21:52, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Откуда ты это выдумал Закрытый ключ используется для генерации ПОДПИСИ открытог... весь текст скрыт [показать]
     
     
  • 9.39, Аноним (-), 22:36, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Ничего я не выдумал, это из описания протокола, пакеты закрытым ключом не шифрую... весь текст скрыт [показать]
     
     
  • 10.41, Аноним (-), 22:44, 24/03/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    И как Вы подтвердите валидность Вашей открытой части подсунутого клиенту ключа ... весь текст скрыт [показать]
     
     
  • 11.42, Аноним (-), 22:52, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Естественно понимаю, по этому и говорю что если открытый ключ изначально встроен... весь текст скрыт [показать]
     
     
  • 12.43, iZEN (ok), 23:11, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    В браузер встроены не публичные ключи, а сертификаты с публичными ключами Серти... весь текст скрыт [показать]
     
     
  • 13.46, Аноним (-), 23:50, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Не ключи а сертификаты, правильно. Но суть то не меняется, протокол не устанавливает их жесткой проверки.
     
  • 11.44, Аноним (-), 23:16, 24/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Процедура подтверждения в удостоверяющем центре может быть заблокирована, см. текст новости, и вообще стандарт не обязывает проверять ключ, это может быть отложено.
     
  • 4.26, User294 (ok), 17:08, 24/03/2011 [^] [ответить]     [к модератору]  
  • –1 +/
    А теперь прикинь, OCSP сервер взял да и умер Ну, умирают вот иногда сервера Да... весь текст скрыт [показать]
     
     
  • 5.28, Аноним (-), 17:24, 24/03/2011 [^] [ответить]     [к модератору]  
  • –2 +/
    Предлагается что OCSP серверов будет несколько, все сразу не помрут Тут другая ... весь текст скрыт [показать]
     
     
  • 6.32, Аноним (-), 19:00, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Вы сейчас о чём Самоподписанный сертификат по определению не верен, его проверя... весь текст скрыт [показать]
     
     
  • 7.35, Аноним (-), 19:15, 24/03/2011 [^] [ответить]    [к модератору]  
  • –1 +/
    Какраз о том что самоподписанный сертификат небезопасен, но их используют ;)
     
  • 6.48, User294 (ok), 00:25, 25/03/2011 [^] [ответить]    [к модератору]  
  • +/
    > Предлагается что OCSP серверов будет несколько, все сразу не помрут.

    Угу, с ауторитями что-то тоже предполагалось. Что они не будут помирать, что подписывать будут не что попало и не кому попало, etc.

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

    Погодите, так если канал УЖЕ защищен и мы уверены в том что он именно с тем кем надо, тогда на кой черт нам еще раз проверять то что мы уже и так установили? Гарантии будут не сильнее чем гарантии по поводу шифрования исходного канала и уверенности в том что он - именно с тем с кем надо был установлен. Потому что если нас обманут на этой фазе - обманут по цепочке и на всех остальных, впарив левый сертификат, с левой инфо о том как его проверяить и прочая, что логично :)

     
     
  • 7.51, Аноним (-), 00:55, 25/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Ну както эту проблему всеравно надо решать Теоретически можно не проверять, но ... весь текст скрыт [показать]
     
     
  • 8.54, User294 (ok), 07:38, 25/03/2011 [^] [ответить]    [к модератору]  
  • +/
    > а с другой - убрать возможности подлома. Задачи прямопротивоположные и ни
    > одна не решается идеально.

    Браузеры могли бы грузить в фоне блеклисты плохих сертификатов как блеклисты фишеров и при натыкании на сертификат из списка верещать в том же духе как при визите фишерского сайта, а дальше - ну оставить сильно сбоку возможность оверрайда, но по дефолту показывать страшилку, как с фишерами и даже позлее. При этом единоразовый срыв обновления БД плохих парней вообще ни на что особо не повлияет, но массовые факапы в случае реального взлома чьих-то привкеев будут предотвращены. ИМХО вполне разумный компромисс: и реалтаймного факапа не получается и информация о плохих парнях все-таки будет распостраняться.

     
  • 5.31, Frank (ok), 18:58, 24/03/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    Не иди в кассу, там тебе фальшивок всучат монетчики под видом работников банка.
    Натуробмен наше всё!
     
     
  • 6.58, Michael Shigorin (ok), 21:20, 25/03/2011 [^] [ответить]    [к модератору]  
  • +/
    > Натуробмен наше всё!

    А если всё-таки не всё, то тут ещё про bitcoin.org подсказывают.

     
  • 5.38, iZEN (ok), 22:05, 24/03/2011 [^] [ответить]     [к модератору]  
  • +/
    OCSP сервер не может быть посторонним Он является структурообразующим PKI, веду... весь текст скрыт [показать]
     
     
  • 6.47, Аноним (-), 00:18, 25/03/2011 [^] [ответить]    [к модератору]  
  • +/
    Это в идеале, а в реальности CA ломают, сертификаты подписывают сами, вовремя не проверяют, протокол позволяет вольности, клиенты не реагируют должным образом и т.п.
     
  • 6.53, User294 (ok), 07:32, 25/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Есть я, клиент Есть банк, сервер Все остальные по определению посторонние Чем... весь текст скрыт [показать]
     
     
  • 7.56, iZEN (ok), 18:06, 25/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Почитай, что ли, об SSL-сертификатах и на чём держится протокол HTTPS OCSP-серв... весь текст скрыт [показать]
     
     
  • 8.59, User294 (ok), 22:27, 25/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Я в курсе на чем он держится, спасибо OCSP не является обязательной частью А т... весь текст скрыт [показать]
     
     
  • 9.60, iZEN (ok), 01:12, 26/03/2011 [^] [ответить]     [к модератору]  
  • +/
    У Mozilla это делается перевыпуском версии браузера, в которой обновляется храни... весь текст скрыт [показать]
     
     
  • 10.61, Аноним (-), 12:58, 26/03/2011 [^] [ответить]     [к модератору]  
  • +/
    Ну так вот и получается, если сторонний OCSP сервер оказался в дауне по внутренн... весь текст скрыт [показать]
     
  • 1.52, StrangeAttractor (ok), 01:31, 25/03/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    > занесены в черные списки web-браузеров Firefox, Chrome/Chromium и Internet Explorer.

    А Opera?

    Я вот только сегодня товарищу, пользователю Opera, комп чистил от какой-то гадости, забившей в hosts на свой айпишник (к сожалению не подумал сохранить) все варианты Gmail и Yahoo и поднявшей на локалхосте прокси и перенаправившей браузеры через него.

     
  • 1.65, Аноним (-), 18:25, 01/05/2011 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Статья подготовленна оперативно, но непрофессионально Причем здесь перекрестная... весь текст скрыт [показать]
     

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


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