SSL-сертификат для HTTP2

wosign

P.S.: Костыль в виде Let's Encrypt не предлагать. Пусть сами своей лабудой пользуются.

Что конкретно не устраивает? Сайт на хостинге что ли?

P.S.: Костыль в виде Let's Encrypt не предлагать. Пусть сами своей лабудой пользуются.

Аргументируешь?

Нет конечно. Сервера.

Да писал я уже: Let's Encrypt идея и реализация Слишком много усложнился процесс, вместо упрощения, как они заявляли изначально. Да и на продакшене пихать какой-то софт, который умеет поднимать сервер, стучится куда-то там - нафиг надо.

Let's Encrypt идея и реализация

Не забывай что все еще бета, думаю получше будет.

th3m3, ты эпический рукожоп и распространитель 4.2. Читать сюда до просветления.

(Топикстартеру тоже, и юзать let's encrypt.)

Дак, я и есть топикстартер же) А что за 4.2?

acme-tiny - это по ходу их какая-то очередная приблуда. Посмотрю конечно.

4.2 состоит в том, что нужно

запускать на сервере свой софт(который ещё свой сервер поднимает, epic), который будет править конфиги.

acme-tiny — это неофициальная реализация спецификации Let's Encrypt со стороны клиента, которая укладывается в 200 строк на питоне, не требует рута, доступа к webroot или остановки существующего сервера.

А «сертификат на три месяца» — это так надо и это правильно. Ты рассматриваешь HTTPS как преграду, которую нужно преодолеть и забыть, а это вообще-то средство защиты. Внезапно. Чем меньше срок действия сертификата, тем меньше успеет натворить гипотетический злоумышленник, который получит доступ к твоему серверу.

Самый простой и бесплатный способ — это использовать самозаверенный сертификат.

StartSSL - сайт тормозит, выдаёт ошибки постоянно. Провал.

Какие ошибки? Тормозит из-за сертификата? Что?

P.S.: Костыль в виде Let's Encrypt не предлагать. Пусть сами своей лабудой пользуются.

У тебя точно руки не из жопы?

Все равно сложно. Конвертировать ключи какие-то, проверка производится только по http, а вдруг я отключил для сайта http вообще? Далеко от совершенства еще.

И еще, вопрос для просвещения, почему для подтверждения контроля доменом просто не сделать единожды TXT-запись для зоны? Безопасность при этом страдает?

Средство защиты не должно превращаться в шило в заднице. Сертификаты так часто ломают, что число в 3 месяца обосновано? Что делать с сетями, где сама сеть обеспечивает шифрование и https избыточен (но пока требуется реализациями http2)?

Средство защиты не должно делаться на отъебись. Все остальные хотелки второстепенны.

Здрасте, ещё один рукожоп-неосилятор. Ты не умеешь генерировать приватный ключ RSA? Ты не умеешь генерировать CSR? Алё, гараж, с «обычными» CA тебе нужно делать то же самое!

P. S. «конвертировать ключ» — это в том случае, если ты уже юзал официальный клиент.

Ещё раз, средство защиты должно быть соразмерно угрозе. В данном случае оно раз в 10 усложняет работу при отсутствии угрозы такого уровня в ближайшее время.

Предлагаю авторам обновлять сертификат раз в день. Это же безопасность, ололо.

Да хоть раз в день — какая разница, если это может делать по крону скрипт в 200 строк на питоне? А при прочих равных чем больше защиты, тем лучше. Всегда. Даже если «не соразмерно».

Разница в том, что это лишние действия, которые имеют абсолютно никакой необходимости.

А при прочих равных чем больше защиты, тем лучше.

И эти люди пытаются заниматься безопасность, Карл...

Разница в том, что это лишние действия, которые имеют абсолютно никакой необходимости.

И эти люди пытаются заниматься безопасностью. Давай, расскажи мне, где я не прав. «Нет необходимости в хорошей защите за просто так» — это не аргумент, к твоему сведению.

StartSSL, WOSign и Letsencrypt, другого бесплатного нет. От себя советую StartSSL, самый адекватный и удобный сайт. Letsencrypt видимо наше светлое будущее, так что придётся переходить на него рано или поздно, но пока есть StartSSL, проще сидеть на нём.

Ничего не бывает бесплатным. Лишние действия всегда должны быть оправданы. В данном случае мы получаем дыру в безопасности за счёт того, что даём чужому софту доступ к нашему серверу, да ещё и по крону автоматически. Кроме того мы заменяем свой сертификат по крону, создавая потенциальные проблемы пользователям, которые в этот момент имеют доступ к ресурсу. Это всё может быть оправдано, если бы была угроза подобного уровня — но её нет и быть не может. Число в 3 месяца взято от балды, что не добавляет авторитета икспертам-авторам.

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

О каких потенциальных проблемах ты говоришь?

Любые числа подобного вида вначале берутся от балды и уже потом корректируются. Это раз.

Чужой софт представляет собой насквозь самоочевидный скрипт на питоне в 200 строк, у которого в ридми написано «эй, админ, прочитай меня полностью _сам_, это несложно». Это два.

Мы можем проверять новый сертификат на работоспособность перед тем, как его заменять по крону. Это не реализовано сейчас нигде за отсутствием необходимости (потому что мы верим CA, блджад), но вполне может быть реализовано. Это три.

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

Что будет, если сертификат заменится посреди запроса? А если мы открыли страницу с одним сертификатом, а потом через ajax получаем доступ к тому же адресу уже с другим?

Ну и почему я должен все это проделывать? Мне нужен сертификат и чтобы он обновлялся по окончании действия, я не хочу генерировать никаких ключей и цсров. Обычные CA это обычные, к ним вопросов нет, а LE позиционируют себя как простое автоматизированное решение, этого я сейчас пока не наблюдаю, есть над чем поработать.

Любые числа подобного вида вначале берутся от балды и уже потом корректируются. Это раз.

Это называется «я у мамы безопасник».

Чужой софт представляет собой насквозь самоочевидный скрипт на питоне в 200 строк

Который загружает нечто, что ты не читаешь, ага.

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

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

Потому что этот клиент — грёбаный proof-of-concept (ололо, юниксвей), который написан с одной целью — показать, что клиента можно впихнуть в 200 строк на питоне. Форкни и впиши в начало автогенерацию ключа + CSR, и будет тебе счастье.

Что будет, если сертификат заменится посреди запроса? А если мы открыли страницу с одним сертификатом, а потом через ajax получаем доступ к тому же адресу уже с другим?

И что же будет? Вот моя версия. Веб-сервер при старте читает сертификат в память и при изменении файлов на это никак не реагирует. После изменения сертификатов веб-серверу делается reload, который реализован, как посылка unix-сигнала. Веб-сервер при получении этого сигнала перечитывает конфиг и все новые соединения будут обслуживаться с новым конфигом. Старые, естественно, со старым.

Вопрос про AJAX — если открывается новое TCP-соединение, браузеру пофиг, будет новый handshake и всё такое. Если будет переиспользовано текущее TCP-соединение, то опять же пофиг, оно уже давно установлено.

Итого — на мой взгляд никаких проблем не может быть.

Это называется «они сами пишут, что 90 дней — первое приближение, потом будет меньше».

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

Вопрос про AJAX — если открывается новое TCP-соединение, браузеру пофиг, будет новый handshake и всё такое. Если будет переиспользовано текущее TCP-соединение, то опять же пофиг, оно уже давно установлено.

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

Но это надо проверить, тут я диванный теоретик.

повторяю ещё раз: это не впечатляет

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

Проверь. Я на 99% уверен, что никто ругаться не будет. Это было бы очень странно.

Прекращай шланговать, оборот «не впечатляет» имеет вполне конкретное значение. Видимо, по существу сказать тебе нечего; что ж, не хочешь — не юзай, мне-то что с того.

Чем меньше срок действия сертификата, тем меньше успеет натворить гипотетический злоумышленник, который получит доступ к твоему серверу.

Странный аргумент. Для того, чтобы злоумышленник меньше натворил — придумали отзыв сертификата. Каким образом срок в 3 месяца как-то повлияет на это?

Период полураспространения CRL'ей больше трёх месяцев.

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

Период полураспространения CRL'ей больше трёх месяцев.

Это как? Браузер или скачивает новый CRL или делает OCSP-запрос (или веб-сервер сразу посылает ему актуальный OCSP-ответ при установлении TLS-соединения). Ты хочешь сказать, что браузер может 3 месяца не проверять актуальность сертификата? Есть где почитать про это?

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

