CNNIC включен во все основные списки доверенных сертификационных центров и поэтому выданным им сертификатам доверяет большинство браузеров и операционных систем. Chrome на всех операционных системах и Firefox версий 33 и старше отклоняют поддельные сертификаты для доменов Google из-за того, что их публичные ключи вшиты в бинарники браузеров, что, однако, не решает проблему вероятного существования поддельных сертификатов для других доменов.
Google оперативно оповестил CNNIC и разработчиков других браузеров об этом инциденте и заблокировал все выданные компанией MCS Holdings сертификаты путём обновления CRLSet. CNNIC ответили 22-го марта и объяснили, что у них был договор с MCS Holdings о том, что эта компания будет выпускать сертификаты только для доменов, которые будут ею зарегистрированы. Однако, вместо того, чтобы хранить приватный ключ в безопасном аппаратном хранилище, MCS прошила его в свой продукт — man-in-the-middle прокси-сервер. Эти устройства позволяли на лету сгенерировать поддельные сертификаты для посещаемых пользователями https-ресурсов, позволяя, к примеру, компаниям следить за своими работниками таким образом, что у тех не возникало подозрений в том, что их текущее соединение не является безопасным. Ситуация похожа на случай с ANSSI в 2013-ом году.
Данное объяснение полностью согласуется с фактами. Однако CNNIC всё ещё не отозвал сертификат у компании MCS Holdings, хотя по всем правилам обязан это сделать.
Пользователям Chrome не нужно ничего предпринимать в связи с тем, что они защищены последним обновлением CRLSet. Google не располагает информацией о потере персональных данных или паролей пользователей.
Данное происшествие ещё раз подтверждает важность проекта Certificate Transparency для защиты безопасности сертификатов в будущем.
(Детали поддельной цепочки сертификатов для разработчиков ПО — здесь)
Обновление: в результате совместного расследования данного инцидента специалистами Google и CNNIC, было принято решение исключить сертификаты CNNIC Root и EV из списка доверенных в продуктах Google. Это будет сделано в следующем обновлении Chrome. В целях уменьшения ущерба для конечных пользователях ещё некоторое время эти сертификаты будут считаться доверенными в Chrome путём включения их во временный «белый список». Google и CNNIC считают, что больше поддельных сертификатов выпущено не будет, а уже выпущенные использовались лишь во внутренней тестовой сети компании MCS Holdings. CNNIC будет работать над внедрением Certificate Transparency для всех своих сертификатов и по окончанию процедур усовершенствования контроля подаст заявку на повторное включение в список доверенных сертификационных центров.
Комментарии (50)
relgames
08.04.2015 14:15+4Рафик невиноват
MCS had received the Sub-ordinate certificate from CNNIC on mentioned date and started the test on same day inside MCS lab which is a protected environment, MCS had assured to store the private key in a FIPS compliant device (Firewall), to run the test which had started with no incidents on Thursday, and for the sack of unintentional action the Firewall had an active policy to act as SSL forward proxy with an automatic generation for a certificates for browsed domains on the internet, which had been taken place on a weekend time (Friday, and Saturday) during unintentional use from one of the IT Engineers for a browsing the internet using Google Chrome which had reported a miss-use at Google’s End.
www.mcsholding.com/MCSResponse.aspx
Совершенно случайно девайс стал работать как SSL прокси, ага.
alexk24
08.04.2015 14:51+2позволяя, к примеру, компаниям следить за своими работниками таким образом, что у тех не возникало подозрений в том, что их текущее соединение не является безопасным
Компания для своих компьютеров без проблем может выпустить корневой сертификат. А тут скорее всего все несколько интереснее.
Helldar
08.04.2015 15:33-11Согласен, учитывая что недавно хакеры взломали сеть Белого Дома, думаю, таким образом за бугорные товарищи пытаются ломануть наших xD
grossws
08.04.2015 17:48+5Когда компания использует для MitM private CA — это никого не волнует. Когда public CA подписывает неограниченный сертификат с CA:True — это принципиально другая ситуация.
dmitrmax
09.04.2015 13:36+1Да это понятно, просто предыдущий оратор, наверное, имел ввиду, что проблема, для решения которой якобы был издан такой сертификат, решается другим способом. А по факту мы имеем дело просто с отмазой.
ColorPrint
09.04.2015 00:42-1Тут еще проблема с браузерами, точнее с их интерфейсом…
Что соединение защищено сертификатом они показывают, а вот кому выдан сертификат (и проверялись ли данные компании, или только сам домен) — никто обычно не смотрит…dmitrmax
09.04.2015 01:38вообще-то браузер проверяет, что сертификат выдан тому домену, на который ты зашел. однако на один и тот же домен сертификат может быть выдан кучей разных CA, и понять какой из них левый, без отпечатка ключа нельзя.
ColorPrint
09.04.2015 15:09Так должен проверять не только домен, но и организацию.
dmitrmax
09.04.2015 15:10Какую организацию?
ColorPrint
09.04.2015 15:13Которой выдан сертификат и документы которой проверялись при выдаче сертификата.
dmitrmax
09.04.2015 15:17+1Вы всерьез полагаете, что если можно подделать сертификат с доменным именем, то в нем нельзя указать такие же данные, что и в настоящем сертификате организации? Или вы знаете какой-то другой способ «проверки организации» браузером?
ColorPrint
09.04.2015 17:56-2Если сертификат выдается легальным доверенным центром сертификации — то естественно нельзя, т.к. у мошенников не будет соответствующих документов. А сертификаты для которых проверяется только домен — легко выпустить взломав сайт или почту на домене.
Аналогично и для всякого софта на ISP подделывающего сертификаты по пути маршрута для перехвата SSL-трафика — при проверке организации, на которую выдан сертификат, браузером — такая проверка просто бы не прошла.dmitrmax
09.04.2015 17:59Вы точно осознали смысл поста? В том-то и дело, что сертификат выдан легальным доверенным центром сертификации.
ColorPrint
09.04.2015 18:01И организация в нем совпадала с организацией, на которую выдан оригинальный сертификат? Сильно сомневаюсь.
dmitrmax
09.04.2015 18:05+2Признайтесь, вы не владете темой X.509?
ColorPrint
09.04.2015 18:07Почему же?
dmitrmax
09.04.2015 18:09+1Потому, что ответ на ваш предыдущий вопрос очевиден любому, кто с этим мало-мальски знаком. И этот ответ «да».
Хуже, что вы в этом боитесь признаться.ColorPrint
09.04.2015 18:10И знаком, и сертификаты продаю в том числе более 13 лет.
dmitrmax
09.04.2015 18:14Какой ужас. И вы продаете своим клиентам сертификаты со свойством CA:True? Продайте мне?
ColorPrint
09.04.2015 18:32Нет конечно )
dmitrmax
09.04.2015 18:35А почему? В смысле почему вы не продаете, но при этом не понимаете, каким образом случилось описанное в посте?
ColorPrint
09.04.2015 18:42Почему не понимаю? Вроде все понятно описано.
И прецеденты с фильтрацией трафика на стороне провайдера по аналогичной технологии уже были.
Только организация в сертификате никогда не подделывалась — просто генерировались сертификаты на домен.dmitrmax
09.04.2015 18:46+1Думаете, что только именно этим такие сертификаты отличались от оригинальных? (ну и разумеется отпечатком)
grossws
09.04.2015 18:50Любой тривиальный кусок говна типа mitmproxy может взять оригинальный сертификат и выпустить аналогичный (с тем же subject /O=Google Inc/CN=*.google.com).
Это просто увеличивает latency (надо сходить на реальный сайт за сертификатом вместо того, чтобы сразу сгенерировать с синтетическим /CN=*.google.com).ColorPrint
09.04.2015 20:03И думаете им за это ничего не будет?
Одно дело домен, другое дело выдавать сертификат за выданный конкретной организации, и подтверждать то что он выдан именно ей.grossws
09.04.2015 20:37+1Любая выдача сертификата не настоящему владельцу (домен там будет или домен + учетные данные организации или физ. лица) публичным CA — это серьезное деяние идущее в разрез с требованиями к аккредитованному public CA и, в идеале, должно приводить к отзыву сертификата самого CA.
dmitrmax
10.04.2015 10:21Отозвать CA, если он рутовый, КМК, нельзя ) Можно только его выпилить на локальной машине, что гуглы и собираются сделать в следующей версии Chrome.
Но, кстати, поглядел сейчас списки доверенных центров — там этой китайской шаражки нет.grossws
10.04.2015 10:43Под «отозвать» я имел ввиду не какая-нибудь техническую процедуру, а недоверие со стороны основных игроков.
Каждый из них может выпустить обновление, удаляющее данный ca (или костыль, чтобы заблокировать его, если он в доверенных в системном списке cacerts и на данной ОС используется системный список). Т.е. это должны сделать Google, Mozilla, Microsoft, Oracle, вендоры разных дистрибутивов (хотя многие пользуются набором от Mozilla).
У себя выпилил его руками за пару дней до этой статьи из nssdb хрома.
dmitrmax
09.04.2015 01:35А на гугле свет клином сошелся? Почему эта контора не могла сгенерить поддельные сертификаты на еще кучу компаний, публичные ключи которых не вшиты в браузеры?
tangro Автор
09.04.2015 10:47+1Могла, и наверняка сгенерировала. Поэтому CNNIC и был исключен из списка доверенных центров выдачи сертификатов. Т.е. все поддельные сертификаты (если они были) теперь тоже не работают.
ColorPrint
09.04.2015 20:05А их клиентам теперь что делать? )
Которые заплатили за сертификаты.grossws
09.04.2015 20:40В части статей по этой теме утверждалось, что сертификаты подписанные до 01.04.2015 (этим CA и подчиненными ему) останутся валидными, как раз, чтобы уменьшить collateral damage.
alexk24
09.04.2015 13:14У гугла (благодаря хрому) просто есть инструмент для выявления подобных фокусов.
Публичный ключик гугла вшит в хром и вероятно при открытии сервисов гугла он проверяет не только то что сертификат соответствует домену, но и то что это действительно тот сертификат который ожидается и в случае если это не так сливает информацию о этом факте на сервера гугла с информацией о левом сертификате.
Таким образом у гугла есть распределенная сеть для отслеживания попыток подмены своих сертификатов и вероятно когда количество пользователей с подобными проблемами на одном сертификате превышает какой-то порог к разбирательству приступают их специалисты.dmitrmax
09.04.2015 13:31Да это всё понятно, я просто к тому, что данная новость воспринята как-то легко. Ну нашли левый сертификат, выданный на гугл, ну нашли того, кто в этом виноват, ну уберут из доверенных этот trusted root только в следующей версии.
А то, что, наверняка, кроме гугла ещё куча таких сертификатов есть — это как-то не обсуждается. Камент был про то, что надо взгянуть на проблему шире, а успокаиваться рано.relgames
09.04.2015 14:42+1Да это всё понятно, я просто к тому, что данная новость воспринята как-то легко. Ну нашли левый сертификат, выданный на гугл, ну нашли того, кто в этом виноват, ну уберут из доверенных этот trusted root только в следующей версии.
А разве когда-то было иначе? Насколько я знаю, только история с голыми знаменитостями получила какую-то более-менее серьезную огласку, да и то, уже про это начинают забывать.
А как насчет вот этого www.rbcdaily.ru/world/562949988649672 или вот этого hitech.newsru.com/article/05Dec2014/auroragold?
Всем действительно стало пофиг. Мне кажется, этот сдвиг произошел буквально за последние пару десятков лет, и фейсбук сыграл не последнюю роль.
BaRoN
09.04.2015 16:02А что тут такого удивительного? Не исключено, что такие сертификаты есть и у, например, американского правительства; крупных транснациональных корпораций или кого-либо ещё. Ничего не изменилось, в общем-то. отпечаток ключа было нужно, нужно и будет нужно проверять.
dmitrmax
09.04.2015 16:41Не исключено.
Отпечаток надо проверять. Только где его взять? Опять таки, имея левый сертификат гугла, можно подсунуть левый хром, который не будет уже проверять глючи гула, например, а проверять свои. В классике отпечатки должны быть переданы другим надежным каналом.
Я согласен лишь с таким утверждением, что при наличии отпечатка, нужно отключать «как бы» доверенные CA.ColorPrint
09.04.2015 18:00Отпечаток надо проверять. Только где его взять?
DNSSEC+DANEdmitrmax
09.04.2015 18:24а простите, DNSSEC у вас как без цепочки доверия будет работать?
ColorPrint
09.04.2015 18:33Куда она денется то?
dmitrmax
09.04.2015 18:36Никуда не денется. И поэтому в ней возможны точно такие же косяки, как и произошли с сертификатом Google. А раз так, то вы предлагаете поменять шило на мыло.
Vindicar
11.04.2015 01:02+1А то, что теперь на гиктаймс не залогиниться из-за ошибки SSL — это случайно не связано? =\
Firefox новый, аддоны/файрвол/антивирус нипричем…
XogN
Грустно все это…
tangro Автор
Да, но радуют несколько фактов: