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.
It's just a fact of life that people with brains the size of grapes have mouths the size of watermelons. -- Aunty Acid
(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.
(Score: 2) by Thexalon on Wednesday July 05 2023, @02:45AM
At some point, software becomes so old that we don't need to support it.
If it were, we'd need to support Mosaic, which we don't.
"Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
(Score: 3, Insightful) by erichill on Wednesday July 05 2023, @02:54AM
Supporting TLS only makes sense when it actually IS secure. Since those older ciphers are effectively insecure due to faster hardware available to crack them using newer algorithms, it only makes sense to deprecate them. For devices that are running really old hardware and software, accessing the site over an insecure HTTP makes sense as it really is insecure. Keep up the good security posture.
(Score: 5, Insightful) by bzipitidoo on Wednesday July 05 2023, @04:17AM (11 children)
One of the things about this drive to move everything to https is that not all traffic needs to be secure. Why can't http, without any automatic or manual user login, still be available as a fallback? A bank's website, yeah, max out the security. But a news site? A news site especially shouldn't need to securely transmit news articles that are meant for public viewing. What exactly is being guarded against? Certainly not unauthorized viewing! A man-in-the-middle altering the content of the articles on the fly? Please. Maybe tracking? Encryption doesn't stop tracking.
I laugh to myself whenever the browser shows the message that I have to enable DRM to view some video. I always say no to that, and silently thank them for blocking a video I most certainly didn't want to autoplay. I guess DRM has a few uses, LOL.
(Score: 5, Interesting) by Anonymous Coward on Wednesday July 05 2023, @04:49AM (8 children)
The drive to SSL is driven by google who didn't like the fact certain American ISPs replaced in-page google ads with their own ads. Encrypting everything makes that infeasible for the ISPs and google happy.
(Score: 4, Interesting) by RS3 on Wednesday July 05 2023, @06:43AM (4 children)
I don't know why your comment was marked "disagree", but after thinking about it I remember those "interstitial" ads! My ISP at the time didn't do that, but many did and I wondered if that behavior amounted to illegal wiretapping.
(Score: -1, Offtopic) by Anonymous Coward on Wednesday July 05 2023, @07:04AM
Obviously an aristarchus comment. Or, maybe not.
(Score: 0) by Anonymous Coward on Wednesday July 05 2023, @10:38PM (2 children)
It isn't illegal wiretapping. You often give them permission in the TOS or other agreement to do that, and there are exceptions in the law for indiscriminate monitoring and certain other activities, including those necessary to prevent abuse or ensure the proper functioning of the ISP itself.
(Score: 2) by RS3 on Thursday July 06 2023, @04:36PM (1 child)
If I give someone permission to shoot me, will they get away with it?
A contract, including a one-sided TOS, can not usurp laws.
(Score: 0) by Anonymous Coward on Friday July 07 2023, @02:59AM
I stated that the laws have numerous exemptions. Giving them permission to do it is one of them. It is just like consensual homicide, where you can give someone permission to kill you and they "get away" with no consequences precisely because the law recognizes it.
(Score: 4, Interesting) by Anonymous Coward on Wednesday July 05 2023, @07:56AM (1 child)
I think the drive for TLS is because the ISP is an active threat for many around the world. Beyond changing ads on the page, they can change whatever else they want, snoop on whatever they want, sell your browsing habits, give it straight to police/intelligence agencies, MITM you at will, and do all sorts of other bad things. ISPs changing ads was just the obvious maneuver that revealed the true power of those between your client and your intended server that broke the camel's back.
(Score: 0) by Anonymous Coward on Wednesday July 05 2023, @08:09AM
I don't disagree with you, but it doesn't change the fact this was initially championed by google and google does not have anyone's well being in mind. It also gave them a handy excuse to deprioritize many informative legacy web sites (that did not bundle google ads) because they were plain HTML and served over plain HTTP.
(Score: 0) by Anonymous Coward on Wednesday July 05 2023, @08:44AM
Plenty of people wanted the move to https not just Google. MITM was/is an actual risk - people were getting pwned from MITM attacks.
But Google was big enough to start the snowball rolling. Before Google started doing it, the rest couldn't get much traction/adoption.
That said even https by itself is/was not enough to protect vs MITM attacks: https://www.schneier.com/blog/archives/2010/09/uae_man-in-the.html [schneier.com]
https://www.eff.org/deeplinks/2010/08/open-letter-verizon [eff.org]
So what you have to do is use Firefox or similar and disable untrusted CAs. You can't use Microsoft's stuff because Microsoft will auto-add CAs and certs that it trusts. You can't use Chrome on Windows because Chrome uses Microsoft's CA stuff on Windows.
(Score: 3, Insightful) by requerdanos on Wednesday July 05 2023, @03:40PM (1 child)
I came here to say this. It's possible to configure https without an auto-redirect (difficulty unknown to me) so that the user may choose between http and https, rendering the matter of what ciphers are available moot as far as the issue concerns mere access to the site. http covers *everyone* regardless of how old their device/operating system. That's what I would recommend, I guess. Plain http not for you? Use https.
(Score: 2) by RS3 on Thursday July 06 2023, @04:42PM
I'm not sure if this is in line with your post, but the webserver has to be configured for http and/or https. IE, it may only serve one or the other. It can serve both. But it's all in the configuration of the server- client has no say in what protocols are enabled.
(Score: 2) by Fnord666 on Wednesday July 05 2023, @04:38AM (1 child)
(Score: 1, Informative) by Anonymous Coward on Wednesday July 05 2023, @05:04AM
They use the Stripe API for that. There is no way this site would be able to keep their PCI-DSS compliance.
(Score: 4, Interesting) by invis on Wednesday July 05 2023, @05:57AM (3 children)
https://ssl-config.mozilla.org/#server=nginx&version=1.17.7&config=old&openssl=1.1.1k&guideline=5.7 [mozilla.org] (fiddle with versions as appropriate).
That covers everything that can reasonably be supported over HTTPS.
However, it doesn't help anyone doing a bit of retro-browsing - they need HTTP but SN redirects (307) to HTTPS.
I suggest adding SN to the preload list (https://hstspreload.org/?domain=soylentnews.org [hstspreload.org]) and disabling the redirect.
(Score: 1, Informative) by Anonymous Coward on Wednesday July 05 2023, @08:03AM (2 children)
HSTS preloading requires that the redirect be intact for both the Chromium and Mozilla lists.
(Score: 1) by invis on Friday July 07 2023, @03:23AM (1 child)
Quick testing on one of my domains suggests that the redirect isn't needed, but i don't have the time atm to do the testing needed to make a definitive statement.
(Score: 0) by Anonymous Coward on Friday July 07 2023, @08:46AM
It isn't a requirement of the RFC (SHOULD not MUST), but the lists themselves say they require it. From your link above:
Having a valid redirect is requirement #2 "Redirect from HTTP to HTTPS on the same host, if you are listening on port 80."
(Score: 0, Funny) by Anonymous Coward on Wednesday July 05 2023, @07:26AM (4 children)
Does NCommander realize that he has left this front page article open to the universe, to anonymous cowards, and any and all soylentils? I commend him for this, though janrinok is probably shitting rectangular clay objects, somewhere.
Welll, maybe not all.
(Score: 2) by janrinok on Wednesday July 05 2023, @07:44AM
I kept it open for discussion. Lets see how the ACs respond shall we?
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 3, Informative) by janrinok on Wednesday July 05 2023, @07:52AM (2 children)
This is something that the AC causes. There is no manual intervention from any staff.
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: -1, Offtopic) by Anonymous Coward on Wednesday July 05 2023, @08:05AM (1 child)
You did this, janrinok! You tried to block my IP! Tricksy wanker! But, I have many IPs, and I change them frequently, as I have to, due to your blocking. Would be easier if I could know what "bad posting" was. Just getting a downmod? Or special admin intervention? Help me out here, janrinok.
(Score: 3, Informative) by janrinok on Wednesday July 05 2023, @08:27AM
I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
(Score: 5, Informative) by Rich on Wednesday July 05 2023, @10:20AM (4 children)
- Plain http rather than insecure old https
- No (out of principle), or optional JavaScript. The principle is that mere display shouldn't require a Turing-complete client. Also, there are no pictures here, so the site should work in lynx/links - which also makes sure that accessibility is in good order.
(Score: 2) by gnuman on Wednesday July 05 2023, @02:44PM (3 children)
But HTML + CSS is Turing complete ... so ...
https://accodeing.com/blog/2015/css3-proven-to-be-turing-complete [accodeing.com]
What JS allows for is single page applications and 3rd party apps. It decouples data from the presentation.
(Score: 2) by Rich on Wednesday July 05 2023, @05:45PM (1 child)
Sigh. Yes.
I thought that was the purpose of CSS?
It's been a while since I dealt with that stuff, and I've especially steered clear of web based widget frameworks...
(Score: 1, Insightful) by Anonymous Coward on Wednesday July 05 2023, @10:48PM
One of the original ideas of HTML was to allow for the separation of content from presentation. Later, CSS was tacked on to allow for websites to describe presentation. JavaScript allows you to separate data from content through the use of tools like XHR or SSE. SPAs are just that idea taken to the extreme.
(Score: 0) by Anonymous Coward on Thursday July 06 2023, @10:30AM
I remember some years ago figuring out that Blogger templates were Turing complete. It seemed to be impossible to do the HTML I wanted, but I could totally compute a number that was equivalent to it.
(Score: 3, Interesting) by Mojibake Tengu on Wednesday July 05 2023, @11:50AM
With arrival of compulsory ciphers and forced usage of the https protocol, simply declaring ciphers outdated breaks old stuff. That was technically expectable. And probably intentional by control freaks out there.
What about possibility of SoylentNews served on http without login feature or even without anonymous posting? For some people or time to time, just reading may be enough, especially on pocket devices.
More, for those dependent on non-free devices, an official SoylentNews Application could be created, just like the banks or corps do. That would regain full control.
Disclaimer: I didn't make the Internets borked. You guys did. I don't even serve cookies on my own domains.
Rust programming language offends both my Intelligence and my Spirit.
(Score: 3, Interesting) by SomeGuy on Wednesday July 05 2023, @12:10PM
I figured you got forced in to changing the TLS requirements during that last update because, you know, somewhere someone else is all becausesecurityyoucantbetoosafethinkofthechildrenpollywannacracker Fortunatly the site still works in Retrozilla on Windows 95, which support TLS 1.2 as long as no virurtual hosts are used - which basically means this is still one of the few sites that it can load any more.
At this point, major sites are already breaking even in Windows XP based browsers, so I keep having to shuffle over to a shitty Windows 10 box (sigh, what is Microsoft going to break today on that thing?! Windows 10 and and 11 are not what I consider stable OSes) just to get a few things done.
- Posted from Microsoft Windows 95
(Score: 3, Interesting) by datapharmer on Wednesday July 05 2023, @12:41PM
I have mixed feelings, but this was done for a reason. The old ciphers are very insecure by modern standards. Anyone that filled out a survey and got an AWS credit can break them. We could say 'sure but you know you are on an old device and isn't that better than nothing?' but the real problem is downgrade attacks and someone using an up-to-date browser and thinking they are secure when they get downgraded to an insecure cipher. I'd rather it downgrade to http or point them to something like insecure.soylentnews.org instead of downgrading to an unsupported and insecure cipher. Frankly it isn't safe to be browsing the web with something that hasn't been patched in so long - more modern devices are literally given away by phone carriers.
(Score: 5, Interesting) by pkrasimirov on Wednesday July 05 2023, @01:15PM (1 child)
Sorry but these security arguments make no sense. Today's computer security is arms race, it is always only temporary and relative to who is the opposite side. If you expect secured content (as in no tampered web pages) from your ISP, then any cypher will do, no matter how old and broken. If you want no tracking from your ISP or big tech (Google, Apple etc.), HTTP(S) won't help. If you want no tracking from soylentnews.org, HTTP(S) won't help if soylentnews.org decides to track you.
If you want old crypto because you use an old device, that is valid argument. However you have to keep up-to-date the root certificates on your device and very much assume it is automatically hackable the instant it goes on the Internet, simply because of the many age-old found zero-day vulnerabilities. So while you still can use soylentnews.org, the expectations of security should be zero. Which in turn means you can very well use plain-text HTTP, it will even have the added benefit of better performance because no encryption/decryption will take place and plain-text content is usually cached while HTTPS is not by default (on old devices). It will also make content separation easier, as in no payments over plain HTTP, no login, no accounts creation.
Having said that, we should keep in mind we're talking an extremely limited number of users here compared to everyone else with normal (read: newer than 10 years) computer. It's okay to still serve them the content, if soylentnews.org desires so, however I'd recommend setting a specific sub-domain for the purpose, like http://insecure.soylentnews.org [soylentnews.org] or something while http://soylentnews.org [soylentnews.org] still redirects to https://soylentnews.org [soylentnews.org] as any normal website should do.
Additionally I recommend throwing out anything below TLS 1.3 and also reviewing what ciphers are actually allowed. Of course only if the effort is worth, after all other much more severe problems were made known of this site codebase, and maybe they should take priority.
(Score: 2) by sjames on Thursday July 06 2023, @12:49AM
It's worth asking secure against what? The only thing remotely private about posting to SN is your password which is only very occasionally transmitted.
Honestly, there's not that much value in getting someone's SN password as long as it hasn't been re-used elsewhere. It's probably not worth exposing that you have managed to get a foothold on someone's machine. It's certainly not worth a targeted effort.
That just leaves keeping crappy ISPs from injecting extra ads. But there, even crappy encryption is good enough. It serves the same legal purpose as a crappy padlock on a fence that can be jumped over, the ISP can't claim they didn't know their intrusion was unwelcome. If you really want to get revenge on such a crappy ISP, add a custom HJTTP header with a witty saying and then slap them with a DMCA violation.
(Score: 2) by Rich on Wednesday July 05 2023, @01:25PM (1 child)
Having logins over https is not a good idea, for anon posting it shouldn't make much of a difference. Annoyers can post over https anyway and afterwards, the post is readable in the clear.
Would it be a reasonable idea that users can get themselves a TAN (transaction number) sheet for logins from an https login to use those to login over http? They'd only have to use it when they want to post under a UID anyway. I don't think live spoofing would be much of a risk with this site's feature profile. It would require significant development effort, but might be considered once everything else is done. It'd probably best, though, to run a poll if anyone would use such a fringe feature before committing any effort...
(Score: 3, Touché) by gnuman on Wednesday July 05 2023, @02:35PM
HTTP is only good for reading, if you don't care if traffic is modified in the middle. With some ISPs inserting their stupid ads in middle of 3rd party websites; it's one of the main reasons that HTTPS-everywhere became the norm.
Write access over HTTP is always a bad idea since any session is basically in clear text.
(Score: 5, Interesting) by gnuman on Wednesday July 05 2023, @02:37PM (3 children)
So, I was in The Philippines the other month and soylentnews.org was blocked. The only way I was able to access it is via VPN. The moral of the story is, why are we worried about old TLS ciphers but are blocking IPs from whole nations because?
(Score: 2) by gnuman on Wednesday July 05 2023, @08:58PM (2 children)
Also, the blocking was done on the soylentnews.org side of things ;)
(Score: 2) by kolie on Thursday July 06 2023, @04:44PM (1 child)
I'm fairly certain no blocking of the sort is in place. Feel free to respond with more details.
(Score: 0) by Anonymous Coward on Saturday July 08 2023, @10:28PM
Multiple people, including myself, have complained about countries being blocked. In my experience, it seems to mostly affect SE Asia. My suspicion is that those "block lists" Janrinok has mentioned of unknown provenance blocks those places. That's not too surprising if you apply your expectations of 1st world RIR/LIR policies to 3rd world RIRs/LIRs.
(Score: 3, Interesting) by NotSanguine on Wednesday July 05 2023, @02:42PM (2 children)
But TLS1.3 [rfc-editor.org] is now five years old.
The computer I'm writing this comment on is eleven years old and runs an OS that was EOL'd more than three years ago.
Even so, my browser reports that this connection is encrypted with the aforementioned TLS1.3 (TLS_AES_256_GCM_SHA384, 256 bit keys).
So it's possible to run old hardware/software with TLS 1.3 (old phones can be an issue, and I ran into that issue myself and moved to more recent versions of Android via custom ROMs to address those issues -- as for old iOS devices, you're on your own and that's your fault for using Apple crap). [note: I guess that is a judgement, despite the comment's title. Oops.]
That said, it's understandable that those using old hardware/software would be annoyed that they cannot connect via TLS.
WRT Ubuntu, I assume that "normal" browser installs (via apt) will use the local shared TLS libraries, which may or may not (depending on revision) support TLS 1.1/1.2/1.3. In such cases, it may be useful to install your browser via Snap [ubuntu.com] packages which are fully self-contained (i.e., don't use system libraries) and presumably have the latest revs of various libraries.
I don't think we should restrict folks from accessing SN insecurely if they need/choose to do so. At the same time, TLS downgrade [wikipedia.org] attacks really are a thing which could compromise/reduce the security of TLS connections even for those with the latest gear/software.
Perhaps a reasonable solution (as was suggested elsewhere in this discussion) would be to have two ingress points for SN -- a modern TLS secured ingress (the default) and an unsecured (i.e., straight HTTP) ingress point.
It's not a perfect analogy, but something along the lines of www.reddit.com vs. old.reddit.com providing similar access with a different ingress point makes sense to me.
From a broader perspective, widespread encryption of traffic across the 'net is, on the whole, a very good thing. Is it absolutely necessary for many sites? Probably not. At the same time, requiring decent quality encryption reduces the ability of bad actors to compromise systems and connections.
I'd also note that Qualys [ssllabs.com] (IPv6 [ssllabs.com], although the IP version shouldn't matter) claims that Android/iOS versions using TLS1.2 (which is eleven years old at this point) are fully supported by https://soylentnews.org. [soylentnews.org.]
Again, it's not a perfect analogy, but we (the general "we") don't support the 'r' tools (rsh, rcp, etc.) or telnet any more either. Because they're insecure and no one complains about that do they?
I get that some folks are into "retro" computing, which is great. But I don't want to be subject to downgrade attacks and/or other issues because someone wants to use their 25 year-old OS to browse the web. I'm sure some will disagree, but that's my take.
I think supporting an eleven year-old TLS version goes far enough back to address this -- with unencrypted access available for those who want (need?) to connect via devices that don't support decade-old standards.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by gnuman on Wednesday July 05 2023, @06:39PM (1 child)
To be fair, Apple supports their OS far far longer than Android. Basically, 6 years and counting for new OS. Android? well, good luck with that.
https://support.apple.com/guide/iphone/supported-models-iphe3fa5df43/ios [apple.com]
(Score: 2) by NotSanguine on Wednesday July 05 2023, @10:24PM
A fair point. They certainly do. But once that six years is done, you're on your own. That's not true for Android devices.
Show me an Apple device old enough to be out of support (and you're stuck on whatever version of iOS was current when support ended) and I'll show you an Android device of the same vintage which while likely unsupported by the manufacturer much sooner, but there are *still* custom ROMs that work on those devices.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 4, Interesting) by SomeRandomGeek on Wednesday July 05 2023, @04:46PM
I have had to deal with a very similar problem for work. What I eventually realized was that while we were thinking about whether to end support for old ciphers, the other websites and even the browsers had already done it. I had trouble testing the old ciphers on my servers because I couldn't find a browser to test with that still supported the old ciphers. Ciphers do not last forever. Just turn off the old ones and move on.
(Score: 4, Insightful) by Freeman on Wednesday July 05 2023, @06:59PM
I don't know enough about the technical side of hosting a site to be able to offer much insight.
What I would like however is that the site be open to as many as possible. In the event that doing so, it means we don't support shiny X feature, that's fine by me. I'm sure it's more work to make the site more "backwards compatible" so to speak, but I think it would be worth the effort. Not everyone in the world is as fortunate as my spoiled self.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by ledow on Thursday July 06 2023, @11:44AM (1 child)
I'd rather you were getting A or A+ on SSL Labs than you bothered about devices too old to allow that.
That's what I do, personally and professionally, in a public-facing way for multiple services for thousands of users... nobody complains.
We used to get complaints about Safari - because Mac OS stops updating Safari when it goes out of support - all the time for this, but we just used to tell them that their computer simply wasn't capable of browsing modern websites and they'd say "Oh, yes, my bank, etc. keep saying that too" and eventually they buy a vaguely modern machine.
But Android 4.0 and iOS 5? They are not only "broken", but they deserve to be now.
Run an SSL Labs test every few months, keep it up to date. You'll probably never get a "perfect" (A+) score, but for sure you should be getting A's.
Hell, even where I'm forced to offer IIS services, I use "IIS Crypto" to turn off the old protocols and operate on its "Best Practice" settings, which effectively does the same... obsoletes all the old insecure crypto algorithms for SSL, RDP and RADIUS. Nobody cares.
(Score: 1, Interesting) by Anonymous Coward on Thursday July 06 2023, @12:20PM
Did that already [ssllabs.com]
And SN gets an A+
(Score: 1) by pTamok on Thursday July 06 2023, @03:04PM
A technical solution would be to proxy / MITM the site. Connect to the proxy using http or outdated ciphers, then get the proxy to access the site using acceptable ciphers. It's fine so long as people know that that is what is going on. I'm pretty certain you can do it with Squid.
Two options:
1) Be nice and provide a proxy for people to use.
2) Be not so nice and say people need to set up their own proxy to allow old operating systems and really old and low-cpu power devices to access SN. They might not have the resources or technical smarts to do it.
The benefit of this approach is that the main site can be completely up-to-date, and if managing the proxy, you can make sure it accesses only SN and not other places.
There's probably plenty of reasons why this is not a good idea.