Нет, у каждого сеанса связи свой уникальный ключ. Но весь спектр MitM атак доступен внутри одной подсети

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

Вперед писать свой убер сниффер и разбиваться о рифы жестокой реальности

Да

PS: man WPA Enterprise

на основе случайных чисел посланных точкой доступа к клиенту и клиентом к точке

Диффи-Хеллман?

видя все хэндшейки, ты можешь получить сессионный ключ

Тогда не получится

А не, там правда решето

Не надо ничего писать. Wireshark расшифровывает трафик, если ему скормить файл с сырыми данными, собранными с интерфейса. Главное что-бы handshake необходимых клиентов в этом дампе были и сообщить правильный пароль Wireshark-у. Так что вопрос снимается. Экспериментом подтвердил, что при известном пароле для WPA2 PSK, трафик всех клиентов можно расшифровать, главное, что бы прошёл handshake с клиентом, где по какой-то причине рандомные числа для создания сессионного ключа передаются в открытом виде.

Меня и удивляет решение передавать случайные числа в открытом виде для формирования сессионного ключа, что стоило для передачи этих чисел задействовать тот же DH, RSA для этого использовать.

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

что мешало

То что все эти дырявые WPA, WEP, WPS и прочее делали одни и те же рукожопы.

ключ

ключи для шифрования трафика формируются только один раз при вводе пароля или при каждой новой сессии?

Hostapd, кстати, умеет wpa2-psk с персональным паролем для MAC-адреса. Кажется, это чинит проблему, о которой ты пишешь.

Весь WiFi дыряв. Причём Ключи доступа ломаются железкой класса RPi мминут за 30, WPA2/PSK, остальное еще быстрей. WPA-Enterprise - требует дополнительной инфраструктуры. Так что самый простой способ - не шифрованный WiFi с IPsec тунелем в роутер.

Что мешает (ну кроме нежелания FCС) подменить MAC на интерфейсе ?

Ничего не мешает. Но речь же не про это? Когда у каждого клиента свой пароль (читай - ключ), компрометация одного ключа не влияет на приватность чужого трафика.

возможность сниферить весь трафик и от других клиентов

Специально для этого есть «ap isolation»

А вот гугль (большой и добрый эээххх) рекомендует жто выключить :)

https://support.google.com/chromecast/answer/3213084?hl=en

Ну так это документация к Chromecast, который не работает с isolation.
AP isolation, вообще хорошая практика, особенно во всяких кафе, чтобы какой-нибудь школьник gismeteo на redtube не перекинул.

Вопрос - делают ли его там :)

Ощущение, что передача не шифрованными, каким-нибудь несимметричным шифром, WPA Key Nonce, специально оставленная лазейка, хотя уж слишком очевидная. Ну как можно было не подумать о защите трафика клиентов точки друг от друга. Как показал эксперимент, зная единый пароль, весь трафик клиентов точки, как на ладони. Более того, шифруй Nonce, от подбора пароля к точке не было бы никакого проку, кроме того, что к ней тоже можно было бы подключиться.

ключи для шифрования трафика формируются только один раз при вводе пароля или при каждой новой сессии?

Они формируются даже в течении одной сессии с каким-то периодом. Но от человека, знающего общий пароль WPA PSK, это не спасёт. Это помогает только от поиска пароля точки.

Специально для этого есть «ap isolation»

А чем это то поможет? Трафик то всё равно видно, он вещается всем, кто способен принять радиосигнал, изоляция эта, уже за точкой доступа.

Hostapd, кстати, умеет wpa2-psk с персональным паролем для MAC-адреса

Спасибо почитаю, оно видимо похоже на WPA Enterprise. ИМХО, если есть возможность поднять hostapd, то и поднять WAP Enterprise проблем не будет.

А чем это то поможет?

Тем, что ты можешь сниферить сам себя сколько угодно.

Пакет отправленный конкретному клиенту по радиоканалу, получит любой, кто этот канал прослушивает. Это защита подключённых к AP клиентов от взаимодействия друг с другом. То есть подключившись к сети, ты не достучишься до соседа. Если же ты канал слушаешь пассивно, зная пароль от точки доступа, не подключаясь к ней, весь трафик радиоэфира к тебе попадает и доступен для расшифровки.

И часто кто-то пассивно слушает твой Wi-Fi трафик, в твоей же сети? Use VPN over Wi-fi connection, тогда например. Самое ценное в Wi-Fi как правило сам доступ в интернет, AP isolation отлично разграничивает клиентов, а сайты банков и платежные гейты, уже как правило over https.

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

Кхм... Я вот даже не знаю... А чем тебе поможет асимметричное шифрование в данной ситуации?

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

И часто кто-то пассивно слушает твой Wi-Fi трафик, в твоей же сети?

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

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

Эти ключи, внезапно, придется передавать в открытом виде. А если они передаются в открытом виде... Ну ты понял :)

Проблема распределения ключей не зря называется «проблемой». Тут, в принципе, помогает протокол Диффи-Хэлмана, но он тоже оказался уязвим (пока - только для некоторых начальных значений).

Эти ключи, внезапно, придется передавать в открытом виде. А если они передаются в открытом виде... Ну ты понял :)

Нет не понял. Эти ключи для не симметричного шифрования. То есть зная открытый ключ, которым был зашифрован текст, ты не сможешь его расшифровать, если у тебя нет его пары (закрытого ключа).