Пользователь
102,0
рейтинг
9 июля 2014 в 00:29

Разработка → NIC India выдал цифровые сертификаты на домены Google



2 июля компания Google обнаружила несколько поддельных цифровых сертификатов на свои домены, выданные Национальным центром сертификации (NIC) Индии. Есть вероятность, что NIC выдал сертификаты и на другие сайты, не Google.

Сертификаты NIC Индии входят в каталог Indian Controller of Certifying Authorities (India CCA), который является частью корневого каталога Microsoft Root Store. Поэтому, к сожалению, фальшивые сертификаты принимались в большом количестве программ под Windows, включая браузеры Internet Explorer и Chrome. Только браузер Firefox использует собственный корневой каталог, а не Microsoft Root Store.

Chrome на других операционных системах, в том числе Chrome OS, Android, iOS и OS X, не подвержен уязвимости. К тому же, конкретно для сайтов Google он и под Windows не принял бы фальшивые сертификаты, потому что несколько лет назад после известных инцидентов с CA компания Google начала составлять собственный каталог и «привязвает» свои сертификаты к Chrome (функция certificate pinning).

Компания Google уведомила об инциденте India NIC, India CCA и Microsoft. Центр India CCA отозвал сертификаты 3 июля и начал расследование инцидента.

Фальшивые сертификаты выпускались и в прошлые годы, в том числе намеренно для проведения MiTM-атак по заказу национальных правительств нескольких стран. Подобную подмену сертификатов очень сложно обнаружить на стороне сервера. Фактически, не существует полностью надёжного способа сделать такую проверку. В данном случае подделка была замечена, можно сказать, случайно — благодаря упомянутой функции certificate pinning для сайтов Google.

Пользователям Chrome не нужно предпринимать дополнительных действий для защиты. Тем не менее, этот инцидент в очередной раз обращает внимание на важность повышения безопасности системы CA в будущем. Например, можно использовать глобальную базу данных с публичными сертификатами, с которой будет сверяться браузер.
Анатолий Ализар @alizar
карма
744,5
рейтинг 102,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (19)

  • +8
    Когда Google захватит мир, таких проблем не будет.
    • +8
      Простите, что вы имеете в виду под «когда»?
      • +14
        Такие проблемы могут быть детектором того, что Google мир ещё не захватил.
  • +30
    Разве NIC India после таких действий не должны лишить права добавлять сертификаты в India CCA?
    • +5
      Это просто обычное индусское коекакерство. Мировое сообщество должно понять и простить.

      «В резюме вы написали, что 10 лет проработали в отделе тестирования майкрософт. Мы проверили — такого отдела не существует.»
  • +3
    Помнится давно уже хотели отвязать ответственность за сертификат от выдающего CA и привязать ее к домену аналогично DNS(SEC), чтобы это дело децентрализовать.
    А то вся система CA дырява настолько. что диву даёшься: любой дурак с сертификатом в Trusted Root может выпустить любой сертификат и ему будут доверять.
    Видать кому-то :) это выгодно.
    • 0
      Давно хотели, да перехотели?
    • 0
      А организации кто будет проверять?
      • 0
        Какие организации?

        Обычно, субъектом защиты сертификата является домен (в контексте интернета), аналогично с DNSSEC, где этот же домен защищается от подделки DNS-ответов. Поэтому можно использовать существующую инфраструктуру DNSSEC c древовидным доверием (от корня вниз, который, в принципе, аналогичен PKI, только в DNSSEC корень один) для реализации PKI.

        Я даже нашел черновик RFC на эту тему — tools.ietf.org/html/draft-turner-dnssec-centric-pki-00

        При подключении TLS там предлагается запрашивать сертификат домена по DNSSEC (он лежит в спецательной записи CERT) и сравнивать его с тем, который нам предоставляют во время handshake. Если они совпадают — всё ништяк.
        • 0
          У большинства сертификатов субъектом защиты является не только имя домена, но и имя организации, владеющей этим доменом.
          Указанное RFC предлагает оставить CA, но дополнительно проверять валидность сертификата.
  • +4
    А что насчет Оперы 12.х?
    • 0
      У 12.x свой каталог, если я ничего не путаю.
      Ctrl+F12 -> Расширенные -> Безопасность -> Управление сертификатами -> Издатели
  • +6
    Ммм… Firefox, люблю его.
  • +3
    А тем временем Windows и Firefox всё ещё доверяют The USERTRUST Network, от имени которого 15.03.2011 было выпущено достаточно большое число сертификатов.
  • +5
    Пример DigiNotar и Comodo Group никого ничему не научил. Спасибо NIC India за еще один пример в мою коллекцию.
  • +1
    Кстати, вот видео с TrustyCon, где Chris Palmer говорит как раз о CA и способах решения проблем: www.youtube.com/watch?v=lkO8SNiDSw0#t=16480
  • 0
    Уверен, что менять систему в корне пока никто не готов. Думаю, дело идет к тому, что гиганты отрасли добьются права иметь свой собственный корневой CA в браузерах. А может быть станут выдавать сертификаты и для других сайтов.

    Также этот случай поднимает интересный вопрос. Безопасность браузера сегодня определяется не только качеством кода, его открытостью, оперативностью фиксов. Но и доверием к небольшой группе людей (никому не известных), которые утверждают список корневых CA.
    • 0
      CA/B Forum это достаточно известная и прозрачная организация.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.