Live data from Hacker News

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

eff.org

231–240 of 476 posts

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

#231
post #199

Earlier quoted context omitted.

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

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.

Both GnuTLS[1] and Nginx[2] have length hiding implemented. But AFAIK OpenSSL doesn't have it yet, so most users are still left in the dark.

[1]http://www.manpagez.com/info/gnutls/gnutls-3.2.10/gnutls_180...

[2]http://nulab-inc.com/blog/nulab/securing-nginx/

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

#232
post #220

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 reason to encrypt your public product catalog pages. Leave them on "example.com" unencrypted. Of course this is true in theory, but in practice, both clients and customers get 'warm fuzzies' from seeing that green lock in the URL window. It let's them 'know' that the company they are dealing with is at least somewhat reputable. Whether this is true or not doesn't matter; it is the perception many people…

i think the realpolitik/"not really caring about users" rationale is more "when someone MITMs the person browsing your company's catalog, it still makes your company look bad". and in my opinion, it should.

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

#233
post #212
post #209

Earlier quoted context omitted.

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

Although such scheme is indeed safer than HTTP (protects against passive attacks), what you're describing is not self-signed certificates, but merely encryption (with new random _unathenticated_ keys per session). Keys would be exchanged via Diffie-Hellman as usual, but a certificate wouldn't be involved since it's useless anyways (you can't certify anything in such a scheme, why bother at all?) and thus would be vul…

I agree that the certificates don't serve any useful function in this scenario; they might be required pro forma, but they aren't actually doing anything helpful.

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

#234

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

[deleted]

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

#235

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?

In this case, SSL protects against MITM attacks. If a customer goes to the unencrypted "example.com" site and gets a bunch of ads for porn, it will give the customer a negative impression of the company. All it would take is a few pitchfork-wielding high-profile twitter accounts to cause a PR nightmare. Even if the cause is a hacked coffee shop wireless access point, it may be hard to restore public opinion.

That scenario is a long-shot, but in my opinion, the potential negative consequences outweigh the time and energy required to set up SSL (especially since a basic SSL certificate is free).

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

#236
post #114

Earlier quoted context omitted.

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

> FWIW, (valid) rogue certificates have been found in the wild several times, CAs have been compromised etc. ... And it's only going to get worse as SHA-1 become more and more affordable to crack.

The CAs have agreed to stop using SHA-1 by 2016, and Let's Encrypt will launch with something stronger on day one.

But SHA-1 attacks are going to be a huge problem all over our protocol stack :(

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

#237

I couldn't be happier about the news, the EFF and Mozilla always had a special place in my heart. However, the fact that we have to wait for our free certificates until the accompanying command line tool is ready for prime time seems unnecessary. Another thing I'm interested in is whether they provide advanced features like wildcard certificates. This is usually the kind of thing CA's charge somewhat significant amou…

The thing that's causing the delay is not the client software development, it's the need to create the CA infrastructure and then perform a WebTrust audit. If we were ready on the CA side to begin issuing certificates today, we would be issuing them today.

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

#238
post #231
post #199

Earlier quoted context omitted.

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

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. Both GnuTLS[1] and Nginx[2] have length hiding implemented. But AFAIK OpenSSL doesn't have it yet, so most users are still left in the dark. [1] http://www.manpagez.com/info/gnutls/gnutls-3.2.…

Thanks, I didn't realize that process was so far along!

It might still be challenging to get large sides to adopt padding that will increase the amount of traffic they send (of course, the idea of reducing the efficiency of compression has the same net effect). But it's great to know that there's already a tool in place for traffic padding, at least in some implementations.

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

#239

This is an awesome idea. But I thought the whole idea of a certificate authority is so that we can trust that the CA has vetted the person/site that they have given the certificate to. If all they do is issue certs for free, all we get is encryption, but no identity verification.

With basic certs, the CA just verifies that the entity controls the website the cert is being issued for. The OP explains how Let's Encrypt will do that. (And if they appeared not to be doing that, no software vendors would include the CA in the trust list).

With an "Extended Validation" cert, the CA additionally verifies that they are who they say they are on the cert (not just that they control the (web)sites the cert was issued for). I'm not sure if Let's Encrypt plans on issuing EV certs, but if they are, they will have to comply with whatever verification standards are standard, in order for vendors not to revoke them from trusted stores. Same as anyone else.

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

#240
post #91

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.

It's primarily because of the interactive challenge to prove that you control the domains you're requesting the cert for. If you want, the client can just give you the cert at the end instead of installing it. In the common case for a user who's not currently comfortable with the process, the client is automating several things -- generating a private key and CSR, proving control of the domain, and installing the key…

It would be really helpful if your how it works page explained in detail how it works, in particular that all browsers are covered, that a key and csr are generated, the certs recd, and that the private key never leaves the server (I'm assuming that at present).

My dream cli tool would just generate key, get certs, and dump them in the dir of my choice. The server config is nice to have but not really essential or the hard part.

Really looking forward to seeing this happen, is there any beta program at present?

Post reply on HN