The OpenNET Project / Index page

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

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

24.03.2011 09:28

Компания 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
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/30013-cert
Ключевые слова: cert, security, ssl
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (61) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 12:11, 24/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Для защиты от подмены сертификатов есть хорошее расширение для Firefox - Certificate Patrol. Оно хранит базу сертификатов посещенных сайтов и в случае изменения сертификата выводит окно, где выведены старый и новый сертификат.

    К сожалению, этот аддон не совместим пока с только вышедшей 4 версией Лисы.

     
     
  • 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 +/
    > А о скольки таких breach'ах мы ещё не знаем, интересно?

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

     

  • 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 +/
    > Если злоумышленик в состоянии блокировать проверочные CRL/OCSP запросы, то какая разница
    > сколько серверов блокировать? Ну создадут собственный кэширующий сервер, а злоумышленик
    > и его заблокирует, где смысл?

    Смысл в том, что у некоторых CA OCSP-сервисы безбожно глючат и в их временной недоступности нет ничего удивительного. Добавив независимый 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 +/
    Ничего там секретным ключом не шифруется, он используется только для расшифровки на принимающей стороне. Естественно если публичный ключ вшит (получен по закрытому каналу) то ничего не получится, но мы то какраз о получении публичных ключей по открытому каналу, протокол это позволяет и это используется, изначально вшито очень мало ключей, добавьте к этому использование самоподписанных, так что от m-in-m зачастую не спасает.
     
     
  • 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 ключём подписанным CA. В начале он формирует посылку для клиента (для DH, например), подписывает своим приватным ключём и высылает клиенту вместе с сертификатом. Клиент проверяет сертификат на валидность по всей цепочке или, хотябы, самый первый CA, сертификат от которого у него точно есть, принимает решение доверять сертификату или нет, и уже только потом проверяется подпись посылки и всё такое. Если кто-то вклинится в середину, то он отпадёт ещё на этапе проверки клиентом сертификата. Обратная посылка шифруется открытым ключём сервера, так что вклинившийся узнать сессионный ключ никак не может. Это всё, есно, работает только если мы доверяем CA, если же нет, то вся PKI, как уже сказали, разваливается к чертям.

     
  • 3.17, iZEN (ok), 13:44, 24/03/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если OCSP-сервисы безбожно глючат, то нету никакой уверенности в достоверности сертификатов, и вся система PKI рассыпается как карточный домик.

    В Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к серверу OCSP. Это самая настоящая дыра в безопасности! В настройках Дополнительные -> Шифрование -> Настройки OCSP можно/нужно изменить это злосчастное умолчание, отметив галочку "При ошибке соединения с сервером 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 [^] [^^] [^^^] [ответить]  
  • +/
    Получить открытый ключ что сервера, что клиента, просто и... бесполезно! Пакеты, зашифрованные закрытыми ключами, расшифровать, имея только открытые, не получится. Нужно иметь закрытый ключ одной из сторон, а его ты не перехватишь потому что он не передаётся.
    Единственный вариант - становится посредине (MiM) и шифровать самому, своим закрытым ключом, но для этого тебе потребуется заставить жертву считать тебя сервером - например, отравлением кэша ДНС сервера, используемого жертвой. Иначе жертва пойдёт устанавливать SSL соединение по айпи адресу настоящего сервера и у тебя опять обломится.
     
     
  • 7.34, Аноним (-), 19:12, 24/03/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Приблизительно так, но проще. Во первых закрытыми ключами ничего не шифруют, нет смысла т.к. они не передаются и соответственно вообще никто не сможет расшифровать. Закрытыми ключами расшифровывают, то что зашифровано открытым ключом. Получать открытый ключ просто и очень полезно, все шифруется сессионным ключом а он формируется на основе открытых, соответственно став посередине можно перехватить открытую передачу открытого ключа и подсунуть вместо него свой, на основе этого ключа будет сформирован сессионный и далее мы сможем расшифровать все остальное. DNS можно не травить, если правильно встать то все запросы будут идти через нас, тогда можно отвечать вместо любых абонентов и глушить лишнее.
     
     
  • 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 +/
    > В Firefox 4.0 по умолчанию сертификат считается валидным, если нет доступа к
    > серверу OCSP. Это самая настоящая дыра в безопасности!

    А теперь прикинь, 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 сервер взял да и умер. Ну, умирают вот
    > иногда сервера. Даже самые хорошие, белые и пушистые. И это что,
    > мне теперь по этому поводу без доступа в онлайн-банк чтоли остаться
    > из-за даунайма ПОСТОРОННЕГО сервера?

    OCSP сервер не может быть посторонним. Он является структурообразующим PKI, ведущим актуальный список скомпрометированных сертификатов.

    Клиентская программа на момент своего выпуска, как правило, уже имеет в своём составе хранилище доверенных сертификатов от тех сайтов, с которыми она должна работать по защищённому соединению. Но время идёт, сайты взламываются, подбираются пароли, узнаются секретные ключи владельцев защищённых сервисов. Когда это обнаруживается, центры сертификации (CA) отзывают сертификаты у взломанных сайтов и размещают списки потерявших валидность сертификатов на серверах OCSP (адреса серверов OCSP указываются в сертификатах, которые подписывает CA — по этим адресам клиентская программа определяет валидность сертификатов).

    Клиентская программа, чтобы быть в курсе последних событий по конкретному сертификату, должна сначала обратиться к его серверу OCSP,  чтобы проверить его валидность. Если сертификат отозван (заблокирован, нет возможности проверить подлинность и т.д.), то вычеркнуть его из хранилища доверенных сертификатов и не позволить пользователю работать с потерявшим доверие (скомпрометированным) сайтом.

    > Мля, тогда банкоматом пользоваться наверное вообще
    > не надо - там кардеры могли ридер привинтить в принципе. Поэтому
    > надо самому дуть в отделение и получать бабло в кассе и
    > никак иначе. К кассиру то ридер не привинтишь :)

    Именно! А лучше за новым подписанным CA сертификатом банка, а старый скомпрометированный сертификат уничтожить.

     
     
  • 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:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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