Может ли роутер-«прослушка» украсть пароли: HTTP vs HTTPS

Верно ли утверждение, что злоумышленник, контролирующий роутер и прослушивающий трафик, может получить логины и пароли от сайтов, на которые заходит клиент?

При HTTP злоумышленник на роутере, прослушивающий трафик, способен увидеть логины и пароли, так как запросы идут без шифрования; при HTTPS (TLS) содержимое запросов/ответов шифруется и защищается от незаметной подмены, поэтому пассивно «снять» пароль из пакетов нельзя, а риски смещаются к downgrade, фишингу и компрометации устройства.

И при HTTP, и при HTTPS логины/пароли одинаково доступны на роутере, потому что браузер всегда отправляет пароль как открытое POST‑поле, а шифрование касается только «файлов»; следовательно, значок замка не влияет на возможность прочитать пароль в трафике и перехват роутером всегда даёт креды.

При HTTPS пароль скрыт, но при HTTP он тоже скрыт, потому что браузер кодирует его в base64 и этого достаточно; поэтому прослушивание трафика роутером не даёт злоумышленнику полезных данных, а все реальные угрозы связаны только с вирусами на компьютере, а не с сетью.

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

Теория и модель угроз

В модели «злоумышленник контролирует роутер» необходимо различать пассивное наблюдение (только чтение пакетов) и активную атаку (подмена DNS/маршрутизации, внедрение ответов, попытки понизить защиту). Важно также разделять «получить именно пароль» и «получить доступ к аккаунту»: второе часто достигается кражей сессионных данных даже без знания пароля.

Утверждение в общем виде верно для HTTP и в общем виде неверно для корректно настроенного HTTPS: при HTTP логины/пароли могут проходить по сети в открытом виде, а при HTTPS они передаются внутри зашифрованного TLS‑канала и пассивно «снять» их с линии не получится.

В вебе «HTTPS» на практике означает «HTTP поверх TLS»: HTTP‑сообщения (включая заголовки, URL‑путь, тело POST) оказываются внутри шифрованной «трубы», а не «немного защищены».

HTTP: что видит атакующий

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

Если аутентификация выполнена через HTTP Basic, значение заголовка Authorization: Basic ... является всего лишь base64 и может быть восстановлено до пары логин:пароль при наличии трафика в открытом виде. Даже когда пароль не отправляется «каждый раз», часто видны сессионные cookie; перехват cookie в HTTP позволяет захватывать сессии, что в практическом смысле эквивалентно компрометации аккаунта.

Наглядно (упрощённая схема, стрелки — сетевой путь):

клиент -> роутер (атакующий) -> интернет -> сайт
HTTP:  GET/POST + headers + body читаются на роутере
HTTPS: TLS(record(HTTP)) выглядит как шифртекст

HTTPS/TLS: что скрыто и что остаётся видимым

При корректном HTTPS логины/пароли, cookie и любое содержимое HTTP‑сообщений защищаются свойствами TLS: конфиденциальностью и целостностью после установления защищённого канала. Это означает, что пассивный наблюдатель на роутере видит факт соединения и набор зашифрованных пакетов, но не может прочитать поля формы, JSON‑тело запроса или заголовки авторизации.

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

Таблица различий по рискам (упрощённо):

Ситуация	HTTP	HTTPS (корректный TLS)
Пассивное прослушивание на роутере	Логин/пароль из формы и/или `Authorization` могут быть прочитаны.	Содержимое HTTP‑запросов/ответов зашифровано, «вытащить» пароль из пакетов нельзя.
Активная подмена трафика на роутере	Можно внедрять/подменять страницы логина и собирать креды «в чистом виде».	Подмена содержимого без обхода TLS обычно приводит к ошибкам целостности или к ошибке сертификата.
Понижение защиты (downgrade)	Защиты нет — всё и так HTTP.	Возможны атаки «свести к HTTP», если сайт допускает вход по HTTP и нет строгой политики, но это должно предотвращаться HSTS.
Что остаётся видимым в любом случае	Домен/URL/параметры видны целиком.	Полезная нагрузка скрыта, но длины/тайминги трафика не скрываются.

Опасная ошибка мышления: «раз сайт умеет HTTPS, значит пароль нельзя украсть в сети». Без HSTS и при наличии начального захода по http:// возможна ситуация, когда пользователь оказывается на HTTP‑версии и вводит пароль в открытом виде.

Как HTTPS всё же может быть обойдён при контроле роутера

Вариант 1 — «SSL stripping» (снятие HTTPS): при активной позиции злоумышленника можно попытаться не дать браузеру перейти на HTTPS, оставив пользователя на HTTP, а далее прочитать пароль уже как обычный HTTP‑трафик. Это работает только там, где сайт реально допускает работу по HTTP (хотя бы на первом шаге) и пользователь не «прибит» к HTTPS политиками браузера.

Механизм HSTS создан именно затем, чтобы браузер переписывал небезопасные обращения на безопасные до выполнения запроса и «ломал сценарий» понижения протокола. Практически это означает, что после того как браузер узнал, что домен обязан быть только на HTTPS, запросы на http:// к этому домену перестают быть вариантом «по умолчанию».

Ключевые ограничения: HSTS не защищает от фишинга и вредоносного кода на устройстве, то есть при компрометации клиента или при подмене домена на похожий пароль всё равно может быть украден, хоть и не «сниффингом HTTPS». Если на устройстве установлен злоумышленный корневой сертификат (или пользователь доверил поддельному сертификату), то роутер‑атакующий может развернуть полноценный TLS‑перехват (MITM) и уже видеть содержимое, потому что доверие на стороне клиента будет изменено.

Практически значимое следствие для веб‑разработки: наличие HTTPS должно сопровождаться запретом логина по HTTP и включением HSTS (Strict-Transport-Security: max-age=...; includeSubDomains), иначе «слабое звено» остаётся на первом небезопасном запросе.

Итого: в HTTP креды читаются при перехвате трафика, в HTTPS содержимое запроса/ответа скрыто TLS и пассивно не извлекается; обходы возможны в основном через downgrade без HSTS, фишинг или компрометацию доверия/устройства.