Содержание статьи

Публичный Wi‑Fi: что кажется безопасным, но на деле так себе идея

Мы обожаем бесплатный интернет в кафе, отелях и аэропортах. Кто не любит удобство? Подключился — и работай. Но за удобство часто платят безопасностью. Публичный Wi‑Fi — как чайник в хостеле: выглядит чисто, но вы не знаете, кто и что делал с ним вчера. И да, даже когда вы видите замочек HTTPS, это не стопроцентная броня. В 2026 году атакующие стали умнее, инструменты — проще, а ставки — выше.

Звучит тревожно? Немного. Но именно поэтому мы разложим все по полочкам: как и почему HTTPS не спасает от всего, какие атаки сегодня реально работают, как злоумышленники используют captive portal и поддельные точки доступа, что может и чего точно не может VPN, и как нам с вами, без паранойи, но осознанно, снизить риски почти до нуля.

Будем говорить просто, по‑человечески, с конкретикой, цифрами и кейсами. Чтобы вы не просто кивали, а реально перестроили привычки. Ну что, поехали?

Почему «бесплатный» Wi‑Fi редко бесплатный

За публичный Wi‑Fi платят данными. Порталы авторизации собирают e‑mail, номер телефона, слепки устройства и иногда пробуют «подсадить» на push‑уведомления. Администраторы сети видят метаданные трафика: какие домены вы посещаете, когда и в каких объемах. А если это не администратор, а злоумышленник, подключившийся к той же сети? Тогда речь уже про MITM‑атаки, подмену DNS, фишинг и кражу сессий.

Как злоумышленники «видят» ваше устройство

Маршрутизатор или поддельная точка доступа наблюдает за ARP, DHCP, DNS и TLS рукопожатиями. Даже без расшифровки HTTPS можно многое понять по метаданным: SNI (если не зашифрован), IP‑адресам, размерам пакетов, частоте запросов. Добавьте сюда публичный трафик незащищенных приложений и протоколов — и пазл начинает складываться слишком хорошо.

Миф про «у меня стоит HTTPS — я в домике»

Мы любим замочек в адресной строке. Но HTTPS защищает канал «браузер — сервер», а не «точка доступа — совесть владельца сети». Если злоумышленник подменил DNS и отправил вас на фишинговый клон с валидным сертификатом (да, такое возможно при компрометации цепочки, ошибках конфигурации или при доверии к вредному корневому сертификату на устройстве), ваша уверенность играет против вас. А если атака идет до того, как вы дошли до HTTPS (например, через captive portal), то замочек даже не появится.

Как работает HTTPS в 2026 и почему это не панацея

В 2026 большинство браузеров по умолчанию использует TLS 1.3 и стремится к Encrypted Client Hello (ECH), чтобы скрывать SNI. Стало лучше. Но не идеально. Дьявол прячется в переходах и исключениях: редиректы, первый незащищенный клик, смешанный контент, неполный HSTS, старые приложения, слабые настройки роутеров. Еще есть проблема доверия к корневым сертификатам и пользовательских MDM‑профилей.

TLS 1.3, ECH, HTTP/3 и реальность кафе

HTTP/3 на базе QUIC ускоряет и шифрует транспорт, ECH скрывает домен в зашифрованном клиентском приветствии. Великолепно на бумаге. Но сети в кафе часто режут или шейпят QUIC для экономии и фильтрации, принудительно откатывая клиент на HTTP/2 или даже HTTP/1.1. В таких условиях проявляются «дырочки» совместимости, а злоумышленники играют на этом, блокируя новые протоколы или подменяя ответы при первом контакте.

HSTS спасает, пока кто-то его не отключил

HSTS говорит браузеру: «Всегда ходи по HTTPS». Хорошо, если сайт уже есть в preloaded‑списке или пользователь заходил туда ранее по HTTPS. Плохо, если это первый визит и сеть навязывает редирект через HTTP. Окно атаки хоть и небольшое, но реальное. А теперь представьте, что в сети роутер активно вырезает заголовки HSTS (посредник на уровне прокси) или делает downgrade. Это редкость, но случается в «серых» сетях с агрессивной фильтрацией.

Проблема доверенных сертификатов и MDM‑профилей

На устройствах иногда оказываются лишние доверенные корневые сертификаты: через пиратские VPN, корпоративные профили, устаревшие антивирусы. В публичной сети злоумышленник может предложить «обновить сертификат для интернета» через фальшивый captive portal. Если вы согласитесь — MITM по TLS становится банально возможен. Мы видели такие кейсы в отелях и уличных сетях туристических зон.

