О проекте Let’s Encrypt
Let’s Encrypt — это бесплатный, автоматизированный и открытый Центр сертификации (ЦС), работающий на благо общества. Это сервис, предоставляемый Исследовательской группой по безопасности Интернета (ISRG).
Мы помогаем людям выпускать SSL/TLS сертификаты для их сайтов с доступом по HTTPS, бесплатно, максимально облегчая процесс выдачи. Потому что хотим сделать интернет безопасным, и уважающим конфиденциальность его пользователей.
О наших успехах за последний год вы можете узнать, скачав наш годовой отчёт.
Ключевые принципы Let’s Encrypt:
- Бесплатность: Любой владелец домена может использовать Let’s Encrypt для получения SSL/TLS сертификатов, не тратя ни копейки.
- Автоматизированность: Программное обеспечение, запущенное на веб-сервере, может взаимодействовать с Let’s Encrypt и само позаботится о получении, безопасной настройке и обновлении сертификата.
- Безопасность: Let’s Encrypt будет платформой для передовых технологии в области безопасности TLS, и на стороне ЦС, и помогая владельцам сайтов защищать их серверы.
- Прозрачность: Все выданные или отозванные сертификаты будут сохранены открыто и доступно для любых проверок.
- Открытость: Протокол автоматического выпуска и обновления сертификатов опубликован как открытый стандарт, готовый для использования другими.
- Взаимодействие: Подобно лежащим в основе Интернета протоколам, Let’s Encrypt — это результат совместных усилий на благо сообщества, неподконтрольных какой-либо одной организации.
У нас есть страница с более подробной информацией о том, как работает ЦС Let’s Encrypt.
Помогите сделать Интернет безопасным и уважающим вашу конфиденциальность.
Let’s Encrypt — это бесплатный, автоматизированный и открытый Центр Сертификации, созданный для вас некоммерческой организацией Internet Security Research Group (ISRG).
548 Market St, PMB 77519 , San Francisco , CA 94104-5401 , USA
Все письма и запросы отправляйте по адресу:
PO Box 18666 , Minneapolis , MN 55418-0666 , USA
- GitHub
- Mastodon
Let’s Encrypt отзовет около 2 млн сертификатов 28 января
Поставщик сертификатов HTTPS Let’s Encrypt планирует отозвать около 2 млн SSL/TLS-сертификатов 28 января, поскольку они были выпущены ненадлежащим образом.
В сообщении на форуме инженер Let’s Encrypt по надежности сайта Джиллиан Тесса объяснила, что во вторник третья сторона сообщила о «двух нарушениях» в коде, реализующем метод проверки «TLS с использованием ALPN» (BRs 3.2.2.4.20, RFC). 8737) в Boulder, программном обеспечении для автоматической среды управления сертификатами (ACME).
«Все активные сертификаты, которые были выпущены и проверены с помощью запроса TLS-ALPN-01 до 00:48 UTC 26 января 2022 года, когда было развернуто наше исправление, считаются неправильно выпущенными», — пояснила Тесса. — «В соответствии с Политикой сертификатов Let’s Encrypt у нас есть 5 дней на отзыв, и мы начнем отзывать сертификаты в 16:00 UTC (19:00 мск) 28 января 2022 года».
По оценкам Let’s Encrypt, затронуто менее 1% активных сертификатов; это 2 млн из 221 млн активных сертификатов, выпущенных Let’s Encrypt.
Затронутые владельцы сертификатов будут уведомлены об отзыве по электронной почте, после чего им потребуется продление сертификата.
Это не исправление эксплойта. «Обновление типа запроса TLS-ALPN-01 было сделано в соответствии с базовыми требованиями, которые требуют использования TLS 1.2 или выше», — сообщил представитель Let’s Encrypt в комментарии The Register. При получении сертификата Let’s Encrypt серверы организации пытаются подтвердить, что владелец контролирует соответствующие ресурсы в соответствии со стандартом ACME. Эта задача может выполняться с использованием HTTP, DNS или TLS. Процесс напоминает отправку ссылки для подтверждения по электронной почте, чтобы завершить настройку учетной записи в Интернете.
TLS-ALPN-01 доступен для тех, кто не может или не хочет использовать порт 80 для HTTP-01. Согласно Let’s Encrypt, он «лучше всего подходит для авторов обратных прокси-серверов с завершением TLS, которые хотят выполнять проверку на основе хоста, например HTTP-01, но хотят делать это полностью на уровне TLS».
Разработчик Let’s Encrypt Аарон Гейбл сообщил в отдельном посте, что в проверочный код организации были внесены два изменения, затрагивающие клиентские приложения, которые специально используют TLS-ALPN-01. Во-первых, программное обеспечение теперь обеспечивает сетевое согласование с использованием TLS 1.2 или выше. Ранее код позволял подключаться через TLS 1.1, который теперь считается небезопасным.
Во-вторых, программное обеспечение больше не поддерживает устаревший OID (идентификатор объекта) 1.3.6.1.5.5.7.1.30.1, который служил для идентификации расширения «acmeIdentifier» в ранних версиях RFC 8737. Программное обеспечение Let’s Encrypt теперь принимает только стандартизированный OID. 1.3.6.1.5.5.7.1.31.
Попытки проверки сертификата с использованием TLS 1.1 или OID, поддержка которого прекращена, завершатся ошибкой в исправленном программном обеспечении; эти сертификаты, проверенные через TLS-ALPN-01 под старым кодом, не соответствуют политике Let’s Encrypt и поэтому должны быть выпущены повторно.
В сентябре 2021 года у Let’s Encrypt истек срок действия корневого сертификата IdentTrust DST Root CA X3. Некоторые старые устройства столкнулись с проблемами в работе.
Минусы Let’s Encrypt
Какие есть минусы у бесплатных сертификатов Let’s Encrypt?
int13h ★★★★★
24.01.17 11:26:47 MSK
← 1 2 →
Быстро заканчиваются, надо писать скрипты для автоматизации процесса обновления сертификатов. И нет wildcard.
Black_Shadow ★★★★★
( 24.01.17 11:32:43 MSK )
Последнее исправление: Black_Shadow 24.01.17 11:32:56 MSK (всего исправлений: 1)
Ответ на: комментарий от Black_Shadow 24.01.17 11:32:43 MSK
А в плане безопасности?
int13h ★★★★★
( 24.01.17 11:36:23 MSK ) автор топика
Ответ на: комментарий от int13h 24.01.17 11:36:23 MSK
Ну, я не вижу проблем безопасности.
Black_Shadow ★★★★★
( 24.01.17 11:38:24 MSK )
ХЗ, мне норм. Главный минус пожалуй — необходимость перебрать несколько отмороженных ACME-клиентов что-бы найти dehydrated. Штатный клиент — наркоманское нечто.
Необходимость автоматизировать реновацию сертификатов это скорее багофича. Заставляет адекватно продумать процедуру которая будет адекватно работать без ручного вмешательства.
MrClon ★★★★★
( 24.01.17 11:40:21 MSK )
Lets Encrypt запросто может подписать сертификат с CN твоего сайта для каких-нибудь внутренних органов, например. Причём никто и никогда не выкинет Lets Encrypt за это из списков CA, как это уже не раз было с китайскими конторами которые были пойманы на раздаче левых сертификатов.
Stanson ★★★★★
( 24.01.17 11:41:16 MSK )
Ответ на: комментарий от Stanson 24.01.17 11:41:16 MSK
Lets Encrypt запросто может подписать сертификат с CN твоего сайта
Black_Shadow ★★★★★
( 24.01.17 11:43:45 MSK )
Ответ на: комментарий от Black_Shadow 24.01.17 11:43:45 MSK
Тем-же самым образом которым это может сделать любой другой СА. Сабж выделяется тут только тем что его (как и некоторых других игроков) очень трудно выкинуть из списков доверенных.
MrClon ★★★★★
( 24.01.17 11:46:02 MSK )
Ответ на: комментарий от int13h 24.01.17 11:36:23 MSK
Кроме тех соображений которые справедливы для всей сложившейся системы CA в целом (думаю гуглинг чего-то вроде ssl in brocken может многое рассказать на эту тему)?
Ну, там нужен клиент который будет иметь доступ как минимум к сертификату и закрытому ключу (и немного к сайту, но там всё можно сильно огородить), как максимум клиент может иметь доступ ко всему серверу (если ты упоришся запустишь его от рута). Некоторые клиенты достаточно просты что-бы провести аудит их безопасности, но понятно что 99.9999% процентов этого не сделают.
MrClon ★★★★★
( 24.01.17 11:51:10 MSK )
Ответ на: комментарий от MrClon 24.01.17 11:46:02 MSK
Тем-же самым образом которым это может сделать любой другой СА.
Я думал, мне сейчас расскажут о чём-нибудь типа man-in-the-midle для acme. Понятно, что в теории любой центр сертификации может выпустить любой сертификат. И Let’s Encrypt тут не отличается от других.
Black_Shadow ★★★★★
( 24.01.17 11:51:36 MSK )
Последнее исправление: Black_Shadow 24.01.17 11:53:42 MSK (всего исправлений: 1)
Ответ на: комментарий от Black_Shadow 24.01.17 11:43:45 MSK
Так же, как этим занимался и занимается CNNIC. За деньги или по приказу, например. CNNIC fake certificate в гуглях набери. А потом загляни в список CA браузера, например.
Поэтому вся эта херня с централизованными CA — вообще ничего не значит в плане безопасности и нужна только для того, чтобы совместно с браузерописателями вытягивать бабло из тех, кто хочет чтобы их сайтеги открывались без предупреждения и с зелёненьким замочком.
Stanson ★★★★★
( 24.01.17 11:52:20 MSK )
Ответ на: комментарий от Black_Shadow 24.01.17 11:51:36 MSK
А вот это кстати интересно, про это надо посмотреть.
Вообще, как я понял, запросы к ACME-серверу подписываются закрытым ключём клиента (отличным от ключа сертификата), но:
1) Я это вообще-то не проверял.
2) Первичная передача публичного ключа серверу защищена в лучшем случае только https.
И похоже что обмен открытыми ключами однонаправленный (клиент регистрируется на сервере), так-что сообщения клиента не шифруются, а ответы сервера не подписываются (кроме того что используется https). Так с ходу решета (кроме подмены публичного ключа клиента при первичной регистрации использую решетовость https) я тут не вижу.
MrClon ★★★★★
( 24.01.17 12:00:46 MSK )
Ответ на: комментарий от Stanson 24.01.17 11:52:20 MSK
И для защиты от мамкиных какиров
MrClon ★★★★★
( 24.01.17 12:05:43 MSK )
Ответ на: комментарий от MrClon 24.01.17 12:05:43 MSK
И для защиты от мамкиных какиров
Зависит от того, кто мама и папа у мамкиного хакера и сколько у них денег и возможностей.
Собственно вся система CA тотально облажалась с китайцами. Если бы CNNIC был выкинут из списков CA немедленно и безвозвратно, причём на уровне личностей сотрудников, т.е. появился бывший сотрудник CNNIC в другом CA — этот CA тоже немедленно выкидывается — тогда вся эта система заработала бы себе хорошую репутацию и доверие. Но всё было мгновенно просрано при первом же фэйле, поэтому никакого доверия к этой системе уже нет и никогда не будет, а у участников оной развязаны руки на предмет раздачи левых сертификатов кому угодно. Поэтому получить мамкиному хакеру левый сертификат от фэйсбучека, чтобы отMiTMить соседа — вопрос только бабла и/или связей папы и мамы.
Stanson ★★★★★
( 24.01.17 12:14:02 MSK )
Ответ на: комментарий от Black_Shadow 24.01.17 11:32:43 MSK
надо писать скрипты для автоматизации процесса обновления
Дык в certbot же есть обновление — надо только в крон или systemd правильно добавить.
gistart ★
( 24.01.17 12:18:25 MSK )
https://freessl.mustlife.ru/ еще для удобство есть такая штука.
gssomi ★★
( 24.01.17 13:33:43 MSK )
Ответ на: комментарий от Black_Shadow 24.01.17 11:32:43 MSK
надо писать скрипты для автоматизации процесса обновления сертификатов
certbot renew в crontab.
Deleted
( 24.01.17 13:37:06 MSK )
Ответ на: комментарий от gssomi 24.01.17 13:33:43 MSK
…указать данные для подключения по SSH/FTP и наш сервис сам загрузит на ваш сервер…
MrClon ★★★★★
( 24.01.17 13:47:48 MSK )
Ответ на: комментарий от Deleted 24.01.17 13:37:06 MSK
ТС ведь просил минусы.
Минус: надо добавлять в крон нечто для обновления сертификата.
Плюс: достаточно добавить одну комменду/срипт в крон что-бы не париться об обновлении сертификатов.
MrClon ★★★★★
( 24.01.17 13:50:59 MSK )
Vit ★★★★★
( 24.01.17 14:37:31 MSK )
Ответ на: комментарий от Vit 24.01.17 14:37:31 MSK
Компенсируется возможностью создать кучу сертификатов. Правда еть какой-то там временной лимит, так-что разом создать сертификаты на всю ЖЖшечку например не получится.
MrClon ★★★★★
( 24.01.17 14:48:15 MSK )
Ответ на: комментарий от MrClon 24.01.17 14:48:15 MSK
Я в курсе. Человек спрашивал про минусы.
Vit ★★★★★
( 24.01.17 14:56:29 MSK )
Ответ на: комментарий от gistart 24.01.17 12:18:25 MSK
Дык в certbot же есть обновление — надо только в крон или systemd правильно добавить.
Нужно сервисы пинать, чтобы использовали новый сертификат.
Black_Shadow ★★★★★
( 24.01.17 15:00:08 MSK )
Ответ на: комментарий от Deleted 24.01.17 13:37:06 MSK
Black_Shadow ★★★★★
( 24.01.17 15:00:24 MSK )
слишком монополисты на своей нише и врятли это просто изменится (слишком крутые инвесторы типа гугла и мозилы). В плане безопасности — не отличается от дефолтных платных
Dred ★★★★★
( 24.01.17 15:02:10 MSK )
Ответ на: комментарий от Black_Shadow 24.01.17 15:00:08 MSK
У меня скрипт обновления сертификата занимает девять строк. Из них три пустых, одна #!/bin/bash, одна для отладки (пишет в лог время и то что сейчас будем обновлять сертификат), две выставляют нужные мне права на сертификат (dehydrated выставляет их согласно своим представлениям о прекрасном). Для каждого сайта такой скрипт генерится и суётся в /etc/cron.monthly автоматически, при добавлении сайта на сервер.
В общем ерунда, просто нужно почесаться на эту тему, подумать и один раз настроить и протестировать всё. Кому-то приятнее раз в год тыкать в веб-интерфейс CA.
MrClon ★★★★★
( 24.01.17 15:37:31 MSK )
Ответ на: комментарий от MrClon 24.01.17 15:37:31 MSK
В общем ерунда, просто нужно почесаться на эту тему, подумать и один раз настроить и протестировать всё
Ну да, я об этом и говорю. Ничего сложного нет, но требуются некоторые телодвижения при первоначальной настройке.
Black_Shadow ★★★★★
( 24.01.17 15:54:30 MSK )
Ответ на: комментарий от MrClon 24.01.17 12:00:46 MSK
А как ты будешь получать сертификат у любого платного сервиса? Точно также зайдешь на их сайт через https, залогинишься (паролем или своим сертификатом) и т. д. Ты же не пойдешь лично в центр выдачи сертификатов с флешкой. Опять же у утилит let’s encrypt вполне может быть что-то типа pinned сертификатов, так что MiTM будет не так уж прост.
Вобщем, уязвимости те же, что и в случае с платными сертификатами. Отличие только в отсутствии wildcard.
KivApple ★★★★★
( 24.01.17 16:07:05 MSK )
Ответ на: комментарий от KivApple 24.01.17 16:07:05 MSK
В общем-то да. Разве-что с ACME-сервером взаимодействие чаще происходит, но ведь основная проблема это первичное взаимодействие.
Хорошо-бы добавить что-то вроде пининга ключей в сам протокол ACME, что-бы утилите надо было скармливать не только URLы сервера и лицензии, но и отпечаток ключа сервера.
MrClon ★★★★★
( 24.01.17 16:13:14 MSK )
Ответ на: комментарий от gistart 24.01.17 12:18:25 MSK
Дык в certbot же есть обновление — надо только в крон или
Он ужасно реализован, кстати. Недавно у меня отвалился, когда запустился по крону обновить сертификаты. Но сперва он решил и себя обновить. Начал пересоздавать свой virtualenv и обломился, пожаловавшись на нехватку памяти для компиляции чего-то. И это несмотря на ключ —no-self-upgrade . Хорошо что мне выхлоп с крона на почту приходит, а то бы узнал только когда сайт отвалился бы. Проблему с компиляцией решил включением свопа. Хотя перед этим пробовал сгенерировать его свежий virtualenv на другой машине, но почему-то при запуске certbot его удалял и пытался создать новый, с компиляцией зависимостей (он на питоне, pip качает и компилит какие-то модули). Жесть вобщем.
Ya_gnu_linux
( 24.01.17 16:58:14 MSK )
EV нет и не будет.
От остальных минусов спасает manuale.
Goury ★★★★★
( 24.01.17 17:06:43 MSK )
Ответ на: комментарий от Ya_gnu_linux 24.01.17 16:58:14 MSK
Питон? venv? Зачем? Им родина дала dehydrated на bash, пользуйся. Не хотят! Питоном обмазываться хотят
MrClon ★★★★★
( 24.01.17 17:07:55 MSK )
Ответ на: комментарий от MrClon 24.01.17 17:07:55 MSK
Питон? venv? Зачем? Им родина дала dehydrated на bash, пользуйся. Не хотят! Питоном обмазываться хотят
После этого я конечно посмотрел на альтернативные acme клиенты. Но естественно сперва я начал с их официального клиента. Так-то в питоне нет ничего плохого, если нормально реализовать. На питоне тоже есть альтернативные клиенты попроще, например acme-tiny.
Ya_gnu_linux
( 24.01.17 17:19:39 MSK )
Ответ на: комментарий от Ya_gnu_linux 24.01.17 17:19:39 MSK
Официальный клиент тоже на ещё дрянь. Вообще я не понял в честь чего они решили что впихнуть сертификаты в конфиг вебсервера это самая сложная для пользователей часть, и её надо непременно автоматизировать.
Так-то в питоне нет ничего плохого
Да. Только при условии что разраб понимает что со скриптом на сотню строк не надо тащить целый отдельный энваермент и компиляторы что-бы его собрать. К сожалению питонисты (и не они одни) в последнее время забывают об этом и радостно превращают свои поделки в блобы способные выжрать всю память на то с чем bash-скрипт справляется используя 9Мб памяти
MrClon ★★★★★
( 24.01.17 17:30:02 MSK )
Ответ на: комментарий от MrClon 24.01.17 17:30:02 MSK
Только при условии что разраб понимает что со скриптом на сотню строк не надо тащить целый отдельный энваермент и компиляторы что-бы его собрать. К сожалению питонисты (и не они одни) в последнее время забывают об этом и радостно превращают свои поделки в блобы способные выжрать всю память
Это всё они сделали ради того чтобы их клиент работал даже в debian wheezy (как раз мой случай), например. Так-то если использовать клиент из реп (в современных дистрах уже есть), этих проблем нет.
Ya_gnu_linux
( 24.01.17 18:28:56 MSK )
Ответ на: комментарий от Ya_gnu_linux 24.01.17 18:28:56 MSK
Я правда не стал доверять их скрипту автоматическую правку конфигов сервера, предпочёл руками. Могли бы хотя бы дать свой клиент без всех этих лишних плагинов.
Ya_gnu_linux
( 24.01.17 18:31:39 MSK )
Ответ на: комментарий от Ya_gnu_linux 24.01.17 18:28:56 MSK
dehydrated тоже работает на wheezy (наверное), и в зависимостях у него только curl, openssl, sed, grep, mktemp.
1123 строк кода, один файл, 9 Мб RAM.
MrClon ★★★★★
( 24.01.17 18:34:20 MSK )
Ответ на: комментарий от MrClon 24.01.17 18:34:20 MSK
Да, но они видимо хотели всё максимально упростить для пользователя, чтобы даже домохозяйка справилась. Поэтому и понапихали всяких возможностей типа автоматической правки конфигов разных вебсерверов.
Ya_gnu_linux
( 24.01.17 18:46:37 MSK )
Ответ на: комментарий от Dred 24.01.17 15:02:10 MSK
Какие в анус монополисты? Во первых, доля letencrypt пока невелика. Во вторых, ACME — открытый протокол, массовый переход на него будет способствовать появлению новых CA. Если у тебя есть деньги, можешь даже сам открыть. Нужно будет заплатить существующему CA и пройти аудит.
MadDeer
( 24.01.17 18:46:52 MSK )
Ответ на: комментарий от MrClon 24.01.17 18:34:20 MSK
А он предлагает какую-то дефолтную структуру папок в etc для ключей? Просто ключики иногда надо нескольким сервисам нужны, волохать их по куче папок не хочется.
Vit ★★★★★
( 24.01.17 18:52:25 MSK )
Ответ на: комментарий от MadDeer 24.01.17 18:46:52 MSK
массовый переход на него будет способствовать появлению новых CA
Речь про рост количества CA, поддерживающих протокол. Деньги же будут зарабатывать на EV, которые требуют подтверждения факта существования компании.
MadDeer
( 24.01.17 18:56:06 MSK )
Ответ на: комментарий от Ya_gnu_linux 24.01.17 18:46:37 MSK
Вот так взял и плюнул в душу с разбега. Я со стандартным клиентом не справился.
MrClon ★★★★★
( 24.01.17 19:39:59 MSK )
Ответ на: комментарий от Vit 24.01.17 18:52:25 MSK
Не в /etc но предлагает.
В моём случае для каждого сайта используется своя BASE_DIR ( /var/www/$/letsencrypt ), в ней-же лежит конфиг dehydrated, файл со списком доменов ( domain.tld и www.domain.tld в 99% случаев), ключ аккаунта используемый для работы с ACME сервером, лог скрипта который запускается кроном и обновляет сертификат, и директория well-known/acme-challenges с которой работает dehydrated и которую nginx впиливает в сайт директивой alias (нех всяким скриптам трогать настоящий webroot, в котором в общем-то что угодно может быть).
Можно использовать одну BASE_DIR на все сертификаты, но в моём случае это неудобно.
Можно указать скрипт который dehydrated будет выполнять после получения/обновления сертификата, ему передаются пути к сертификату и ключу, имя домена. Этот скрипт может класть сертификат куда тебе надо, релоадить nginx, постить приватный ключ в твиттер… в общем что накодишь то и будет.
Но думаю что если тебе неудобно указывать $/certs/$/cert.csr в конфигах всех твоих сервисов то можно просто создать симлинки на $/certs/$/cert.csr в нужных местах. Или я неправильно понял твою проблему?
MrClon ★★★★★
( 24.01.17 20:02:26 MSK )
Последнее исправление: MrClon 24.01.17 20:04:15 MSK (всего исправлений: 1)
Ответ на: комментарий от MrClon 24.01.17 19:39:59 MSK
Вот так взял и плюнул в душу с разбега. Я со стандартным клиентом не справился.
Ну это часто так. То что заточено под ламеров, опытным пользователям зачастую неудобно.
Ya_gnu_linux
( 24.01.17 20:18:54 MSK )
Ответ на: комментарий от Stanson 24.01.17 12:14:02 MSK
Поэтому получить мамкиному хакеру левый сертификат от фэйсбучека, чтобы отMiTMить соседа — вопрос только бабла и/или связей папы и мамы.
HTTP Public Key Pinning
atrus ★★★★★
( 24.01.17 22:03:35 MSK )
Ответ на: комментарий от atrus 24.01.17 22:03:35 MSK
Оно перпендикулярно вопросу о нужности CA. HPKP точно так же и с тем же успехом можно использовать и с самоподписанными сертификатами, впрочем, нужность этого костыля в случае самоподписанного сертификата сомнительна — ведь ключ которым подписан самоподписанный сертификат есть только у владельца сайта, и никто кроме самого владельца сайта липовый валидный сертификат выпустить не может. А на совсем левый самоподписанный сертификат браузер и без всякого HPKP ругаться будет по-полной.
И оно никак не решает проблему фейковых сертификатов, совершенно валидных, например, для свежеустановленного браузера, который ещё никаких хэшей ниоткуда не получил.
Stanson ★★★★★
( 24.01.17 23:01:50 MSK )
Последнее исправление: Stanson 24.01.17 23:03:29 MSK (всего исправлений: 2)
Ответ на: комментарий от Stanson 24.01.17 23:01:50 MSK
И оно никак не решает проблему фейковых сертификатов, совершенно валидных, например, для свежеустановленного браузера, который ещё никаких хэшей ниоткуда не получил.
Существует примерно ноль сайтов, состоящих из одной странички без скриптов, css, картинок. Попытка подгрузить их как минимум приведёт к угасанию зелёного замочка, а может и к непрогрузке сайта целиком (я пока не проверял, надо будет поглядеть завтра).
atrus ★★★★★
( 24.01.17 23:28:17 MSK )
Ответ на: комментарий от MrClon 24.01.17 11:51:10 MSK
Есть, например, certbot упакованный в docker. Запускаешь в отдельном контейнере, экспортируешь том из этого контейнера в контейнер сайта и настраиваешь веб-сервер, что бы акми челендж ввел туда, все. Достаточно настроить один раз. К сайту и самой машине клиент доступов не имеет.
Конечно, он имеет доступ к сертификатам и приватным ключам (потому что он их пишет, как минимум, да CSR нужно чем-то подписывать).
BigAlex ★★★
( 24.01.17 23:36:24 MSK )
Ответ на: комментарий от atrus 24.01.17 23:28:17 MSK
HPKP никак не решает проблему Trust on First Use. Вообще. Это костыль предназначенный для того, чтобы хоть как-то заткнуть дыру в виде системы коммерческих CA, которая в случае самоподписанных сертификатов вообще не существует.
Т.к. система коммерческих CA полностью скомпроментирована (одной только ситуацией с CNNIC выше крыши), то вот понадобились эти сраные костыли в виде HPKP чтобы хоть как-то попытаться сохранить лицо и продолжить доить сайтовладельцев.
Stanson ★★★★★
( 24.01.17 23:37:17 MSK )
Ответ на: комментарий от Stanson 24.01.17 23:37:17 MSK
HPKP никак не решает проблему Trust on First Use.
Все знают, успокойтесь. Была проблема вообще. Её сократили до first use. Для начала неплохо.
Это не костыль, а начало работ над стандартом. На HPKP дело не кончится.
Т.к. система коммерческих CA полностью скомпроментирована
белки_истерички.jpg. Всё, отключайте tls, скомпрометировано.
Не доитесь, используйте Let’s Encrypt. А деньги будут платить компании, которым нужен сертификат выданный не домену, а конкретной ЗАО/ООО/НКО/ОПГ/etc. А это сейчас всё равно не обеспечить без доверяемого лица. Потому что введение всепланетарного блокчейн-реестра всё равно невозможно вот так в один момент, просто по желанию чьей-то левой пятки.
которая в случае самоподписанных сертификатов вообще не существует
Не вопрос, используйте самоподписанные. :trollface:
atrus ★★★★★
( 24.01.17 23:50:15 MSK )
Ответ на: комментарий от MrClon 24.01.17 20:02:26 MSK
Да я вот думал, что серитификаты разумно хранить где-то в /etc/dehydrated/certs/.
Или я не прав и так делать не стоит? У меня помимо www еще nntp есть как минимум, и вроде как в /var/www не очень логично получается сертификаты пихать.
Мнение: использовать Let’s Encrypt — плохая идея
Let’s Encrypt помогает быстро и бесплатно получить SSL-сертификат. Разбираемся, почему он при этом может угрожать безопасности всей системы сертификации.
Прим. ред. Это перевод одной из точек зрения о сервисе Let’s Encrypt. Мнение редакции может не совпадать с мнением автора оригинала.
Будет сайт отображаться в результатах поиска Google или нет зависит от того, использует ли сайт SSL (англ. Secure Sockets Layer). Или, проще говоря, начинается ли адрес сайта с «https».
Чтобы распространить использование SSL в интернете, участники веб-отрасли создали Let’s Encrypt — сервис, предоставляемый исследовательской группой по интернет-безопасности (ISRG). Сервис взлетел, а крупные хостинг-провайдеры начали создавать инструменты для автоматического получения и установки SSL на сайтах. Звучит как прорыв в кибер-безопасности!
Общая информация об SSL-сертификации
Сердцем шифрования является ключ шифрования. Представьте на минуту, что у вас есть реально большой замок, способный выдержать выстрел из винтовки 50 калибра. Но это не поможет, если у какого-нибудь злодея окажется ключ.
Цифровая аналогия — это криптографическая стойкость сертификата, используемого для шифрования трафика с сайта. По аналогии с замком и винтовкой, если у злодея появляется приватный ключ, с помощью которого был сгенерирован SSL-сертификат, криптографическая стойкость уже не имеет никакого значения.
Существует достаточно центров сертификации (CAs), предоставляющих SSL-сертификаты, и у каждого из них есть своя «Система Управления Ключами» (KMS). Такие центры обращаются к производителям операционных систем, таким как Microsoft, Apple и Google, чтобы поместить свои коренные сертификаты в список доверенных сертификатов их ОС.
SSL-сертификат сайта tproger.ru выдан компанией CloudFlare. Если её система управления ключами будет скомпрометирована, то все её сертификаты нужно будет перевыпустить. Однако, если такой атаке подвергнется любой другой центр сертификации, то на сайте tproger.ru это никак не отразится.
Чем больше сайтов получат защиту от Let’s Encrypt, тем больше становится потенциальная угроза. Ведь в случае атаки на их системы будет страдать всё больше и больше сайтов. Сейчас Let’s Encrypt выбирают по принципу «сделал и забыл». Если сертификат будет отозван и никто не обратит на это внимание, то трафик сайта начнёт стремительно падать. Кстати, именно из-за истёкшего сертификата, на который никто не обращал внимание, в Equifax (американском бюро кредитной истории) в течение нескольких месяцев не знали, что они были взломаны.
«Сделал и забыл» — возможно, не лучшая идея в кибер-безопасности.
Что такое TLS-рукопожатие и как оно устроено
Опасность компрометации KMS
Чтобы понять, почему проблема с Let’s Encrypt важна, представьте себя где-то между сайтом компании и его посетителями. Вы можете перехватывать весь трафик, а если у вас есть закрытые ключи из центра сертификации (например Let’s Encrypt), вы сможете расшифровывать трафик сайтов, используя их сертификаты. Но это не самое худшее: из-за того, что вы находитесь как бы между сайтом и конечным получателем трафика, вас не так просто обнаружить стандартными способами. Вы не обязательно должны находиться в сети сервера сайта или же в одной сети с посетителем — вы где-то посередине, с «ключами от всех дверей». Заманчивая картинка для любого злоумышленника.
Как попасть в такое место? Самый простой и вероятный способ мало связан с технологиями. Вам просто нужно внедрить своего человека в компанию, выдающую сертификаты (а именно в то подразделение, которое отвечает за систему управления ключами). И тут нужно задать самый главный вопрос.
Кто пострадает от компрометации KMS?
Первым делом страдает сам центр сертификации и его репутация. Если такая организация позиционируется как публичная, её инвесторы «ухудшат» своё портфолио. А следовательно, вероятнее всего, на такую компанию обрушится лавина исков акционеров, руководство будет уволено, а доверие к центру сертификации — значительно подорвано, что может даже поставить крест на его существовании. Достаточные последствия, чтобы предпринимать максимум усилий, чтобы их избежать.
Кто же пострадает в случае Let’s Encrypt?
У этой компании нет «владельцев», она не для коммерческого использования. У неё нет дохода, т. к. сертификаты выдаются бесплатно. В таком случае никто не проиграет и не понесёт убытки.
Выводы
Чем больше бизнес уходит в интернет, тем больше бизнесменов хотят использовать решения «сделал и забыл», в том числе для защиты данных их пользователей. И вот мы имеем растущую популярность сервиса с одной стороны и отсутствие какой-либо ответственности за безопасность сертификатов с другой. Всё вместе это может привести к катастрофе, когда личные данные пользователей тысяч сайтов будут получены злоумышленниками.
Что делать стартапам и маленьким компаниям?
Жестокая правда в том, что простого решения не существует, поэтому стоит придерживаться нескольких правил, чтобы обеспечить безопасность сайта и его пользователей:
- Избегайте манящих вывесок «бесплатно» и «удобно». Основные центры сертификации имеют различные инструменты или техническую поддержку для выпуска SSL-сертификата. Обычно эта же поддержка помогает вам с установкой сертификата. Должна быть проверка на владение доменом (иногда она обоснованно громоздкая). Обратите внимание на страховку от нарушений, которую центр предлагает в дополнение к своим услугам.
- Если ваш сайт размещён хостинговой компанией, то обратите внимание, на кого накладывается ответственность с точки зрения кибер-безопасности. Скорее всего, вам понадобятся ряд инструментов для создания «запроса подписи сертификата» (CSR).
- Если вы заключаете контракт на разработку и обслуживание сайта, спросите поставщика, заботится ли он о кибер-страховании. Попросите поставщика предоставить доказательства того, что он покроет убытки в случае, если их ошибки и недоработки приведут ко взлому или нарушению работы вашего сайта.
Следите за новыми постами по любимым темам
Подпишитесь на интересующие вас теги, чтобы следить за новыми постами и быть в курсе событий.