Миф: HTTPS означает, что сайт безопасный

MAATRIX

«У них в адресной строке зелёный замочек, значит сайту можно доверять» — логика, которую слышишь и от обычных пользователей, и от владельцев сайтов, которые искренне считают, что после установки SSL-сертификата вопрос безопасности закрыт. Отчасти это правда: HTTPS действительно решает одну конкретную и важную задачу. Но именно потому, что задача решена хорошо, у людей возникает иллюзия, что решены и все остальные. Разберём, что замочек в браузере гарантирует на самом деле, а что нет.

Что на самом деле проверяет замочек в браузере

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

Первое — трафик между вашим браузером и сервером зашифрован. TLS-рукопожатие устанавливает симметричный ключ шифрования на каждую сессию, и дальше все данные — запросы, куки, вводимые пароли, содержимое страниц — идут по каналу, который в теории невозможно расшифровать, просто перехватив пакеты где-то посередине. Это критично на открытом Wi-Fi в кафе или аэропорту, где без HTTPS любой сосед по сети с Wireshark увидел бы ваш трафик в открытом виде.

Второе — определённый уровень подтверждения, что вы соединились именно с тем доменом, который указан в адресной строке, а не с кем-то, кто выдаёт себя за него посередине пути (MITM). Сертификат выпускается удостоверяющим центром только после того, как заявитель докажет контроль над доменом — через ACME-challenge, если это Let's Encrypt, или через более тяжёлую ручную проверку для OV/EV-сертификатов. Про то, как именно происходит эта проверка домена, есть отдельный разбор — как Let's Encrypt доказывает, что домен ваш.

Вот и всё. Замочек не проверяет содержимое сайта, репутацию владельца, безопасность серверного кода или намерения человека, который сайт зарегистрировал. Он проверяет канал и то, что вы говорите именно с заявленным доменом. Дальше — зона полной неизвестности, в которую HTTPS не заглядывает вообще.

Шифрование канала не защищает от дыр в самом сервере

Первая и самая частая путаница: HTTPS шифрует то, что передаётся, но никак не влияет на то, что происходит на сервере, который эти данные принимает.

Представьте сайт на устаревшей версии WordPress с непропатченным плагином, в котором есть известная SQL-инъекция. Владелец поставил Let's Encrypt, зелёный замочек на месте — но зашифрованный HTTPS-запрос с вредоносной SQL-нагрузкой в параметре долетает до сервера так же исправно, как и обычный. Шифрование канала не читает и не фильтрует содержимое запроса на предмет опасных конструкций — это не его задача, для этого нужны совсем другие механизмы (WAF, валидация ввода на уровне приложения, подготовленные выражения в SQL-запросах).

То же самое с любой другой уязвимостью серверной стороны:

• устаревшее ПО с известными CVE (старый Apache, nginx, PHP, движок CMS);
• открытые административные панели без ограничения по IP;
• слабые пароли для SSH или базы данных;
• неправильно настроенные права доступа к файлам;
• незакрытые порты, на которых висят сервисы с дефолтными учётками.

HTTPS работает на уровне транспорта (TLS поверх TCP) — он не знает и не может знать, что происходит выше, в логике приложения. Сервер может быть решетом, а канал к нему — идеально зашифрованным. Для атакующего, который эксплуатирует уязвимость приложения напрямую, наличие или отсутствие TLS вообще не имеет значения — он не перехватывает трафик, он бьёт по открытой двери сервера.

Практический вывод для владельца VPS: сертификат — это пункт из чек-листа, а не финальная галочка. Обновления ОС и ПО, firewall с ограничением портов, отключение root-логина по паролю на SSH, регулярный аудит открытых сервисов — это отдельная работа, которую HTTPS за вас не делает.

Бесплатный сертификат доступен кому угодно, включая фишинговые сайты

Второй источник ложного доверия — это мысль «раз у сайта есть сертификат, значит его кто-то проверил и одобрил». Для DV-сертификатов (доменная валидация, самый массовый тип, включая весь Let's Encrypt) это не так вообще.

Получить бесплатный DV-сертификат может абсолютно любой, кто зарегистрировал домен и может пройти автоматическую ACME-проверку — то есть положить файл на сервер или прописать TXT-запись в DNS. Это занимает секунды и не требует ни паспорта, ни юрлица, ни модерации человеком. Именно поэтому DV-сертификаты и стали стандартом для 99% сайтов в интернете — они дёшевы (точнее, бесплатны) и решают ровно задачу шифрования канала, ради которой создавались.

Но из этого прямо следует: домен-двойник легального банка или маркетплейса, зарегистрированный вчера злоумышленником с целью фишинга, получит точно такой же честный зелёный замочек за те же секунды. Например:

paypal-secure-login.com       ← чужой домен, но свой честный HTTPS
sberbank-online-verify.ru     ← аналогично
your-bank.support-center.net  ← аналогично

Пользователь смотрит в адресную строку, видит замочек и — если не проверяет сам домен внимательно — делает ложный вывод «раз есть HTTPS, значит это настоящий сайт банка». А сертификат тут вообще ни при чём: он честно подтверждает лишь то, что канал зашифрован и что вы говорите с сервером именно этого домена (paypal-secure-login.com), а не с сервером настоящего paypal.com. Легитимность самого домена, добросовестность владельца, соответствие бренду — это вне зоны ответственности DV-сертификата.

Отдельно стоят OV (Organization Validation) и EV (Extended Validation) сертификаты, где CA действительно проверяет документы компании вручную — но такие сертификаты дороги, требуют времени на выпуск и в массовом вебе почти не используются. Более того, большинство современных браузеров давно перестали визуально выделять EV-сертификаты отдельной плашкой с именем компании, как это было раньше, — так что даже более строгая проверка сегодня незаметна обычному пользователю в интерфейсе.

Что HTTPS не защищает: приложение и данные после сервера

Третий блок — уязвимости, которые находятся не в канале передачи и не в инфраструктуре сервера, а в логике самого веб-приложения. HTTPS их не видит и не должен видеть — это разные слои модели угроз.

XSS (межсайтовый скриптинг). Если сайт не экранирует пользовательский ввод и вставляет его в HTML-страницу как есть, атакующий может внедрить свой JavaScript, который выполнится в браузере жертвы — с теми же правами, что и легитимный скрипт сайта. HTTPS честно доставит эту вредоносную страницу зашифрованной — шифрование канала не отличает «правильный» HTML от HTML со встроенным вредоносным скриптом, потому что смотрит только на то, что данные передаются целостно и без изменений в пути, а не на то, что внутри этих данных.

CSRF (подделка межсайтового запроса). Атака эксплуатирует то, что браузер сам подставляет куки авторизации при запросе к сайту, даже если запрос инициирован со стороннего ресурса. Это вопрос архитектуры приложения (CSRF-токены, проверка заголовка Origin/Referer, атрибут SameSite у куки) — TLS-канал тут ни при чём, оба запроса (легитимный и поддельный) одинаково успешно проходят через зашифрованное соединение.

Утечка после того, как данные попали на сервер. HTTPS защищает данные в пути — от вашего браузера до сервера. Как только пакет расшифрован на стороне сервера и данные записаны в базу, зона ответственности TLS заканчивается. Если база данных настроена без пароля, доступна извне, хранит пароли пользователей в открытом виде вместо хеширования с солью (bcrypt, argon2) — весь массив данных может утечь целиком, и никакой сертификат канала передачи это никак не предотвратит. Подавляющее большинство громких утечек баз данных за последние годы — это именно эта история: канал был зашифрован идеально, а хранилище на сервере — нет.

Итого HTTPS покрывает только транспортный уровень модели OSI (условно 4-6 уровень), а XSS, CSRF, инъекции и утечки хранилища живут на прикладном уровне (7) и в инфраструктуре сервера — совершенно другая зона, которую нужно закрывать отдельными инструментами.

Как реально проверить, стоит ли доверять сайту

Раз замочек ничего не говорит о добросовестности сайта, вот что действительно стоит проверить перед тем, как вводить платёжные данные или пароль:

Ни один из этих пунктов не читается по одному только наличию замочка в адресной строке — придётся потратить лишние 30 секунд и посмотреть чуть глубже.

Что делать владельцу сайта: HTTPS — это база, а не потолок

Если вы администрируете собственный сервер, HTTPS должен быть обязательным минимумом (и современные браузеры сами всё активнее помечают HTTP-сайты как небезопасные), но дальше стоит закрыть слои, которые сертификат не закрывает:

# Регулярные обновления системы и пакетов
apt update && apt upgrade -y

# Ограничение доступа по SSH только по ключу, без пароля
# в /etc/ssh/sshd_config:
PasswordAuthentication no
PermitRootLogin no

# Базовый firewall — открыты только нужные порты
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Дальше по списку, в порядке приоритета для типичного VPS с сайтом:

1. Автообновление ОС и CMS-плагинов — большинство успешных атак эксплуатируют уязвимости, для которых патч уже вышел месяцы назад.
2. WAF (Web Application Firewall) — фильтрует типовые паттерны SQL-инъекций и XSS ещё до того, как запрос дойдёт до приложения. На уровне nginx можно начать с ModSecurity, на уровне облака — с готовых WAF-провайдеров.
3. Хеширование паролей с солью (bcrypt, argon2) в базе — даже при утечке базы пароли пользователей не восстанавливаются напрямую.
4. Ограничение прав СУБД — приложение должно ходить в базу под учёткой с минимально необходимыми правами, не под root/admin.
5. Логирование и мониторинг — без логов вы узнаете о взломе от пользователей или поисковика (внесение в чёрный список), а не от собственной системы.
6. Регулярные бэкапы вне сервера — если взлом всё же случился, бэкап на отдельном хранилище — разница между часом простоя и потерянным бизнесом.

Отдельный сертификат Let's Encrypt настраивается за несколько минут через certbot или встроенный ACME-клиент Caddy — это дешёвая по усилиям часть чек-листа. Если у вас ещё нет настроенного HTTPS вообще, шаги описаны в статье как установить и настроить Let's Encrypt SSL на VPS. Но именно потому, что этот пункт закрывается быстро, легко остановиться на нём и не дойти до остальных пунктов списка — а взломы чаще всего происходят именно через них.

Частые вопросы