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

21–30 of 48 posts

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

#21

Post by horsawlarway »

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.

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)

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

#22

Post by ryan-c »

tialaramex wrote: post #9
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…

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

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.

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

#23

Post by ryan-c »

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…

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

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

#24

Post by ryan-c »

justsomehnguy wrote: post #10
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…

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

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.

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

#25

Post by Justsignedup »

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.

My favorite is cell providers replacing http advertising with their own.

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

#26

Post by tenebrisalietum »

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…

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.

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

#27

Post by JohnFen »

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

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

#29

Post by Sohcahtoa82 »

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…

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

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

#30

Post by Sohcahtoa82 »

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

Post reply on HN