Slashdot Mirror

Chrome does "use" Certificate Transparency, just not in the particular way you believe they should. (BTW, with a road map for the kind of implementation you want.)

And crypto currencies. If you choose to ignore the two biggest uses today then I wonder how many others they "missed" https://www.certificate-transp...

What are the negative impacts of encryption?

I think the right question to ask is "what are the tradeoffs of moving to encryption?". The hardest part about designing a system for the web is that the costs are borne by everyone, while the protection offered needs to fit the most vulnerable person. There is no way for a browser to force the server to behave in a certain way, while the deployment of HTTPS almost exclusively benefits the browsers, not the servers.

To me, the situation is very clear cut, the benefits of universal deployment of HTTPS vastly outweigh the costs. I can understand and respect other people looking at the situation and coming to a different conclusion, but I want to make sure that the facts on the table are correct first.

My experience tells me that the most obvious approach to changing the cost equation, namely negotiating how much security is required in each a given context, will not work. The main limit is that people only defend against attacks they can imagine, and their five seconds of imagination is not as thorough as a billion dollar intelligence agency. Tapping all US backbones to snoop all internet packets and save them for future reference seemed wild until it was a well-established truth.

(Also, having more negotiation simply means more options which are less tested and more likely to be broken in ways we haven't noticed. Like IPSEC tunnels with a billion options that are easy to accidentally run insecurely even with a full team of experts vs. OpenVPN.)

I'll answer your examples point by point.

2) Increased bandwidth requirements as caching servers are rendered moot

This is the one argument against HTTPS by default that resonates with me. Bandwidth problems are real, and caching is important. Unfortunately caches are inherently in conflict with the confidentiality part of security. The cache has to see the response to store it and the cache has to see the request to check the cache. I think the current state of the art is that you can proxy your connection through the cache, if you choose to trust it. This only rules out transparent caches. Designs where either the server or the client has a cache it can trust are workable.

Maybe some day we can use fully homomorphic encryption databases to create caches that don't break the confidentiality guarantees, but that's strictly research material today.

3) Automatic ability to identify you uniquely when using a service

I'm not sure what you're thinking of here? What unique identifier does TLS have that HTTP doesn't? I would expect that encrypting more data means that there's less to use to fingerprint a client?

4) Requires CA (Let's Encrypt helps, but modern HTTPS really does not promise who is on the other end anymore)
6) Most of the "attacks" described could just as easily happen via malware, which is still an issue. This removes only one attack vector and even then incompletely (leading to false sense of security, see 4).

Ah, I see. It's a waste of effort to work on curing cancer because people can still die of AIDS. Even in the field of computer security, we can separate problems and solve them independently, even when there are other vectors that cause the same symptom.

If you think that CAs don't promise who's on the other end, I encourage you to demonstrate by standing up a server that responds with a valid cert for gmail.com. CAs are far from perfect, but they're also far from HTTP. There's policy enforced through audits (and even auditors can be distrusted, third point), and more recently there's technical enforcement too. If you make a gmail.com cert you either don't upload it to the CT log

LetsEncrypt submits all certificates as they issue them: https://letsencrypt.org/certif... More details in cert transparency: https://www.certificate-transp...

If you have an authentication server why do you need or even want block chain.

Seems like people are deafened by the clamor of buzzwords. Heard about the Certificate Transparency project? A certificate audit log is a Merkle tree that is appended to by adding a new root node of which the old root is a child, proving the history has not been tampered with. The end nodes of the Merkle tree are also digitally signed data structures. These two properties give the audit log the same data structure shape as a blockchain.

Furthermore if you want to distribute the authentication to many servers how do you control the authentication list if there's no proof of work. and if there's proof of work, then it gets expensive because that's why its called work

The entirety of the log is issued by a single entity, so each new root can simply be signed by the CA, and all the heavyweight Byzantine distributed consensus cruft such as proof of work that applications like Bitcoin use is completely irrelevant to this use case. Individual certificates can be verified by the embedded digital signature, issuance can be verified by consulting the (also signed) audit log.

Note that this doesn't mean I think Microsoft's project referenced in TFA is necessarily a good idea. I don't know enough about it even after reading TFA to pass judgement on it. That may itself be an artifact of excessive buzzword density.

Google invented a technology that does everything HPKP did, and also handles key rotations, allows you to monitor for someone else issuing keys in your name, doesn't have the "HPKP ransom" vulnerability and actually scales well. You should read about certificate transparency and the Expect-CT header.

It's really gauche to accuse Google of doing anti-security things when they're single-handedly advancing the state of the art and have caught state actors breaking PKI. In fact that's the incident which led Google to invent HPKP in the first place, and they knew the problems with it at the time which is why they then went on to invent certificate transparency to replace it.

