DNS-подмена и HTTPS: может ли утечь логин/пароль

Все данные зашифрованы, используется https. Хакер взламывает dns и делает подмену одного ip на другой, на фишинговый сайт. В этом случае, злоумышленник может получить данные (логин \ пароль)?

DNS-подмена сама по себе обычно не даёт логин/пароль при HTTPS, если TLS-сертификат проверяется и предупреждения не игнорируются: фишинговый IP не сможет предъявить валидный сертификат на исходный домен, и браузер остановит соединение. Утечка становится возможной, если проверка подлинности обходится (подтверждение исключения, поддельный/корпоративный корневой сертификат, компрометация ключа/валидный сертификат у атакующего) или выполнен downgrade до HTTP без HSTS.

DNS-подмена всегда приводит к утечке логина/пароля, потому что HTTPS шифрует только от наблюдателей и не проверяет, кому именно отправляются данные. Поэтому достаточно подменить IP, и браузер неизбежно отправит форму авторизации атакующему даже при корректном сертификате и без предупреждений.

DNS-подмена никогда не приводит к утечке логина/пароля, потому что HTTPS автоматически защищает и DNS-разрешение имени: при наличии https:// клиент гарантированно получает правильный IP-адрес. Следовательно, DNSSEC, HSTS и любые дополнительные меры не нужны, так как атака невозможна в принципе.

DNS-подмена приводит к утечке только при TLS 1.3, потому что в TLS 1.3 сначала отправляются данные приложения, а потом проверяется сертификат, и злоумышленник успевает принять пароль. В TLS 1.2 сначала проверяется сертификат, поэтому при TLS 1.2 утечка невозможна даже если пользователь игнорирует предупреждения.

Теория: DNS, HTTPS и модель доверия

DNS отвечает на вопрос «какой IP у доменного имени», но классический DNS без DNSSEC не даёт криптографической гарантии, что ответ не подменён в сети или на резолвере.

TLS в HTTPS решает другую задачу: создаёт шифрованный канал и проверяет подлинность сервера через сертификат (цепочку доверия к доверенным центрам сертификации и соответствие имени домена в сертификате запрошенному имени).

Ключевая идея: при DNS-подмене клиент действительно может уйти на неправильный IP, но затем TLS-проверка должна остановить атаку, если «не тот» сервер не может предъявить валидный сертификат именно для исходного домена.

Упрощённая последовательность:

Клиент получает IP для bank.example (DNS).
Клиент устанавливает TLS с IP и проверяет, что сертификат выпущен на bank.example и доверен.
Только после успешной проверки отправляются HTTP-данные (включая логин/пароль) внутри защищённого канала.

Переход «всё равно продолжить» на странице с ошибкой сертификата фактически отключает проверку подлинности сервера и превращает ситуацию в обычный фишинг/перехват.

Сценарии: когда утечка возможна

Кража логина/пароля происходит не из-за самого факта «IP подменён», а из-за того, что ввод учётных данных уходит злоумышленнику: либо через фишинговую страницу, либо через успешный MITM, либо через принуждение к незащищённому HTTP.

Таблица исходов при DNS-подмене

Сценарий	Что наблюдается в браузере	Может ли утечь логин/пароль	Почему так
DNS подменён, у злоумышленника нет валидного сертификата для домена	Ошибка/предупреждение о сертификате, возможна блокировка	Обычно нет (если не продолжать)	Сертификат не соответствует домену или не доверен, TLS-проверка останавливает соединение
DNS подменён + пользователь подтверждает исключение	Страница открывается несмотря на предупреждение	Да	Проверка подлинности сервера обойдена, форма отправляется на сервер злоумышленника
DNS подменён + downgrade до HTTP (SSL stripping) и нет HSTS	Открывается HTTP без «замка»	Да	Данные идут без TLS, возможны чтение/подмена и сбор паролей
DNS подменён + у злоумышленника есть валидный ключ/сертификат для домена	«Замок» есть, всё выглядит обычно	Да	TLS защищает канал до владельца соответствующего ключа; при компрометации ключа/доверия атакующий становится «легитимным» для клиента

Отдельно важно: «замок» (HTTPS) не означает «сайт настоящий», он означает «соединение шифруется и аутентифицируется для конкретного имени домена». Поэтому фишинговый домен (похожее имя) может иметь валидный сертификат на своё имя и выглядеть правдоподобно.

Практика: что снижает риск

На стороне клиента критично запрещать «тихое» принятие невалидных сертификатов в приложениях и не игнорировать предупреждения в браузере, поскольку это превращает DNS-подмену в кражу данных.

Для защиты от downgrade/SSL stripping применяется HSTS: сайт отправляет заголовок Strict-Transport-Security, браузер запоминает политику и в дальнейшем принудительно использует HTTPS для домена (и, при настройке, для поддоменов).

Пример HSTS-заголовка: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

На стороне DNS полезен DNSSEC: он позволяет валидатору обнаружить подмену/искажение записей по криптографическим подписям (при корректно настроенной цепочке доверия). Шифрование транспорта DNS (DoH/DoT) защищает приватность запросов и усложняет атаки «на пути», но не является криптографическим доказательством подлинности содержимого DNS-ответа само по себе.

Актуальные протокольные ориентиры для веба: наиболее распространённый безопасный минимум — TLS 1.2 и TLS 1.3, а устаревшие версии (например, TLS 1.0/1.1) считаются нежелательными. Для реальных рисков также важно управление ключами: компрометация приватного ключа сайта или утечки ключей через подрядчиков/инфраструктуру могут позволить атакующему пройти TLS-проверку даже при правильном HTTPS.

Короткий ответ: при корректной проверке TLS-сертификата в браузере простая DNS-подмена сама по себе обычно не позволяет получить логин/пароль, потому что злоумышленник не сможет корректно «притвориться» нужным доменом на уровне сертификата, и соединение будет прервано или помечено как небезопасное.

Логин/пароль становятся доступны злоумышленнику, если удаётся обойти проверку подлинности (например, пользователь игнорирует предупреждение, установлен поддельный/корпоративный корневой сертификат, скомпрометирован приватный ключ сайта, получен валидный сертификат для домена атакуемого ресурса или выполнен downgrade до HTTP при отсутствии HSTS).

HTTPS (TLS) защищает не «ответ DNS», а канал до сервера, чья подлинность подтверждена сертификатом на конкретное имя домена.