On Wed, Aug 15, 2018 at 11:41 AM Jakob Bohm via dev-security-policy < [email protected]> wrote:
> On 14/08/2018 02:10, Wayne Thayer wrote: > > I'd like to call this presentation to everyone's attention: > > > > Title: Lost and Found Certificates: dealing with residual certificates > for > > pre-owned domains > > > > Slide deck: > > > https://media.defcon.org/DEF%20CON%2026/DEF%20CON%2026%20presentations/DEFCON-26-Foster-and-Ayrey-Lost-and-Found-Certs-residual-certs-for-pre-owned-domains.pdf > > > > (NOTE: this PDF loads in Firefox, but not in Safari and not, I'm told, in > > Chrome's native PDF viewer). > > > > Demo website: https://insecure.design/ > > > > The basic idea here is that domain names regularly change owners, > creating > > "residual certificates" controlled by the previous owner that can be used > > for MITM. When a bunch of unrelated websites are thrown into the same > > certificate by a service provider (e.g. CDN), then this also creates the > > opportunity to DoS the sites by asking the CA to revoke the certificate. > > > > The deck includes some recommendations for CAs. > > > > What, if anything, should we do about this issue? > > > > - Wayne > > > > Suggested corrective processes that may be added to BRs, Mozilla > policies or similar, and which the relevant parties (CAs and browsers) > can begin to implement before they are standardized, as none contradict > urrent policies, and several require coding and testing. Backend > uppliers (such as ejbCA and NSS) will probably be doing most of the work > for the smaller players. > > 1. Browser members of CAB/F MUST do revocation checking, revocation > being semi- or completely disabled in browsers is a glaring security > hole that also affects these scenarios. Browsers MUST support OCSP, > CRL and other (future?) revocation protocols, in order to work > securely with a heterogeneous mix of public CAs (that currently must > run OCSP) and non-public offline organizational CAs. Certificate > client libraries made for/by major players should do the same, so they > can be used in minor clients such as server side https clients and > SMTP sending implementations. The profound harm this would cause to the ecosystem is not worth considering further. I am not sure why there is such a strong and supportive view of CA-lead censorship, but given these issues have been repeatedly pointed out - that such a system gives a few dozen entities complete and total censorship control of the Internet - it likely does not bear further discussion as at all being viable without substially larger improvements. 2. When updating a CDN-style multi-SANs certificate and the replacement > omits at least one of the previous SANs, CAs must revoke the old cert > versions after a short administrative delay that allows the CDN to > deploy the replacement cert. Because this is not hard evidence of > certificate invalid/misissued (this is a voluntary retraction due to > non-compromise), something like 72 hours would be fine unless a > faster revocation is explicitly requested by the previous cert holder > (the CDN), the domain owner or any other relevant entity. This is already required of the BRs, at 24 hours, and should remain so. 3. When updating a normal multi-SAN certificate (less than 3 different > directly-below public-suffix DNS labels) always ask the certificate > holder if and how quickly they want the old certificate voluntarily > revoked (again no presumption of misissuance or compromise, domain > owner may simply be regrouping his servers, rotating SANs between > certificates from multiple CAs). Also, with some CAs, the updating > process is identical to the process for getting duplicate certs > corresponding to different server end HSMs/TLS accelerators with an > explicit intent to keep both certs valid for years. > Unless of cause a faster revocation is explicitly requested by the > previous cert holder, the domain owner or any other relevant entity. > > For example a certificate with the following SANs would fall under > this more permissive rule: > example.com > www.example.com > static.example.com > mail.example.com > example.org > www.example.org > example.net > www.example.net > example.co.uk > web.example.co.uk > example.blogblog.com > beispiel.de > www.beispiel.de > eksempel.no > www.eksempel.no > The labels directly below public suffix in this cert are "example", > "beispiel" and "eksempel" totaling the maximum 3. In a real case > these would typically be names associated with a single real world > entity that has registered its domains under a bunch of available > suffixes, however the counting to 3 rule is easier to explain and > enforce than subjective rules about companies and trademarks. (Hint: > In this example, the 3 labels are translations of the same word). There is no basis to assume this distinction is at all correct and/or meaningful. Such a distinction contradicts the design of the domain name system, introducing yet another arbitrary set of rules, and should not be considered further. It remains entirely subjective as to whether or not the entities will be affiliated, and ignores the abuse of the notion of public suffices, which themselves are a patch for cookies. 4. Public CAs should have an efficient automated system for revocation > of certificates for transferred or rehosted domains (a rehosted domain > is a domain with no change in ownership, but a change in 3rd party > TLS server hosting provider). This system should not allow revocation > just because someone else (perhaps an attacker) obtains brief control > over a domain, as has recently happened in a number of DNS and > registrar attacks. For example the system should mechanically verify > that the revoker maintains continuous domain control for 1 week with > no intervening reports of relevant major infrastructure breeches as > input by CA staff (for example CA staff would enter the event that a > particular registrar, DNS provider or ASN was hijacked for a specific > period, thereby automatically nullifying domain controls autoverified > through the compromised infrastructure). Waiting about one week to > get exclusive control of a pre-owned domain is not unreasonable, DNS > caching causes similar delays already. This proposal supposed that it is acceptable to be subjected to MITM for one week after incident, at least, and without any recourse. We can and should do better. 5. CAs should avoid issuing certificates to known domain parking > facilities if they have "owned" a domain less than a typical domain > recovery grace period as per the usual ICANN and registrar procedures. > (This avoids issuing certs to domains that are briefly in such a state > due to payment errors). Much like the discussions about CAs vs Resellers, while it sounds compelling on “paper”, it creates an arbitrary and effectively unenforceable rule as it tries to create a hierarchy of domain providers and expect all independently CAs agree on the participants in each, and have complete and total global knowledge of all new participants. Without that, this achieves nothing from a security point of view. 6. Professional CDNs and domain parking providers should be offered only > shorter lived certificates (such as 2 month certificates renewed > monthly), even if they are given discounts for prepaying their bulk > purchases. This is because these specific types of cert holders > generally have much better automation than ordinary domain owners and > also naturally have a high churn of arriving and leaving domains. > This applies even to OV and EV certs, not just ACME based DV certs > (although the OV/EV validation data may remain valid and reusable for > longer as per the current BRs). This short-life for CDNs etc. rule > should go away once revocation has been working globally for several > years (ensuring non-checking clients have been replaced even in > systems with long upgrade cycles). What about amateur CDNs? Is there some point in the transition where they have to get shorter certs? This suffers all of the same problems as before. The above steps should combine to significantly reduce the problems > described in the slides. While I appreciate this long list of suggestions, they either cause substantially greater harm in their implementation, or themselves rely on assumptions that simply don’t bear out. More practical, immediately viable solutions exist - such as reducing aggregate certificate lifetime and reducing the use of cached validations for domains - that can address the immediate and real problem. Other aspects - particularly those with profoundly dangerous trade offs (such as DANE or revocation) can continue to be discussed for the more esoteric or adversarial cases, with far, far less overhead than the solutions offered here. The "problem" of a truly "bygone" domain sharing a cert with a > production domain, causing inconvenience if revoked is a non-problem, > loosing the domain should be fully expected to loose the certs for that > domain, with the reasonable exception of short "grace period" and other > short events, when ownership or domain control is quickly restored. A > grace period after a true domain ownership change will also allow a > legitimate former domain owner time to get a new (DV) certificate > without the bygone domain, while waiting for the full validation of an > OV or EV cert if wanted (Consider the case of the bygone domain being > lost due to a an unfair domain dispute ruling or other adverse event). There’s no need for a grace period with improved automation. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