HTTPS isn't that safe. Any agency that can coerce one of the numerous CA's can snoop traffic quite easily.

While your concerns are real, I think they're overstated.

A coerced CA cert does allow MITM attacks, but they have to be used very carefully and on a targeted basis, because if they're used too broadly it will be noticed. A TLS MITM attack is very noticeable to anyone who is looking. Google Chrome has caught a few subverted CAs now, thanks to certificate pinning of intermediates for Google, Verisign, GeoTrust and some others. Firefox pins large numbers of intermediates, for lots of domains. I think other browsers are also getting into it.

Of course Eric Schmidt is an avid fan of the surveillance society so thats why they weren't going to back anything less centralised than CA-based HTTPS

Nice cheap shot. In fact Google has a couple of significant projects to address the shortcomings of the CA system. One is to increase pinning, but that's kind of a hack. The other is the Certificate Transparency project, which aims to ensure that any certificate produced by any CA for any domain is visible to the owner of that domain. If that succeeds covert certificate issuance will be impossible.

At bottom, the problem with the CA isn't centralization, it's more complicated than that. The CA system is decentralized in the sense that there are many CAs... but that makes every one of them a single point of failure. In some ways we'd be safer with a truly centralized CA system, because then we'd have one single point of failure rather than a few hundred. The semi-decentralized system we have is pretty decent... if we can enable the world to easily recognize improperly-issued certificates. Certificate Transparency is one good way to do that. I'm also a fan of the Convergence system, but in addition to the existing CA system, rather than as a replacement.

In any case, although the CA system has some issues, and we have seen a handful of cases where they've been exploited, by and large it works very well, securing more connections and more data than anything else ever has. We'd be foolish to replace it, but augmenting it to address the problems is a good idea.

Part of the dynamic here is that the PKI is so fragile that TOFU simply works better.

Cite? I seriously doubt that TOFU would actually work better if it were used on a large scale (SSH is *not* large scale). Key rotation is particularly problematic; by default TOFU just says "no" to key rotation, which is also bad. PKI + TOFU has interesting properties, but key rotation is still a problem.

IMO, what would be best is PKI + Certificate Transparency + Convergence + (limited) TOFU. Marlinspike touts Convergence as an alternative to PKI, but I think it would work better as an additional layer. PKI works beautifully in the common case where CAs behave correctly and don't lose their keys. Adding Certificate Transparency covers the poor key management case (and would have identified these Symantec problems immediately), and Convergence provides further defense against MITM attacks. CT and Convergence server certs should be pinned, of course.

And note that in most cases there's no reason your browser needs to delay the connection while it checks the additional layers. It can go ahead and establish the connection and begin downloading content while it checks with the CT and Convergence servers. It probably should defer rendering until it completes the additional checks, to protect against malicious content... unless it has already visited this site, and seen and checked this certificate (i.e. TOFU), in which case it can proceed with rendering. Though it should probably still check CT and Convergence in the background.

It may seem like I'm suggesting just piling on layers, but each one of them addresses specific problems and each has specific tradeoffs.

It might seem as if there is nothing changing under the hood, but people are actually working on improving things and actually making sure CA's can't issue certificates for your website you didn't want to be issued:

http://www.certificate-transpa...

https://developer.mozilla.org/... (available in the release version of Firefox and Chrome)

https://blog.mozilla.org/secur... (available in the release version of Firefox, Chrome already had something similar)

https://blog.mozilla.org/secur...

https://www.grc.com/revocation...

What this summary neglects to say is that Google is open to the idea of adding them back. Quote (link mine):

[...] CNNIC will be working to prevent any future incidents. CNNIC will implement Certificate Transparency for all of their certificates prior to any request for reinclusion. We applaud CNNIC on their proactive steps, and welcome them to reapply once suitable technical and procedural controls are in place.

Ahahaha, this just says "basically before you can even talk to us again, you'll need to implement Certificate Transparency." That's not reinclusion, that's a requirement for you before you can request to be reincluded.

What this summary neglects to say is that Google is open to the idea of adding them back. Quote (link mine):

[...] CNNIC will be working to prevent any future incidents. CNNIC will implement Certificate Transparency for all of their certificates prior to any request for reinclusion. We applaud CNNIC on their proactive steps, and welcome them to reapply once suitable technical and procedural controls are in place.

Color me paranoid but this sounds like Google is going out of there weigh too weeken encryption in transport. For "national security" in homeland, amirite? God save the homeland!

Huh?

