Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why HTTP without encryption and self-signed sertificates are OK

sininenankka.dy.fi

Post reply on HN
Print view View original

11–20 of 48 posts

Re: Why HTTP without encryption and self-signed sertificates are OK

#11

Post by Gordonjcp »

ryan-c wrote: post #3

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 interne…

"Encrypt the whole call", but the l2tp interface between the modem bank and the POP is almost certainly not encrypted.

Re: Why HTTP without encryption and self-signed sertificates are OK

#12

Post by gruturo »

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.

Re: Why HTTP without encryption and self-signed sertificates are OK

#14

Post by yalogin »

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.

Re: Why HTTP without encryption and self-signed sertificates are OK

#15

Post by nottorp »

gruturo wrote: post #12

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.

That's what privacy laws are for isn't it?

Re: Why HTTP without encryption and self-signed sertificates are OK

#16

Post by P5fRxh5kUvp2th »

yalogin wrote: post #14

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.

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.

Re: Why HTTP without encryption and self-signed sertificates are OK

#17

Post by account42 »

tamrix wrote: post #7
AndyMcConachie wrote: post #4

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…

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

Re: Why HTTP without encryption and self-signed sertificates are OK

#18

Post by viraptor »

smoppi wrote: post #8
ryan-c wrote: post #3

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 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, enc…

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

Re: Why HTTP without encryption and self-signed sertificates are OK

#19

Post by trillic »

nottorp wrote: post #15
gruturo wrote: post #12

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.

That's what privacy laws are for isn't it?

Hah.

Re: Why HTTP without encryption and self-signed sertificates are OK

#20

Post by viraptor »

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

Post reply on HN