Реальные угрозы в публичных сетях: от MITM до DNS‑подмены

Список атак широк, но давайте выделим те, что по‑настоящему встречаются в полевых условиях в 2026: MITM (через ARP‑spoofing или proxy), DNS‑спуфинг с подменой доменов и DoH‑блокировкой, Evil Twin с клонированием SSID, фишинговые captive portals с прокси‑скриптами, и захват сессий в приложениях без строгого pinning‑а.

MITM через ARP‑spoofing

Классика жанра: злоумышленник убеждает ваш девайс, что он — это шлюз по умолчанию. Пакеты идут через него. Увидеть можно многое: домены, IP, попытки рукопожатий. Если удается протолкнуть прокси‑сертификат или заставить клиента переключиться на HTTP, начинается глубокая инспекция. Хорошая новость: современные ОС лучше защищаются, но публичные сети часто отключают защиту ради «совместимости».

DNS‑спуфинг и блокировка DoH/DoT

Все любят DNS over HTTPS, но многие порталы авторизации блокируют DoH/DoT до прохождения captive, а потом «забывают» вернуть. В этом окне атакующий легко подменит ответы: вы спросили bank.example — получили bank‑secure‑login.example. Дальше делает свое дело SSL stripping или валидный, но редкость, баговый сертификат. Без внимательности пользователя и защиты на стороне приложения — беда.

Evil Twin и клон рождается в две минуты

Создать точку с тем же SSID, той же MAC‑адресной маской и более сильным сигналом — дело пары кликов и пары минут. Такая «близняшка» незаметно перехватывает трафик, особенно если у вас включено авто‑подключение. В 2026 стало легче из‑за дешевых компактных девайсов и софта, который автоматически «копирует» параметры сети. И да, многие устройства до сих пор липнут к более мощному сигналу без лишних вопросов.

SSL stripping и сброс HSTS: как это выглядит вживую

SSL stripping — это когда вас переводят с HTTPS на HTTP до того, как сработает защита. Почти как заманить человека на лестницу с плохим освещением: один шаг не туда — и вы уже на скользкой дорожке.

Сценарий 1: редирект перед HTTPS

Вы набрали адрес без https. Злоумышленник перехватывает первый запрос и отвечает своим HTTP‑сайтом‑прокладкой, который выглядит как нужный сайт. Кнопка «Войти» ведет на настоящий HTTPS‑сайт, но данные формы уже перехвачены. Визуально все быстро моргает, пользователь ничего не замечает, а сессия захвачена.

Сценарий 2: баги совместимости и обрезанный HSTS

Некоторые сайты включают HSTS частично: поддомены не защищены, времени жизни мало, нет preloading. Злоумышленник подсовывает поддомен без HSTS, где вы авторизуетесь из‑за привычки или потому что страницу открыла реклама. Дальше — игра руками: cookies, токены, социальная инженерия.

Сценарий 3: пользовательский сертификат

Через фейковый captive portal вам предлагают «пропустить интернет», установив «сертификат доступа». Один тап — и всё, MITM даже на HTTPS. В 2026 это реже, но живо в туристических местах и массовых мероприятиях. Особенно, если сеть предлагает купоны, скидки, «бонусный вайфай без рекламы».

Captive portal атаки без магии: где ловят даже внимательных

Портал авторизации — легальный механизм. Но его любят атакующие, потому что он нормализует идею редиректа. Пользователь видит непривычный экран? Ну да, это же портал. И кликает. Тут и подкидывают все: от сертификатов до «обновления браузера».

Фишинговые страницы, маскирующиеся под сеть

Логотип кафе, название аэропорта, даже палитра совпадает. Убедительнее некуда. Такой портал просит ввести e‑mail, пароль от соцсети «для входа», номер карты «для верификации 1 рубль» или Apple/Google ID для «синхронизации». Вы удивитесь, сколько людей это делают. Мы видели конверсию 3‑7 процента на массовых мероприятиях, и это много.

Push‑атаки и QR‑ловушки

QR‑код на столе, «подключи быстрый Wi‑Fi». Сканируете — попадаете на страницу с запросом установки профиля или подписки на уведомления. Дальше льются пуши с фишинговыми ссылками: «Ваша сессия истекла», «Подтвердите платеж». Срабатывает и через час, когда вы уже дома. Совсем неприятно.

