Live data from Hacker News

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

eff.org

191–200 of 476 posts

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

#191
post #6

My website only contains publically available stuff for people to read. Is there any reason why I would want to use https for this use case? Or what does "entire web" mean?

Honestly, you're probably not going to get a large personal benefit from this. The larger good is that you'll be helping move the Internet toward encrypted-by-default, which is an enormous societal benefit.

Like you, I don't host any private or remotely sensitive information. I'm encrypting my site because I think it's the right thing to do, even though there's little personal return on investment.

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

#192
post #135

Earlier quoted context omitted.

My concern is that your reach is too far. Asking domain administrators to trust your software to manipulate private keys (and server configurations) is as troubling as asking end users to click past security warnings. The whole purpose of the CSR is to obtain the signed certificate without putting the private key at risk. This decoupling isolates the challenge of identity verification in a reasonable place (nobody is…

Oh, our software does NOT send the private key to the CA. Never never never never. The point of having it manage the keys is not to give us access to them, it's to be convenient for the end-user, on the end-user's own system, under the end-user's control. You can tell because our software is open source, written in Python. https://github.com/letsencrypt/lets-encrypt-preview We expect the users to get this software fr…

I'd still be more comfortable if the process never went anywhere near the private key (and I'm concerned that a proprietary competitor or look-alike would prey on naive users by leveraging your example). But I also applaud your effort and transparency. I admit I trust openssl to manage my own keys and certificates, and there is definitely room in this space for improvement and alternative approaches. But it does sadden me that we risk making administrators as trusting and ignorant of the underlying principles as end users already are today.

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

#193

One possible solution is a BitCoin-like block chain of certificate proof, so that a website's certificate can be verified against the domain without a central authority.

That doesn't even remotely work, who has the private keys to authorize the certificates?

So, blockchain solutions do work, and here is how:

https://github.com/okTurtles/dnschain

You can replace all CAs with a single blockchain.

And we should do this, because this Let's Encrypt CA, while a great step forward, is still vulnerable to man-in-the-middle attacks, explained in this video:

https://vimeo.com/100433057

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

#194
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 absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.

We do have a solution that does accept self-signed certificates. The remaining pieces need to be finished and the players need to come together though:

https://github.com/okTurtles/dnschain

If you're in San Francisco, come to the SF Bitcoin Meetup, I'll be speaking on this topic tonight:

http://www.meetup.com/San-Francisco-Bitcoin-Social/events/18...

Let's Encrypt seems like the right "next step", but we still need to address the man-in-the-middle problem with HTTPS, and that is something the blockchain will solve.

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

#195

from the ACME spec, it looks like proof of ownership is provided via[0]: >Put a CA-provided challenge at a specific place on the web server or > Put a CA-provided challenge at a DNS location corresponding to the target domain. Since the server will presumably be plaintext at that point and DNS is UDP, couldn't an attacker like NSA just mitm the proof-of-site-ownership functionality of lets-encrypt to capture ownershi…

Four things:

(1) You can do the attack you describe today with existing CAs that are issuing DV certs because posting a file on the web server is an existing DV validation method that's in routine use.

(2) There is another validation method we've developed called dvsni which is stronger in some respects (but yes, it still trusts DNS).

(3) We're expecting to do multipath testing of the proof of site ownership to make MITM attacks harder. (But as with much existing DV in general, someone who can completely compromise DNS can cause misissuance.)

(4) If the community finds solutions that make any step of this process stronger, Let's Encrypt will presumably adopt them.

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

#196
post #57

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.

I'm curious as to whether Firefox's sync functionality propagates CA overrides across machines. If not then this is something you'd have to repeat over for every machine you use, making it effectively too tedious to be practical.

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

#197
Kudos to the EFF for making an easy-to-use tool to generate TLS certs!

Kudos also for creating the second CA to issue free certificates (the first being StartSSL).

The next step needs to be to man-in-the-middle (MITM) proof these certs. We still have to address that problem. We'll be talking about how the blockchain can be used to solve this problem tonight at the SF Bitcoin Meetup, if that interests you, you're welcome to come:

http://www.meetup.com/San-Francisco-Bitcoin-Social/events/18...

A primer can be found here: https://vimeo.com/100433057

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

#198

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…

Without some kind of authentication, the encryption TLS offers provides no meaningful security. It might as well be an elaborate compression scheme. The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session. But of course, real attackers trivially see all the the traffic for a session, because they snare attackers with routing, DNS, and layer 2 redirection.

What's especially baffling about self-signed certificate advocacy is the implied threat model. Low- and mid-level network attackers and crime syndicates can't compromise a CA. Every nation state can, of course (so long as the site in question isn't public-key-pinned). But nation states are also uniquely capable of MITMing connections!

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

#199

Earlier quoted context omitted.

> Governments putting people in jail for reading your publicly available (in your country) content, which is illegal in theirs // How does that work, surely the gov can still see people accessing the information by monitoring network traffic and the info itself is still public. HTTPS doesn't encrypt the actual request traffic does it, and in any case the gov would still see which server the traffic is going to unless…

There's a difference between "User X browses Wikipedia" and "User X browses Wikipedia articles about topics A, B, C" where topics A, B, C could be anything user X doesn't want people recording them reading about: for instance, various political articles, articles about mental illness, articles about LGBT issues, etc. Fill in the blanks.

I use this example myself quite a bit, although we've also got to figure out the distinguishability from page sizes issue. Different Wikipedia pages are different sizes, and they're still different sizes when they're encrypted.

One interesting idea I heard from someone recently is tuning compression so that you target a small number of total page sizes -- rather than padding to expand pages to the same sizes, just don't compress them all quite as well as you could have.

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

#200
post #104
post #102

Earlier quoted context omitted.

Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.

The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.

But when you browse over http, you don't know who you're talking to either, so how are self-signed certificates worse than http?

I'm really having trouble figuring out the attack scenario unique to self-signed certificates that you don't have with plain http.

Post reply on HN