Как DNSCrypt решил проблему просроченных сертификатов, введя срок действия 24 часа



    Раньше сертификаты часто истекали из-за того, что их нужно было обновлять вручную. Люди просто забывали это сделать. С появлением Let’s Encrypt и автоматической процедуры обновления вроде бы проблема должна быть решена. Но недавняя история с Firefox показывает, что на самом деле она по-прежнему актуальна. К сожалению, сертификаты продолжают истекать.

    Если кто-то пропустил эту историю, в полночь 4 мая 2019 года внезапно прекратили работать почти все расширения Firefox.

    Как выяснилось, массовый сбой возник из-за того, что у Mozilla истёк срок действия сертификата, который использовался для подписи расширений. Поэтому они отмечались как «невалидные» и не проходили проверку (технические детали). На форумах в качестве обходного пути рекомендовали отключить проверку подписей расширений в about:config или переводом системных часов.

    Mozilla оперативно выпустила патч Firefox 66.0.4, который решает проблему с невалидным сертификатом, а все расширения возвращаются в нормальный вид. Разработчики рекомендуют установить его и не использовать никакие обходные пути для обхода проверки подписей, потому что они могут конфликтовать с патчем.

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

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

    DNSCrypt


    DNSCrypt — протокол шифрования DNS-трафика. Он защищает DNS-коммуникации от перехватов и MiTM, а также позволяет обойти блокировки на уровне DNS-запросов.

    Протокол оборачивает DNS-трафик между клиентом и сервером в криптографическую конструкцию, работая по транспортным протоколам UDP и TCP. Чтобы его использовать, и клиент, и DNS-резолвер должны поддерживать DNSCrypt. Например, с марта 2016 года его включил на своих DNS-серверах и в браузере «Яндекс». О поддержке объявили и некоторые другие провайдеры, в том числе Google и Cloudflare. К сожалению, их не так много (на официальном сайте перечислено 152 публичных DNS-сервера). Но программу dnscrypt-proxy можно установить вручную на клиентах под Linux, Windows и MacOS. Есть и серверные имплементации.



    Как работает DNSCrypt? Если вкратце, то клиент берёт публичный ключ выбранного провайдера и с его помощью проверяет его сертификаты. Уже там находятся краткосрочные публичные ключи для сессии и идентификатор набора шифров. Клиентам рекомендуется генерировать новый ключ для каждого запроса, а серверам — менять ключи каждые 24 часа. При обмене ключами применяется алгоритм X25519, для подписи — EdDSA, для блочного шифрования — XSalsa20-Poly1305 или XChaCha20-Poly1305.

    Один из разработчиков протокола Фрэнк Денис пишет, что автоматическая замена каждые 24 часа решила проблему просроченных сертификатов. В принципе, эталонный клиент dnscrypt-proxy принимает сертификаты с любым сроком действия, но выдаёт предупреждение «Период dnscrypt-proxy ключей для этого сервера слишком велик», если он действителен более 24 часов. Одновременно был выпущен образ Docker, в котором реализовали быструю смену ключей (и сертификатов).

    Во-первых, это чрезвычайно полезно для безопасности: если сервер скомпрометирован или ключ утёк, то вчерашний трафик не может быть расшифрован. Ключ уже изменился. Вероятно, это составит проблему для исполнения «закона Яровой», который вынуждает провайдеров хранить весь трафик, в том числе зашифрованный. Подразумевается, что позже его можно будет расшифровать при необходимости, запросив ключ у сайта. Но в данном случае сайт просто не сможет его предоставить, потому что использует кратковременные ключи, удаляя старые.

    Но главное, пишет Денис, краткосрочные ключи заставляют серверы с первого дня настроить автоматизацию. Если сервер подключается к сети, а скрипты смены ключей не настроены или не работают, это будет немедленно обнаружено.

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

    В то же время, если автоматизация настроена нормально, то не имеет значения, как часто производится смена ключей: каждый год, каждый квартал или три раза в день. Если всё работает более 24 часов, то будет работать вечно, пишет Фрэнк Денис. По его словам, рекомендация ежесуточной смены ключей во второй версии протокола вместе с готовым образом Docker, реализующим это, эффективно уменьшило количество серверов с истёкшими сертификатами, одновременно улучшив безопасность.

    Однако некоторые провайдеры всё-таки решили по каким-то техническим причинам установить срок действия сертификата более 24 часов. Эту проблему в основном решили с помощью нескольких строк кода в dnscrypt-proxy: пользователи получают информационное предупреждение за 30 дней до истечения срока действия сертификата, другое сообщение с более высоким уровнем серьёзности за 7 дней до истечения срока действия и критическое сообщение, если у сертификата осталось менее 24 часов. Это относится только к сертификатам, изначально имеющим длительный срок действия.

    Такие сообщения дают пользователям возможность сообщить операторам DNS о предстоящем истечении срока действия сертификата, пока не стало слишком поздно.

    Возможно, если бы все пользователи Firefox получили такое сообщение, то уж кто-нибудь наверняка сообщил разработчикам и те бы не допустили истечения срока действия сертификата. «Я не помню ни одного DNSCrypt-сервера из списка общедоступных DNS-серверов, у которых истёк срок действия сертификата за последние два или три года», — пишет Фрэнк Денис. В любом случае, наверное, лучше сначала предупреждать пользователей, а не отключать расширения без предупреждения.




    СПЕЦИАЛЬНЫЕ УСЛОВИЯ на PKI-решения для предприятий действуют до 30.11.2019 г. по промо-коду AL002HRFR для новых клиентов. Подробности уточняйте у менеджеров +7 (499) 678 2210, sales-ru@globalsign.com.
    GlobalSign
    167,85
    Компания
    Поделиться публикацией

    Комментарии 14

      +1
      Хм, интересно как сильно увеличится нагрузка на какой-нибудь условный летсэнкрипт если все сайты будут ежедневно обновлять свой сертификат, а ещё половина их будет настроена делать это в 0:00 UTC — сильный ли ддос ли будет?
        0

        LE не разрешит сделать сертификат раньше 30 дней до истечения срока действия.

          0

          На самом деле ограничения Let's Encrypt описаны на странице https://letsencrypt.org/docs/rate-limits/. На момент написания этого комментария на выпуск сертификатов действовали следующие ограничения:


          1. Выпуск сертификата, список имён в котором в точности совпадает со списком имён в другом действующем сертификате, выданном Let's Encrypt — не более 5 штук в течение 7 суток.
          2. Выпуск сертификата, список имён в котором не совпадает ни с одним другим сертификатом, выданным Let's Encrypt — не более 50 штук в течение 7 суток для зарегистрированного домена (определяется с учётом Public Suffix List); это ограничение может быть повышено по специальному запросу. До марта 2019 года это ограничение действовало и на перевыпуск сертификатов, но теперь для перевыпуска действует только первое ограничение.
          3. При использовании ACME v2 с одной учётной записи можно отправлять не более 300 запросов на выдачу сертификата в течение 3 часов.
          0

          Нужно использовать тот же принцип. С 0:00 до 0:05 не работать вообще — тогда всем придётся вводить своё время и все введут разное.

          +3
          Возможно, если бы все пользователи Firefox получили такое сообщение, то уж кто-нибудь наверняка сообщил разработчикам и те бы не допустили истечения срока действия сертификата

          Там сертификат истёк не у пользователей, не у разработчиков расширений, а рутовый сертификат мозиллы.
          Соответственно нужно писать код который проверяет срок действия сертификата, промежуточного сертификата и рутового сертификата. А если мы пишем код проверяющий срок действия рутового сертификата, — не проще ли сразу слать уведомление разработчикам?
          В остальном согласен с автором статьи, быстрая смена сертификатов — добро.
            0
            Точнее, истёк сертификат, который пакуется внутрь каждого дополнения («корневой» (встроен в браузер, не истёк) → «промежуточный» (один на все дополнения, поставляется внутри дополнения, истёк) → «индивидуальный» (уникален для дополнения, поставляется внутри дополнения)). Так что, всё-таки, на стороне пользователя он присутствует.
              0
              Ваша правда, истёк промежуточный сертификат. Был неправ, посыпаю голову пеплом. Но это не отменяет всего остального — рутовый сертификат у пользователя тоже есть, иначе пользователь не мог бы проверить валидность промежуточного сертификата.
            0
            А это поэтому у меня FF стал при запуске пытаться сожрать память и не откликался пока не отжирал всё и потом сбрасывал и оживал?
              0
              Если у вас версия 66.0.4 или выше, а проблема осталась, то, вероятно, не поэтому.
              0
              > Во-первых, это чрезвычайно полезно для безопасности: если сервер скомпрометирован или ключ утёк, то вчерашний трафик не может быть расшифрован. Ключ уже изменился. Вероятно, это составит проблему для исполнения «закона Яровой», который вынуждает провайдеров хранить весь трафик, в том числе зашифрованный. Подразумевается, что позже его можно будет расшифровать при необходимости, запросив ключ у сайта. Но в данном случае сайт просто не сможет его предоставить, потому что использует кратковременные ключи, удаляя старые.

              В TLS и так достаточно давно есть forward secrecy, при котором никакая утечка ключа от сертификата не позволит ничего расшифровать.
                0
                Правда, у DNSCrypt свой протокол. Если чувак пишет, что ротация сертифкатов помогает с forward secrecy, видимо, этого perfect secrecy в самом протоколе нет.
                  0
                  просто не сможет его предоставить

                  До первого раза. После чего намекнут на ненулевую вероятность пойти сообщником и установить правильно пропатченную версию, которая просроченные сертификаты складывает в отдельную папочку.
                  0
                  Я может глупую вещь спрошу, но разве нельзя обеспечить шифрование без сертификатов? (именно шифрование, проверку соответствия я сам как-нибудь обеспечу).

                  Установить соединение по Diffie–Hellman (или подобное), и не нужен никакой третий дядя. Почему так нельзя?
                    0
                    Потому что активный MITM сломает этот шифрование. Вам нужно доверенное лицо, которое удостоверит, что вы соединяетесь с аутентичным сервером.

                    Попробую объяснить наглядно, есть три узла: А подключается к Б, их хочет перехватить С.
                    В момент когда вы начинаете обмен ключами DH, — С перехватает эти пакеты и не доставляет к Б, а представляется сервером и вы фактически устанавливаете соединение с ним. Параллельно с этим С устанавливает соединение с Б.
                    Установив оба соединения, — С прозрачно пробрасывает расшифрованный трафик из тунеля А-С в тунель С-Б, и наоборот.

                    Соответственно проверка сертификата при установке соединения, — это защита подтверждающая, что вы соединяетесь именно с Б, а не с С.

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

                  Самое читаемое