Google has pushed continually to increase the usage and the security of transport encryption. Google's SPDY, the basis for HTTP/2, was designed without any unencrypted mode; it's all TLS all the time. The IETF insisted on making unencrypted transport optional in HTTP/2, but you can be sure that Google won't take that option. Google's next-next generation replacement for HTTP, called QUIC, is a more radical redesign build on UDP rather than TCP, and also has no unencrypted mode. Encryption is baked so deeply into QUIC that it basically can't be removed. Google has also been instrumental in pushing the industry off of various weak versions of SSL/TLS, most recently leading the charge in removing SSL3 support. It was Google's researchers that brought Heartbleed, BEAST, CRIME and POODLE to light. Google Chrome was the first widely-used browser to implement certificate pinning, which was instrumental in the quick discovery of the DigiNotar CA compromise. Google engineers are working to develop a more final solution to the CA trust problem with the Certificate Transparency project. I could go on and on with all the great encryption-related work Google is doing (including my own small contributions to strong crypto on Android).

I think there's an extremely compelling argument to be made that Google is doing and has done more for internet transport encryption security than any other entity for quite some time.

(Disclaimer: I'm a Google security engineer, not a Google spokesperson. The above is not an official statement but only my -- very strongly held -- personal opinion.)

Actually the US Department of Defense and dozens of other governments have their own CAs with which they could issue a certificate for your domain, if they wished to. Here's a map we made of them using our SSL Observatory datasets.

Nonetheless we should be able to use publication mechanisms such as Certificate Transparency to ensure that any compromise or compulsion of the Let's Encrypt CA could be quickly detected.

I don't mind DigiCert, as long as they will participate in Certificate Transparency.

Very soon; I will not want to trust anything issued by a Certificate authority that does not participate in Certificate Transparency.

I wonder which ones are already subverted.

None of the leaked documents from Snowden appear to mention compromised CA's, or at least no kind of compromise at scale. This is most likely because (1) CA's are not the weakest link, the browser security is and (2) they need to find their targets traffic streams before they can do the MITM attack, which would mean doing MITM on all SSL connections which would be detected almost immediately. A compromised CA would be useful only if they were unable to exploit the targets computer, and they needed to view SSLd traffic anyway, which does not appear to be a common situation for them circa 2013.

Google has only one way to know if a CA is trustworthy: running its own.

No. They can develop a system that involves every certificate produced by every CA being published in public audit logs, and then make Chrome verify that any given cert is in those public audit logs, thus allowing savvy site operators to find fake certs issued in their name (also useful for old fashioned phishing). And in fact that's exactly what they are doing.

Yes, indeed. This meme that SSL is broken or useless is very damaging and needs to end.

The fact is that despite all the handwaving and noise, nobody has yet presented proof that a CA has been subverted by intelligence agencies, let alone knowingly. It's certainly possible that this has happened and one may think it is even likely, but in the absence of any proof it's hard to credibly argue the entire system is hosed.

The difficulty of course is finding such a proof. If a CA was found to have been routinely issuing certificates to intelligence agencies, it's very very likely that browser makers would revoke that CA and destroy the business. Their written policies are quite clear on this point and do not make governments special, that's why GoDaddy revoked LavaBit's SSL cert after learning the private key had been disclosed to the FBI. So far we don't have any evidence that the NSA or GCHQ were willing to risk destruction of a civilian business in order to reach one of their targets - though I guess there are still plenty of Snowden disclosures to come.

But even if there have been such certs issued, SSL is not useless. Firstly, it raises the complexity a lot. And secondly, there are initiatives underway to prevent subversion even by multi-billion-dollar intelligence agencies. For example the certificate transparency initiative is intending to upgrade the certificate format to contain a proof of inclusion in a public log. Browsers will start requiring the presence of these proofs in future, and thus it will no longer be possible to issue secret SSL certs that nobody can see except the victim. This is a large, complex upgrade of a massive infrastructure so it will take years, but eventually this system will raise the bar for SSL attackers to the point where they will either have to give up, or actually pass new laws that formally subvert SSL to the will of governments (at which point of course it does not matter if they are detected and there is no need to compromise CA's).

Which will happen is an open question at this point. However, Slashdot should get its ass into gear and switch on SSL and HSTS by default. Saying it's an option for logged in users just isn't good enough, especially when that option is so well buried I can't actually find it! SSL all the time should be the default, these days, there's just no reason not to anymore.

Certificate transparency is a new project initiated at least partly by Google's engineers, which intends to solve this problem with SSL trust model: http://www.certificate-transparency.org/
It uses an append only public log, similar to Bitcoin transaction log to make certificate information public.