Search Linux Wireless

RE: wifi: mac80211: unencrypted message in 4-way handshake

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > > recently we moved from a 4.9 kernel to 5.4 kernel
> > >
> > > 🤯️
> >
> > :D
> > >
> > > > Do you have some hints where to look at to solve the issue?
> > >
> > > No, way too old.
> >
> > That's why we also tried it with kernel 6.6, where we faced the same issue. So
> I'd
> > appreciate hints for kernel 6.6 (or probably later), too. :)
> 
> Yeah but even moving 4.9->6.6 is a huge range, even bigger :)
> 
> > > Take a look at supplicant logs in how it behaves differently, I guess.
> > >
> > > The only thing that comes to mind is that *maybe* the eapol-over-nl80211
> > > path gets used (different kernels) and that has different behaviour in
> > > wpa_s, but honestly, no idea.
> >
> > Thanks, will have a look there.
> 
> I would certainly hope that wpa_s uses that path on the new kernel. It
> wasn't in 4.9, pretty sure.
> 
> johannes

I guess you were on the right track. For now we disabled the control_port via
driver option in the supplicant conf, because the wpa_s logs were pointing to
that and now the 4/4 frame of the 4-way handshake is encrypted as expected.

Looking to the supplicant the problematic code is in the following function.
When WPA_DRIVER_FLAGS_CONTROL_PORT is set, during rekeying at the time
of frame 4/4 the (new) PTK is not yet installed and therefore, leading to the
frame being unencrypted. The additional check for PTK being installed is probably
to prevent some race conditions. At least that's what I think after reading the
commit messages of when control port was introduced. 

int wpa_ether_send(struct wpa_supplicant *wpa_s, const u8 *dest,
		   u16 proto, const u8 *buf, size_t len)
{
[...]
	if (wpa_s->drv_flags & WPA_DRIVER_FLAGS_CONTROL_PORT) {
		int encrypt = wpa_s->wpa &&
			wpa_sm_has_ptk_installed(wpa_s->wpa);

		return wpa_drv_tx_control_port(wpa_s, dest, proto, buf, len,
					       !encrypt);
	}

	if (wpa_s->l2) {
		return l2_packet_send(wpa_s->l2, dest, proto, buf, len);
	}

	return -1;
}

Currently I don't really get the relation of PTK of the 4-way handshake and the
PEAP session key of the TLS handshake. Latter encryption should be applied
independently of the PTK being installed or not or am I wrong? Searching in
the IEEE802.11 standard didn't help me to find an answer to that question.

So I'd assume there's a bug in the wpa_supplicant or what's your impression?
Or is disabling of control_port already considered as a proper solution?





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux