SoylentNews is people
SoylentNews
So, I know its been a bit quiet here, but we're working through getting through the last few items relating to cutting over to newer infrastructure. As such, its been working through the bug list, and there's one issue I want to get some feedback on.
Back in November when the infrastructure was upgraded to Ubuntu 22.04, a few users with older devices stopped being able to connect to SoylentNews. This confused me, since we've been using the same NGINX SSL termination setup that has been in use since at least 2016. Well, I finally found the root cause, and as it turns out, Canonical bumped up the minimum OpenSSL security level, which disabled several ciphers, and broke devices not supporting TLS 1.2 or later.
By testing the site with the SSL Labs site checker, it appears anything older than Android 4.0, or iOS 5 is broken. This mostly seems to be devices that are over a decade old at this point, and won't be able to browse the vast majority of sites on the Internet as is. We discussed this internally a bit, and I'm of the opinion that its not worth re-enabling the older ciphers to allow these devices to reconnect, especially since we're working to modernize the stack, and get it as up to date as we can get it. I also believe we had very few users who were actually affected by this, however, as the editors did get a few emails about SN breaking after the site upgrade, I wanted to poll the community, and make sure this is not a more widespread issue than initially believed.
Ultimately, this is going to be part of a broader discussion on what we will and won't support on SoylentNews going forward, and this seems as good of place as any to get the ball rolling.
~ NCommander
(Score: 2) by driverless on Thursday July 06 2023, @12:35PM (1 child)
Given the reference to 1 hour I assume you mean NOMORE, that's for TKIP, not TLS. The time for TLS is quite a bit longer, and it's a specialised technique that allows recovery of fixed values re-sent hundreds of billions of times at fixed locations, namely cookies. Even if you're the most OCD person on earth you're not going to reconnect to SN with your password a hundred billion times in a row. The remaining attacks all take advantage of weaknesses in the first lot of bytes output from RC4 and typically need a lot of retries to get the right conditions, so as long as your password isn't right at the start of the message and you're really unlucky at the same time it should be OK.
Even beyond that, to MITM the traffic you're going to need (outside of a few pathological cases like someone getting net access by stealing their neighbour's WiFi with the neighbour acting as the MITM) something like an ISP- or state-level attacker, who's going to have to spend a considerable amount of resources, to get... your SN password, with which they can post ASCII cat pictures and mess up your feed if they so desire. Why would anyone do that?
Finally, if you're really worried about this all you need to do is disable RC4, which most things do anyway. Older clients can still connect just fine, they just won't use RC4 any more.
Point is, you can still use TLS 1.0 and 1.1 with SN without anything bad happening. Heck, you can probably use no encryption at all without anything bad happening.
(Score: 0) by Anonymous Coward on Friday July 07 2023, @02:33AM
NOMORE was for TKIP and TLS and increasing the number of requests reduces the difficulty but is not a hard requirement. But things haven't stood still in the intervening years. Research still continued on RC varients and attacks. Plus the computing power has increased in the mean time.
And they have more than just your password. They have access to an account linked to a particular person. That opens the door to all sorts of techniques they can use to do much worse than just post cat pictures.
RC4 is just one example. There are plenty of other vulnerabilities in a number of cipher suites and TLS 1.0/1.1. There are ways to mitigate many, but not all, of them. But if your client is old enough not to support TLS 1.2 at all, then it is likely to also not mitigate them. And a larger problem is that leaving them enabled can put other users at risk thanks to various attacks on the protocols. Sure, the risk using them on SN is probably low (but not zero). But that really isn't the point. The point was that these ciphers are broken, many with relatively trivial effort, especially from those most important to protect against.