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

201–210 of 476 posts

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

#201

Post by ademarre »

kayone wrote: post #175
ademarre wrote: post #169

This is great news! I'd also like to see a push for technologies like DANE (and necessarily DNSSEC) which address the flawed CA trust model. While we're at it, let's get a non-profit domain registrar going.

> non-profit domain registrar domain squatters are already an issue. imaging if you could register domains for free. I think having to pay $10 for a year is pretty fair. That's one reason I don't mind paying ~$70 for .io domain. it keeps most squatters away.

You misunderstand. Domains must not be free, and domain cost isn't the problem. Nonprofit registrar != free domains.

The problem is the horrible user experience of registrars like Godaddy. I'd rather give my money to a nonprofit that isn't confusing non-technical website owners into buying products they don't need.

The registrar landscape is better now with Gandi, but still I'd rather pay a fully transparent nonprofit registrar if one existed.

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

#202

Post by Buge »

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…

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

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

#203

Post by MichaelGG »

lazyjones wrote: post #92
iancarroll wrote: post #79

Earlier quoted context omitted.

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

They can get US corporations (including many CAs) to cooperate. For example, to obtain a fake (but perfectly working google.com certificate, they can ask Google (more or less) nicely to provide one, or they can go ask any CA instead. It's not likely that compromise is required with so many potential sources, some of which may be paid or coerced to cooperate. PS. nice (presumably political) downvote further up ...

The NSA can do this, yes. But, any CA that issues a fake CA for Google will be found out rather quickly, and then will get blacklisted and lose business.

So while the NSA can technically do that, they only get a few shots cause each one has a high chance of burning the CA.

For lesser sites and narrow targets, this may not be true.

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

#204

Post by kaoD »

schoen wrote: post #187
kaoD wrote: post #160

Earlier quoted context omitted.

No. Self-signed certificates are much worse because they bring a false sense of security. A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. At the moment CAs are the best known way to do that (and before anyone brings certificate pinning or WoT, they come with their own problems, please read this comment of mine https://news.ycombinator.com/item?id=8616766 ). EDIT: Y…

The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats. An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt: http://www.tcpcrypt.org/ So if anyone wants to make progress on opportunistic unaut…

> With some browser behavior self-signed certs could make some users safer against some threats

How exactly? Did you read my linked comment?

As far as I can tell, self-signed certs are always a no-no. As soon as one is compromised and has to be revoked the whole system breaks apart.

The only situation where a self-signed certificate makes sense is when you control both ends of the communication and can revoke the cert on the client yourself.

In the age of WiFi, you can't dismiss active attacks.

EDIT: Again, whoever is downvoting can downvote all he wants but I'm still right. If I am not, prove it via comments, not downvotes, and we'll be able to discuss each other's views.

Even parent's Tcpcrypt link says it is vulnerable.

> By default Tcpcrypt is vulnerable to active attacks

> Tcpcrypt, however, is powerful enough to stop active attacks, too, if the application using it performs authentication.

How are you going to perform authentication via insecure channels without CAs?

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

#205

Post by zorked »

balabaster wrote: post #123

How does a CA that's formed by a conglomerate of U.S. companies (under the jurisdiction of the NSA) make us any safer than we are currently? It doesn't. The chain of trust chains up all the way to a U.S. company, which can be coerced into giving up the certificate and compromising the security of the entire chain. I'm on the side of the EFF trying to encrypt the web, but this is not the solution.

Something like Certificate Transparency would counter that - where the browser can only accept certificates that have been made public record. So the owners will at least know when their domain has been attacked.

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

#206

Post by TillE »

mike-cardwell wrote: post #139

I'm hoping that one day soon, I'll be able to remove this line from my nginx config: ssl_certificate /path/to/file.crt; My web server will notice that I want SSL, but haven't specified a path to a cert. It will then go off and generate one and get it signed automatically using an API like the one being discussed. It will also handle renewing automatically when the time comes.

Automatic unconfigured behavior is bad, but something like a ssl_certificate_auto directive that's in the default config would make a lot of sense.

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

#207

Post by Tossrock »

lowglow wrote: post #3

Free CA? This is cool. Why this wasn't done a long time ago is beyond me. (Also please support wildcard certs) An interesting thing happened at a meet-up at Square last year. Someone from google's security team came out and demonstrated what google does to notify a user that a page has been compromised or is a known malicious attack site. During the presentation she was chatting about how people don't really pay atte…

Google is a CA, and they sign their own certs as "Google Internet Authority G2" under SHA fingerprint BB DC E1 3E 9D 53 7A 52 29 91 5C B1 23 C7 AA B0 A8 55 E7 98.

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

#208

Post by eric_bullington »

mike_hearn wrote: post #39
tatterdemalion wrote: post #36

Earlier quoted context omitted.

I don't see how this actually keeps the CA PKI from being a scam. While I personally trust the EFF & Mozilla right now, as long as I can't meaningfully revoke that trust, it's not really trust and the system is still broken.

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…

>A browser extension could automate this.

Unfortunately, it couldn't on Chrome, because you can't even access a page's certificate from an extension in Chrome:

http://stackoverflow.com/questions/18689724/get-fingerprint-...

And Firefox's certificate API is not much better, only passive access without ability to block connections if you detect an unwanted cert.

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

#209

Post by schoen »

kaoD wrote: post #204
schoen wrote: post #187

Earlier quoted context omitted.

The extent to which this is true depends on browser behavior. With some browser behavior self-signed certs could make some users safer against some threats; with other browser behavior they could make some users more vulnerable to some threats. An opportunistic privacy solution with no legacy installed base to worry about is tcpcrypt: http://www.tcpcrypt.org/ So if anyone wants to make progress on opportunistic unaut…

> With some browser behavior self-signed certs could make some users safer against some threats How exactly? Did you read my linked comment? As far as I can tell, self-signed certs are always a no-no. As soon as one is compromised and has to be revoked the whole system breaks apart. The only situation where a self-signed certificate makes sense is when you control both ends of the communication and can revoke the cer…

Well, the best example I know of is proposals to do opportunistic upgrades from HTTP to HTTPS, for example via a browser header in the HTTP reply. If the browser performs the opportunistic upgrade, and negotiates an HTTPS connection behind the scenes, and doesn't tell the user that the connection was served over HTTPS, then accepting a self-signed cert invisibly in this context makes the user no worse off than not performing the upgrade (and better off against an adversary who's not currently performing an active attack).

I forgot what the current status of drafts proposing this is. Amazingly, I found that Rohit Khare described a form of this mechanism way back in 1998 (so it's not a super-new concept).

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

#210

Post by justcommenting »

schoen wrote: post #195
justcommenting wrote: post #180

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…

agree completely and it's worth noting that i don't have a solution to the issues i mentioned, either.

leveraging other (potentially-insecure) paths to establish trust might help further enhance confidence in authenticity; e.g. verification using something like the broad-based strategy of moxie's perspectives (except via plaintext) or maybe through additional verification of plaintext on the site as fetched via tor or retrieving a cached copy of the site securely from the internet archive or search engines.

dvsni and multipath testing sound quite interesting, and i think defense in depth is the right approach.

having been at akamai's recent edge conference, i didn't hear much from them on this. does anyone have any additional details of their interest in the project?

Post reply on HN