Комментарии 12
Допишите, что SSL небезопасен (poodle attack) и должен быть отключен на серверах как можно скорее.
Это вечная проблема — как хранить ключи на серверах. Особенно, если это чужие сертификаты (например, TLS для раздачи статики на CDN).
Keyless SSL
www.cloudflare.com/keyless-ssl
www.cloudflare.com/keyless-ssl
Спасибо за ссылку. Не знал. Однако, получившаяся конструкция требует постоянно живого key-server'а у кастомера, что совсем не счастье с точки зрения стабильности. Для раздачи статики и вовсе не подходит.
Вот что я бы хотел видеть, если про улучшения говорить, так это temporal delegation, когда владелец сертификата может выписывать on behave сертификаты с не очень большим сроком (а если честно — на своё усмотрение), на указанный (и подписанный тем же CA) сертификат у которого есть право быть таковым.
Сервер предъявляет клиенту цепочку сертификатов до клиента, предъявляет свой сертификат, доказывает владение своим секретом. Клиент сравнивает сертификат сайта, сертификат прокси, соглашается, делает сессию.
От «отдать приватный ключ» это отличается тем, что ключ общий для всех обслуживаемых ssl-сертификатов проксёй, при его компрометации:
1) отзывается один сертификат, а не стопятьсот у разных клиентов.
2) У on behave сертификата ограниченный короткий срок жизни.
Общий CA гарантирует, что не будет «mitm'а с on-behave от китайско-турецких CA», плюс нужна подпись оригинального владельца сертификата.
Но CA'шный бизнес строго против дешёвых сертификатов, которые могут удостоверять другие сертификаты. Печалька…
ЗЫ А вообще, очень хорошая идея: один wildcard, который может удостоверять сертификат на конкретные поддомены.
Вот что я бы хотел видеть, если про улучшения говорить, так это temporal delegation, когда владелец сертификата может выписывать on behave сертификаты с не очень большим сроком (а если честно — на своё усмотрение), на указанный (и подписанный тем же CA) сертификат у которого есть право быть таковым.
Сервер предъявляет клиенту цепочку сертификатов до клиента, предъявляет свой сертификат, доказывает владение своим секретом. Клиент сравнивает сертификат сайта, сертификат прокси, соглашается, делает сессию.
От «отдать приватный ключ» это отличается тем, что ключ общий для всех обслуживаемых ssl-сертификатов проксёй, при его компрометации:
1) отзывается один сертификат, а не стопятьсот у разных клиентов.
2) У on behave сертификата ограниченный короткий срок жизни.
Общий CA гарантирует, что не будет «mitm'а с on-behave от китайско-турецких CA», плюс нужна подпись оригинального владельца сертификата.
Но CA'шный бизнес строго против дешёвых сертификатов, которые могут удостоверять другие сертификаты. Печалька…
ЗЫ А вообще, очень хорошая идея: один wildcard, который может удостоверять сертификат на конкретные поддомены.
Хотелось бы советов как поступать с *.domain.tld сертификатами. Вернее что делать с приватным ключом — его приходится давать слишком многим… Есть какие-то варианты?!
Странные советы. Ни слова по делу: выбор шифров, протоколов, настроек PFS, TLS Tickets, false start и прочее…
Друзья, вышла часть 2
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Лучшая практика развертывания SSL/TLS, часть 1. Теория