Google: Maintaining digital certificate security

If something is signed by a valid CA that users worldwide may end up accepting without question, that's a different story entirely.

If you want to MITM, nobody is stopping you. Sometimes it's necessary. And that's why you use your own certificate chain and add it to the machines somehow (even on BYOD setups).

Generating a certificate for a MITM that is signed by a CA that browsers trust by default, that's just stupid. Sure, it lets you sniff "unknown", and that's exactly the problem. You just broke the chain of trust, deliberately and knowingly. Thus, you have no right to be a CA.

And THIS is why places like Google publish their certificate hashes and have their browsers check for the correct hash so they aren't MITM'd unknowingly.

Has the company disclosed, in a meaningful fashion, to users of its network that this is happening? Do they understand a third party is intercepting their Google (and banking and whatever else) login? What checks and controls does the company have to ensure the interception is used for legitimate purposes rather than, say, a rogue security officer stealing banking details?

Maybe this would not help much against NSA, as they might be able to steal the secret key of the root CA, but this helps against all those little criminals, that just want to break my banking security to empty my bank account.

With SSL it is enough to get hold on the private key of one of the thousands of sub-CAs available. With DANE (ontop of DNSSEC), the attacker needs access to the root key, the key of the TLD, or the key of my bank. I would feel much better if I just have to trust these three instances, instead of the thousands of CAs out there.

What DNSSEC allows is this issuance to be made cryptographically secure, so Widget Ltd. can prove that they are indeed the legitimate owner of widgets.com. And DANE hijacks this cryptographic assurance to transfer TLS keys.

For all practical purposes, this system does not place more trust in TLD operators as they already have the power to delegate (and by extension, get a certificate for) a domain. In a DANE-only system, you would remove or reduce the complete trust in every CA world wide. But no one is currently proposing that, and it's not going to happen overnight.

However, not many are using it, which shows. There is a big push to modernize TLS right now (RC4 and SHA1 is out, ECDHE and GCM is in, for example), and no one is really looking at DNSSEC.

DANE as currently specced can be used in two ways: ignore a compliant user-agent's pre-trusted CA list entirely (leaving the DNS as the sole chain of trust), or augment it as a whitelist where the TLSA records have to match the site and CA certificates presented.

The latter would require an attacker to not only MITM with a "trusted" certificate in the browser's store, but also do the same for DNSSEC.

Using DNSSEC for SSL certs would still give them the same power over .com, but it would eliminate its ability to spoof anything outside of that domain.

Then if a website owner doesn't trust Verisign, then can just avoid .com.

There is no simple solution to PKI that doesn't involve trusting somebody. However, using a hierarchical system tied to DNS at least greatly reduces the amount of trusting that you have to do. Right now navy.mil has to trust some Chinese CA to not spoof it, and vice-versa. In what world does that make sense?

>That's not even close to the same category as CAs abusing their position of trust to enable MITM attacks. Why fault the only zero-cost CA for charging for something that actually incurs a cost on their end, when every other CA charges for certificates in the first place?

Part of the supposedly rigorous NSS database inclusion process is that any enrolled CA is *required* to issue revocations for any certificate if it becomes known they've been compromised. There's no clause about compensation, and I'm not satisfied with that assertion that throwing a few keys in a CRL until they expire months later is unfairly costly to maintain either. They'd be getting positive PR for their expense in any case.

A few users gave evidence of breaches happening to StartCom and got brushed off with a "pay up or get lost" prewritten reply. At least one user went as far as posting their private key in a Github repo to make a point - amusing but also had no result. So, now, there's undeniably compromised certs in the wild with StartCom's brand name and browsers' trust attached to them. The complete indifference on the corporates' part should be a huge red warning flag.

> TLS seems fine, as long as you kill off the CA model and replace it with a more sensible scheme. What would you suggest replacing TLS with?

Anything a bit closer to the web and reality than ASN1 (itself a rich source of nasty bugs) and X.509. libsodium looks like a good starting point.

I'm also not a fan of the STARTTLS command - it's something that can conveniently go missing without detection, depending on the protocol it's used in. Secure should be the default, compatibility be damned.

My understanding is that you can't even issue a new key for a domain without paying them to revoke it.

The problems are:
1. Their users have incentive to continue to use potentially-compromised keys because it costs money not to do so.
2. Even if their customers somehow switch to a different key the old key remains valid, and can be used to compromise anybody who trusts them as a CA.

and

3. Anytime somebody brings up the issues with CAs costing money people always trot out StartSSL and say "hey, you can use these guys for free!" The problem is that you can only do that if you don't follow good security practices.