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: 5, Insightful) by Snotnose on Wednesday July 05 2023, @02:43AM (18 children)
It's my understanding the older ciphers are easily broken. So if you support them you're giving your users a false sense of security. IMHO, they'd be better off not using SSL at all, where they know they're vulnerable; as opposed to a cracked cipher, where they think they're safe.
Of course I'm against DEI. Donald, Eric, and Ivanka.
(Score: 4, Insightful) by Common Joe on Wednesday July 05 2023, @03:00AM (6 children)
I don't know about "better off not using SSL at all", but generally I'm with you on your statement. The modern web requires a modern client.
The "old fashioned" stuff I like (and I think what a majority like) isn't so much "old fashioned" as it is "simplicity". We're looking for a simple web experience -- unencumbered and not entshittified.
I think the people with the old technologies are trying to avoid websites that are overly engineered, but there comes a point when the programmer can't keep bending over backwards because then it becomes encumbering and entshittified for the the programmer. There's a give and take here with a happy middle. I think working towards the middle and keeping things very simple should be the goal.
That's my two cents, at least.
(Score: 2) by RS3 on Wednesday July 05 2023, @06:38AM (5 children)
Totally agree. I wish browsers (and all software) were more modular, like it would be great if browser SSL and TLS were done in a plugin, library, something replaceable rather than compiled into a great blob executable. I still like and use Old Opera much of the time, but it only goes up to TLS 1.2, so there are quite a few websites it won't connect with.
(Personal frustration: why does everyone demand https? If it's some kind of business, banking, email, login, etc., sure, but I'm just reading news or general information- it doesn't need to be encrypted, does it?)
(Score: 4, Informative) by mth on Wednesday July 05 2023, @11:18AM (4 children)
Even if the information is public, using HTTPS is still useful because it prevents the content from being tampered with. With plain HTTP for example a greedy ISP could insert ads into sites or a malicious WiFi access point could insert misinformation or exploits into the requested data.
(Score: 1) by Runaway1956 on Wednesday July 05 2023, @01:43PM (1 child)
Additionally, if an attacker can intercept and decipher some of your traffic, said attacker can gain insights and data that might enable him to capture the rest of your data. Every nougat of intel on the target makes the target easier to defeat.
“I have become friends with many school shooters” - Tampon Tim Walz
(Score: 2) by RS3 on Wednesday July 05 2023, @02:21PM
Well, with http, no "s", no deciphering needed- we're handing it to them. Again, seems like wiretapping to me.
(Score: 2) by RS3 on Wednesday July 05 2023, @02:19PM
Yes, thanks. After I posted above I saw AC's comment about ISP (mostly ad) injection, and then I remember that had become a big problem many years ago. As I commented below, that injection seems like illegal wiretapping.
(Score: 3, Informative) by SomeGuy on Wednesday July 05 2023, @06:19PM
As someone who browsers with older browsers, I sometimes come across sites that attempt to load because they support older encryption. But then they crap out as they try to load thousands of advertising links. It the ADVERTISERS who want high levels of encryption.
A long time ago, there actually used to be ad blockers that would interceppt and alter HTTP traffic before it got to a browser. There are still malicious networks that try to insert advertising in to HTTP traffic (and they should be considered nothing less than that - absolutely malicious. Never something that should be put up with).
You know damn well if broken encryption was to become common enough, some even more corrupt than usual ISP would start inserting their own advertisements in place of existing ones.
(Score: 0) by Anonymous Coward on Wednesday July 05 2023, @05:02AM
It depends on the exact cipher suite. What would help is knowing what cipher suite names are missing or if it is just the lack of TLS 1.2 support. That would help telling apart issues with a suite like TLS_RSA_EXPORT_WITH_DES40_CBC_SHA or TLS_RSA_WITH_3DES_EDE_CBC_SHA or TLS_RSA_WITH_RC4_128_SHA because that would drastically affect my answer. A report from the SSL labs client test from the affected user(s) would go a long way in answering whether or not adding suport is giving someone a false sense of security or not.
(Score: 5, Insightful) by janrinok on Wednesday July 05 2023, @06:05AM (3 children)
I agree with much of your comment. The problem is that there are some in our community who were simply cut off from accessing our site last November. We have now lost them. I have no way of contacting them to tell them that they can now reconnect. For the last 7-8 months they have been unable to do so. How long would you go on trying to reconnect in the hope that somebody would realise your plight and correct things? I do not want to arbitrarily cut off community members when we can still allow them to remain with us.
The encryption might not be the most secure, but kolie has said that there are ways we can protect the site while still allowing those who rely on earlier encryption to join in discussions. They might remain vulnerable but our site will not. Therefore it was not a case of SN being unable to support the software, but actually not being prepared to do so. We stated when we started that we would create a simple system that did not rely on later software developments that we simply do not require. We are now setting the bar a little higher but not, as far as I can see, for any good reason.
Should we now also insist on ecmascript being enabled? Will future displays depend upon Bootstrap or some other technology which needs ecmascript? Are we moving to a site that requires a modern, high resolution, device?
There are some who cannot update their 'phones, cannot simply upgrade their computers, and cannot simply do the things that you and I have taken for granted for a long time. They still have to use a specific version of Windows because that it all that the teaching material they use in their school will work with. They have a single 'phone (provided by charity) that provides a connection to the internet for multiple households. One teacher using such a network was a member of our community. He has now gone. Others also reported the problem so he was not the only one.
There are several points that I would like to make:
How about we first fix the bugs that the community are complaining about and discuss the changes that they are asking for?
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 1) by Runaway1956 on Wednesday July 05 2023, @01:53PM (2 children)
Quite honestly, I can and will make a determined effort, after a time. There is a site I frequently visit, which does go down from time to time. Downtime is usually over the weekend, and generally lasts until mid-day Monday. It recently went down, to all appearances, but I didn't worry about it. On Monday, it hadn't come up. On Tuesday, it wasn't back. On Wednesday, I checked one of those "Is the site down" pages, to find that the site was up, and healthy. So, I started digging, only to learn that the site was blocking my VPN due to abuse from the VPN. I switched VPN servers, and immediately connected.
So, the answer to your question is, "Depends on how badly a person wants to fix the problem." If he doesn't really care, he'll make no effort. If he really cares, he'll put in a lot of effort.
In other words, you probably didn't lose anyone who cared very much.
“I have become friends with many school shooters” - Tampon Tim Walz
(Score: 4, Informative) by janrinok on Wednesday July 05 2023, @03:28PM (1 child)
You are missing the point I think. It was 7 months before the problem was fixed, not a weekend. There is little he can do to fix anything. He is not behind a VPN, he isn't using any clever software. He is in Africa. Life is quite different there for many people.
He actually cared very much.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 2) by ElizabethGreene on Thursday July 06 2023, @01:54AM
If your hypothetical African needs a modern TLS capable browser, I believe the MyPal browser supports TLS1.2 and works as far back as XP. I don't have an alternative solution for non-windows devices though.
Opening a page like e.g. cnn.com hoovers across almost 10mb of content even with ublock origin; Can an older PC or phone (Circa 2005?) handle that or do they run out of RAM?
(Score: -1, Offtopic) by Anonymous Coward on Wednesday July 05 2023, @07:01AM
Older Soylentils are easily broken, and so many are really, really old. Exampla Gratia, Runaway. Too old to know to not put his geographical location in his posts.
(Score: 3, Interesting) by driverless on Wednesday July 05 2023, @12:43PM (4 children)
They're not easily broken, they're broken with a large amount of effort (excluding the toy export ciphers from 25+ years ago, which have been disabled by default for forever). And when someone does go to that large amount of effort, they get to see that someone's reading this post, which they can also do with basic traffic analysis no matter what encryption you use.
In other words for any real-world scenario, having this site disable older ciphers is not protecting anyone from anything.
(Score: 0) by Anonymous Coward on Wednesday July 05 2023, @10:33PM (3 children)
That's not entirely accurate. There are exploits for a number of retired ciphers. RC4, for example, is so absolutely broken that an adversary in the middle can crack TLS traffic on a Raspberry Pi in less than an hour. And there is more at risk than just seeing what articles someone is reading. You share much more information with SN than that, especially if you have an account or post.
(Score: 2) by ElizabethGreene on Thursday July 06 2023, @01:57AM
The attacker could, hypothetically, capture your login sequence and steal credentials or steal your cookie and pretend to be you.
I assume the login/auth cookie can't be trivially reversed to yield e.g. a user password, but I have seen that on other sites. :)
(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.