Google: Maintaining digital certificate security

Posted Mar 24, 2015 6:12 UTC (Tue) by ttonino (guest, #4073)
In reply to: Google: Maintaining digital certificate security by josh
Parent article: Google: Maintaining digital certificate security

The CA system is just totally broken. And things like DNSSEC - which might be a better trust anchor - don't seem to fly.

Google: Maintaining digital certificate security

Posted Mar 24, 2015 8:49 UTC (Tue) by marcH (subscriber, #57642) [Link] (8 responses)

> The CA system is just totally broken.

It's not broken; it's only "centralized". As in: the nearest to the center you are, the easier you can spy.

Google: Maintaining digital certificate security

Posted Mar 24, 2015 9:01 UTC (Tue) by ttonino (guest, #4073) [Link] (7 responses)

If only it was centralized. There are way too many CAs. And removing a CA has too much impact on legitimate customers, so CAs are only rarely removed, even if they a make mistake now or then.

Google: Maintaining digital certificate security

Posted Mar 24, 2015 16:57 UTC (Tue) by jeff_marshall (subscriber, #49255) [Link] (6 responses)

Agreed. One of the biggest problems with X.509 is that it was designed to be centralized, but actually has a huge number of trust roots operating independently. Since trust-roots aren't restricted to the domains over which they should have authority, people looking to compromise any given domain can shop for the weakest trust root and compromise/buy-off that one (rather than the CA you actually used).

While DANE isn't perfect, at least it reduces the number of potential points of failure for any given domain (Verisign for .com + whoever you put in your TLSA record). IMO, it would definitely be an improvement if any old cc-based CA couldn't successfully convince my browser that the certificate it just signed was valid.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 12:36 UTC (Wed) by gerv (guest, #3376) [Link] (5 responses)

Since trust-roots aren't restricted to the domains over which they should have authority

They are if you deploy HPKP, which was invented precisely to give sites an opt-in way to avoid this problem.

Gerv

Google: Maintaining digital certificate security

Posted Mar 25, 2015 14:50 UTC (Wed) by cesarb (subscriber, #6266) [Link] (4 responses)

Doesn't HPKP require you to have visited the site at least once before? I wouldn't help if the initial connection was also MITM'ed.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 15:33 UTC (Wed) by gerv (guest, #3376) [Link] (3 responses)

If this is the first time you've ever connected to a site, it's less likely you are going to be doing high value transactions on it. Most web visits are to places people have been before. HPKP is not perfect, clearly, but for sites which adopt it, it mostly removes this risk.

Gerv

Google: Maintaining digital certificate security

Posted Mar 25, 2015 16:24 UTC (Wed) by josh (subscriber, #17465) [Link]

As much as people make fun of QR codes and similar, one of these days, I'd love to see a standard for an easily-scanned barcode that includes not only a URL but the expected public key of that URL. That provides continuity from, for instance, the physical entity of your bank and a secure connection to their website.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 21:05 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

> If this is the first time you've ever connected to a site, it's less likely you are going to be doing high value transactions on it. Most web visits are to places people have been before.

That's not a strong argument.

First, if my home connection (or work connection) is persistently MITM'ed, and I always (or almost always) use it, it's likely that both the first visit and all subsequent visits to any site will be MITM'ed.

Second, let's take a real example: online banking. The first time I ever connect to it, I set up the online password by using the ATM password. The online banking website asks for the ATM password as an extra verification when doing important transactions. That is, the first time I connect to that online banking website is precisely when I need the most for it to NOT be MITM'ed.

Sure, HPKP can remove a lot of the risk in many situations (nomadic devices, MITM starting after you've already visited the site, etc), but there are several situations in which it doesn't help.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 21:34 UTC (Wed) by dlang (guest, #313) [Link]

no security is absolute, but if your home system is targeted by a persistent MITM that's after you and faking the sites you connect to, what are the odds against them doing a black-bag job on your system?

There are a lot of cases where something like this does help, and if it can be coupled with something like the ssh key update things so that planned migrations from one key to another don't generate noise for users, there would be a lot of value in it.

Google: Maintaining digital certificate security

Posted Mar 24, 2015 9:32 UTC (Tue) by Aissen (subscriber, #59976) [Link] (4 responses)

I fail to see how reducing the number of trust anchors (ie DNSSEC root) or putting the burden on TLDs operator will make DNSSEC a better solution.

Google: Maintaining digital certificate security

Posted Mar 24, 2015 9:52 UTC (Tue) by matthias (subscriber, #94967) [Link]

The described attack using a MITM proxy would not be possible, as the MCS CA simply would not be allowed to issue new certificates for my banking website.

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.

Google: Maintaining digital certificate security

Posted Mar 24, 2015 13:45 UTC (Tue) by job (guest, #670) [Link]

The TLD operator is already trusted with delegating ownership of domains. If they say Widget Ltd. owns widgets.com, they do. The legitimate owner is the one the TLD operator says it is. The legitimate owner can get a certificate issued for the domain through _any_ CA world wide.

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.

Google: Maintaining digital certificate security

Posted Mar 24, 2015 16:36 UTC (Tue) by flussence (guest, #85566) [Link]

It's not all about decreasing the number of anchors, but decreasing possible points of breach.

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.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 11:57 UTC (Wed) by rich0 (guest, #55509) [Link]

Right now Verisign can already spoof any .com domain that exists including any SSL certificates it uses. It can additionally spoof certificates for any domain anywhere.

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?