5 ms·

Why HTTP without encryption and self-signed sertificates are OK

37 points by smoppi 4y ago

sieabahlpark 4y ago
ryan-c 4y ago
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-at-defcon-can-crack-widely-used-pptp-encryption-in-under-a-day.html https://www.computerworld.com/article/2505117/tools-released... 2. https://www.theverge.com/2018/4/24/17275982/myetherwallet-hack-bgp-dns-hijacking-stolen-ethereum https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha... 3. https://en.wikipedia.org/wiki/ARP_spoofing https://en.wikipedia.org/wiki/ARP_spoofing
- Gordonjcp 4y ago
  "Encrypt the whole call", but the l2tp interface between the modem bank and the POP is almost certainly not encrypted.
- smoppi 4y ago
  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.
  - viraptor 4y ago
    > 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.
  - ryan-c 4y ago
    > 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.
AndyMcConachie 4y ago
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.
- tamrix 4y ago
  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.
  - account42 4y ago
    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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
- benjojo12 4y ago
  There exist other free ACME providers, let's encrypt was just the first and biggest
- easrng 4y ago
  ZeroSSL and Google both have free ACME CAs, tho Google needs a special step the first time iirc.
- tenebrisalietum 4y ago
  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.
gruturo 4y ago
Your ISP is - or soon will - be datamining the crap out of your browsing data, or injecting supercookies, or replacing NXDOMAIN queries taking you to their advertisement pages, or worse. Encrypting as much of your traffic (DNS included) is only sensible unless you wish more of your data to be mined and sold.
- nottorp 4y ago
  That's what privacy laws are for isn't it?
  - trillic 4y ago
    Hah.
  - 10000truths 4y ago
    We don't need locks to protect our homes, that's what burglary laws are for.
  - UltraViolence 4y ago
    Like there aren't any in the U.S.
    - nottorp 4y ago
      Are there? I believe the ISPs are fighting tooth and nail against being classified "common carriers" and are winning in the name of "innovation" :)
- Justsignedup 4y ago
  My favorite is cell providers replacing http advertising with their own.
theandrewbailey 4y ago
The NSA has recorded your receipt of this message.
yalogin 4y ago
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.
- P5fRxh5kUvp2th 4y ago
  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.
- horsawlarway 4y ago
  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)
- JohnFen 4y ago
  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.
  - hotpotamus 4y ago
    Well, you run one self-signed cert then.
    - JohnFen 4y ago
      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.
viraptor 4y ago
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".
denysvitali 4y ago
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.
Sohcahtoa82 4y ago
> 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.
- hotpotamus 4y ago
  I thought the whole EV cert thing already came and more or less went. https://en.wikipedia.org/wiki/Extended_Validation_Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificat...
- KronisLV 4y ago
  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/ 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?
0x08 4y ago
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?
- mrg2k8 4y ago
  "Starting in version 90, Chrome’s address bar will use https:// 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://” http://xn--ivg or “https://” https://xn--ivg. For example, users often type “example.com” instead of “https://example.com” 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:// http:// as the default protocol1." https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html?m=1 https://blog.chromium.org/2021/03/a-safer-default-for-naviga...
Raymonf 4y ago
> 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.
- smoppi 4y ago
  Clearly it is not suggesting anything like that. You misunderstood it on purpose.

37 points by smoppi 4y ago

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-at-defcon-can-crack-widely-used-pptp-encryption-in-under-a-day.html https://www.computerworld.com/article/2505117/tools-released... 2. https://www.theverge.com/2018/4/24/17275982/myetherwallet-hack-bgp-dns-hijacking-stolen-ethereum https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha... 3. https://en.wikipedia.org/wiki/ARP_spoofing https://en.wikipedia.org/wiki/ARP_spoofing

Gordonjcp 4y ago
"Encrypt the whole call", but the l2tp interface between the modem bank and the POP is almost certainly not encrypted.
smoppi 4y ago
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.
- viraptor 4y ago
  > 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.
- ryan-c 4y ago
  > 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.

AndyMcConachie 4y ago

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.

tamrix 4y ago
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.
- account42 4y ago
  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_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
benjojo12 4y ago
There exist other free ACME providers, let's encrypt was just the first and biggest
easrng 4y ago
ZeroSSL and Google both have free ACME CAs, tho Google needs a special step the first time iirc.
tenebrisalietum 4y ago
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.

gruturo 4y ago

Your ISP is - or soon will - be datamining the crap out of your browsing data, or injecting supercookies, or replacing NXDOMAIN queries taking you to their advertisement pages, or worse. Encrypting as much of your traffic (DNS included) is only sensible unless you wish more of your data to be mined and sold.

nottorp 4y ago
That's what privacy laws are for isn't it?
- trillic 4y ago
  Hah.
- 10000truths 4y ago
  We don't need locks to protect our homes, that's what burglary laws are for.
- UltraViolence 4y ago
  Like there aren't any in the U.S.
  - nottorp 4y ago
    Are there? I believe the ISPs are fighting tooth and nail against being classified "common carriers" and are winning in the name of "innovation" :)
Justsignedup 4y ago
My favorite is cell providers replacing http advertising with their own.

theandrewbailey 4y ago

The NSA has recorded your receipt of this message.

yalogin 4y ago

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.

P5fRxh5kUvp2th 4y ago
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.
horsawlarway 4y ago
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)
JohnFen 4y ago
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.
- hotpotamus 4y ago
  Well, you run one self-signed cert then.
  - JohnFen 4y ago
    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.

viraptor 4y ago

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".

denysvitali 4y ago

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.

Sohcahtoa82 4y ago

> 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.

hotpotamus 4y ago
I thought the whole EV cert thing already came and more or less went. https://en.wikipedia.org/wiki/Extended_Validation_Certificate https://en.wikipedia.org/wiki/Extended_Validation_Certificat...
KronisLV 4y ago
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/ 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?

0x08 4y ago

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?

mrg2k8 4y ago
"Starting in version 90, Chrome’s address bar will use https:// 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://” http://xn--ivg or “https://” https://xn--ivg. For example, users often type “example.com” instead of “https://example.com” 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:// http:// as the default protocol1." https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html?m=1 https://blog.chromium.org/2021/03/a-safer-default-for-naviga...

Raymonf 4y ago

> 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.

smoppi 4y ago
Clearly it is not suggesting anything like that. You misunderstood it on purpose.