И сгоревший датацентр LEшников выводит из строя половину интернета :)

Это как? Браузер <...>

Помимо браузеров есть ещё много всего. И не у всех последние браузеры. И подход, предполагающий кучу действий (зарепортить взлом, добавить в CRL, распространить этот CRL, ...) хуже, чем подход, предполагающий тупо невыдачу нового короткоживущего сертификата.

И сгоревший датацентр LEшников выводит из строя половину интернета :)

А сгоревший корневой DNS — весь интернет. Резервирование всех спасёт.

В данном случае мы получаем дыру в безопасности за счёт того, что даём чужому софту доступ к нашему серверу, да ещё и по крону автоматически.

Я так понимаю у тебя весь софт на машине самописный. Начаная с ядра и веб сервера и заканчивая кроном...

А я и не говорил что бывает 100% безопасность. Но чем меньше лишнего софта, тем лучше.

одход, предполагающий кучу действий (зарепортить взлом, добавить в CRL, распространить этот CRL, ...) хуже, чем подход, предполагающий тупо невыдачу нового короткоживущего сертификата

Отзывают сертификат сразу, а не через 3 месяца после взлома. Да и с какого перепугу новые сертификаты перестанут генериться, как только сервер взломали? Как скрипт об этом узнает?

Отзывают сертификат сразу

Да, все равно, на самом деле. Злоумышленник во время атаки просто заблокирует доступ к OCSP и CRL, и клиент даже не ругнется. Короткоживущий сертификат - самое простое решение.

Да и с какого перепугу новые сертификаты перестанут генериться, как только сервер взломали?

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

А, имеется в виду проблема со скопированными ключами. Понял.

Да, все равно, на самом деле. Злоумышленник во время атаки просто заблокирует доступ к OCSP и CRL, и клиент даже не ругнется.

Значит клиенту на безопасность плевать, раз не ругнётся.

Короткоживущий сертификат - самое простое решение.

Самое простое решение — починить клиента.

Значит клиенту на безопасность плевать, раз не ругнётся.

Не плевать, просто существующая схема отзыва сертификатов - самая уязвимая часть в PKI. И никто пока не придумал нормального решения. Короткоживущие сертификаты - одно из наиболее вменяемых решений на данный момент, хоть и не без изъянов.

Самое простое решение — починить клиента.

Ну иди почини все браузеры, а заодно и всю инфраструктуру PKI, потом нам расскажешь.

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

Ой ли..? Ой ли..? Прямо вот таки, тот же apache, получив reload, перечитает файл сертификата?

Это отличный способ. Использую давно для своих личных нужд.

Но если публичный сайт/сервис - то самоподписанный уже не прокатит.

Какие ошибки? Тормозит из-за сертификата? Что?

Ошибки на самом сайте StartSSL.

Посмотрел acme-tiny - очередной костыль. Столько лишних движений. Я просто хочу получить подписанный сертификат, а не разбираться, как работают все эти приблуды, а потом ещё их настраивать на автоматический режим.

Проект Let's Encrypt делался для того, чтобы получит сертификат было легко и просто. Они говорили, что якобы сейчас процедура очень сложна - нужно регаться на сайтах, делать там всякие действия и т.д. Они обещали что-то лёгкое и простое. Но, как видим, реализация сделана через задницу, проще зарегаться на сайтах продавцов воздуха и получить у них. Да я даже заплатить готов вменяемую цену, чем пользоваться Let's Encrypt.

Может быть через несколько лет до Let's Encrypt дойдёт и выкатят что-то более адекватное, там посмотрим. Но пока пусть сами пользуются своими приблудами.

А как, по-твоему, должна выглядеть процедура без лишних движений? Ещё раз, acme-tiny — это PoC. Напиши над ним обёртку, которая сгенерит ключи, CSR, спросит путь к $webroot/.well-known/acme-challenge и добавит минимальный скрипт обновления серта в крон, и будет тебе щастье.

В конце концов, Let's Encrypt как бы не избавляет админа от необходимости минимальной квалификации на тему того, чтобы вписать десяток команд из гайда и правильно урезать права доступа.