Does openwrt set wpa_strict_rekey=1

pwr · March 21, 2022, 2:06pm

does not seem to do a rekey when a station is bumped/disassociated

also does not visibly (in the log) do a periodic group rekey unless you specify a value for it in the wireless config file.

/var/run/hostapd-phy1.conf does not have a wpa_strict_rekey parameter but does have wpa_group_rekey= if you set in luci

does not seem to be any openwrt option to set strict-rekey anywhere

I know the hostapd default values for wpa_group_rekey should be 600 and for wpa_strict_rekey should be 1 but?

I'm wondering if in stripped down hostapd these defaults are not working if not specified in the config. ?

lleachii · March 21, 2022, 7:19pm

As you should see on the web GUI, this is the OpenWrt default also.

So the group rekey would take place at 600 seconds.

I'm not understanding why you believe this isn't occurring every 600 seconds?

Did you try verbose logging?

pwr · March 22, 2022, 3:42pm

Tried verbose logging and no sign of any rekeying every 10 minutes if the parameter is not set in /etc/config/wireless or via luci... there is a greyed out value of 600 in luci, and no parameter in /etc/config/wifi after changing via luci, and no rekeying events appear in the log.

If you set the value in luci (i.e. actually set it to 600 or whatever) do get the rekey messages in the log

however what you do get at default is one set of rekeying messages once a day when the group master key is rekeyed at its hostapd default value. another parameter of hostapd that is not accessible via luci

also hostapd should default to doing a rekey whenever a station leaves, it seems also to not be doing that.

this is a stock openwrt 22.02 image.

the normal default values for hostapd for gtk rekey seem to not being used if they are not specified explicitly in /etc/config/wireless

you have to specify them in /etc/config/wireless

and there is actually an undocumented parameter for strict rekeying already available. (having scanned /lib/netifd/hostapd.sh and tested my theory that it was already optionally there)

option wpa_strict_rekey '1'

and hey presto - it works!

now rekeys whenever some punk does a deauth!

sorted! (though I am rather disapointed to discover it was not already working... "open" wrt eh! back to the philosophical meanderings of whether to treat an idiot as as bad as a saboteur....)

By the way, that comment not aimed at you! I expected it to be working as default should too!, could be a change that crept in from upstream hostapd... ???

A great paper I read ages ago by Dennis Ritchie... "Reflections on trusting trust!"

pwr · March 24, 2022, 10:15pm

I guess if I really wanted to prove it i could log with kismet, but I reckon I already have proved it... (given the outside chance that the default is not logged, if so then basically they should just actually log it at the verbose level which it is not)

"assume nothing" seems certainly the post-torvalds-conversion-to-pc state of affairs. If "assume-nothing" was ever a false state in the first place.

indeed, perhaps... "assume the worst" seems the correct posture post the covid scamdemic eh!

maybe it is a good method to always specify all parameters having scanned a hostapd file with good comments in, but thing is, istm, stuff changes that even negates a well commented config file... and they do not post an up to date commented config file...

like the whole ffmpeg and avconv split eh! like no avconv examples... yet reams of still valid today ffmpeg examples eh! cryptic without examples.

I'd say I had a couple of military grade vulnerabilities... streaming audio over http, and... at least another one.... that without rekeying were extra vulnerable...

drifting off topic but... that nadal complaining of chest pains after lambasting jokovic for not taking the vaccine is.... well, whatever you make of it i guess eh!

I'm wondering, if, at some point in time, some years ago, 600 seconds was considered a reasonable rekeying time, what, now, is considered reasonable? given gpu power and prices coming back down into pleb. like me territory? and stuff like kali linux and wifi pineapple etc. and all the refinements to foreknowledge...

I'm thinking 300?

I guess what I would like building in to openwrt is an auto attack detect and deploy bunker busters... except... what if they live in the flat above LOL?

lleachii · March 25, 2022, 4:43am

From your descriptions, it seems you might have a unique opinion of what the Group Key is...but I can understand in theory how multicast (e.g. a music stream) over WiFi can compromise the group key.

Perhaps I'd should share this:

http://etutorials.org/Networking/802.11+security.+wi-fi+protected+access+and+802.11i/Part+II+The+Design+of+Wi-Fi+Security/Chapter+10.+WPA+and+RSN+Key+Hierarchy/Pairwise+and+Group+Keys/

