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

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

eff.org

Post reply on HN
Print view View original

71–80 of 476 posts

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

#71

Post by tatterdemalion »

desdiv wrote: post #57
mike_hearn wrote: post #39

Earlier quoted context omitted.

You can revoke your trust in any CA at any time, you don't even need to see any errors! Just click the little padlock each time you visit a secure website and see if the CA is in your good books. If it's not, pretend the padlock isn't there! OK, that's a little awkward. A browser extension could automate this. But in practice, nobody wants to do this, because hardly anyone has opinions on particular CAs. It's a sort…

Can't you just delete the CA from the browser? On Firefox it's preferences -> advanced -> certificates -> view certificates.

Yes you can. Obviously, you can choose not to make secure connections with sites certified by a CA you don't trust. But then you just can't use your bank's website anymore, or your search engine, or whatever.

Users have a clear stake in whatever informational exchange occurs between them and the websites we access. We should have the authority to participate in determining the terms on which that exchange is secured.

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

#72

Post by jerf »

overshard wrote: post #11

The "How It Works" page, https://letsencrypt.org/howitworks/ , has me a bit worried. Anytime I see a __magic__ solution that has you running a single command to solve all your problems I immediately become suspicious at how much thought went into the actual issue. If I'm running a single web app on a single Ubuntu server using Apache then I'm set! If I'm running multiple web apps across multiple servers using a load…

Yes, this will only hit the common small-site case. Hopefully if you're running "multiple web apps across multiple servers using a load balancer" you will have the skill to configure HTTPS properly for that situation, which will probably involve custom configuration on the load balancer. It's not a criticism of something trying to solve the common case, where the common solution up until today is pretty much "just forget about it", that it doesn't work at "cloud scale".

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

#74

Post by schoen »

trothamel wrote: post #26
pde3 wrote: post #8

Earlier quoted context omitted.

This is just a pre-announcement to let folks (OSes, hosting providers, other platforms) plan and do integration work. Per our own warnings, we definitely don't want this running on production machines until it launches in 2015. Our Apache code is a developer preview, we'll be working on Nginx next. ISRG will be operating a new root CA for this project. Although if you think that your choice of CA makes you more or le…

"ISRG will be operating a new root CA for this project." Does that mean every client/browser will need to be updated to include the new CA? Or will it somehow be signed by other (competing) CAs? I like the idea of this project, and I think it's a great thing for the Internet - I just worry that it will take a long time for it to be usable in practice.

No, it will be cross-signed and provide the chain so that it will work immediately in all mainstream browsers.

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

#75

Post by lazyjones »

pilif wrote: post #60
digitalsushi wrote: post #32

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

That would be correct if you could assume that the NSA couldn't fake certificates for websites. But it can, so it's wrong and misleading. It's certificate pinning, notary systems etc. that actually give some credibility to the certificate you're currently using, not whatever the browsers indicate as default.

FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ...

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

#76

Post by geofft »

3pt14159 wrote: post #58
Someone1234 wrote: post #42

Earlier quoted context omitted.

I totally agree that CAs are a racket. There's zero competition in that market and the gate-keepers (Microsoft, Mozilla, Apple, and Google) keep it that way (mostly Microsoft however). That being said: Identity verification is important as the encryption is worthless if you can be trivially man-in-the-middled. All encryption assures is that two end points can only read communications between one another, it makes no…

It is not a legitimate requirement. HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy. In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used. The content provider can have a process that sits on top of a VPN…

That's all good in theory, but there have been demonstrated attacks against man-in-the-middle-able protocols and we've lacked the ability to respond usefully, precisely because the protocols were designed to be man-in-the-middle-able. Everyone knows it's happening and it's even easier to detect than your example, but there's nothing useful to do with that knowledge other than complain.

https://www.eff.org/deeplinks/2014/11/starttls-downgrade-att...

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

#77

Post by jackalope »

erickt wrote: post #46
general_failure wrote: post #35

Earlier quoted context omitted.

I don't get why they are releasing a command line, instead of just giving us a cert that we can install by ourselves.

That wouldn't be safe, because then they would have access to your private key and impersonate you. Having you (indirectly via their script) generate the key and submit the public key for signing means your private key never leaves the premises.

There is no reason for the CA to ever see the private key. All they need is a CSR. This approach is fundamentally broken.

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

#78

Post by pde3 »

mangeletti wrote: post #45

So, one CA to rule then all? There's a scenario (simplified for illustration, but entirely possible) that's normally not a huge risk because there are many CAs, and they are private, for-profit companies that have an economic incentive to protect you and your certificate's ability to assure end users that a conversation's privacy won't be compromised. 1) browser requests site via SSL 2) MITM says, "let's chat - here'…

Let's Encrypt is going to publish records of everything it signs, either with Certificate Transparency or some other mechanism.

Browsers will be able to check any cert signed by the Let's Encrypt CA against the published list. If there's a discrepancy, that will be immediately detectable.

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

#79

Post by iancarroll »

lazyjones wrote: post #75
pilif wrote: 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…

> 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". That would be correct if you could assume that the NSA couldn't fake certificates for websites. But it can, so it's wrong and misleading. It's certificate pinning, notary systems etc. that actually give some credi…

The NSA has no CA. The only attack they really have is brute force or server compromise - both of which undermine pinning.

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

#80

Post by [deleted] »

schoen wrote: post #69
mangeletti wrote: post #45

So, one CA to rule then all? There's a scenario (simplified for illustration, but entirely possible) that's normally not a huge risk because there are many CAs, and they are private, for-profit companies that have an economic incentive to protect you and your certificate's ability to assure end users that a conversation's privacy won't be compromised. 1) browser requests site via SSL 2) MITM says, "let's chat - here'…

We will look for ways to mitigate the risk of misissuing for any reason, including because someone tries to coerce us to misissue. One approach to this that's interesting is Certificate Transparency. http://www.certificate-transparency.org/ There's also HPKP, TACK, and DANE, plus the prospect of having more distributed cert scans producing databases of all the publicly visible certs that people are encountering on th…

[deleted]
Post reply on HN