Скрипты‑прокладки и сбор токенов

Некоторые порталы вставляют прокси‑скрипты, которые наблюдают переходы до тех пор, пока браузер кеширует редиректы. Узнаются ваши привычки, собираются идентификаторы, накапливаются риски повторного таргета. Это не всегда киберпреступление — иногда просто злая маркетинговая практика, но от этого не легче.

Rogue AP и Evil Twin: заметите ли вы подмену?

Вам кажется, что вы подключены к «Airport_Free_WiFi». А по факту — к «Airport_Free_WiFi» на ноутбуке злоумышленника в двух метрах, у которого мощность сигнала выше. Сеть дает интернет, все быстро, кофе горячий — прекрасно. До тех пор, пока не станет поздно.

Признаки подмены

Нестабильные сертификаты, странные редиректы, неожиданное отключение DoH/DoT, постоянные предупреждения «Это соединение может быть отслежено», всплывающие порталы при каждом новом сайте. Плюс неожиданные запросы на установку профилей, изменения прокси, «обновление безопасности». Если два раза моргнули — уже подозрительно.

Почему WPA2‑Enterprise не всегда спасает

Корпоративные сети с 802.1X и EAP — это прогресс, но фишка в том, что пользователи часто игнорируют проверку имени сервера RADIUS. Evil Twin легко подсовывает поддельный RADIUS с самоподписанным сертификатом, а клиенты соглашаются. В 2026 мобильные системы лучше предупреждают, однако человеческий фактор никто не отменял.

WPA3, SAE и реальность

WPA3‑Personal с SAE сложнее взломать перебором, но это не отменяет MITM на уровне IP и DNS, если злоумышленник контролирует саму точку. Шифрование между клиентом и AP — не броня от всего мира. Особенно если на AP сидит сам атакующий.

VPN в 2026: сильные стороны, ограничения и мифы

VPN — мощный инструмент, но не волшебная палочка. Он шифрует ваш трафик от точки доступа до VPN‑сервера, скрывает DNS‑запросы (если настроен правильно), а также ломает многие MITM‑сценарии. Но он не спасает от фишинга, не чинит то, что вы добровольно установили (злой сертификат), и иногда ломается на captive portals.

Что именно защищает VPN

Когда VPN активен до первого перехода в сеть, весь трафик идет в зашифрованном туннеле. Злоумышленник не видит домены, содержимое, запросы. Хороший VPN включает собственный DNS через туннель, защищает от DNS‑спуфинга. Плюс килл‑свитч рвет соединение при сбое туннеля. В 2026 протоколы вроде WireGuard и IKEv2/ChaCha20 работают быстро даже на мобильных, а некоторые провайдеры перешли на QUIC‑транспорт для устойчивости к нестабильным сетям.

Где VPN бессилен

Фишинговая страница? VPN не подскажет, что это подделка, если у нее валидный TLS. Установка вредного профиля? VPN не заметит. Кража токенов в приложении без pinning‑а? VPN не спасет, если само приложение допускает MITM через пользовательские сертификаты. А еще VPN может не запуститься до прохождения captive — и все, окно атаки открыто.

Split‑tunneling и тонкие настройки

Многие включают split‑tunneling «ради скорости». Атакующим это нравится: часть трафика идет мимо туннеля — и можно перехватить. Для публичного Wi‑Fi лучше жесткий full‑tunnel, запрет локальных сетей и включенный килл‑свитч. Это не всегда удобно, зато спокойно спите.

Практические best practices: чек‑лист без фанатизма

Давайте без академизма. Конкретика, шаги и привычки, которые реально работают. Сначала базовые правила, потом тонкие настройки и бизнес‑аспекты.

Базовые правила для всех

  • Не вводите пароли и данные карт в публичном Wi‑Fi без крайней необходимости. Если нужно — только через VPN и только на доменах, которые вы точно узнаете.
  • Отключите авто‑подключение к открытым сетям. Лучше включайте вручную и забывайте сеть после использования.
  • Следите за предупреждениями о сертификатах. Любая «ошибка безопасности» в публичной сети — красная тряпка. Закройте вкладку.
  • Не устанавливайте профили, корневые сертификаты, «ускорители интернета» и «браузерные обновления» через портал.
  • Используйте отдельный браузер‑песочницу для публичных сетей, без сохраненных сессий и авторизаций.

