The OpenNET Project / Index page

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

Сертификат удостоверяющего центра был использован для перехвата трафика произвольных доменов

24.03.2015 18:36

Компания Google сообщила о выявлении в сети обманного TLS-сертификата, используемого в прокси-сервере для установки не вызывающих подозрений защищённых соединений с любыми серверами в сети. В том числе создание поддельных TLS-соединений зафиксировано для некоторых доменов Google.

В ходе разбирательства выяснилось, что китайский удостоверяющий центр CNNIC (China Internet Network Information Center) передал холдингу MCS промежуточный (вторичный) корневой сертификат, на условии его использования только для доменов, зарегистрированных данной компанией. В нарушение всех правил обращения с корневыми сертификатами, закрытый ключ не был изначально помещён в HSM (Hardware Security Module), а установлен в MITM-прокси, осуществляющем перехват защищённых соединений с целью контроля за работой сотрудников корпорации.

По сути прокси сервер был наделён полномочиями полноценного удостоверяющего центра, на лету генерирующего необходимые для любых доменов корректные сертификаты. Подобные сертификаты не вызывали подозрений во всех операционных системах и браузерах, так как сертификат CNNIC был занесён в список заслуживающих доверие корневых сертификатов. Инцидент является серьёзным ударом по всей инфраструктуре удостоверяющих центров, подрывающим доверие к ней, так как CNNIC делегировал свои полномочия сторонней организации, не имеющей право на обращение с подобными сертификатами. Сам вторичный корневой сертификат был помечен как тестовый и выписан на две недели.

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

