SSL/HTTPS: 7 ошибок, из-за которых «защищённый» сайт всё равно ломается

SSL/HTTPS: 7 ошибок, из-за которых «защищённый» сайт всё равно ломается

HTTPS — это не «галочка», а цепочка проверок: TLS (Transport Layer Security) строит ключи, а браузер сверяет имя хоста, срок действия и доверие к CA. Если хотя бы одно звено слабое, соединение может выглядеть безопасным только внешне.

Типовые провалы просты: — сертификат выпущен не на тот домен; — цепочка доверия неполная; — редирект с HTTP на HTTPS настроен, но часть ресурсов грузится по HTTP; — сервер поддерживает устаревшие шифры или отключает проверку SNI/ALPN, и часть клиентов отваливается.

Отдельно опасен mixed content: страница открыта по HTTPS, но скрипт, картинка или iframe тянут данные по HTTP. В RFC 2818 и практике браузеров это не «косметика», а реальный канал для подмены. Ещё одна ловушка — неверная санация прокси и балансировщиков: они могут ломать заголовки X-Forwarded-Proto, а приложение начинает генерировать ссылки на HTTP.

Проверяйте не только замок в адресной строке, но и HSTS, корректность цепочки, единый канонический URL и то, как сайт ведёт себя за прокси. И да: наличие SSL-сертификата само по себе не доказывает безопасность логики сайта.

Bottom line: HTTPS защищает транспорт, но не спасает от ошибок конфигурации; тестируйте путь запроса целиком. Further reading: RFC 8446, RFC 2818, Browser Security documentation.