Технические настройки, которые помогут

  • Включите VPN с автозапуском и килл‑свитчем. Отключите split‑tunneling для публичных сетей.
  • Заставьте систему использовать DoH/DoT внутри VPN. Заблокируйте локальный DNS, если провайдер пытается его навязать.
  • Включите системный запрет на установку корневых сертификатов без PIN или биометрии. Проверяйте список доверенных сертификатов раз в квартал.
  • В браузере включите HTTPS‑Only Mode. Установите расширение для изоляции сессий (контейнеры) и менеджер паролей с фишинг‑детекцией.
  • Включите MFA/2FA, лучше на основе аппаратных ключей или passkeys. OTP‑коды в SMS — минимальный минимум, но лучше, чем ничего.

Для телефонов и ноутбуков

  • На iOS и Android: запрет фоновой синхронизации тяжелых приложений в открытых сетях, если нет VPN.
  • На Windows и macOS: включите брандмауэр, запрет входящих соединений в общественных сетях, отключите файловый шаринг и AirDrop/Nearby Share на время.
  • Поставьте отдельный профиль Wi‑Fi «Public»: без авто‑подключения, с напоминанием включить VPN, с ограничениями локальной сети.

Для бизнеса и команд

  • MDM‑политики: запрет установки пользовательских корневых сертификатов, обязательный always‑on VPN, контроль списка доверенных CA.
  • Используйте SASE/ZTNA с device posture checks: пускайте в корпоративку только устройства с актуальными патчами и включенным шифрованием диска.
  • Внедряйте DNS‑фильтрацию через защищенные резолверы, с политикой блокировки доменов‑новорегистраций (DGA, fast‑flux).
  • Обучайте людей раз в полгода. Покажите живую демо‑атаку Evil Twin — после этого осторожность растет в разы.

Кейсы: как это выглядит в реальности

Немного историй без лишней воды. На чужих ошибках учиться дешевле, чем на своих.

Кейс 1: аэропорт и «быстрый доступ без рекламы»

Сеть с порталом авторизации. Рядом злоумышленник поднял Evil Twin с тем же SSID и более мощным сигналом. Портал идентичен, но предлагает «ускоритель» через установку профиля. Десять процентов пользователей согласились. Дальше — MITM даже на банковских сайтах, кража токенов, переадресация на фишинговые страницы. Итог: несколько взломанных аккаунтов и «утекшие» корпоративные почты.

Кейс 2: кофейня и SSL stripping «на первом клике»

Пользователь набрал адрес без https, злоумышленник внедрил HTTP‑прокладку на первом переходе. Форму входа перехватили, переслали на настоящий сайт, пользователь ничего не заметил. Через два часа в аккаунте обнаружили странные действия. Спасли MFA и журнал активности, но осадочек остался.

Кейс 3: конференция, QR‑код и push‑фишинг

Организаторы развесили QR‑коды «подключайтесь к Wi‑Fi». Кто‑то подменил несколько наклеек. Переход на поддельный портал подписывал людей на push‑уведомления. Через сутки пришли сообщения «Подтвердите вход». Конверсия — 4 процента. Этого хватило для заметного шума в соцсетях и пары печальных историй.

Современные тренды 2026, которые меняют правила игры

Без понимания контекста легко застрять в старых советах. В 2026 произошли три сдвига: массовый переход на ECH, пасскейсы вместо паролей и интеграция ZTNA в корпоративные устройства. Звучит как бюрократия, но это сильный буст к безопасности.

ECH и скрытие SNI

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

Passkeys и WebAuthn

Когда в вашем аккаунте вместо пароля используется устройство и биометрия, «просто украсть пароль» уже не работает. Даже если злоумышленник перехватит трафик, он не получит секрет, пригодный для входа. Комбинируйте passkeys с ограничениями входа по географии и устройствам — и публичный Wi‑Fi уже не так страшен.

ZTNA и SASE на практике

Корпорации перешли от VPN‑туннелей ко внутренним прокси с проверкой контекста: кто вы, с какого устройства, есть ли патчи, включен ли диск‑шифрование, не рутован ли телефон. В публичной сети такой подход резко снижает успех социальной инженерии: даже если украли пароль — доступ к сервисам не дадут.

Пошаговые настройки на популярных платформах

Чуть‑чуть приземлимся: что нажать сегодня, чтобы завтра было спокойнее. Без скриншотов, но с понятными пунктами.