Chrome и Firefox позволяет отловить некорректные манипуляции с сертификатами благодаря наличию механизма Public Key Pinning, позволяющего явно определить сертификаты каких удостоверяющих центров допустимо использовать для заданного сайта (в частности, Google жестко привязывает в Chrome свои домены к определённому удостоверяющему центру). Если для установки защищённого соединения применён достоверный сертификат выписанный иным удостоверяющим центром, соединение будет отвергнуто из-за подозрения в атаке "man-in-the-middle". Для оперативного отзыва сертификатов промежуточных удостоверяющих центров в Google Chrome используется механизм CRLset. В следующем выпуске Firefox ожидается появление механизма OneCRL, предоставляющего похожие на CRLset средства для централизованного отзыва сертификатов.

  1. Главная ссылка к новости (http://googleonlinesecurity.bl...)
  2. OpenNews: EFF, Mozilla, Cisco и Akamai создадут контролируемый сообществом удостоверяющий центр
  3. OpenNews: Выявлены обманные SSL-сертификаты, полученные из-за халатности удостоверяющего центра TurkTrust
  4. OpenNews: Mozilla объявляет ультиматум удостоверяющим центрам
  5. OpenNews: Взлом аккаунта в удостоверяющем центре Comodo привёл к генерации 9 обманных SSL-сертификатов
  6. OpenNews: Опубликован полный список обманных SSL-сертификатов. В списке ЦРУ и МИ-6
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41902-ssl
Ключевые слова: ssl, cert, crypt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 19:02, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    расстраивает то что фаерфокс не позволяет отключить сертификаты вот таких вот ненадежных CA
     
     
  • 2.3, Аноним (3), 19:16, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    с введение мозилой своих центров сертификации, такое станет доступным
     
     
  • 3.6, Аноним (-), 19:44, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > с введение мозилой своих центров сертификации, такое станет доступным

    Чем это отличается от того, что есть сейчас?

     
     
  • 4.13, Ан0ним (?), 20:21, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Чем больше центров сертификации тем надежнее! Правильно?


     
     
  • 5.15, Fomalhaut (?), 21:48, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У семи нянек... (С)
     
     
  • 6.24, Anonim (??), 22:27, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +28 +/
    Четырнадцать титек.
     
     
  • 7.28, Аноним (-), 23:53, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это в теории. У няньки может быть член или отсутствующая титька.
     
     
  • 8.47, XoRe (ok), 15:09, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Но титьки то тоже будут ... текст свёрнут, показать
     
  • 5.17, Аноним (-), 22:00, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Еще как: теперь и мозилла сможет подписывать сертификаты на что угодно!
     
  • 5.18, Аноним (-), 22:03, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет. Наоборот.
     
  • 2.4, rm_ (ok), 19:19, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Позволяет, в опциях поройтесь. Но это не выход.
     
  • 2.9, Аноним (-), 19:48, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Позволяет, плохо смотрели. Но туда редко кто заглядывает.
    Другой вопрос как узнать ненадежные CA?
     
     
  • 3.12, Ан0ним (?), 20:18, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Все, которые расположены не на /dev/sda
     
  • 3.21, Аноним (-), 22:06, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Позволяет, плохо смотрели. Но туда редко кто заглядывает.
    > Другой вопрос как узнать ненадежные CA?

    Никак. Без OCSP это вообще нереально, кроме как вручную - а не заипёшься ли ты их повсюду проверять вручную? А OCSP так и не прижилось 15 лет спустя как стандарт и повсеместное требование.

     
     
  • 4.26, sur pri (?), 23:33, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> Другой вопрос как узнать ненадежные CA?
    > Никак.

    :-) Вот узнали же.

    Хотя в заявлениях Google что-то не находится например неправильный сертификат, о котором идёт речь...

     
  • 4.27, Аноним (-), 23:41, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Никак. Без OCSP это вообще нереально, кроме как вручную -

    Чего бы это вдруг? Запомнить при первом конекте fingerprint и если поменялся - спрашивать, доверяем ли мы этим, новым. Не говоря уж о блеклисте.

    А отчитываться каким-то левым хренам с OCSP сервером каждый раз когда я в банк хожу - как-то жирновато будет, имхо.

    > не прижилось 15 лет спустя как стандарт и повсеместное требование.

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

     

  • 1.8, Аноним (-), 19:45, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Они изобрели SSL Bump! :)))))))))))))))
     
  • 1.10, Аноним (-), 19:58, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Отключил для пробы доверие к сертификату CNNIC в Фоксе. aliexpress не пострадал, вопреки опасениям
     
     
  • 2.16, Anonplus (?), 21:58, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    CNNIC славился тем, что бесплатно раздавал сертификаты для некоммерческих проектов, поддерживая повсеместное внедрение https.
     
     
  • 3.20, Аноним (-), 22:05, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > CNNIC славился тем, что бесплатно раздавал сертификаты для некоммерческих проектов, поддерживая
    > повсеместное внедрение https.

    Серверные. А тут речь о том, что эти ушлёпки отдали корневой, с правом подписи.

     
  • 3.52, sur pri (?), 02:42, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > CNNIC славился тем, что бесплатно раздавал сертификаты для некоммерческих проектов, поддерживая
    > повсеместное внедрение https.

    Поддерживая повсеместное внедрение. Внедрение.
    Своих сертификатов >:-)

     

  • 1.11, Аноним (-), 19:58, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    dpkg-reconfigure ca-certificates
     
  • 1.14, Ilya Indigo (ok), 21:09, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Инцидент является серьёзным ударом по всей инфраструктуре удостоверяющих центров, подрывающим доверие к ней.

    В который уже раз, она всё живее всех живых.

     
     
  • 2.25, Michael Shigorin (ok), 23:29, 24/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Инцидент является серьёзным ударом по всей инфраструктуре удостоверяющих центров,
    >>подрывающим доверие к ней.
    > В который уже раз, она всё живее всех живых.

    Как и МВФ с ФРС, забавное совпадение -- и тут опять китайцы...

     

  • 1.29, Аноним (-), 23:56, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И главное, никто даже и не пытается особо обеспечивать поддержку RFC6091 в приложениях, особенно в собственно клиентских браузерах. Уже сколько раз об это X.509 руки-ноги ломали, а они так и не учатся и ничему учиться не хотят.
     
     
  • 2.36, Аноним (-), 07:52, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Существующая система сертификации прекрасно выполняет свои цели (как известно, истинные цели любого проекта становятся ясными только после запуска в эксплуатацию) - гарантированный перехват трафика и обход защиты по заказу. А рассматриваемый случай - досадный пример, который не должен был стать достоянием.

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

     
     
  • 3.42, Demo (??), 12:58, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Существующая система сертификации

       Не вызывает доверия.

     

  • 1.30, Аноним (-), 23:57, 24/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    отключил в фоксе и конкьюре. спасибо за инфо!
     
  • 1.31, Dzmitry (??), 01:44, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А opennet.ru вообще не поддерживает HTTPS :D
     
     
  • 2.32, Ilya Indigo (ok), 01:46, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > А opennet.ru вообще не поддерживает HTTPS :D

    https://ssl.opennet.ru

     
     
  • 3.33, Аноним (-), 02:34, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Алгоритм подписи: PKCS #1 MD5 с шифрованием RSA

    E = mc@tyumen.ru
    CN = *.opennet.ru
    OU = web site
    O = Opennet.ru
    L = Tyumen
    ST = Tyumen reg.
    C = RU

    nice try, но нет, спасибо, в таком виде не пойдёт.

     
     
  • 4.44, Ilya Indigo (ok), 13:02, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    С этим я не спорю, он тут просто для галочки, но он на этом сайте и не нужен, особенно анонимам.
     
  • 3.34, Аноним (-), 04:51, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    а мини-opennet, версия которая открывается по http://opennet.ru есть?
     
  • 3.40, ryoken (?), 09:33, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > https://ssl.opennet.ru

    Не знал, спасибо :).

     
     
  • 4.56, Адекват (ok), 07:10, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> https://ssl.opennet.ru
    > Не знал, спасибо :).

    Да нафиг нужно на самоподписанных то..

     
     
  • 5.57, Andrew Kolchoogin (ok), 12:29, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да нафиг нужно на самоподписанных то..

    Судя по тексту новости, несамоподписанные не сильно отличаются от самоподписанных. :)))

     

  • 1.35, Аноним (-), 05:56, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Что, собственно, очередной раз демонстрирует эпичный системный фейл всей текущей системы сертификации.
     
  • 1.37, Slot (?), 07:57, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Замочил CA в firefoxе
     
  • 1.39, AlexAT (ok), 09:12, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Именно поэтому давно пора переводить сайтовую PKI на публикацию компаниями собственных ключей в защищённых DNSSEC зонах, а не продолжать стричь бабло с желающих купить сертификат.
     
     
  • 2.43, Demo (??), 13:01, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/

    > ключей в защищённых DNSSEC зонах, а не продолжать стричь бабло с

    Ну, будут публиковать нужные поддельные сертификаты с неподконтрольных авторитетных или корневых серверов, толку то?..


     
     
  • 3.49, AlexAT (ok), 20:13, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >> ключей в защищённых DNSSEC зонах, а не продолжать стричь бабло с
    > Ну, будут публиковать нужные поддельные сертификаты с неподконтрольных авторитетных или корневых серверов, толку то?..

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

     

  • 1.41, а (?), 10:41, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В каком месте CNNIC расшифровывается как China Internet Network Information Center?
    Может тогда уж CINIC?
     
     
  • 2.58, pavelpat (ok), 20:14, 02/12/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Может быть Network Information Center зоны CN?
     

  • 1.45, Аноним (-), 13:02, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В списке рассылки Firefox после новости http www opennet ru opennews art shtml... большой текст свёрнут, показать
     
     
  • 2.46, Ilya Indigo (ok), 13:08, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > 2. Это может быть не безопасно.
    > Тут я вообще не понял, о чем речь.

    Ну это же не безопасно для
    > ...центров, продающий свои сертификаты налево...

     
  • 2.53, sur pri (?), 03:29, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    > компании либо полное раздолбайство, либо это произошло с негласного разрешения руководства
    > компании).
    > Однако на мое сообщение появились аж два возражения:
    > 1. Это не дает 100% гарантию, ведь можно отключить JavaScript или вырезать
    > его на промежуточном узле, осуществляющем атаку.
    > Ну, конечно, можно, только для этого потребуется реализовать Искусственный интеллект,
    > который анализирует страницу, убирает нужный скрипт и не изменяет поведение страницы
    > в браузере пользователя.
    > 2. Это может быть не безопасно.
    > Тут я вообще не понял, о чем речь.

    You are an stupid idiot. Really, a certificate falsification means the server are falsified. Where you send information to?
    И они почему-то считают, что фальсификация сертификатов допустима, если она делается внутри каких-то компаний в их внутренних сетях от имени этих компаний.
    Я лично не вижу оснований оправдывающих такое. Конечно например Google может подарить кому угодно право подписываться за себя, но в любом другом случае когда какая-либо действующая в сети компания или сайт такого права не предоставляли такое должно быть недопустимо. Наравне с использованием и подделкой подписи или торговой марки.
    Например невозможно же оправдать кого-либо если он у себя в офисе своему сотруднику вручит некое обязательство, заверенное подписью председателя правления скажем соседнего банка. На скажем какое-то количество рублей. Подделав бланк этого соседнего банка и подпись председателя. А потом будет говорить, что в пределах своей компании он вполне может использовать любые подписи и бланки... :-)

     
     
  • 3.54, sur pri (?), 04:06, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Примечание. Сайты не заинтересованные в такого рода вещах могут и должны использовать http. Без s.
     
     
  • 4.55, sur pri (?), 04:19, 26/03/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Примечание к примечанию. Даже последний случай не даёт права фальсифицировать данные.
     

  • 1.48, adolfus (ok), 15:55, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пора переходить на одноразовые блокноты.
     
     
  • 2.50, Какаянахренразница (ok), 20:24, 25/03/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Пора переходить на одноразовые блокноты.

    "А на словах просил передать следующее" (C)

     

  • 1.51, arisu (ok), 23:34, 25/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    «мужик, я не понимаю: ты охотник или #$%:с?» (ц)
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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