Most people increase this value...not lower it. You start to enter client negotiation retry windows with lower settings.

Lastly, OpenWrt doesn't require users to directly manipulate those config files - which is why there also may be few others replying.

I agree it's odd that - with no setting, it doesn't rekey at all.

pwr · March 26, 2022, 12:14pm

Yes, part of the problem is not having a definition of what good settings should be. (until I found a well documented hostapd.conf)

Thanks for the link.

This is the hostapd.conf file I was reading.

github.com

xradvanyip/hostapd-openwrt/blob/master/hostapd/hostapd.conf

##### hostapd configuration file ##############################################
# Empty lines and lines starting with # are ignored

# AP netdevice name (without 'ap' postfix, i.e., wlan0 uses wlan0ap for
# management frames with the Host AP driver); wlan0 with many nl80211 drivers
interface=wlan0

# In case of atheros and nl80211 driver interfaces, an additional
# configuration parameter, bridge, may be used to notify hostapd if the
# interface is included in a bridge. This parameter is not used with Host AP
# driver. If the bridge parameter is not set, the drivers will automatically
# figure out the bridge interface (assuming sysfs is enabled and mounted to
# /sys) and this parameter may not be needed.
#
# For nl80211, this parameter can be used to request the AP interface to be
# added to the bridge automatically (brctl may refuse to do this before hostapd
# has been started to change the interface mode). If needed, the bridge
# interface is also created.
#bridge=br0

This file has been truncated. show original

The dhcp stuff is broadcast stuff and I was noticing deauths and then double dhcp in the logs on several nodes. (I have 10+ wifi nodes so its also quite a busy wifi internal network)

I can say from after a couple of days since doing the strict-rekey and the periodic rekey that I am no longer getting massive amounts of deauths (I do think I am in certainly a likely wardriving spot, next to a main road, a very busy wifi area, and I suspect someone quite possibly has kali linux or similar installed in an in-range place.)

My theory about the rekeying is that if it does not change for 24 hours until the gmk rekeys (the state it was in) then there may be some replay attacks opened up. If the attacker knows there is some particular data in a packet (i.e. they are in audio range, which includes parabolic mic type things) and the gtk is near-constant then there is only one key to defeat in decrypting the packet.

with the gtk changing that is made more difficult for an attacker, and an auto gtk-rekey after a deauth should add an extra complication to them.

I did also set wifi isolation on as I figured better to reduce another weakness which is one node on the wifi that was contacted by other wifi nodes, so I put that function on the wired lan, which is isolated from the wifi and needs a firewall rule.

I think it is possibly a weakness that the config files are not fully documented and "set in stone", as what it does is add a layer of uncertainty in each layer upline, uci, then luci as to what a function in either of them actually sets in the config files.

How no gtk rekeying crept in seems to me perhaps some assumption problem, like perhaps assuming hostapd assumes a default. ? Or assuming a hack attack will be the exception rather than the rule?.

lleachii · March 26, 2022, 12:53pm

Unless I'm mistaken:

they would still need a pairwise to have received it (i.e. they were authorized devices on the BSSID); but I understand your point - and you'd have a bigger issue that simply changing your pairwise PSK would fix
the sending client is no longer associated and the AP shouldn't accept it (if there's sanity checking at this point)
only the AP transmits to all clients on behalf of the received broadcast message from the sending client, so [if there's some sanity checking] the group key would not work unless they also spoofed your BSSID to replay (that might cause you other observable issues)

I don't know...I'm really shocked, actually, I'm glad I set a value...

screen360

But...I don't see a log entries...I assume that's because I need x >= 1 machines on the AP for 24+ hours?

In any case...

@hnyman @jow

I think @pwr has found a nice little bug here...

pwr · March 26, 2022, 1:43pm

It does actually rekey once a day anyway, when the group master key rekeys, which does actually seem to be set at 86400 seconds.

I just happen to be under attack I reckon, so using the powers of remote-logging and google (lol) I may have sussed the nature of it.

(still, got to be thankful for the raspberry pi, 10-15 watts for an always on machine with a hard disk, nice!)