Live data from Hacker News

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

eff.org

411–420 of 476 posts

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

#411

Earlier quoted context omitted.

> Tell me how the logic works here (for an average user). "Neutral Chrome" is the default state of the web -- the site doesn't assert that it should be trusted, and it shouldn't be, and that's the default state people should have in approaching the web. "Cool Green" is "the site asserts that it has a particular identity and that communication with that identified site is private, and it passes the tests built into th…

Plaintext is zero security. Self-signed is a low probability of security. Signed is a high probability of security. This continuum makes more sense than the current state of affairs.

If someone forwards plaintext, it's called a proxy.

If someone forwards encrypted content on behalf of my server, it's called man-in-the-middle attack, and they should not be capable of doing it without the huge red flags.

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

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

My browser also offers me to accept any self-signed certificate, I can investigate it and then I can accept it and it won't ever bother me again, until the certificate changes.

The problem is that this is a huge hassle for incidental visitors. Whereas SSH does not have incidental visitors. Same goes for email, if it's your own server, you know the cert to be the real one, and you can accept it, you're not bothered again.

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

#414

Earlier quoted context omitted.

You don't need a new IPv4 address for each cert. That's for Windows XP. Just stop giving a shit about XP and use SNI. Problem solved.

Try telling that to any business. XP's marketshare worldwide is between 10-20% according to some metrics (cursory google result: http://www.netmarketshare.com/operating-system-market-share.... ) There are very few companies out there that are okay with serving 1/5th of their potential customers an error page, and for good reason.

Looking at a recently created map by cloudflare (http://blog.cloudflare.com/introducing-universal-ssl/ http://cloudflare.github.io/sni-visualization/) it looks that a large portion of that seems to come from china.

A quick glance over EU countries reveals that more than 91% of potential users support SNI.

It might depend on your line of business but I think for some entities this might be a viable option

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

#415
post #293

Earlier quoted context omitted.

That's the third comment of yours in which I've seen you taunt downvoters via edits in this thread alone. That's why I'm downvoting you. Knock it off, please.

I'm sorry it came across as a taunt, I didn't mean it like that. Downvote sprees without an explanation detract from healthy discussion since they basically mean "I'm so mad about how wrong you are that I don't even care about why you think you are right". I guess I'll just ignore them...

Do please ignore them. That's what the HN guidelines ask.

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

#417
post #313

Earlier quoted context omitted.

Stopping snooping by encrypting without strictly checking certificates the first time you connect is better than not using encryption because it stops dragnet surveillance. Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).

That would make dragnet surveillance easier. Just MITM everything and you'll be the Trusted Source™ for all traffic.

No, that does not make dragnet surveillance easier. Dragnet surveillance depends on not being easily detectible. However, a SSL MITM attack is easily detected, as it changes the fingerprint of the SSL-key of the site you're talking too. By recording fingerprints and comparing them over time or for different users, or directly contacting the site's operator (using a secure communication channel, e.g. meeting him in person), the existence of a MITM is easily proven.

BTW what you call "dragnet surveillance" is better described as "Pervasive Monitoring", see also RFC7258 "Pervasive Monitoring Is an Attack" [1].

[1] http://tools.ietf.org/html/rfc7258

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

#418

Earlier quoted context omitted.

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.

Google is indeed in a (unique) good position to detect and possibly prevent a fake certificate, but we don't know if that's what they want or whether they can be coerced to cooperate. Millions of other websites are not protected in the same way.

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

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

Here's one thing that's NOT the solution: throwing out all encryption entirely. Secure vs insecurse is a gradient. The information that you're now talking to the same entity as you were when you first viewed the site is valuable. For example it means that you can be sure that you're talking to the real site when you log in to it on a public wifi, provided you have visited that site before. In fact, I trust a site that's still the same entity as when I first visited it a whole lot more than a site with a new certificate signed by some random CA. In practice the security added by CAs is negligible, so it makes no sense to disable/enable encryption based on that.

Certificates don't even solve the problem they attempt to solve, because in practices there are too many weaknesses in the chain. When you first downloaded firefox/chrome, who knows that the NSA didn't tamper with the CA list? (not that they'd need to)

Post reply on HN