Открыть список
Как стать автором
Обновить

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

Допишите, что SSL небезопасен (poodle attack) и должен быть отключен на серверах как можно скорее.
Практическая часть и детали конфигураций будут во второй части статьи и все уязвимости и пути их устранения будут там рассмотрены)
Вы через строчку пишете про развертывание SSL/TLS через слеш. А SSL свертывать надо как можно скорее.
В названий статьи имеется в виду технология в целом. TLS-протокол основан на спецификации протокола SSL версии 3.0.
Про уязвимости ssl мы расскажем, как и говорили, уже во второй части.
Это вечная проблема — как хранить ключи на серверах. Особенно, если это чужие сертификаты (например, TLS для раздачи статики на CDN).
Спасибо за ссылку. Не знал. Однако, получившаяся конструкция требует постоянно живого key-server'а у кастомера, что совсем не счастье с точки зрения стабильности. Для раздачи статики и вовсе не подходит.

Вот что я бы хотел видеть, если про улучшения говорить, так это temporal delegation, когда владелец сертификата может выписывать on behave сертификаты с не очень большим сроком (а если честно — на своё усмотрение), на указанный (и подписанный тем же CA) сертификат у которого есть право быть таковым.

Сервер предъявляет клиенту цепочку сертификатов до клиента, предъявляет свой сертификат, доказывает владение своим секретом. Клиент сравнивает сертификат сайта, сертификат прокси, соглашается, делает сессию.

От «отдать приватный ключ» это отличается тем, что ключ общий для всех обслуживаемых ssl-сертификатов проксёй, при его компрометации:

1) отзывается один сертификат, а не стопятьсот у разных клиентов.
2) У on behave сертификата ограниченный короткий срок жизни.

Общий CA гарантирует, что не будет «mitm'а с on-behave от китайско-турецких CA», плюс нужна подпись оригинального владельца сертификата.

Но CA'шный бизнес строго против дешёвых сертификатов, которые могут удостоверять другие сертификаты. Печалька…

ЗЫ А вообще, очень хорошая идея: один wildcard, который может удостоверять сертификат на конкретные поддомены.
Хотелось бы советов как поступать с *.domain.tld сертификатами. Вернее что делать с приватным ключом — его приходится давать слишком многим… Есть какие-то варианты?!
Странные советы. Ни слова по делу: выбор шифров, протоколов, настроек PFS, TLS Tickets, false start и прочее…
это статья об огранизационных, а не технических моментах.

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

Информация

Дата основания
Местоположение
Россия
Сайт
usedesk.ru
Численность
2–10 человек
Дата регистрации

Блог на Хабре