71–76 of 76 posts
http://googleonlinesecurity.blogspot.com/2015/03/maintaining... is a better URL. (For potential future reference, the current URL is http://arstechnica.com/security/2015/03/google-warns-of-unau... )
Earlier quoted context omitted.
> I don't see why the CA wouldn't immediately query logs for all certificates that chain off of their intermediates, to verify that intermediates are only used in the way that people said they'd be used. That's unlikely to happen (I suspect) because the amount of data that would need to be processed would be significant. Each CA would have to effectively mirror all of the logs out there, and the logs impose rate limi…
> Each CA would have to effectively mirror all of the logs out there, and the logs impose rate limits on queries. It would be interesting also to see what happens when a log gets DDoS'ed (we know OCSP servers aren't useful because of that problem). Hrrrm. The data in a log is public; the act of logging needs to be done by the log server, but all output (STHes, audit proofs, etc.) is signed, and thus can be mirrored.…
If you'd be interested in reading a draft of a blog post on this topic, please shoot me an email (see my profile).
Why can the CN registrar sign .com certs? Why aren't national authorities limited to their country's TLD? I'd imagine they'd want this, and the public would want this. Its so obvious, what am I missing?
It seems to me that we have several building blocks available and it may be a combination we need:
1. CERTIFICATE PINNING (HPKP) - example: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-21 - if a browser had previously pinned the certs of affected sites then it would have known that it was going to bogus sites and could have displayed a warning or prevented the user from going to those sites.
The challenge with pinning is that somehow you have to learn what to pin before you visit a site, either by having the pinset or certs pre-loaded into the app/browser or simply by doing Trust On First Use (TOFU). Additionally, if the first use is to the site controlled by an attacker, the cert that gets pinned in the browser could in fact be the attacker's cert, which could make recovery difficult.
Which brings us to...
2. DANE/DNSSEC - http://www.internetsociety.org/deploy360/resources/dane/ - with DANE (RFC 6698) you put a fingerprint (or an entire cert) into a TLSA record in DNS and then sign that with DNSSEC. A browser or app that supported DANE could deal with the TOFU issue by doing a DANE check to verify the cert that it is receiving from the web server. This would then effectively bootstrap the cert pinning process by providing a way to test the validity of the cert.
Because the DANE TLSA records are entered by the owner/operator of the domain and then through DS records are tied into a validated chain-of-trust up to the root of DNS, it would be difficult for an attacker to subvert this with his/her malicious TLSA records.
But we have a third layer to help...
3. CERTIFICATE TRANSPARENCY (CT) - http://www.certificate-transparency.org/ - CT provides a way to log all the issued certs and have browsers/apps check those logs through an auditor. When the browser gets the TLS cert, it also gets a signed cert timestamp (SCT) and can use that through an auditor component to check if the cert is valid. The challenge is that right now only some CAs log issuance of certs and only some browsers/apps check via an auditor. (I also don’t understand myself exactly how real-time CT is, but that may just be that I need to understand the SCT mechanism better.)
To me these three different components can work together to provide a higher degree of trust: cert pinning to help with the speed of connecting to frequently-visited sites; DANE to help with the first use/key learning issue[1]; and CT to provide another means of checking the cert validity.
Comments?
[1] And yes, DANE could be used to store entire TLS certs separately, but right now I’m looking at how these pieces could be used together to give the maximum efficiency and security.