Live data from Hacker News

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

eff.org

221–230 of 476 posts

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

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

>So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown.

Maybe a security-conscious person thinks that, but the typical user does not knowingly choose http over https, and thus the danger of MitM and (unaccepted) snooping is at least as large for the former.

So it's somewhat debatable why we'd warn users that "hey, someone might be reading this and impersonating the site" for self-signed https but not http.

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

#222

Who will handle abuse complaints and revocations of known bad actors? I'd be curious to see who's abuse department will be handling those issues.

What kind of abuse where you thinking about? If the domain is hijacked, you simply repossess the domain and request a new certificate and the old one is revoked.

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

#223
post #200
post #104

Earlier quoted context omitted.

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.

Security-wise, if they are both vulnerable to trivial exploits, how can you say one is "more secure" than another?

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

#224

The EFF has a bad track record in this area. The last time they tried something to identify web sites, it was TRUSTe, a nonprofit set up by the EFF and headed by EFF's director. Then TRUSTe was spun off as a for-profit private company, reduced their standards, stopped publishing enforcement actions, and became a scam operation. The Federal Trade Commission just fined them: "TRUSTe Settles FTC Charges it Deceived Cons…

> There's no particular reason to encrypt traffic to most web pages

how about the SPDY protocol and the faster speed it offers?

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

#225
post #102
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…

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.

Reddit discussion about this, with much of the same arguments there as here (and talking past each other just as much):

http://www.reddit.com/r/ProgrammerHumor/comments/2l7ufn/alwa...

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

#226

The EFF has a bad track record in this area. The last time they tried something to identify web sites, it was TRUSTe, a nonprofit set up by the EFF and headed by EFF's director. Then TRUSTe was spun off as a for-profit private company, reduced their standards, stopped publishing enforcement actions, and became a scam operation. The Federal Trade Commission just fined them: "TRUSTe Settles FTC Charges it Deceived Cons…

> If it's public static content, what is SSL protecting?

Comcast was recently caught injecting self-promotional ads via JavaScript injection. Sites using HTTPS are immune from this sort of attack. [1]

[1] http://arstechnica.com/tech-policy/2014/09/why-comcasts-java...

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

#227

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 welc…

The blockchain can't fix this problem - it's too large for most embedded devices, which do matter. It isn't a solution just because it's a 'cool new crypto idea' to every problem on the planet. Just because something uses crypto doesn't mean adding the blockchain to it makes it any better.

> The blockchain can't fix this problem - it's too large for most embedded devices

That's a wise observation, which is why we are making it accessible to such devices over a MITM-proof connection via DNSChain:

https://github.com/okTurtles/dnschain

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

#228
post #222

Who will handle abuse complaints and revocations of known bad actors? I'd be curious to see who's abuse department will be handling those issues.

What kind of abuse where you thinking about? If the domain is hijacked, you simply repossess the domain and request a new certificate and the old one is revoked.

As in, revoking a cert for a known C&C box, or a confirmed spammer, confirmed box serving an exploitkit, confirmed phishing domain (such as my-apple-ikloud-verify.foo)

Basically, my assumption is they won't want to be providing certs to known bad actors. So I'm curious who is going to own the abuse handling for the CA.

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

#229

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 welc…

The blockchain can't fix this problem - it's too large for most embedded devices, which do matter. It isn't a solution just because it's a 'cool new crypto idea' to every problem on the planet. Just because something uses crypto doesn't mean adding the blockchain to it makes it any better.

Hmm, I'm not sure exactly how the parent intends using it, but isn't something like the blockchain (i.e. a publicly auditable log of all changes to certificates) already being proposed for improving the current PKI infrastructure? Also, is the problem you have for embedded devices that they can't afford to download, store, and verify the full bitcoin block-chain? Surely there are compromise solutions that could be made? Not denigrating your comment btw, it's an interesting observation!

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

#230

The EFF has a bad track record in this area. The last time they tried something to identify web sites, it was TRUSTe, a nonprofit set up by the EFF and headed by EFF's director. Then TRUSTe was spun off as a for-profit private company, reduced their standards, stopped publishing enforcement actions, and became a scam operation. The Federal Trade Commission just fined them: "TRUSTe Settles FTC Charges it Deceived Cons…

TLS gives you authenticity and secrecy; those seem like useful defaults, and in 2014, I think the question should be "how?" rather than "why?" It seems this project aims to address some of the process headaches and cost barriers that currently deter some from using TLS by default.

I do think behind-the-CDN interception, in-front-of-the-CDN compromises, and weak CDN crypto are all serious concerns. I won't name any names here, but the employment histories of major CDNs' security team members definitely deserve closer scrutiny by civil society groups and reporters, especially those interested in fighting mass surveillance.

But overall, I think it's important to respect the privacy and security of users first, and work toward solving the engineering problems that need to be solved in order to affirm that commitment to users, as these folks have tried to do.

Post reply on HN