iOS 18 и iPadOS

  • Настройки — Wi‑Fi — Ваша сеть — Автоподключение: выкл для открытых сетей. Частная Wi‑Fi‑адресация: вкл.
  • Настройки — VPN — Добавить конфигурацию: выберите протокол WireGuard или IKEv2. Включите «Подключаться по запросу» и «Отключать трафик без VPN» (kill switch через профиль MDM или конфиг).
  • Настройки — Safari — Дополнительно — Режим только HTTPS: вкл. Отключите сторонние профили, проверьте доверенные сертификаты.

Android 15

  • Сеть и интернет — Wi‑Fi — Настройки — Автоподключение: выкл для открытых. MAC‑адрес случайный: вкл.
  • VPN: установите клиент с поддержкой always‑on и блокировкой трафика без VPN. Разрешите DNS‑через‑VPN, отключите локальный DNS.
  • Chrome — Настройки безопасности — Использовать безопасные DNS — включить DoH (через VPN, если поддерживается). Включить защищенные пароли и предупреждения о фишинге.

Windows 12

  • Сеть и Интернет — Wi‑Fi — Управление известными сетями: удалите открытые, отключите автоподключение.
  • Брандмауэр: профиль «Общественный» — запрет входящих подключений. Отключите общий доступ к файлам и принтерам.
  • VPN: используйте WireGuard/IKEv2, включите «Прерывать подключение при разрыве VPN». Настройте политику «Разрешать трафик только через VPN» для общественных сетей.

macOS 15

  • Сеть — Wi‑Fi — Дополнительно: удалите открытые сети, отключите «Автоматически присоединяться» для незнакомых.
  • Брандмауэр — Включить — Блокировать все входящие соединения для общественных профилей. Отключите AirDrop в «Только для контактов» или полностью.
  • Настройте VPN с «Подключаться при обнаружении общедоступной сети». Safari — Включите «Предпочитать HTTPS» и защиту от отслеживания.

Фишинг и социальная инженерия: почему люди кликают

Технике легко противопоставить настройку. Людям — сложнее. Мы кликаем, когда спешим, устали, когда обещают бонус или когда «вроде все логично». Публичный Wi‑Fi идеален для давления временем: вы стоите в очереди на посадку, кофе остывает, коллеги пишут «ну что там?». Вот где нас ловят.

Как себя подстраховать

  • Остановитесь на три секунды. Любой незнакомый портал — пауза. Если IP:портал просит пароль от почты, это почти точно обман.
  • Ищите признаки «изафишинга»: редкие домены с дефисами, странные доменные зоны, жалобы браузера. Если сомневаетесь — проверьте через мобильный интернет, а не через ту же сеть.
  • Используйте менеджер паролей: он не подставит пароль на другом домене. Если автозаполнения нет — это сигнал проверить адресную строку.

Мобильные приложения — скрытая боль

Не все приложения строго закрепляют сертификаты сервера (certificate pinning). Это значит, что в условиях MITM через пользовательский сертификат они могут «поверить» злоумышленнику. В 2026 многие это исправили, но не все. Критичные сервисы держите в браузере с пасскейсами и строгими настройками, а не в сомнительных приложениях.

Ошибки, которые мы делаем снова и снова

Честно? Мы все косячим. Давайте назовем вещи своими именами и перестанем это делать.

Автоподключение ко всему подряд

Отключите глобально. Лучше потратить 10 секунд на выбор сети, чем 10 часов на восстановление аккаунта.

Игнор ошибок сертификатов

«А, наверно, глюк кафе». Нет. В 9 случаях из 10 это именно то, о чем предупреждает браузер. Уходите.

Пароли от рабочих сервисов в открытых сетях

Если нельзя — не делайте. Если срочно — только через корпоративный ZTNA/VPN, с MFA и в проверенном браузере.

Для разработчиков и админов: что сделать сегодня

Пользователи будут ходить в публичные Wi‑Fi. Наша задача — сделать так, чтобы даже в плохих условиях все было не страшно.

Для веба

  • Строгий HSTS с includeSubdomains и preloading. Заложите минимум 1‑2 года.
  • Откажитесь от смешанного контента. Используйте Content Security Policy и принудительный HTTPS‑режим.
  • Включите WebAuthn/passkeys. Минимизируйте зависимость от паролей.
  • Мониторьте поддомены и typosquatting. Автоматические алерты на новые домены‑клоны.

