Why does OpenWrt still include the vulnerable RC4 encryption algorithm (TKIP cipher)?

I totally missed the discussion "dumping" 4/32 devices actually. Some ideas were raised like having a "tiny" flavor or something to still have at least basic/limited support (for example as a WDS repeater) but somewhat it just ended that there are no(?) security updates anymore (End-of-life "was" projected to March 2022.) for a new device I bought 5 years ago and which supported WPA2 out of the :package:.

Not sure why it needs a discussion to get rid of a vulnerable cipher suite that is 35 years old and shouldn't be used by any one.

https://c.tenor.com/GXgi36aVH3gAAAAd/confused-meme-confused.gif

However valid your point is, its always better to get other peoples opinions about it. A lot of times it enlightens.

1 Like

If you feel so strongly about this agenda, can i suggest you write a patch to remove the functionality, fling it at the mailing list, and i'm sure that will garner further discussion.

1 Like

You can suggest that obviously. But as it looks like there is more discussion needed (and I don't have the skills anyways) so I don't think it's a good time to do this already.

Maybe just put this thread on re-submission for 2025 and see if we get some enlightenment till then :+1:

1 Like

Or you could use the time to acquire the skills, apparently that is a topic close to your heart. :wink:

2 Likes

This is what I thought but I resisted to write that till the day the the collective have mercy to dumb this (since 10 years obsolete) cipher I might be even able to deliver the code for removal :joy:

While TKIP was intended to be at least relatively more secured than WEP, the standard has since been deprecated in the 2012 revision of Wi-Fi 802.11 after it was found to have glaring security loopholes that can be exploited by hackers without too much of a problem. That’s because TKIP uses the same underlying mechanism as WEP, and is hence, equally vulnerable to attacks.
https://beebom.com/tkip-vs-aes/

Another fun fact: The openwrt wiki actually mentions that WPA (defaults?) are not secure :point_down:

image
https://openwrt.org/docs/guide-user/network/wifi/encryption

On the other hand most people probably will not bother to look into the wiki and trust the openwrt web ui which still states it is secure::

image

...but hopefully not much longer

Sorry for the rude message...

It was asked to AT LEAST write an email to the mailing list.
And still we are here flaming about this....

I will make a PR on Luci to change that to not secure. Again here it's user fault for using unsecure stuff... It's really like saying don't write your admin pass in the router what should we do? Enforce private key login?

1 Like

Don't spotted anything rude :wink:

Well, I have no idea how this mailing list stuff works nor how to register for it or something. It might be easier if this is addressed by someone who is already active (maybe even a dev?) and knows how that stuff works, can be something like:

"A forum user posted this threa [link] and pointed out if the vulnerable TKIP stuff can be removed. It is deprecated since 2012. What do other people on the mailing list think?"

For now I only saw one user flaming around (but not yet in this thread actually) :thinking:

:+1:

With that "idea" why does openwrt now ships with https by default? Why did openwrt got rid of wep? Why does openwrt has a strength check for the router password?

Because it is always desired to have it secure as possible (while at the same time easy as possible) by default (imho that includes to do don't even ship broken ciphers and also have a strength check for the wifi key).

That probably raises complexity for the average user (doesn't keep the principle "easy as possible"). But activating https by default and check the router password for strength at least raised the minimum standard :bulb:

Also I wonder what "discussions" took place that the collective could agree letting wep rest once and for all. Maybe some one got a link? Did found much discussion in the forum about that...

Pls leave comments there if you want to improve this.

4 Likes

Actually I found it now, it's archives are available here by the looks of it: https://lists.openwrt.org/pipermail

Out of curiosity I searched it for the term WEP to see what discussion was necessary that everybody could agree on to don't ship it anymore by default.

Turns out there wasn't anything one could call a discussion to be found - the closest related thing was this here:

[OpenWrt-Devel] [PATCH 2/2] hostapd: disable support for Wired Equivalent Privacy by default

...
disabled as default, because WEP should not be used for anything anymore.
...
https://lists.openwrt.org/pipermail/openwrt-devel/2020-May/028960.html

The same "should not be used for anything anymore" is true for TKIP.

That (sadly) wasn't successful :frowning:

Looking at the newest RC6 things are now really messed up:

image

While WPA-PSK is now titled as weak the mixed mode WPA-PSK/WPA2-PSK (same obsolete TKIP cipher) is "still" marked as medium security :woozy_face:

I'm still somewhat baffled that there is no obvious interest to just let this obsolete encryption/cipher combo rest in peace like the good old WEP :put_litter_in_its_place:

The way I understand that is, WPA-PSK/WPA2-PSK will be as problematic as WPA-PSK for devices that will only connect via WPA, but more modern WPA2 devices will use CCMP/AES, so this is arguably a safer option, as if all stations support WPA2 TKIP will essentially not be used anymore...

Personally, I am sitting on the fence here, for one having shitty encryption in the field is bad, but on the other hand relaying on WiFi encryption as the only/main source of security for local traffic seems like a fools errand as well (on a suspicius link, like any internet path, we routinely use better encryption if security is of value, the same approach can be used over insecure WiFi links).

I understand the two sides of the "medal" but shouldn't openwrt then be consequently ship all the shitty ciphers and include WEP again? Why was that purged out of the official images at all then?

That's another PITA for sure:

image

:person_facepalming:

Anyways till today nobody here discovered not one (:one:) device which is only able to communicate via WPA (TKIP) but not WPA2 (CCMP-AES) btw..... (I don't count that device I linked from 1998 as it was said a software update made it ready for WPA2 despite that device is EOL anyways...)

You probably need to ask whoever removed that... if you want to know. IMHO security is always a continuum and always at odds with convenience. If a cypher gets removed and no one hollers however it seems clear that jettisoning it was OK, the catch is you only know after the fact...

Why? As they say, unix gives you enough rope to shoot yourself in the foot. As far as I can tell tha is not the default, no?

Well, your problem, as I see it, is that you would need to prove that this apparent failure to present such an example is due there not being any such devices and not just because those folks affected did not participate in the thread, if you want to make a point out of this. But a "negative" is hard to prove.

Maybe re-phrase your whole approach into something ala:

Since TKIP can hardly be considered secure anymore and we can't really check whether it is required on some devices in our user-base a priori, let's try to disable it in an rc or test version to see how many complaints come in, if that number is zero maybe it can be disabled for good...

I wrote the author (@ynezz) who delivered the code for the wep removal already but didn't got an anwser

I owned a device which was only able to communicate with WEP but retired it in favor to don't have a vulnerable network long ago openwrt removed WEP out of the official images.

If you do a short forum search you will find out that a few people still want WEP and they essentially help themself by compiling images with added WEP support.

Because

I don’t know what the past rationale was for dropping WEP (I disagreed) but I do know that it promptly triggered complaints from users who were unable to setup a WEP enabled guest network for their PSP handhelds anymore.

As a consequence, people will stick to old, discontinued versions that still support their use cases which arguably is worse in the grand scheme of things than offering a current version with secure defaults that still offers legacy features for those people who need them.

4 Likes

Any particular reason they stick to a old firmware and don't upgrade their PSP?

The PSP originally only supported WEP encryption. The official 2.00 firmware upgrade added support for WPA-TKIP. Later on, firmware 2.50 added WPA-PSK support.
https://psp-archive.github.io/apps/wpa2.html

Many of my openwrt hardware was just recently EOL'ed so I need to stick to a old discontinued version of openwrt now for them (still no interessed to use RC4/TKIP technology :wink: )

Is that? For me the default "encryption" is always a open network aka as "no encryption":

image

I think everybody could agree on that if these legacy features would be still consider "safe" to some extend. But as we talking RC4/TKIP here that is (sadly) not the case

I don‘t know what there reason was, just that forcibly removing wep broke their use case. It was also so thoroughly removed that it is not even possible to install another package flavor like hostapd-full to gain it back.

This is just unnecessary removal of features.

I would call it more a necessary housekeeping to discourage users making use of obsolete and insecure technologies.

Who knows - if that would have been done earlier maybe there would be still maintenance releases for "low end" devices possible today because of the "saved space".

+1; it is not that WiFi encryption should be trusted with anything too sensitive anyway (it is not that WPA2 did not have its own set of issues).

The problem with this approach, 'I know what is best for you' is that unless you really do know best and cover all eventualities, you might look somewhat stupid if you end up forcing users into retiring otherwise still operational hardware, even if that would not cause security issues.
E.g. I can for example use a wireguard link over a insecure WiFi channel and might hence not care all that much about the WiFi link's own encryption.

1 Like