В Windows, согласно этой информации обновление корневых сертификатов производится с помощью Certificate Trust List — CTL. Хотя из статьи следует, что это какая то примочка для кеширования списка сертификатов на локальном сервере, поиск услужливо подсказывает, что существует authrootstl.cab, подписанный Microsoft, которому Windows, начиная с 7, доверяет безоговорочно, и обновляет его каждую неделю, а в случае установки обновления KB3004394 — каждый день.


В консоли (MMC) можно добавить сертификаты, к которым нет доверия, но вот удалить корневой сертификат не так то просто.



Вдохновившись недавним скандалом с объединением WoSign и StartCom, решил удалить какой-нибудь стремный сертификат из Windows 7. Выбор пал на Izenpe.com (?06 e8 46 27 2f 1f 0a 8f d1 84 5c e3 69 f6 d5), ибо баски и SHA-1. Но не тут-то было. После удаления корневого сертификата и захода на https://www.izenpe.com из Chrome 55.0.2883.87 m сертификат появился в списке сторонних корневых центров сертификации, и, соответственно, в списке доверенных корневых центров сертификации. Что, в принципе, ожидаемо.


Google Chrome attempts to use the root certificate store of the underlying operating system to determine whether an SSL certificate presented by a site is indeed trustworthy, with a few exceptions.
https://www.chromium.org/Home/chromium-security/root-ca-policy

Повторить трюк с Firefox 50.1.0 не вышло, те используют внутри браузера свое хранилище сертификатов. С Internet Explorer 11.0.9600.18163 трюк повторяется.


Казалось бы, виновники найдены. Но нет, берем https://opensource.apple.com/source/security_certificates/security_certificates-55036/roots/Izenpe-RAIZ2007.crt и открываем через Расширения оболочки шифрования, то бишь двойным щелчком.


И видим, что сертификат доверенный.


Это как вообще? Заходим в консоль и видим, что злосчастный сертификат есть в списке доверенных корневых центров сертификации.


А может Windows все неизвестные корневые сертификаты подтягивает в доверенное хранилище? Берем OpenSSL, генерируем корневой сертификат, открываем. Недоверенный.


А я уже раскатал губу, что удастся подписывать своим CA сертификаты для гитхаба. Хотя ни одна из записей реестра, описанная в статье на technet не существует по умолчанию ни в Windows 7, ни в Windows Server 2012, по всему видно, что имеется захардкоженный список доверенных сертификатов, не видимый ни в реестре, ни в групповых политиках, ни в консоли управления.

Поделиться с друзьями
-->

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


  1. Halt
    17.01.2017 09:02
    +5

    Бекдор для АНБ? :)


    1. unxed
      17.01.2017 09:07
      +11

      Для ??Б.


      1. 4dmonster
        17.01.2017 09:42
        +7

        Бекдор для *


    1. petrovartur
      18.01.2017 16:00
      -1

      Точно, и все сис.админы про это знают, особенно работающие на гос. и военком. структуры


      1. navion
        18.01.2017 16:29

        У них должен стоять сертифицированный дистрибутив, обновления к которому тоже проверяются.


  1. orcy
    17.01.2017 09:44
    +3

    Это же известная фича, если я правильно понял описание. Windows по умолчанию установлена с небольшим количеством сертификатам в store и новые сертификаты берутся либо через Windows Update по необходимости, либо из ресурсов Crypt32.dll (например когда нет связи с Windows Update).


    1. galeksandrp
      17.01.2017 12:34

      Я просто думал, что вбандлены только 3 сертификата, ну и с десяток в хранилище, а оказалось что нет, вбандлены все из Root CA Program, плюс обновляться они могут как из WSUS при обновлении библиотеки, так и через authrootstl.cab.



  1. OasisInDesert
    17.01.2017 10:20
    +3

    Разработчики Огнелиса весьма предусмотрительно создали и эксплуатируют собственное хранилище сертификатов.


    1. AleksGRV
      17.01.2017 12:40

      Которое использует и Node.js


      1. mayorovp
        17.01.2017 12:51
        +1

        Это как вообще?


        1. AleksGRV
          17.01.2017 13:37

          If the 'ca' option is not given, then Node.js will use the default publicly trusted list of CAs as given in http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt.
          Документация

          Но уважаемые разработчики Node.js несколько лукавят, т.к. используют бандл, который вручную сами и правят.

          Несколько странный уровень доверия, не так ли?

          И только в недавнем пулл реквесте добавили опцию, для указания собственного (пользовательского) бандла.


          1. mayorovp
            17.01.2017 13:46

            Вот именно, они собирают свой бандл. Который не обращается к хранилищу сертификатов браузера.


    1. foxmuldercp
      17.01.2017 13:00

      Mozilla и The BAt в почтовиках делает точно так же — свои хранилища.
      Я долго возился, когда внедрял корпоративные сертификаты и ЦА и удивлялся, что не все почтовые клиенты их видят по умолчанию, пока не полез достаточно глубоко в настройки чтобы обьяснить Mozilla TB что ему для почты надо использовать и системное хранилище сертификатов


      1. navion
        18.01.2017 10:35

        В линуксовых приложениях часто используют набор УЦ от Мозиллы. А свои хранилища ещё есть в JRE и WAS.


    1. V2008
      27.01.2017 15:10
      +1

      И Огнелис и браузеры Chrome от Google

      создали и эксплуатируют собственное хранилище сертификатов

      на базе NSS (Network Security System)


      1. navion
        27.01.2017 15:14
        +1

        На Винде Хром использует системное хранилище.


        1. saipr
          27.01.2017 16:10

          Да, это именно так. Спасибо. Все время этот Windows


  1. Iqorek
    17.01.2017 11:18

    Один раз имел с этим небольшой секс, везде работает, в лисе невалидный сертификат на одном из линков. И да, я тогда еще не знал, что у них свое хранилище.


    1. vip1953
      27.01.2017 15:10

      Да, в Лисе свое хранилище на NSS, также как и Гугл


  1. navion
    18.01.2017 10:25

    Автоматическое обновление можно отключить через ГП, также с ним при недоступности CDN и протухании CTL возможны интересные эффекты.
    А тут исследователь ведёт список добавляемых сертификатов, у него вообще много интересного по теме.


  1. Tante
    18.01.2017 16:00

    Ну так то предустановленные корневые сертификаты используются для проверки валидности ПО и драйверов для самой ОС. Что само по себе вполне рабочий вариант, не считая постоянных дырок для обхода этих проверок.


  1. alsii
    18.01.2017 16:31

    хм… я правильно понимаю, что чтобы внедрить национальный HTTPS MITM достаточно договориться с Microsoft?


    1. navion
      18.01.2017 16:37
      -1

      Хром настучит при первом запуске и сертификат отзовут.


      1. alsii
        19.01.2017 16:26

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


        1. navion
          19.01.2017 16:38

          В Хроме захардкожены сертификаты для некоторых сайтов (GMail, Paypal и т.п.) и при подмене сертификата публичным CA идёт уведомление.
          Отзовёт сам Microsoft: наверняка реакция прописана в правилах CA/B Forum и из-за угрозы перехвата данных за пределами РФ.


          1. alsii
            20.01.2017 09:26

            Как показали недавние события с Google тоже можно договориться.


            Насчет угрозы перехвата за педелами РФ, понятное дело, что сертификат внесут только в русскую версию. Microsoft обычно идет на сотрудничество с национальными правительствами. Во французской версии, например, свои заморочки на тему криптографии.


    1. Tante
      19.01.2017 06:35
      +1

      К счастью договорится с MS в наших реалиях проблематично. Но в наших казахских степях у большинства стоят корневые сертификаты местного центра. Без них не работает онлайн сервис всяких справок, а без него жизнь сильно усложняется.
      Самое веселое — у всей страны один пароль на личный сертификат. Безопасность на уровне!


      1. alsii
        19.01.2017 16:28

        Ну почему же проблематично. Не перевелись еще мастера делать "предложения, от которых невозможно отказаться".


      1. monah_tuk
        20.01.2017 05:56

        Ну… при паранойе нижнего уровня, я бы сделал как-то так:


        #!/bin/sh
        #export HOME=/some/path
        export profile="$HOME/some-profile-path"
        exec firefox --profile "$profile" "$@"

        Засунуть это в gosfirefox и сделать ему chmod +x… Затем добавить туда корневой сертификат местного центра и использовать этот "бандл" для работы с гос-сайтами.


        Дефолтный firefox использовать для обычной жизни.


        По мере роста параноидальности, можно разбавить:


        1. Убрать комментарий с экспорта HOME
        2. Запускать вообще от отдельного пользователя
        3. Запускать из chroot
        4. Виртуалки

        5. N. ..

        А по поводу пароля… Его же вроде средствами OpenSSL поменять можно, не?


        1. Tante
          20.01.2017 05:59

          Вы абсолютно правы, вариантов много и разных. Только вот большинство населения этим заниматься не будут ввиду отсутствия элементарных навыков. Правильнее было бы генерировать рандомный пароль для каждого выданного сертификата, а не 123456. Ой, кажется я допустил утечку государственного масштаба! =)


  1. JhaoDa
    19.01.2017 16:34

    Интересно, чем вам баски-то не угодили?


  1. maxdm
    25.01.2017 16:07

    Обновление корневых сертификатов можно отключить в компонентах Windows или в групповой политике.
    https://technet.microsoft.com/en-us/library/cc734054(WS.10).aspx
    Есть несколько required сертификатов, но в целом никаких секретных мест больше вроде бы нет. Но их тоже можно удалить. Вот список для старой ОС:
    https://support.microsoft.com/en-us/help/293781/trusted-root-certificates-that-are-required-by-windows-server-2008-r2,-by-windows-7,-by-windows-server-2008,-by-windows-vista,-by-windows-server-2003,-by-windows-xp,-and-by-windows-2000