Live data from Hacker News

Launching in 2015: A Certificate Authority to Encrypt the Entire Web

eff.org

331–340 of 476 posts

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#331

Earlier quoted context omitted.

> Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I kno…

There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com. A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.

There is such a thing -- name constraints. It allows exactly what you describe, limiting the valid names for certificates signed by the certificate.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#332
post #60

This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have. The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and big…

> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool" no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Treating…

The solution is something nobody hasn't quite come up with.

SSH has. It tells me:

WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future.

That model isn't perfect either but it is much preferable over the model that we currently have, which is: Blindly trust everyone who manages to exert control over any one of the 200+ "Certificate Authorities" that someone chose to bake into my browser.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#333
post #331

Earlier quoted context omitted.

There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com. A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.

There is such a thing -- name constraints. It allows exactly what you describe, limiting the valid names for certificates signed by the certificate.

Interesting - that's news to me, and does allow a domain-registry-based hierarchy. I guess there's the old revocation-check problem, though - when someone transfers a domain or it expires, you'd need to be able to revoke the authority cert. Potentially leads to a lot of revocation checks to validate a cert chain correctly...

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#334
post #60

Earlier quoted context omitted.

> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool" no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Treating…

Private to the NSA and reasonably private to the person sitting next to you are different use cases. The current model is "I'm sorry, we can't make this secure against the NSA and professional burglars so we're going to make it difficult to be reasonably private to others on the network". It's as if a building manager, scared that small amounts of sound can leak through a door, decided that the only solution is to na…

The person next to you in cafe can MITM a self-signed TLS connection just as easily as the NSA; and the NSA can probably MITM a CA-signed TLS session, since the U.S. government owns or has access to quite a few root certificates. So, "no self-signed certs" is really a measure to protect you from the lowest level of threat. Almost any attacker than can MITM http can MITM https with self-signed certs that you never verify in any way. Encryption without authentication is useless in communications.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#335

Earlier quoted context omitted.

There's no question in my mind that the whole thing is a racket and militates against security (you generally don't even know all the evil organisations that your browser implicitly trusts - and all the organisations that they trust etc). There are certainly other options too: here's my suggestion- The first time you go to a site where the certificate is one you haven't seen before, the browser should show a nice fri…

How would you rotate keys with that scheme?

You'd need a strong root key and subkeys that rotate underneath. To change the root key would require signing by the original root and a new message to appear for confirmation.

All this plus something like a notary system to double check all your trusted root keys, would be much better than the hierarchical CA system we have.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#336
post #202

This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have. The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and big…

I just bought a cert on Saturday for $9. It's less than the domain name.

Can get them free for web use. Not sure where he is coming from.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#338

Earlier quoted context omitted.

> Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I kno…

There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com. A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.

> There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.

As currently implemented this is mostly correct. I don't think the CAs want that situation to change, but it really harms the usability of the entire system.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#339
post #303

Earlier quoted context omitted.

The registrar issuing cert solution would certainly speed up HTTPS adoption; you're dealing with one less org to secure your site. The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee? Or what about revoking the previous cert? Now the registrar is functioning as a de facto CA so it doesn't completely eliminate…

> The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee? Then everyone stops using that registrar and they go out of business. > Or what about revoking the previous cert? You're asking this as if there is some kind of functioning method of revoking certificates already. If anything this makes it easier because i…

If the popularity of GoDaddy has taught me anything, it's that people use what they know; not what's good. The list of companies that should have gone out of business is as long as the number of years since commerce began.

The fact that they still stay means (and this is relevant to the EFF project as well), creating alternatives is just as hard as making enough people know and care about them.

The registrar check per domain is probably the biggest plus in having it act as CA. Of course, that adds overhead to the registrar which they may not be willing to accept (margins and all that).

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#340
post #321

Earlier quoted context omitted.

That would be stupid. Google is a US company. NSA has NSLs. Mission accomplished. No certs involved.

How did you get Google into all this? If you're implying that Google owns a search site/Gmail/a browser, know that there are alternatives, which NSA's target could be using. A fake certificate from a trusted US CA can MITM any connection to almost any website from almost any browser.

That should have been a reply to the sibling comment, where it was implied this would be a strategy against Google.
Post reply on HN