Why HTTP without encryption and self-signed sertificates are OK
sininenankka.dy.fi
Why HTTP without encryption and self-signed sertificates are OK
1–10 of 48 posts
Re: Why HTTP without encryption and self-signed sertificates are OK
#2No post body was provided.
Re: Why HTTP without encryption and self-signed sertificates are OK
#3My comments:
> 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...
Re: Why HTTP without encryption and self-signed sertificates are OK
#4Imagine Let's Encrypt disappeared tomorrow. Not an outage, but just up and vanished from the face of the earth. Maybe they get raided by the FBI. Maybe all of their engineers suddenly die. Whatever, it's gone.
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.
Re: Why HTTP without encryption and self-signed sertificates are OK
#5Imagine Let's Encrypt disappeared tomorrow. Not an outage, but just up and vanished from the face of the earth. Maybe they get raided by the FBI. Maybe all of their engineers suddenly die. Whatever, it's gone. 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…
There exist other free ACME providers, let's encrypt was just the first and biggest
Re: Why HTTP without encryption and self-signed sertificates are OK
#6Imagine Let's Encrypt disappeared tomorrow. Not an outage, but just up and vanished from the face of the earth. Maybe they get raided by the FBI. Maybe all of their engineers suddenly die. Whatever, it's gone. 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…
ZeroSSL and Google both have free ACME CAs, tho Google needs a special step the first time iirc.
Re: Why HTTP without encryption and self-signed sertificates are OK
#7Imagine Let's Encrypt disappeared tomorrow. Not an outage, but just up and vanished from the face of the earth. Maybe they get raided by the FBI. Maybe all of their engineers suddenly die. Whatever, it's gone. 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…
There's a Web3 project called Dane. Which seeks to add CAs to the blockchain. I suppose if successful, you wouldn't need to trust a company but instead a blockchain. But with all the web3 hate these days, it probably won't see the light of day.
Re: Why HTTP without encryption and self-signed sertificates are OK
#8My comments: > 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 interne…
1: You can always use a stronger encryption. You don't have to use decades-old encryption that has already been compromised.
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.
Re: Why HTTP without encryption and self-signed sertificates are OK
#9My comments: > 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 interne…
> 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.
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.
Re: Why HTTP without encryption and self-signed sertificates are OK
#10My comments: > 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 interne…
> This can be solved with a proxy.
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.