Hacker News new | ask | show | jobs
by andirk 1254 days ago
Good point! No encryption shows zero issue.

Your mention of us all using LetsEncrypt and similar is beyond my understanding of cryptography but why do they need to be signed by a central authority exactly?

4 comments

Ultimately every cert is signed by a Certificate Authority. This is a "Trust Anchor". An authority that you trust implicitly. Your web browser maintains a list of these trusted parties, which are measured in the dozens and only change occasionally after careful scrutiny by Browser vendors. If your cert is not signed by one of these CAs, there is no way to verify it's veracity. That is why the browser gives a scary warning. I could issue a cert claiming to be google.com without any deterance. Until recently all such authorities charged a fee to issue you a verified certificate. Also the process was usually not fully automated and required human intervention to renew a cert. LetsEncrypt was a major innovation for two reasons:

1. They provided the certificates for free, no strings attached 2. They provided a fully automated and optimized process to issue/renew/deploy the cert

This had the effect of making HTTPS accessible to everyone, and is the reason that HTTPS has become the default rather than only being used for a small fraction of websites (e-commerce etc...).

Overall this has been a positive development and has raised the bar against mass-surveillance across the world. However, the downside as mentioned, is that much of the world's infrastructure now relies on this small company. Since the certs are only valid for 3 months, any blockage in that renewal process means rapidly failing services.

It would be interesting to see governments or domain registries set up ACME-compatible CAs.

At the moment, it looks like there are options in Norway and Austria as well as the US: https://www.xf.is/2020/06/30/list-of-free-acme-ssl-providers...

Wouldn't this allow them to easily MITM you?
A lot of governments already have CAs, so they could MITM you anyway.

For example, the Netherlands government CA: https://cert.pkioverheid.nl/

The other answer to your question seemed to me to have guessed wrong what you're concerned about. My guess is that like a lot of non-experts, your thought was "Why do we need this CA role?" and that, fortunately, is something where I can appeal to your intuitions rather than needing some mathematical proof about cryptography you won't understand.

This is about identity. How can we (and everybody else) agree on the identity of something? Is "Chris Pratt" the movie guy we've both heard of, or is it some Belgian guy's friend's brother you met once at a party? The Screen Actors Guild insists its members all have distinct names so you can tell them apart. If your real name is Clint Eastwood and you go into acting, too bad change it or you won't be allowed to work on most stuff with union rules. You don't need a legal change of name (although if you're a serious actor you might decide it's less bother to get one) but you must use a name distinct from those already in use in the industry.

Naturally there can't be some objective "truth" to a name. People may say "She looks like a Deborah" but that's not really how it works - when we find someone in a coma with no ID we don't go "Oh, he looks like a Jim Smith, of 420 Springfield Crescent", we have to put out a public appeal with photos. If I show you a web page it may look like Wikipedia, but I can trivially do that myself, so the real Wikipedia is the one everybody agrees on, and if for some reason we all agreed tomorrow that's not Wikipedia, it wouldn't be.

So, with no objective truth† we have to instead have an authority, and for everybody's convenience we should all trust at least roughly the same authorities, so we're all agreed about who we're talking about

† We can use cryptography to "assign" things names, but these names aren't very satisfactory, that's how Tor's private services work, which is why they have ugly names like facebookwkhpilnemxj7asaniu7vnjjbiltxjqhye3mhbshg7kx5tfyd.onion -- notice that all those letters are crucial, facebookwkhpilnemxj7asaniu7vnjjxiltxjqhye3mhbshg7kx5tfyd.onion is one letter different and would be a different Tor service not operated by Facebook.

> How can we (and everybody else) agree on the identity of something?

we do, I rephrase it, billions of people do it all the time everyday on WhatsApp.

It's called TOFU

The first T means Trust.

Another example: Protonmail, it uses PGP, it works.

The important thing for privacy is the encryption part, not the identity part.

Even more so when we all know that full fledged HTTPS site put TENS OF MEGABYTES of garbage on their web pages to track people.

Identity: I want it confirmed if I'm talking to my bank, but why the bank cannot buy a 10 year certificate it's a mystery to me, I sure hope they'll still be in business in 10 years time from now, at least they should be able to not think about this minutia so often.

> why the bank cannot buy a 10 year certificate it's a mystery to me, I sure hope they'll still be in business in 10 years time from now, at least they should be able to not think about this minutia so often.

There's no more reason they should "think" about this than, say, testing fire extinguishers, it's just routine maintenance, it is presumably somebody's job to ensure all the routine maintenance gets done. If you're holding a meeting about the certificates on the web site, rather than knowing that's maintained and monitored properly as part of normal operations, you screwed up.

Now, why does it need maintaining? Why not have them issued for 10 years (so, longer than many employees will work for the bank) ? Well the lifetime of a certificate in the Web PKI is in practice the best possible agility we can achieve for the entire Web PKI, so the longer the maximum lifetime, the slower we're able to fix any problems.

If the bank's new certificate today is valid for 10 years that means if we sunset things which are a terrible idea tomorrow they are still polluting the ecosystem until at least January 2033. A new browser, written by a team who are all in primary school today, might ship in 2033 and yet it's expected to put up with every weird thing we're still allowing, even if it's known to have been a bad idea for about a decade by then.

Currently the rule is 398 days, so if we outlaw something tomorrow, it's no longer a problem by the end of February 2024. More realistically, if we argue about it for a few weeks, and then agree to ban it from May 2023, it's no longer a problem by the second half of 2024.

> fire extinguishers

fire extinguishers are for emergencies!

if a fire extinguisher doesn't work, people can die

if an HTTPS cert has expired, there is no risk involved, it can still be used only o. the domain it was issued for.

Anyway in.my country you have to check them every 3 years and someone comes to you, you don't have to remember about it.

> If the bank's new certificate today is valid for 10 year

nothing prevents reissuing new certificates before expiration, if necessary.

> nothing prevents reissuing new certificates before expiration, if necessary.

So you want a product advertised with a 10 year lifespan, but sometimes it fails much earlier? I guess I have great news, you can use the existing product this way, although everybody you work with may find you exasperatingly incompetent.

The CA signing provides different levels of validation. DV (Domain validation) certificates require demonstration of control over the dns record(s) to the CA, ensuring the (IP address) server responding to your request has demonstrated control of the domain name by which you addressed it, to the CA.

Let’s say your local dns is poisoned to resolve to a nefarious server at a specific IP address for ss64.com, that server’s certificate won’t be signed by a CA (unless they also controlled ss64.com’s dns records, in which case there would have be no need to poison your local dns). Your connection to this server can still be encrypted via a certificate, but the CA won’t be providing validation of their identity or affiliation with the real ss64.com.

TL;DR

It's just for Identification.

The signature on the public key matches what domain it should resolve, and said public key pairs with a private key that encrypts your data. Assuming you don't a) mishandle the private key, b) the Signatory has a reasonably process to assure that person with the private key should be able to encrypt the domain, and c) all potential trusted Signatories can be trusted, then you can reasonably assume the site you're visiting is legit.

The actual encryption doesn't need identification. Doing so would ensure others can't listen to your conversation, but wouldn't help if the person you think you're talking to isn't actually the right person. This is a realistic problem, because there's nothing in DNS or routing that ensures trust.