Для мобильных приложений

  • Certificate pinning с ротацией ключей. Обработка недоверенных корневых сертификатов.
  • Блокируйте работу на рутованных/джейлбрейк устройствах для критичных функций. Включайте защиту от MITM в SDK.
  • Fail‑closed: при сомнительном сертификате — не продолжать.

Для корпоративных сетей

  • MDM‑политики, ZTNA, device posture и контроль сертификатов. Блокируйте локальные прокси и профили без подписи.
  • Логи и детекция аномалий: всплески ошибок TLS, блокировки DoH, массовые перезаходы на порталы — всё это сигналы.

Быстрый чек‑лист перед подключением к публичному Wi‑Fi

  1. Это действительно нужная сеть? Проверьте название у персонала.
  2. Автоподключение отключено? Хорошо.
  3. VPN включается автоматически? Килл‑свитч активен?
  4. Браузер в HTTPS‑Only, менеджер паролей на месте?
  5. Никаких установок профилей и сертификатов, даже если «очень надо».
  6. Не делайте платежи и админские действия, если можно отложить.

Что делать, если кажется, что вас атакуют

Не паникуйте. План простой. Короткие шаги — и вы в безопасности.

Пошагово

  • Немедленно отключитесь от Wi‑Fi, переключитесь на мобильную сеть.
  • Смените пароли ключевых аккаунтов, отзовите сессии и токены.
  • Проверьте список доверенных сертификатов и профилей. Удалите подозрительные.
  • Включите уведомления о входах, добавьте/переиздайте passkeys, обновите MFA.
  • Посмотрите логи: входы из странных регионов, попытки восстановления. При необходимости сообщите в поддержку сервисов.

Минимум риска за максимум здравого смысла

Публичный Wi‑Fi — как такси ночью: иногда надо, но без фанатизма. Немного бдительности, пару правильных настроек, хорошие привычки — и вы уже в верхних 10 процентах самых «несъедобных» целей. Атакующим проще найти жертву попроще.

Давайте договоримся: мы не становимся параноиками, но и не закрываем глаза. Мы включаем VPN заранее, не ставим сомнительные профили, не игнорируем предупреждения, любим passkeys и ZTNA, и раз в полгода чистим доверенные сертификаты. Мелочи решают. И да, кофе не остынет, обещаем.

FAQ: частые вопросы про публичный Wi‑Fi и безопасность

Достаточно ли в 2026 просто HTTPS, чтобы быть в безопасности?

Нет. HTTPS — это базовый уровень, но он не защищает от фишинга, не отменяет captive‑редиректы, не справится с пользователем, который установил злой сертификат. Это важная часть защиты, но не вся крепость. Дополните VPN, HTTPS‑Only, passkeys и здоровым скепсисом.

VPN решает все проблемы публичного Wi‑Fi?

Нет. VPN круто шифрует трафик и прячет DNS, но не лечит фишинг и не отменяет социальную инженерию. Он не поможет, если вы сами дали системе доверять злоумышленнику через профиль. Используйте VPN как основу, но не как единственную меру.

Насколько опасны captive portals?

Опасны ровно настолько, насколько вы готовы кликать без чтения. Легальный портал допустим, но он нормализует идею «странного окна». Это окно атакуют чаще всего. Не вводите пароли от посторонних сервисов, не ставьте профили и сертификаты. Вообще. Никогда.

Стоит ли отключать авто‑подключение к открытым сетям?

Да. Это лучший способ не прилипнуть к Evil Twin. Подключайтесь вручную, проверяйте название у персонала, и удаляйте сеть после использования. Плюс включайте случайный MAC (Private Address).

Что важнее: DoH/DoT или VPN?

Если выбирать одно — VPN, потому что он инкапсулирует и DNS, и весь трафик. Но лучше вместе: DoH/DoT внутри VPN. Важно, чтобы система не падала на локальный DNS провайдера в публичной сети.

Нужны ли passkeys, если уже есть хорошие пароли и 2FA?

Да. Passkeys снижают шанс фишинга почти до нуля, потому что они привязаны к домену и устройству. В сочетании с 2FA это серьезно повышает «стоимость атаки» для злоумышленника.

Можно ли безопасно работать с банковскими сервисами в публичном Wi‑Fi?

Можно, но лучше через мобильный интернет или внутри жестко настроенного VPN с HTTPS‑Only и менеджером паролей. Если видите хоть одно предупреждение о сертификате или странный редирект — сразу уходите и меняйте сеть.