Why HTTP without encryption and self-signed sertificates are OK
sininenankka.dy.fi
sininenankka.dy.fi
Encrypting as much of your traffic (DNS included) is only sensible unless you wish more of your data to be mined and sold.
How much of the encrypted web would cease to function and when? We'd still have their certs in our browsers, but no one would be able to get a new cert. Many would revert back to unencrypted because they don't want to pay for a cert.
It's an interesting thought exercise. I'm all for the encrypted web, but I would like to see the eggs spread across more baskets.
[0] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
Phone app traffic that isn't through a browser would be in a rougher situation, but it would be solveable by your major phone app store providers offering their own root certificates. Since there is only Google and Android, any app provider wanting to target all smartphone users would have to get a cert from one of them, and it would probably be rolled into any developer fees and sold as part of a larger security program.
That's exactly what I would like to see happening. The current warnings make no sense and they only make security worse.
Browsers are not different from any other applications at this.
Not only is your ISP the MitM (sometimes malicious), what happens between them and the service cannot be trusted at all. Or as NSA put it "ssl added and removed here".
Basically... he's arguing for something more akin to old school email pgp, where you need to have pre-shared details about the other side, and verify them yourself.
Personally - I think that's a non-starter for almost everyone, and is particularly useless for a browser where the details of the cert aren't known until you make a request and establish a tls connection to the other side. None of them support "Pausing" at that point to let you inspect the cert. So how are you possibly supposed to do the verification as a user? (assuming you can even be bothered, which is the whole problem with pgp in email in the first place)
If you want to use my systems, and want to ensure the certs are correct, you need to get and install a root cert from me personally.
> When connecting to the internet required calling the ISP with a modem, it was possible to encrypt the whole call
Assuming this is talking about MPPE for PPP, it's completely broken[1].
> if the server also has (and it probably will have) a trusted connection to the public internet and the route of the packages between the server and the user's ISP is known.
Trustworthy connections to the public internet don't really exist. Routes can be changed via BGP hijacks at any time[2].
> Often the route of the packages is also completely known (for example in intranets)
Intranets are almost always vulnerable to MitM via ARP spoofing[3].
> Are we encrypting a wrong protocol?
This point argues that it is wasteful to wrap end-to-end encrypted messages with HTTPS/TLS. Given how regularly people botch implementing things like that, HTTPS/TLS provides a useful safety net - and the overhead is negligible.
> there is nothing wrong with self-signed certificates as long as the browser actually shows the relevant information (the public key etc.) so that the user can make sure that the other end of the connection really is what it claims to be.
The vast majority of users cannot do the "making sure" bit suggested here. Of those who can, the vast majority (including myself here) don't.
> Allow using the site with retro hardware.
This can be solved with a proxy.
> some [...] cannot afford a newer, more modern device. Continually imposing new technical requirements for accessing the site may be discriminating against these people.
I expect that the vast majority of devices less than 10 (even 15) years old can run software which can handle modern protocols just fine.
> Let the user decide. [...] Web browsers, and in many cases also servers, should respect the user's choice.
The vast majority of users are incapable of meaningfully consenting to unencrypted connections.
1. https://www.computerworld.com/article/2505117/tools-released...
2. https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha...
2: So clearly in this case the route wasn't trusted. The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed.
3: Intranets are vulnerable only if there is untrusted devices in the network.
As I wrote, encryption is a good thing and improves security when used correctly, but all software must respect the user's choices. Nothing can fix stupidity and ignorance.
Designing for a perfect user is going to end up in sadness. Users will make mistakes regardless of how experienced they are.
> Intranets are vulnerable only if there is untrusted devices in the network.
In practice that's "always" given large enough networks.
Which? As I said, I assumed you were talking about MPPE.
> So clearly in this case the route wasn't trusted.
Then trusted routes don't exist.
> Intranets are vulnerable only if there is untrusted devices in the network.
I don't think I would ever be willing to assert an intranet is free of untrusted devices.
> software must respect the user's choices
Software performing security functions generally should not give users (or even developers) choices where they are unlikely to understand the potential consequences. If someone can supply a "--insecure-tell-fvey-my-kinks" command line argument, fine, but otherwise no.
Any choice a user can freely make is one that they can be manipulated into making. Failing to protect them accordingly because of "stupidity and ignorance" is effectively social darwinism.
Please consider that most people don't have your level of technical sophistication, nor is it reasonable to expect them to.
When designing anything that's going to be used by the general public on the Internet, you have to keep in mind that's the entire public, including grandma and grandpa that don't even realize that their Facebook app is not Google and post their search queries as status updates.
For fuck's sake, we can't even get professional office workers to not fall for painfully obvious phishing campaigns, and now you want to try to teach them how to recognize a bad SSL certificate?
You're not living in reality.
This isn't reasonable or ethical - and it's telling you didn't respond to my other comment replying to you.
If someone experiences harm due to use of unencrypted HTTP because they didn't understand the implications of it, they're not going to be able to make a causal association. Without the causal association, there is no opportunity to learn.
The way to "preserve freedoms" in these sorts of situations is to require a "warranty voiding" action.
Crucially, the browser is showing you historical information. This was the certificate for a transaction which already happened. Because this is about the past not the future you can't make decisions here, only have regrets.
Whereas for certificate name verification and all the other stuff your browser does, that is done by the browser in real time during the connection setup.
When you type the destination bank account, and amount to send, into a bank's "send money" form, and then decide to "check the certificate" the browser is not showing you a certificate for the HTTPS transaction you're about to perform, it can't. It's showing you the certificate associated with the form page, when you click "Submit" or "Send" or whatever, there may be a totally different certificate for the HTTP POST operation, it may result in a 30x redirect, which can result in yet another different certificate, you aren't shown these certificates before your form data is sent, the browser does all its checks because they're instant, but your dithering would be too slow.
You just need to click on the "Not Secure" warning that's where the lock symbol would be, then on "Certificate is not valid".
Only if your retro hardware understands some form of SSL/TLS (ie https:// scheme), otherwise you need to rewrite all https:// requests to http:// inline.
And (don't quote me on this though) more and more proxy software drops the old SSL/TLS protocol versions and ciphers.
One more thing which is usually overlooked, is what TLS (or any other encryption for that matter) indirectly helps with payload corruption in transit: unencrypted packet would be just silently corrupted and most of the time you would never even know it happened, a corrupted encrypted packet couldn't be unencrypted. Most of the time you can't do anything with it anyway, but at least it breaks the connection (or starts to slow down for the retries) so you know what something is wrong.
In the case of retro computing especially, specially compiled software supporting legacy versions of SSL/TLS is reasonable.
https://blog.chromium.org/2021/03/a-safer-default-for-naviga...
So is this suggesting that browsers should automatically trust all certificates? The Kazakh government sure would like that to happen.
First off, this grossly misunderstands what a certificate does. All it does is prove that your browser is having a private conversation with the remote server. The remote server might be evil, but that's not what a certificate solves.
Malicious sites didn't have valid certs because certs used to be overpriced and the people that ran them wanted to minimize the paper trail as much as possible.
> Self-signed certificates used to be considered fine, but now every mainstream browser shows a scary warning before entering a site with such certificate. The same will happen to the certificates from Let's Encrypt
You're jumping to quite the conclusion.
Let's Encrypt is such a huge part of the Internet now that I don't think browser vendors could decide to just stop trusting their certs. Even if they did, another free certificate vendor would appear and we'd be back at square one.
> Phishing websites also did not have lookalike domains before unicode characters were allowed in domain names.
Factually incorrect.
I have to be honest, this feels like a troll post. There's so much misinformation, misunderstanding, and unrealistic expectations that I can't take it seriously. What you're asking for is dangerous and would lead to massive amounts of data compromise.
> Let's Encrypt is such a huge part of the Internet now that I don't think browser vendors could decide to just stop trusting their certs. Even if they did, another free certificate vendor would appear and we'd be back at square one.
I wonder how come every large provider out there doesn't have their own free certificates in an attempt to compete with Let's Encrypt, get a piece of the free cert market share and possibly upsell their premium services in the process?
The only viable alternative to Let's Encrypt that I personally know of appears to be ZeroSSL: https://zerossl.com/
Though from what I can tell, they have a 3 free cert limitation, at least when provisioned through the website. Which actually seems like a decent attempt to encourage people to pay for their other products (and things like wildcard certificates).
Sure, many might just stick with Let's Encrypt, but why isn't every vendor out there doing the same thing?
https://en.wikipedia.org/wiki/Extended_Validation_Certificat...
A self-signed certificate can also be used to make sure that the connection is private. Sometimes the private key may have leaked and then the certificate can be "trusted" without being private - though it's easier to just register a lookalike domain and a certificate for it than have a leaked private key.
I was forced to use HTTP to see the page.