Why HTTP without encryption and self-signed sertificates are OK(sininenankka.dy.fi)
sininenankka.dy.fi
Why HTTP without encryption and self-signed sertificates are OK
http://sininenankka.dy.fi/~sami/httpencryption.txt
47 comments
That's what privacy laws are for isn't it?
We don't need locks to protect our homes, that's what burglary laws are for.
Like there aren't any in the U.S.
Are there? I believe the ISPs are fighting tooth and nail against being classified "common carriers" and are winning in the name of "innovation" :)
Hah.
My favorite is cell providers replacing http advertising with their own.
Imagine 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.
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.
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.
That's funny because we already have DANE [0] for DNS-based certificates and that's precisely the right place for domain-validated certs. No blockchain needed.
[0] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
[0] https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
There exist other free ACME providers, let's encrypt was just the first and biggest
All browsers (even smartphones) support importing certificate files. The exception are Windows PCs on domain lockdown. Non-corporate-supported browsers might transition to being more friendly to this process instead of the unhelpful and scary SSL warnings provided now.
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.
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.
> Non-corporate-supported browsers might transition to being more friendly to this process instead of the unhelpful and scary SSL warnings provided now.
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.
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.
ZeroSSL and Google both have free ACME CAs, tho Google needs a special step the first time iirc.
The author claims that securing the link to your ISP removes the threat of MitM, then a few paragraphs later mentions how end-to-end encryption should be used by discord and others. Yet somehow they don't connect those two ideas...
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".
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".
I don’t understand why the author claims self signed certificates are safe that users on the other end can verify for themselves that it’s the right party. Isn’t this exactly not possible for self signed certs? Anyone can mint a cert in my name, and that is the sole reason why CAs exist.
Anyone can mint a cert in your name, but they can't mint a cert with the same details (pubkey) as yours.
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)
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)
I think they're saying self-signed certs are ok for encryption IF you can verify it's the right party, not that they're automatically ok.
I don't use self-signed certs for this reason. Instead, I run my own CA to sign my certs.
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.
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.
Well, you run one self-signed cert then.
True, but that's no different than any other root cert. It doesn't really count because it's not a cert that's directly used.
Yep, the root of trust has to start somewhere.
My 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...
3. https://en.wikipedia.org/wiki/ARP_spoofing
> 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...
3. https://en.wikipedia.org/wiki/ARP_spoofing
> 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.
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.
I believe the flow allows you to view certificate information prior to accepting, and then only that certificate will be accepted for only that hostname.
Which browser do you think that's true for, and, have you tried it?
All desktop browsers I've tried. I don't have anything other than Chrome handy at the moment, but it definitely still works.
You just need to click on the "Not Secure" warning that's where the lock symbol would be, then on "Certificate is not valid".
You just need to click on the "Not Secure" warning that's where the lock symbol would be, then on "Certificate is not valid".
> 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.
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.
Rewriting all https URLs to http is fairly trivial in the vast majority of cases, and I would imagine it would be adequate for this use case.
In the case of retro computing especially, specially compiled software supporting legacy versions of SSL/TLS is reasonable.
In the case of retro computing especially, specially compiled software supporting legacy versions of SSL/TLS is reasonable.
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.
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.
> but the users were ignorant and continued using the service even after the certificate suddenly changed.
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.
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.
> You can always use a stronger encryption.
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.
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.
> The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed.
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.
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.
I am living in reality. I don't want to limit the user's freedom. Sometimes people have to learn the hard way, but the other option (giving away your freedoms) is always worse.
> Sometimes people have to learn the hard way
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.
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.
"Encrypt the whole call", but the l2tp interface between the modem bank and the POP is almost certainly not encrypted.
The biggest practical issue that I have with the author's advice is that most people just want to type domain.tld into a web browser. This will guarantee that most people will get the http version of the website which is not ideal. You'll get a large number of, you should add security to your site messages. Also, Many firewalls (looking at you fortinet) block http by default and only allow https through. So in addition to the why doesn't your site have security, you'd also get, why is your site down/blocked?
"Starting in version 90, Chrome’s address bar will use https:// by default, improving privacy and even loading speed for users visiting websites that support HTTPS. Chrome users who navigate to websites by manually typing a URL often don’t include “http://xn--ivg or “https://xn--ivg. For example, users often type “example.com” instead of “https://example.xn--com-9o0a in the address bar. In this case, if it was a user’s first visit to a website, Chrome would previously choose http:// as the default protocol1."
https://blog.chromium.org/2021/03/a-safer-default-for-naviga...
https://blog.chromium.org/2021/03/a-safer-default-for-naviga...
> Showing the user nonsensical warnings like
"Someone is trying to steal your credit card information!!!!11" only creates
confusion and misconceptions about security.
So is this suggesting that browsers should automatically trust all certificates? The Kazakh government sure would like that to happen.
So is this suggesting that browsers should automatically trust all certificates? The Kazakh government sure would like that to happen.
Clearly it is not suggesting anything like that. You misunderstood it on purpose.
> There used to be a time when malicious websites usually didn't have encryption at all, or if they had, their certificate was self-signed. Let's Encrypt changed that. Now every malicious site has a certificate that appears trusted, and there will soon be a need of having different levels of "trust", where free-of-charge certificates like the ones from Let's Encrypt will become essentially untrusted.
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.
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.
Perhaps less related to the original post, but I found this interesting:
> 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?
> 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?
When I'm talking about "lookalike domains", I mean domain names that look exactly the same. It is simply not possible with 7-bit ASCII.
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.
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 thought the whole EV cert thing already came and more or less went.
https://en.wikipedia.org/wiki/Extended_Validation_Certificat...
https://en.wikipedia.org/wiki/Extended_Validation_Certificat...
Funny how the last point does not apply to the very website the text is written into.
I was forced to use HTTP to see the page.
I was forced to use HTTP to see the page.
The NSA has recorded your receipt of this message.
Encrypting as much of your traffic (DNS included) is only sensible unless you wish more of your data to be mined and sold.