DEFCON Talk - Lost and Found Certificates

[Wayne Thayer]

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

[Jakob Bohm]

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

[Ryan Sleevi]

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

[Eric Mill]

On Wed, Aug 15, 2018 at 6:36 AM Wayne Thayer via dev-security-policy <

dev-secur...@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.

-- Eric



> - Wayne
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


--
konklone.com | @konklone <https://twitter.com/konklone>

[Ryan Sleevi]

On Wed, Aug 15, 2018 at 11:41 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 14/08/2018 02:10, Wayne Thayer wrote:

> 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.

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.

[ianf...@vorsk.com]

Hey Everyone,

Author here, happy to answer any questions. Wayne did a good job summarizing the two problems, MitM and DoS. Basically there should be extra caution whenever sharing a certificate between different users/organizations. And We'd like to suggest that CA's not issue certificates that live beyond their domain's current lifetime.


I'm not sure what happened with the DEFCON slides, but I've uploaded a newer version here that seems to work better (at least in Chrome) here: https://insecure.design/BygoneSSL_DEFCON.pdf
The recording of the talk should be up in a few weeks.

[Wayne Thayer]

> I have to agree that the most practical improvement here is the reduction
of max validity to 13 months. As pointed out by Ryan, a step in that
direction would be to reduce the max data reuse period to 13 months or less.

I've also proposed a CAB Forum ballot [1] that should make it a bit easier
for domain owners to get residual certificates revoked. It includes a more
specific revocation requirement covering this scenario and clearer
disclosure of the CA's problem reporting mechanism.

- Wayne

[1] https://cabforum.org/pipermail/servercert-wg/2018-August/000093.html

[Jakob Bohm]

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.

[Eric Mill]

On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> 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.
>

The trend is away from manual replacement, not towards it -- and that's
true for individual people, for large enterprises, and for smaller
companies in between. For individuals and smaller enterprises, this
manifests mostly in the increasing outsourcing of certificate management to
third parties (e.g. SquareSpace, CloudFlare, AWS Certificate Manager,
etc.).

For larger enterprises, the same outsourcing is also present and is
mitigating manual rotation burdens, but some are also investing in their
own systems for automation inside their environments. I've seen several
spring up in enterprise environments I'm close to in the last few years in
order to handle the increasing pressure to secure connections by default
even when the certificate volume is high.

Reducing certificate lifetimes to 13 months, in addition to addressing the
real security issue identified by the Lost and Found Certificates
presentation, is likely to further these trends, which would be a positive
development both for user security and enterprise agility.

- 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.
>

DV certificates are appropriate for even the largest of organizations, and
are likely to supplant OV/EV certificates over time. For an example by one
of the largest enterprises in the world, see the U.S. Department of
Defense's policy changes to allow and encourage the use of DV certificates
throughout its public-facing infrastructure, and their public commitment to
Congress to use this policy change to complete their public HTTPS-only
transition by the end of 2018:

https://www.wyden.senate.gov/imo/media/doc/wyden-web-encryption-letter-to-dod-cio.pdf

>
> 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.
>

So you're aware, this is the default behavior of "Reply All" for this list,
at least in Gmail. If this creates a particular hassle for people, I can
personally try to remember to remove their emails when replying to the list
-- but I think the only practical way to address this would be to modify
the list settings in some way, rather than ask for changes from individual
posters.

-- Eric

[Eric Mill]

On Sun, Aug 19, 2018 at 3:56 PM Eric Mill <er...@konklone.com> wrote:

> On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> - 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.
>>
>
> DV certificates are appropriate for even the largest of organizations, and
> are likely to supplant OV/EV certificates over time. For an example by one
> of the largest enterprises in the world, see the U.S. Department of
> Defense's policy changes to allow and encourage the use of DV certificates
> throughout its public-facing infrastructure, and their public commitment to
> Congress to use this policy change to complete their public HTTPS-only
> transition by the end of 2018:
>
>
> https://www.wyden.senate.gov/imo/media/doc/wyden-web-encryption-letter-to-dod-cio.pdf
>

