On Thursday, July 20, 2017 at 8:13:23 PM UTC-5, Nick Lamb wrote: > On Friday, 21 July 2017 01:13:15 UTC+1, Matthew Hardeman wrote: > > As easily as that, one could definitely get a certificate issued without > > breaking most of the internet, without leaving much of a trace, and without > > failing domain validation.
> One trace this would leave, if done using Let's Encrypt or several other > popular CAs, is a CT log record. Google has pushed back its implementation > date, but it seems inevitable at this point that certificates for ordinary > web sites (as opposed to HTTPS APIs, SMTP, IRC, and so on) will need to be > submitted for CT if you expect them to work much beyond this year. The most > obvious way to achieve this is for the CA to submit automatically during or > immediately after issuance. Indeed, I should have better qualified my "without leaving much of a trace". CT logging would absolutely catch this issuance from many CAs today (and presumably from all of the publicly trusted CAs sometime in 2018.) I think the public at large, the security community, and even the CA community owe a debt of gratitude to the Googlers who brought CT to bear and the (primarily) Googlers who are doing / have done so much to drive its adoption. In the period since around 2014, as CT logs depth of coverage has increased, entire categories of misissuance and significant misdeeds have come to light and proper responses have been made. Having said that, I meant to refer particularly that if carefully orchestrated there would likely be no forensic trace that could be reconstructed to identify the party who successfully acquired the certificate. Indeed, but for the fact of the issuance, should a domain owner who knows that the certificate was not requested properly become aware of the issuance, it is unlikely that a skilled and brief hijack would even get noticed for someone to begin trying to investigate. Even still, in many instances a skilled attacker would be able to scope the advertisement carefully enough that a single validation point could be tricked while managing to miss having the route propagate to any of the systems that might meaningfully notice and log the anomalous route advertisement. What I meant by "without a trace" is that in the case of an artful and limited-in-scope IP hijack, a CA exploited as in my hypothetical might well be called to present evidence in a court room. Should they need to attest to the veracity that this certificate represents the party in control of eff.org on the date of the issuance, said CA would likely present an evidence file which perfectly supports that it was properly issued to the party in control of eff.org. Nothing in the CA's logs -- at least presently -- would be expected to hint at a routing anomaly. Further, from the network side of the equation, I strongly suspect that if a CA, questioning whether there was an anomalous route for the few minutes surrounding request and issuance of the suspect certificate would, even mere days after the issuance, be able to get any conclusive log data from their ISP as to 1) if a route change encompassing the IPs in question occurred at all at said specific time and (even less likely) 2) which of their peers introduced what prefix specifically and when. To the extent that MOST service providers log individual announcement / withdrawal of individual prefixes, (many don't persist this for any time period at all), these logs are terribly ephemeral. It's voluminous and generally is of low value save for in the moment. It's also in a category of records that the ISP has every incentive to have for their own diagnostics and debugging for a very brief period and every incentive NOT to keep for longer than very strictly needed as when knowled ge that you have it gets out, it will lead to burdensome requests to produce it. > Now, most likely the EFF (if your example) does not routinely check CT logs, > and doesn't subscribe to any service which monitors the logs and reports new > issuances. But a high value target certainly _should_ be doing this, and it > significantly closes the window. In as far as they're a major sponsor and participant in the Let's Encrypt community (they author/maintain the certbot client, right?), I would be shocked if they didn't monitor such things, at least periodically. > DNSSEC is probably the wiser precaution if you're technically capable of > deploying it, but paying somebody to watch CT and tell you about all new > issuances for domains you control doesn't require any technical steps, which > makes it the attractive option if you're protective of your name but not > capable of bold technical changes. Sadly, I did some quick checks on quite several top domain names. Out of a quick search of Twitter, Amazon, Google, Ebay, and PayPal, only paypal.com has implemented DNSSEC. I presume there must still be too many badly configured or badly implemented validating resolvers which always fail validation and break things. It seems many exceptionally technically talented owners of very high value domain names aren't signing their zones as yet. Having said that, for those domains that do implement DNSSEC, I concur that many risks are mitigated. Indeed, a combination of proper DNSSEC implementation, CAA, and picking the right domain registrar and right security options for the management access to those domains at said domain registrar, probably eliminates most risks of domain hijack via either registrar hijack as well as DNS server IP hijacks. (For even small owners, domain registration at domains.google.com protected by a Google user account with U2F based 2FA enabled is very accessible economically, not difficult to set up and maintain, and probably way above average as far as overall security posture goes.) That said, presently DNSSEC implementation prevalence is quite poor. Meanwhile, knowing retrospectively (especially if it occurs in within minutes to hours of misissuance) via CT that a bad certificate has issued can at least make it possible to warn your user base of a risk they may encounter. Sadly, the state of revocation today makes revocation almost entirely ineffective, especially for DV leaf certs. I do believe that OCSP must-staple will eventually fix this problem. That said, OCSP must-staple will require good server-software support which is just now in its infancy. (By that I mean that competent non-IIS solutions for OCSP must-staple are only just recently available.) I believe it will be at least another 3 to 5 years before the default packed-in HTTP server software in major distributions and stacks will have good OCSP stapling support out-of-the-box. Meanwhile I think there is some value to exploring risks, vulnerabilities, and mitigations with a view to splitting these down a dividing line: 1) those matters a reasonable web domain owner / operator can implement themselves to improve their property's security posture and 2) those risks over which a normal site owner/operator can have no influence over whatsoever and further that the normal site owner/operator is unlikely to even be aware of the existence of said risks In those which the site owner/operator can influence: 1. Domain Registrar could get hacked - Starts with picking a domain registrar who is behaving in a manner which suggests that the registrar overall at the registrar administration level is not going to be compromised. 2. Domain owner/operator's account at registrar could get hacked - Having picked a security conscious domain registrar, the owner/operator must properly secure his account and account recovery options to ensure no unauthorized changes occur to the domain registration by defrauding access by impersonating the owner/operator to the registrar. 3. DNS servers could get hacked - Maintain strong security over the authoritative DNS servers themselves, whether you run the servers or just have access to modify your records. 4. IP space of DNS servers could be hijacked - (Iffy) Properly implementing DNSSEC, but I don't really count this as yet because the lack of deployment by the big boys you would expect would implement first makes me think that there's a compat issue I'm just not fully versed in. Those which the domain owner/operator can not influence: 1. IP space hijacks allowing spoofed DNS responder to become authoritative - Other than DNSSEC, the average site operator is totally powerless and largely blind on this. In as far as significant risks exist for which the site owner/operator is powerless to mitigate, and probably also because the subject matter aligns to some of my own expertise and operational experience, I believe that an examination of the risks and mitigations of IP space hijacking should be a topic of engagement in the community, with a view to closing gaps that only the community (and consensus from the community driving action by the various actors in the CA ecosystem) can resolve. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
