Comments 14
Хм, интересно как сильно увеличится нагрузка на какой-нибудь условный летсэнкрипт если все сайты будут ежедневно обновлять свой сертификат, а ещё половина их будет настроена делать это в 0:00 UTC — сильный ли ддос ли будет?
LE не разрешит сделать сертификат раньше 30 дней до истечения срока действия.
На самом деле ограничения Let's Encrypt описаны на странице https://letsencrypt.org/docs/rate-limits/. На момент написания этого комментария на выпуск сертификатов действовали следующие ограничения:
- Выпуск сертификата, список имён в котором в точности совпадает со списком имён в другом действующем сертификате, выданном Let's Encrypt — не более 5 штук в течение 7 суток.
- Выпуск сертификата, список имён в котором не совпадает ни с одним другим сертификатом, выданным Let's Encrypt — не более 50 штук в течение 7 суток для зарегистрированного домена (определяется с учётом Public Suffix List); это ограничение может быть повышено по специальному запросу. До марта 2019 года это ограничение действовало и на перевыпуск сертификатов, но теперь для перевыпуска действует только первое ограничение.
- При использовании ACME v2 с одной учётной записи можно отправлять не более 300 запросов на выдачу сертификата в течение 3 часов.
Нужно использовать тот же принцип. С 0:00 до 0:05 не работать вообще — тогда всем придётся вводить своё время и все введут разное.
Возможно, если бы все пользователи Firefox получили такое сообщение, то уж кто-нибудь наверняка сообщил разработчикам и те бы не допустили истечения срока действия сертификата
Там сертификат истёк не у пользователей, не у разработчиков расширений, а рутовый сертификат мозиллы.
Соответственно нужно писать код который проверяет срок действия сертификата, промежуточного сертификата и рутового сертификата. А если мы пишем код проверяющий срок действия рутового сертификата, — не проще ли сразу слать уведомление разработчикам?
В остальном согласен с автором статьи, быстрая смена сертификатов — добро.
Точнее, истёк сертификат, который пакуется внутрь каждого дополнения («корневой» (встроен в браузер, не истёк) → «промежуточный» (один на все дополнения, поставляется внутри дополнения, истёк) → «индивидуальный» (уникален для дополнения, поставляется внутри дополнения)). Так что, всё-таки, на стороне пользователя он присутствует.
А это поэтому у меня FF стал при запуске пытаться сожрать память и не откликался пока не отжирал всё и потом сбрасывал и оживал?
> Во-первых, это чрезвычайно полезно для безопасности: если сервер скомпрометирован или ключ утёк, то вчерашний трафик не может быть расшифрован. Ключ уже изменился. Вероятно, это составит проблему для исполнения «закона Яровой», который вынуждает провайдеров хранить весь трафик, в том числе зашифрованный. Подразумевается, что позже его можно будет расшифровать при необходимости, запросив ключ у сайта. Но в данном случае сайт просто не сможет его предоставить, потому что использует кратковременные ключи, удаляя старые.
В TLS и так достаточно давно есть forward secrecy, при котором никакая утечка ключа от сертификата не позволит ничего расшифровать.
В TLS и так достаточно давно есть forward secrecy, при котором никакая утечка ключа от сертификата не позволит ничего расшифровать.
Правда, у DNSCrypt свой протокол. Если чувак пишет, что ротация сертифкатов помогает с forward secrecy, видимо, этого perfect secrecy в самом протоколе нет.
просто не сможет его предоставить
До первого раза. После чего намекнут на ненулевую вероятность пойти сообщником и установить правильно пропатченную версию, которая просроченные сертификаты складывает в отдельную папочку.
Я может глупую вещь спрошу, но разве нельзя обеспечить шифрование без сертификатов? (именно шифрование, проверку соответствия я сам как-нибудь обеспечу).
Установить соединение по Diffie–Hellman (или подобное), и не нужен никакой третий дядя. Почему так нельзя?
Установить соединение по Diffie–Hellman (или подобное), и не нужен никакой третий дядя. Почему так нельзя?
Потому что активный MITM сломает этот шифрование. Вам нужно доверенное лицо, которое удостоверит, что вы соединяетесь с аутентичным сервером.
Попробую объяснить наглядно, есть три узла: А подключается к Б, их хочет перехватить С.
В момент когда вы начинаете обмен ключами DH, — С перехватает эти пакеты и не доставляет к Б, а представляется сервером и вы фактически устанавливаете соединение с ним. Параллельно с этим С устанавливает соединение с Б.
Установив оба соединения, — С прозрачно пробрасывает расшифрованный трафик из тунеля А-С в тунель С-Б, и наоборот.
Соответственно проверка сертификата при установке соединения, — это защита подтверждающая, что вы соединяетесь именно с Б, а не с С.
Попробую объяснить наглядно, есть три узла: А подключается к Б, их хочет перехватить С.
В момент когда вы начинаете обмен ключами DH, — С перехватает эти пакеты и не доставляет к Б, а представляется сервером и вы фактически устанавливаете соединение с ним. Параллельно с этим С устанавливает соединение с Б.
Установив оба соединения, — С прозрачно пробрасывает расшифрованный трафик из тунеля А-С в тунель С-Б, и наоборот.
Соответственно проверка сертификата при установке соединения, — это защита подтверждающая, что вы соединяетесь именно с Б, а не с С.
Sign up to leave a comment.
Как DNSCrypt решил проблему просроченных сертификатов, введя срок действия 24 часа