On Mon, Aug 13, 2018 at 8:10 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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?
>

>From the recommendations:
- CAs could only issue short lived certificates
- CAs should not issue certificates valid for longer than domain
registration

It seems like both of those could/should be required of CAs via policy. For
example, aligning validity on 395 days (13 months). Not all registrars
provide the registration period information, so that seems the safer, more
reliable means.

Note that the use of cached validations also adds a further wrinkle - this
doubles the effective risk window. That is, a domain validation that occurs
on Day 1 can be used on Day 825 to issue a certificate valid for 825 days -
an effective window of 1,650 days - or 4.5 years.

I think it'd also be worth exploring the dataset with the authors, to see
and compare the overlap bucked by validity periods. That is, they report
1.5M domains with pre-existing certificates (25% unexpired), and 7M domains
sharing a certificate with a 'bygone' domain (41% unexpired). It would be
hugely beneficial to the discussion to take the set of unexpired
certificates, bucket them into validity windows (90D, 1Y, 2Y, 825 day, 3Y),
and then see the overlap of Bygone domains.

A third suggestion is also raised "Be careful with subject alt-names".
While some may wish to distinguish this into service providers vs
non-service providers, as a practical distinction, it's not going to be a
bright line (see: the same discussions around CAs vs resellers vs service
providers vs users). If we're to take meaningful steps there, it might be
better to look at the practice of including multiple SANs.

We know cloud providers are increasingly turning down SNI-less connections.
As a bellwether for the industry, cloud providers are incentivized to
maximize the number of connections they can handle for their customers, and
if they're not seeing significant negative impact from requiring SNI,
perhaps its worth discussing a sunset for multiple-SAN certificates within
the next several years.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to