4 ms·
With the current CA system, you have to worry about far more than just the CAs. An attacker just needs to MITM the connection between the target website and a
by ynik 11y ago
With the current CA system, you have to worry about far more than just the CAs.
An attacker just needs to MITM the connection between the target website and a CA of his choosing, and the CA will give the attacker domain-validated certificates for the target website.
So the current SSL in browsers can be compromised not just by the 600+ CAs, but also by anyone who can launch MITM attacks on the internet (e.g. the thousands of ISPs who can publish BGP routes).
For email-based domain validation, the attacker doesn't even need MITM capabilities -- catching the domain validation email in passive bulk data collection is sufficient. The NSA can trivially get valid certificates for arbitrary domains even without the cooperation of any CA! And if the attack on the target website is discovered, it would look like $RANDOM_CA is to blame, even when the CA did nothing wrong (unless you consider the whole idea of domain-validated certificates to be wrong).
DNSSEC+DANE has the potential to be much much more secure than the status quo.
The problem is that no one wants to be the first to implement client-side DNSSEC validation and get blamed for failing to connect to incorrectly configured domains.
- deleted 11y ago[deleted]
- ikeboy 11y agoIs there a way to see if any CA has issued a cert for a site? If all CAs posted the certs they sign to some database, then there could be services that alert you and you'd know right away and raise an alarm. If such a system doesn't exist, why not?
- realityking 11y agoCertificate Transparency (http://www.certificate-transparency.org http://www.certificate-transparency.org) is a Google initiative working on just that. It's already required for EV certs in Chrome.
- ikeboy 11y agoHave any CAs publically committed to submit all their generated certs to that? Does https://pki.google.com/ https://pki.google.com/ do that?
- geofft 11y agoChrome currently requires that all extended-validation certs with an issuance date of 1/1/2015 or later be submitted to the CT logs. (Otherwise it will not show up in the UI as an EV cert.) As with all browsers, only a subset of CAs are trusted to provide EV certs in the first place, regardless of whether they include the EV bits in the certificate. And this policy only applies to EV certs, not to all certs by an EV-capable CA.
- Caer 11y agoWith some exceptions, at least. For example, twitter.com shows up as an EV green bar while my browser tells me there's no CT information available. The CT website mentions a list of exceptions would be generated but I haven't been able to find any public list, and there's been no update to their rollout plans in over 7 months[1]. Oddly enough I noticed the other day that certificate-transparency.org isn't even accessible over https. [1] http://www.certificate-transparency.org/ev-ct-plan http://www.certificate-transparency.org/ev-ct-plan
- geofft 11y agoThe twitter.com cert I see in my browser was issued on 9 September 2014, which is before the 1 January 2015 threshold. (Eventually this should go away because a compromised CA key can obviously just lie about the time, but this is just a migration step.)
- Caer 11y agoYou're right, I missed that at the top of the doc. I assumed all of the details would be in the numbered list.
- geofft 11y agoI think a good chunk of the foot-dragging on CT has been a concern about customers not wanting certs for private names to be publicized (yet wanting publicly-valid certs for those names). It's unclear if there are concrete customers with this actual concern, but the argument goes that if Uber gets a cert issued for lyft-acquisition.uber.com in advance of an announcement, they don't want that leaked in CT logs. The current Internet-Draft for RFC 6962bis allows them to register this in CT logs as "?.uber.com", which is enough for Uber's sysadmins to raise an alarm if something matching that pattern was issued without their knowledge. https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08#section-3.2 https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-08#...
- tptacek 11y agoThat is inaccurate. Several mainstream vendors have implemented DNSSEC+DANE clientside resolvers. Chrome had one. OS X briefly had one. They were removed. DNSSEC was implemented on mainstream platforms, then taken out.