Wrong URL on my part - that was the letter to the Department of Defense,
and this is the letter they responded with describing their approval of DV
certificates and their plans in 2018 and beyond:

https://www.wyden.senate.gov/imo/media/doc/Wyden%20-%20DoD%20Web%20Services%20-%20Best%20Practices%20(Jul%2020%202018).pdf

-- Eric

[Michael Casadevall]

On 08/19/2018 12:56 PM, Eric Mill via dev-security-policy wrote:
> On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>

>> 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.
>>
>
> The trend is away from manual replacement, not towards it -- and that's
> true for individual people, for large enterprises, and for smaller
> companies in between. For individuals and smaller enterprises, this
> manifests mostly in the increasing outsourcing of certificate management to
> third parties (e.g. SquareSpace, CloudFlare, AWS Certificate Manager,
> etc.).
>

In my limited experience, this trend is *because* of Let's Encrypt
getting them to do it four times a year. A lot of my freelance work has
been automated certificate rollovers due to cost, and usually some
fiddling every X months when a domain fails to validate and the
certificate fails to issue. For a lot of places, the time spent having
someone automating it offsets the annual cost of having to fork up for a
certificate (or getting management to approve an expense)

It should be also noted that I've seen quite a few organizations decide
the cost of automation is too difficult or the systems using the
certificates are too fragile and rather pay for longer lasting
certificates.

> For larger enterprises, the same outsourcing is also present and is
> mitigating manual rotation burdens, but some are also investing in their
> own systems for automation inside their environments. I've seen several
> spring up in enterprise environments I'm close to in the last few years in
> order to handle the increasing pressure to secure connections by default
> even when the certificate volume is high.
>> Reducing certificate lifetimes to 13 months, in addition to addressing
the> real security issue identified by the Lost and Found Certificates
> presentation, is likely to further these trends, which would be a positive
> development both for user security and enterprise agility.
>

> - 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.
>

SANs are also important in DV certificates unless we're talking about
wildcards. Lets Encrypt certificates use the first domain as the CN, and
then all the subdomains as SANs. Given that wildcard certificates can be
undesirable, there are more than a few valid reasons to have SANs, even
in cases where everything is within one domain.

My largest problem with long lived certificates is that expiration is
essentially the only effective mechanism of removing old certificates
from circulation. Revocation at best is iffy, and down right broken
depending on who you ask between Chrome's CRLSets, OCSP Soft Fail, etc.

If we could fix revocation so it could work effectively, longer lived
certificates would be less of a risk factor.
Michael

[Matt Palmer]

On Mon, Aug 20, 2018 at 05:28:15PM -0700, Michael Casadevall via dev-security-policy wrote:
> On 08/19/2018 12:56 PM, Eric Mill via dev-security-policy wrote:
> > The trend is away from manual replacement, not towards it -- and that's
> > true for individual people, for large enterprises, and for smaller
> > companies in between. For individuals and smaller enterprises, this
> > manifests mostly in the increasing outsourcing of certificate management to
> > third parties (e.g. SquareSpace, CloudFlare, AWS Certificate Manager,
> > etc.).
>
> In my limited experience, this trend is *because* of Let's Encrypt
> getting them to do it four times a year.

Hardly. Anyone who deals with certificates at even modest scale has been
working on automating certificate issuance for a long time ($DEITY knows I
certainly have been). Most CAs have some way to get DV certificates
automatically, it's just that they're unique to each CA (hurrah customer
lock-in!) and generally abysmally poor UX. It's simply that Let's Encrypt
was the first one to provide a sensible means of automating the entire
process, along with providing useful tooling to make it practical for the
vast majority of people to have automated certificate issuance, which means
that shorter lifetimes become more practical.

> If we could fix revocation so it could work effectively, longer lived
> certificates would be less of a risk factor.

That's somewhat akin to saying "if we could just fix that silly
speed-of-light problem, we'd be having dinner in orbit around Sirius A".
Actually, speed-of-light *is* somewhat related to (one of) the problems of
revocation...

- Matt