Компания Google сообщила (http://googleonlinesecurity.blogspot.ru/2015/03/maintaining-... о выявлении в сети обманного TLS-сертификата, используемого в прокси-сервере для установки не вызывающих подозрений защищённых соединений с любыми серверами в сети. В том числе создание поддельных TLS-соединений зафиксировано для некоторых доменов Google.
В ходе разбирательства выяснилось, что китайский удостоверяющий центр CNNIC (China Internet Network Information Center) передал холдингу MCS промежуточный (https://en.wikipedia.org/wiki/Intermediate_certificate_autho... (вторичный) корневой сертификат, на условии его использования только для доменов, зарегистрированных данной компанией. Нарушив все правила обращения с корневыми сертификатами, закрытый ключ не был изначально помещён в HSM (Hardware Security Module), а установлен в MITM-прокси, осуществляющем перехват защищённых соединений с целью контроля за работой сотрудников корпорации.
По сути прокси сервер был наделён полномочиями полноценного удостоверяющего центра, на лету генерирующего необходимые для любых доменов корректные сертификаты. Подобные сертификаты не вызывали подозрений во всех операционных системах и браузерах, так как сертификат CNNIC был занесён в список заслуживающих доверие корневых сертификатов. Инцидент является серьёзным ударом по всей инфраструктуре удостоверяющих центров, подрывающим доверие к ней, так как CNNIC делегировал свои полномочия сторонней организации, не имеющей право на обращение с подобными сертификатами. Сам вторичный корневой сертификат был помечен как тестовый и выписан на две недели.
Напомним, что компрометация любого из существующих удостоверяющих центров может привести к возможности сгенерировать рабочий сертификат для любого сайта в сети, независимо от того каким центром сертификации выдан оригинальный SSL-сертификат. При каждом HTTPS/TLS-сеансе пользователь изначально доверяет всем имеющимся центрам сертификации, поэтому утечка корневого сертификата у одного из центров сертификации может привести к коллапсу всей системы. Средства защиты от подобных манипуляций, например методы перекрёстной сертификации или специальные расширения (http://www.opennet.me/opennews/art.shtml?num=33937) к протоколу TLS, только разрабатываются.
Chrome и Firefox позволяет отловить некорректные манипуляции с сертификатами благодаря наличию механизма Public Key Pinning, позволяющего явно определить сертификаты каких удостоверяющих центров допустимо использовать для заданного сайта (в частности, Google жестко привязывает в Chrome свои домены к определённому удостоверяющему центру). Если для установки защищённого соединения применён достоверный сертификат выписанный иным удостоверяющим центром, соединение будет отвергнуто из-за подозрения в атаке "man-in-the-middle". Для оперативного отзыва сертификатов промежуточных удостоверяющих центров в Google Chrome используется механизм CRLset. В следующем выпуске Firefox ожидается появление механизма OneCRL (https://wiki.mozilla.org/CA:RevocationPlan#OneCRL), предоставляющего похожие на CRLset средства для централизованного отзыва сертификатов.URL: http://googleonlinesecurity.blogspot.ru/2015/03/maintaining-...
Новость: http://www.opennet.me/opennews/art.shtml?num=41902
расстраивает то что фаерфокс не позволяет отключить сертификаты вот таких вот ненадежных CA
с введение мозилой своих центров сертификации, такое станет доступным
> с введение мозилой своих центров сертификации, такое станет доступнымЧем это отличается от того, что есть сейчас?
Чем больше центров сертификации тем надежнее! Правильно?
У семи нянек... (С)
Четырнадцать титек.
Это в теории. У няньки может быть член или отсутствующая титька.
> Это в теории. У няньки может быть членНо титьки то тоже будут :)
Еще как: теперь и мозилла сможет подписывать сертификаты на что угодно!
Нет. Наоборот.
Позволяет, в опциях поройтесь. Но это не выход.
Позволяет, плохо смотрели. Но туда редко кто заглядывает.
Другой вопрос как узнать ненадежные CA?
Все, которые расположены не на /dev/sda
> Позволяет, плохо смотрели. Но туда редко кто заглядывает.
> Другой вопрос как узнать ненадежные CA?Никак. Без OCSP это вообще нереально, кроме как вручную - а не заипёшься ли ты их повсюду проверять вручную? А OCSP так и не прижилось 15 лет спустя как стандарт и повсеместное требование.
>> Другой вопрос как узнать ненадежные CA?
> Никак.:-) Вот узнали же.
Хотя в заявлениях Google что-то не находится например неправильный сертификат, о котором идёт речь...
> Никак. Без OCSP это вообще нереально, кроме как вручную -Чего бы это вдруг? Запомнить при первом конекте fingerprint и если поменялся - спрашивать, доверяем ли мы этим, новым. Не говоря уж о блеклисте.
А отчитываться каким-то левым хренам с OCSP сервером каждый раз когда я в банк хожу - как-то жирновато будет, имхо.
> не прижилось 15 лет спустя как стандарт и повсеместное требование.
Потому что тормозно и сильно гадит приватности пользователя, информируя совершенно левый сервер о активности юзверя.
Они изобрели SSL Bump! :)))))))))))))))
Отключил для пробы доверие к сертификату CNNIC в Фоксе. aliexpress не пострадал, вопреки опасениям
CNNIC славился тем, что бесплатно раздавал сертификаты для некоммерческих проектов, поддерживая повсеместное внедрение https.
> CNNIC славился тем, что бесплатно раздавал сертификаты для некоммерческих проектов, поддерживая
> повсеместное внедрение https.Серверные. А тут речь о том, что эти ушлёпки отдали корневой, с правом подписи.
> CNNIC славился тем, что бесплатно раздавал сертификаты для некоммерческих проектов, поддерживая
> повсеместное внедрение https.Поддерживая повсеместное внедрение. Внедрение.
Своих сертификатов >:-)
dpkg-reconfigure ca-certificates
>Инцидент является серьёзным ударом по всей инфраструктуре удостоверяющих центров, подрывающим доверие к ней.В который уже раз, она всё живее всех живых.
>>Инцидент является серьёзным ударом по всей инфраструктуре удостоверяющих центров,
>>подрывающим доверие к ней.
> В который уже раз, она всё живее всех живых.Как и МВФ с ФРС, забавное совпадение -- и тут опять китайцы...
И главное, никто даже и не пытается особо обеспечивать поддержку RFC6091 в приложениях, особенно в собственно клиентских браузерах. Уже сколько раз об это X.509 руки-ноги ломали, а они так и не учатся и ничему учиться не хотят.
Существующая система сертификации прекрасно выполняет свои цели (как известно, истинные цели любого проекта становятся ясными только после запуска в эксплуатацию) - гарантированный перехват трафика и обход защиты по заказу. А рассматриваемый случай - досадный пример, который не должен был стать достоянием.Типа как намеренно введенные дыры в Windows становятся известными благодаря утечкам, случаю или хакерам.
> Существующая система сертификацииНе вызывает доверия.
отключил в фоксе и конкьюре. спасибо за инфо!
А opennet.ru вообще не поддерживает HTTPS :D
> А opennet.ru вообще не поддерживает HTTPS :D
Алгоритм подписи: PKCS #1 MD5 с шифрованием RSAE = mc@tyumen.ru
CN = *.opennet.ru
OU = web site
O = Opennet.ru
L = Tyumen
ST = Tyumen reg.
C = RUnice try, но нет, спасибо, в таком виде не пойдёт.
С этим я не спорю, он тут просто для галочки, но он на этом сайте и не нужен, особенно анонимам.
а мини-opennet, версия которая открывается по http://opennet.ru есть?
> https://ssl.opennet.ruНе знал, спасибо :).
>> https://ssl.opennet.ru
> Не знал, спасибо :).Да нафиг нужно на самоподписанных то..
> Да нафиг нужно на самоподписанных то..Судя по тексту новости, несамоподписанные не сильно отличаются от самоподписанных. :)))
Что, собственно, очередной раз демонстрирует эпичный системный фейл всей текущей системы сертификации.
Замочил CA в firefoxе
Именно поэтому давно пора переводить сайтовую PKI на публикацию компаниями собственных ключей в защищённых DNSSEC зонах, а не продолжать стричь бабло с желающих купить сертификат.
> ключей в защищённых DNSSEC зонах, а не продолжать стричь бабло сНу, будут публиковать нужные поддельные сертификаты с неподконтрольных авторитетных или корневых серверов, толку то?..
>> ключей в защищённых DNSSEC зонах, а не продолжать стричь бабло с
> Ну, будут публиковать нужные поддельные сертификаты с неподконтрольных авторитетных или корневых серверов, толку то?..Толк в том, что для подделки сертификата придётся подделать конечную запись о нём. DNS-серверов много, клиенты валидность могут вполне проверять с корня DNS - т.е. геморроя потребуется много.
В каком месте CNNIC расшифровывается как China Internet Network Information Center?
Может тогда уж CINIC?
Может быть Network Information Center зоны CN?
В списке рассылки Firefox после новости http://www.opennet.me/opennews/art.shtml?num=33034 я предлагал сделать из JavaScript доступной информацию о полученном сертификате, чтобы ее можно было переслать обратно на сервер. Эта информация доступна для расширений, но не для JavaScript на загруженной странице. Таким образом было бы возможно собрать сертификаты, подписанные такими вот удостоверяющими центрами и сформировать базу центров, продающий свои сертификаты налево. Что очень серьезно смогло бы повлиять на их бизнес. Вряд ли владельцы сайтов при наличии альтернативных поставщиков TLS сертификатов захотят иметь дело с такими умниками, а детсадовские отговорки в духе: "Нас взломали, мы проводим проверку, виновные будут наказаны", - не прокатят (потому что при утечке сертификата удостоверяющего центра в компании либо полное раздолбайство, либо это произошло с негласного разрешения руководства компании).Однако на мое сообщение появились аж два возражения:
1. Это не дает 100% гарантию, ведь можно отключить JavaScript или вырезать его на промежуточном узле, осуществляющем атаку.
Ну, конечно, можно, только для этого потребуется реализовать Искусственный интеллект, который анализирует страницу, убирает нужный скрипт и не изменяет поведение страницы в браузере пользователя.
2. Это может быть не безопасно.
Тут я вообще не понял, о чем речь.
> 2. Это может быть не безопасно.
> Тут я вообще не понял, о чем речь.Ну это же не безопасно для
> ...центров, продающий свои сертификаты налево...
>[оверквотинг удален]
> компании либо полное раздолбайство, либо это произошло с негласного разрешения руководства
> компании).
> Однако на мое сообщение появились аж два возражения:
> 1. Это не дает 100% гарантию, ведь можно отключить JavaScript или вырезать
> его на промежуточном узле, осуществляющем атаку.
> Ну, конечно, можно, только для этого потребуется реализовать Искусственный интеллект,
> который анализирует страницу, убирает нужный скрипт и не изменяет поведение страницы
> в браузере пользователя.
> 2. Это может быть не безопасно.
> Тут я вообще не понял, о чем речь.You are an stupid idiot. Really, a certificate falsification means the server are falsified. Where you send information to?
И они почему-то считают, что фальсификация сертификатов допустима, если она делается внутри каких-то компаний в их внутренних сетях от имени этих компаний.
Я лично не вижу оснований оправдывающих такое. Конечно например Google может подарить кому угодно право подписываться за себя, но в любом другом случае когда какая-либо действующая в сети компания или сайт такого права не предоставляли такое должно быть недопустимо. Наравне с использованием и подделкой подписи или торговой марки.
Например невозможно же оправдать кого-либо если он у себя в офисе своему сотруднику вручит некое обязательство, заверенное подписью председателя правления скажем соседнего банка. На скажем какое-то количество рублей. Подделав бланк этого соседнего банка и подпись председателя. А потом будет говорить, что в пределах своей компании он вполне может использовать любые подписи и бланки... :-)
Примечание. Сайты не заинтересованные в такого рода вещах могут и должны использовать http. Без s.
Примечание к примечанию. Даже последний случай не даёт права фальсифицировать данные.
Пора переходить на одноразовые блокноты.
> Пора переходить на одноразовые блокноты."А на словах просил передать следующее" (C)
«мужик, я не понимаю: ты охотник или #$%:с?» (ц)