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.
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.
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).
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.
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).
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).
The above steps should combine to significantly reduce the problems
described in the slides.
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).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
