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

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

I think it's enough if the ready made images cover like 99% of the use cases and therefor don't include known vulnerable ciphers.

A lot of my network gear (all capable of WPA2 :wink: ) is "stuck" on openwrt 19.07 which is EOL since april. At the moment everything is still fine but if a security issue is discovered in the future this devices might end up as landfill :put_litter_in_its_place:

Correct. Could use a unencrypted wifi if wanted.

Except you made these 99% completely up. You have no idea about use-cases and their likelihood, and nor do I.

Yes, that is sad. However I assume that the issue is likely either:
a) lack of RAM
b) lack of storage
c) lack of developer time

All IMHO bigger issues than the perception of less secure encryption methods over WiFi...

Yepp, sad as I said. However I do not see that dropping TKIP will recover enough space to keep your hardware supported much longer. And the point here is that the problem is not necessarily to obsolete your router/AP but all the end devices that might require WEP or TKIP.

Or TKIP, which as it seems is going to be available into the future... I guess we will not agree on this, which is fine. I will however try to bow out of this thread to avoid endless repetitions.

It's probably more :stuck_out_tongue_winking_eye:. I assumed this number based on some facts:

  • WEP was standardized in 1999
  • WPA was standardized in 2003
  • WPA2 was standardized in 2004
  • My calendar dates to the year 2022 at this very moment

Other than WEP (which was around for about 4 years) and doesn't necessary allowed a software upgrade path it was different for WPA (which was only around for a year) because that typically allowed a software only upgrade path to support WPA2.

Solely because of this timeline one could already assume that there are more (20 year old) "WEP only" devices out there than a "WPA only" device (which actually still lacks proof to really exist in the wild :joy:)

I also did some little research in the openwrt forum how many people need/miss WEP. Because time is limited I only searched for posts/topics from this year that contain WEP.

In the end it looks to me that there was exactly one (in numbers: :one:) user in this forum that "missed" WEP:

On the other hand while browsing thru the topics and posts some user probably used some vulnerable cipher without knowing (that can only happen if obsolete ciphers are shipped :warning:) and were happy when other forum member suggested WPA2 or WPA3 to them.

I would call this a good example why not to include vulnerable ciphers by default :bulb:

That's interesting and just remembered that when looking at this code/config here:

So couldn't it be an improvement when having a package called something like vulnerables-ciphers which contain RC4 and TKIP so they can be added by the users who needs them in a :one:-click-fashion?

On the other hand this will greatly improve the status-quo as it doesn't allow a random user to accidentally create a vulnerable wifi network :signal_strength:

Not sure if this is the exact reason but if openwrt is using the "mainline" hostap version it might be because it is already removed from the "default" builds in version 2.10

ChangeLog for hostapd

2022-01-16 - v2.10

  • removed WEP support from the default build (CONFIG_WEP=y can be used
    to enable it, if really needed)

It also looks like initial "support" for getting rid of TKIP is already present :tada:

  • added a build option to remove TKIP support (CONFIG_NO_TKIP=y)

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.