Почему соединения WPA3 разрываются через 11 часов
В 2018 году началась сертификация первых устройств Wi-Fi с поддержкой нового протокола безопасности WPA3, а в последующие года WPA3 стал привычной функцией для всего нового оборудования, включая маршрутизаторы, одноплатники вроде Raspberry Pi и т. д.
Но иногда технология вызывает совершенно неожиданные и необъяснимые сбои. Некоторые пользователи начали сообщать о странном баге, когда беспроводные соединения WPA3 разрываются через 11 часов по непонятной причине.
WPA3
WPA3 (Wi-Fi Protected Access 3) основан на криптографическом протоколе Simultaneous Authentication of Equals (SAE) от Дэна Харкинса (Dan Harkins), автора многих RFC. Стандарт добавляет новые функции для упрощения безопасности Wi-Fi, более надёжной аутентификации, повышения криптографической стойкости и отказоустойчивости критически важных сетей.
WPA3 предлагает два профиля для личных и корпоративных сетей:
- WPA3-Personal обеспечивает более надёжную парольную аутентификацию и защиту от брутфорса даже для коротких или простых паролей. Это реализуется за счёт замены старого протокола Pre-shared Key (PSK) на SAE, который относится к протоколам типа PAKE (password-authenticated key agreement). Ключевое свойство PAKE — человек в середине не может получить достаточно информации, чтобы провести «офлайновый» брутфорс в пассивном режиме, ему обязательно требуется взаимодействие со сторонами для проверки каждого варианта.
- WPA3-Enterprise предоставляет гораздо более высокие требования к безопасности, используя особо стойкие криптографические протоколы с минимум 192-битными ключами и следующие криптографические инструменты для защиты данных:
- Аутентичное шифрование: 256-битный Galois/Counter Mode Protocol (GCMP-256)
- Формирование ключа и подтверждение: 384-битный Hashed Message Authentication Mode (HMAC) с хэшированием по протоколу Secure Hash Algorithm (HMAC-SHA384)
- Обмен ключами и аутентификация: обмен по протоколу Elliptic Curve Diffie-Hellman (ECDH) и цифровая подпись по алгоритму Elliptic Curve Digital Signature Algorithm (ECDSA) на 384-битной эллиптической кривой
- Надёжное управление защитой трафика: 256-битный Broadcast/Multicast Integrity Protocol Galois Message Authentication Code (BIP-GMAC-256)
Предполагается, что при выборе 192-битного режима будут использоваться все перечисленные инструменты, что обеспечивает базовую платформу безопасности внутри сети WPA3. - Аутентичное шифрование: 256-битный Galois/Counter Mode Protocol (GCMP-256)
Разрыв соединений Wi-Fi
Первые сообщения о разрыве соединений WPA3 после определённого времени датированы 2021 годом. Проблема обсуждалась на форуме Infinion в октябре 2021 г.
Инженеры пришли к выводу, что причина связана с некорректной работой чипсета Broadcom/Cypress/Infineon именно в режиме WPA3. Если же снизить уровень защиты до WPA2, то всё работает нормально. Обсуждение продолжалось почти год и завершилось в августе 2022 года без какого-либо решения.
Raspberry Pi Pico WH с беспроводным чипом Infineon CYW43439, который поддерживает IEEE 802.11 b/g/n и Bluetooth 5.2
Спустя два с половиной года баг так и не устранили окончательно. По крайней мере, сейчас владельцы Raspberry Pi сообщают об аналогичных разрывах соединений Wi-Fi через 11 часов работы именно в режиме WPA3. События в логах выглядят примерно таким образом:
01:03:51 NetworkManager [...]: new IWD device state is connected [...] 12:04:39 iwd[...]: Received Deauthentication event, reason: 0, from_ap: false
Вероятно, разработчики чипсета решили, что баг не слишком критический, поэтому не стоит тратить ресурсы на выяснение причины. Ведь такой реверс-инжиниринг — очень нетривиальная задача.
На форуме разработчиков HN предполагают, что баг может быть связан с интервалом переподключения и перевыпуска ключей (rekey interval). Например, он установлен на 3600 с, но при одиннадцатом переподключении (39 600 с) происходит сбой, ключи отсутствуют — и соединение разрывается из-за ошибки аутентификации.
Из других возможных причин — переполнение буфера, в котором хранится какая-то переменная (например, счётчик времени). В частности, интервал 11 ч 06 мин 40 с (40 000 с) соответствует 10000000 тикам с частотой 250 Гц, то есть сбой возможен в случае, если некто хранит время (значение счётчика) в численном виде. Говорят, такая же беда случилась 8 сентября 2001 года с KDE, когда счётчик time_t перешёл с 999999999 на 1000000000 секунд, что сломало почтовый клиент KDE.
Повреждение SSH
В связи с этим вспоминается история далёкого 2012 года про то, как между серверами в Лондоне и Монреале необъяснимо падало соединение SSH: оно то зависало, то завершилось без ошибки по таймауту. Инженеры очень долго отслеживали причину сбоев — и в конце концов выяснили, что в теле TCP-пакетов (после 576 байта) повреждался каждый 15-й байт из шестнадцати. Причём повреждение было предсказуемым: например, все символы h превращались в x, а все c становились s:
Из ASCII-таблицы стало понятно, что один бит «застрял» в положении 1.
Например, заполненный нулями пакет приходил в точку назначения в изменённом виде. Вот часть одного из пакетов:
0x0210 ..... 0x0220 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0230 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0240 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0250 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0260 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0270 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0280 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0290 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x02a0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x02b0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x02c0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x02d0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x02e0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x02f0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0300 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0310 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0320 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0330 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0340 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0350 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0360 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0370 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0380 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x0390 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x03a0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x03b0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x03c0 0000 0000 0000 0000 0000 0000 0000 1000 ................ 0x03d0 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x03e0 .....
Оставалось выяснить, какой из 17-ти узлов в маршруте портил TCP-пакеты. Инженеры использовали тот факт, что в результате порчи слетает соединение SSH. Поэтому они составили список географически распределённых открытых SSH-серверов — и протестировали соединение с каждым из них. Сравнение маршрутизации пакетов на сбойных соединениях позволило вычислить конкретный IP-адрес, который присутствовал во всех сбойных маршрутах. О проблеме сообщили администратору этой зарубежной системы.
… Так что всякое бывает. И переход на «более безопасную» версию протокола не всегда гарантирует реальное повышение безопасности. В некоторых случаях разумно придерживаться проверенных решений, которые работают более надёжно. Судя по всему, в случае с Wi-Fi более надёжно работает WPA2.
