On 16/08/2018 16:24, Eric Mill wrote:
On Wed, Aug 15, 2018 at 6:36 AM 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?
I think this paper provides a good impetus to look at further shortening
certificate lifetimes down to 13 months. That would better match the annual
cadence of domain registration so that there's a smaller window of time
beyond domain expiration for which a certificate would be valid, and would
continue the momentum Mozilla and the CA/B Forum have been building around
reducing certificate lifetimes and encouraging automation.
The presentation suggests having certificates only be valid through the
expiration date of the relevant registered domain, but I think that's
unrealistic. Most of the time, domains are set to autorenew so that people
never have to think about them, and their renewal cadence is totally
disconnected from certificate renewal cadence. If a domain is 6 days from
autorenew, a CA offering a 6-day-long cert and forcing someone to come back
a week later for another one would be very unreasonable.
I don't think the presentation points to building in stronger support for
revocation. If anything, it points to revocation being a threat vector for
DoS-ing sites that have nothing to do with the problem at hand, due to the
long-standing (and reasonable) practice of multi-SAN certs that combine
clumps of customers into individual certificates. Ryan points out that SNI
is becoming something that can be relied on more universally, which would
reduce the need for multi-SAN certificates, but multi-SAN certificates also
provide useful operational benefits to organizations who are using CAs with
rate limits, or simply for whom the ability to use 100x fewer certificates
relieves an operational scaling burden.
It may still be useful to deprecate multi-SAN certificates over time, but I
think the single biggest thing to take away from the presentation is that
long-lived certs create invisible risks during domain transfers, and that
the risk is more than just theoretical when looking at the whole of the
web. It's been a year and a half now since the last discussion and vote
that went from a 39-month max to a 27-month max, so I think it's a great
time to start talking about a 13-month maximum.
It seems that my response to this presentation has brought out the crowd
of people who are constantly looking to reduce the usefulness of
certificates to anyone but the largest mega-corporations.
To summarize my problem with this:
- While some large IT operations (and a minority of small ones) run
fully automated setups that can trivially handle replacing
certificates many times per year, many other certificate holders treat
certificate replacement as a rare event that involves a lot of manual
labor. Shortening the maximum duration of certificates down to Let's
encrypt levels will be a massive burden in terms of wasted man-hours
accumulated over millions (billions?) of organizations having to do 4
times a year what they used to do every two or five years.
- In terms of end user security, having certificates and domains expire
at different times significantly decreases the risk of legal domain
hijacks by "domain parking" providers, domain squatters and the like,
as it reduces the role of domain renewal as a single point of failure.
If certificate pinning protocols weren't broken by design (such as
preventing private key replacement), they would further increase this
end user protection against trusting an unexpected site that has no
legitimate relationship with a dubiously obtained domain.
Thus the papers suggestion that certificates should be limited to the
domain lifetime is a security loss in the common case where the domain
owner has some trust that cannot be forwarded to any unrelated new
domain owner. It also does nothing for the cases where domain control
is consensually transferred such as when the domain owner changes
hosting providers or sells the domain.
- While infinitely wealthy organizations can afford getting separate
certificates for each DNS name, and while lowest-security (DV)
certificates are now available for zero dollars in the US, SANs remain
significant in case of high security validation (OV, EV) that costs
real money and effort, both to pay the CA and to provide evidence of
human and organizational genuineness, such as showing government IDs,
obtaining certified copies of registration statements, answering
validation phone calls to CEOs at strange hours etc.
- While one of the biggest obstacles to relying on SNI for general
consumer websites (the ones that CDNs are most concerned about) has
recently disappeared, there is still a very long tail of both client
and server systems that cannot be upgraded with this features, and
thus there will be an equally long tail of organizations that will
need multi-SAN certificates to serve those needs. Not everyone lives
on the bleeding edge.
Off topic notes related to this thread:
- It is bad form to reply to posts with a personal e-mail cc-ed to the
mailing list unless explicitly requested by the original poster.
- One of the responses was basically just trolling with nonsense
arguments that would only derail any sane discussion. I try not feed
that troll as it would only end in tears.
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
