That's a great idea and I'm a big fan of the EFF. But what browser support will this have? Even if all browser on all platforms add this to their root certificates, how many years will it take before even half of the devices in use support it (remember the number of people still using windows XP!)
Launching in 2015: A Certificate Authority to Encrypt the Entire Web
341–350 of 476 posts
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#342Earlier quoted context omitted.
How would you rotate keys with that scheme?
You'd need a strong root key and subkeys that rotate underneath. To change the root key would require signing by the original root and a new message to appear for confirmation. All this plus something like a notary system to double check all your trusted root keys, would be much better than the hierarchical CA system we have.
Which root keys? The ones you store on your web server, which just got compromised?
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#343Earlier quoted context omitted.
Out of curiosity, what if MITM says, "include me in this list for IP "? If the check is not done in a way that solves the byzantine generals problem, I don't see how this feature provides any more protection, other than one more hoop to jump through.
Certificate Transparency tries to solve the Byzantine Generals problem (up to high levels of collusion). Take a peek at their design -- it's pretty interesting! It does rely on the legitimate site owner actively checking the records to notice the misissuance. Maybe that process could be automated somehow.
Is that automation not what the monitors and auditors do? http://www.certificate-transparency.org/what-is-ct
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#344Earlier quoted context omitted.
> Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I kno…
There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com. A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.
This is the problem that pinning is intended to solve.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#345That's a great idea and I'm a big fan of the EFF. But what browser support will this have? Even if all browser on all platforms add this to their root certificates, how many years will it take before even half of the devices in use support it (remember the number of people still using windows XP!)
It's initially cross-signed by IdenTrust, which has wide browser support today.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#346Earlier quoted context omitted.
So this is where we stand: Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME I think there's a pretty blatant antipattern here, and I'm not talking about colourblind-proofing the browser chrome.
> Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I kno…
>> Encrypted (Certified) COOL GREEN
> I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.
Maybe. I just checked my browser and it already trusts more than 100 certificate authorities from all around the world, including some companies that I don't trust, some governments that I don't trust, but mainly composed of organisations I've never heard of. Even in a good system, there would occasionally be leaks etc, but this mess of promiscuous trust is clearly insane.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#347Earlier quoted context omitted.
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 redirecti…
>The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session Could you elaborate here? With a self-signed cert, the server is still not sending secret information in the first few packets; it just tells you (without authentication) which public key to use to encrypt the later packets (well, the public key to encrypt the private key for later encryption). T…
There are no such attackers.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#348Earlier quoted context omitted.
How would a browser know that the the self-signed certificate that was just presented for www.mybank.com is intended to be self-signed (show no error, but also show no padlock) or whether it's the result of a MITM attack because www.mybank.com is supposed to present a properly signed certificate (show error)? How would you inform people going to www.mybank.com which is presenting a self-signed cert in a way that a) t…
If the user typed www.mybank.com, let the server redirect to https but don't show the lock icon if it's self-signed. This is no worse than an impostor that just doesn't redirect to https. If the user typed https://www.mybank.com , show the usual warning for self-signed certificates.
How many people are careful to type "https" every time they visit a website? How many people pay close attention to the lock icon/color of the URL bar? This advice seems to ignore the existence of sslstrip [0] and related attacks, and the numerous countermeasures that have been designed to deal with this problem (e.g. HSTS).
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#349Earlier quoted context omitted.
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…
Let's Encrypt can run a web spider - crawl the web to build a database of actively used domain names. Periodically poll DNS for the list from that database to obtain the NS records for pretty much all of the web, and also A records for all the actively used hosts you find in the crawl. Keep this cache as a trace of how DNS records change. Now, do the DNS polling from several different geographic locations. Now you've…
Thanks for the interesting suggestion -- I'll mention it to the people working on the CA implementation as a possible validation technique to consider.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#350Earlier 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…
>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.
> And Firefox's certificate API is not much better, only passive access without ability to block connections if you detect an unwanted cert.
Nope. Firefox's Addon API lets you do pretty much whatever you want. It might be kind of hard and annoying, but you can certainly block connections that are signed by an untrusted CA. How do you think Convergence [0] worked?