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 

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 

> 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

Reply via email to