Почему SSL-сертификат не делает сайт «безопасным» сам по себе

Почему SSL-сертификат не делает сайт «безопасным» сам по себе

SSL в разговорной речи обычно означает TLS (Transport Layer Security), а HTTPS — это HTTP, переданный поверх TLS. Он решает конкретную задачу: шифрует канал и проверяет, что вы общаетесь именно с владельцем домена. Но он не лечит уязвимый код, не защищает от фишинга и не отменяет компрометацию сервера.

Ключевая ошибка — считать, что «замочек» равен доверию. На практике важно проверить три вещи: — сертификат выпущен на нужное имя; — цепочка доверия собирается до корневого удостоверяющего центра; — соединение не деградирует в смешанный контент, когда HTML грузится по HTTPS, а скрипты или картинки — по HTTP.

Ещё одна тонкость: TLS даёт конфиденциальность в канале, но не гарантирует целостность приложения. Если форма отправляет пароль на корректный HTTPS-адрес, а дальше сервер хранит его без хеширования, проблема уже не в шифровании. RFC 8446 описывает сам протокол, а браузерные политики вроде HSTS уменьшают риск downgrade-атак, но не заменяют дисциплину разработки.

Bottom line: HTTPS — это базовый слой доверенной передачи данных, а не знак «сайт надёжен». Проверяйте цепочку сертификата, убирайте mixed content и помните: безопасность начинается выше транспортного уровня. Further reading: RFC 8446, RFC 2818, HSTS в RFC 6797.