Live data from Hacker News

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

eff.org

371–380 of 476 posts

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

#371
post #332
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…

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

...and then if the fingerprint changes, you get something like this:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

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

#372
post #285

Here's my current issue with moving to TLS: library support. I do a lot of custom stuff and want to run my own server. I can set up and run the server in maybe 50-100 lines of code, and it works great. I know, I should conform and use Apache/nginx/OpenSSL like everyone else. Because they're so much more secure, right? By using professional code like the aforementioned, you won't get exposed to exploits like Heartblee…

I'm in a similar position to you. LibTLS looks promising, but as you said, it's not tested (and not portable yet?)

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

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

I think this is kind of backwards? I.e. a CA that implements name constraints for one of its sub-CAs does limit the certs that sub-CA may sign. However, name constraints do not allow one to say "for this domain, only this sub-CA may sign certs", which is more what I feel we're looking for here?

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

#375
post #50

Won't people need to have LetsEncrypt CA certificate installed on their computers to not get that red SSL incorrect certificate thing? Other than that, this is awesome.

I just installed it including all its Python dependencies, and tried it on my Apache server, but it throws me tons of Python errors.

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

#376

Earlier quoted context omitted.

> I can substitute/add/send... Only if you control any of the infrastructure. If you do, then you can make my life a misery anyway, encrypted or not.

Authenticated and encrypted? That throws a wrench into things.

The authentication provided by the extant PKI system is much weaker than the encryption provided. Any CA can do anything it wants, and browsers trust lots of them.

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

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

Name constraints don't work [1] [2]. It's a nice thought, though :-/

[1] http://blog.codekills.net/2012/04/08/adventures-in-x509-the-... [2] http://middleware.internet2.edu/pki06/proceedings/chadwick-n...

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

#378

Earlier quoted context omitted.

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.

Which root keys? The ones you store on your web server, which just got compromised?

Why would one store them there? Why not just use them to sign other keys that are actually used in online systems?

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

#379

> Let's Encrypt will be overseen by the Internet Security Research Group (ISRG), a California public benefit corporation. ISRG will work with Mozilla, Cisco Systems Inc., Akamai, EFF, and others to build the much-needed infrastructure for the project and the 2015 launch What's Cisco's role in this? I'm quite worried about that. It has been reported multiple times that Cisco's routers have NSA backdoors in them, from…

Lawful Intercept isn't a blanket government back door per se. It's a featureset that allows the operator to configure what is effectively a remote packet capture endpoint. That endpoint is disabled by default and requires operator configuration to be enabled.

It just happens that every ISP/telco in the US needs this capability to comply with CALEA so it's manufacturers responding to market forces. Juniper supports it, A Latvian router manufacturer supports it (http://wiki.mikrotik.com/wiki/CALEA), there's even open source code to do it (https://code.google.com/p/opencalea/) if you're building your own routers.

There's a place to focus your ire over wiretapping. The manufacturers aren't it.

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

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

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

Well... that's true regardless, as the NSA almost certainly has control over one or more certificate authorities.

But I agree with the sentiment. :)

Post reply on HN