Subject: exposing certificate information (current + upcoming)

From: Stefan Eissing <[email-masked]>
Date: Fri, 10 May 2019 12:46:53 +0200

Christophe Brocas (@cbrocas), organizer of Pass-the-Salt security conference, tweeted 
about checking HTTP server certificates against CT logs to detect very early if someone
successfully highjacked one of your domains.

A renewed certificate is often not immediately used on a server but activated on the
next restart which can be several hours away. To check if a certificate mentioned in a
CT log, one would need to obtain information about upcoming certificates as well.

One approach is to expose this on a /.well-known resource of a domain. A JSON 
representation of current and upcoming certificate information. CN, serial,
fingerprint, alt-names, begins at, expires on. Maybe the hole certificate?

I would be interested in your opinion if this information can be exposed publicly or
should be considered sensitive? For the current cert, the client
obviously already has this at the connection, but is there any risk of exposing
an upcoming cert?

Feedback appreciated,

Stefan

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 May 2019 16:10:22 +0300

> CT log, one would need to obtain information about upcoming certificates as well.

If the certificate managment is automated, the time window between
obtaining the certificate from CA and deploying it to production
is typically much faster than few hours, typically few seconds to few
tens of seconds, altough some setups deploy in sub-second timescales
and some may take hundreds of seconds.

This is because the clients typically reload the webserver after any
run which changed the certificates (the craziest setups hot-reload from
inotify, or something similar).

Regarding using CT for highjack detection, there is proposed mechanisms
for CT "gossip" where clients send recently seen certificates or pointers
thereof to the webserver, which can then alert admins on reports of
unknown publically trusted certificates. I do not think there are any
concrete specifications about that however (only some drafts).

-Ilari

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 10 May 2019 18:42:00 +0200

> Am 10.05.2019 um 15:10 schrieb Ilari Liusvaara <[email-masked]>:
> 

I wrote the ACME client in Apache httpd, and it does not reload right
away. There is no need for that since renewal times are way before
expiry. But I agree that many client do, e.g. certbot for example.

> concrete specifications about that however (only some drafts).

Offering the readonly information to a checking clients seems like
an easy and secure way, since the server does not need to open up
a notification/reporting mechanism which can be abused as well.

I was just wondering if there is an undesirable information leak
this way that I had not seen.

Thanks, Stefan

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 10 May 2019 13:48:54 -0400

> CT log, one would need to obtain information about upcoming certificates

I'm not sure I understand the CT use case. Are you attempting to verify
that a certificate with embedded SCTs has been incorporated within a logs
MMD? The discussion of detecting very early if someone hijacked one of your
domains seems largely orthogonal to providing information about your
present certificate, since the attacker/adversary would simply not provide
this information. In CT, this is fine, because the reliance is upon the
SCTs (whether from TLS, embedded, or OCSP) being proof of inclusion within
a log, and, as Ilari mentioned, client verification and/or gossip of those
SCTs (and related STHs) to ensure presence within a log.

While I don't think there's any harm in exposing information about upcoming
certificates, particularly if they've already been logged (by the server,
in the case of TLS, or by the CA, in the case of embedded SCTs or OCSP
responses), it doesn't seem to fit with a very clear threat model, and I
worry I'm missing something that's supposed to be obvious here.

---

From: Stefan Eissing <[email-masked]>
Date: Sat, 11 May 2019 14:37:32 +0200

As I understood Christophs use case, he wants to monitor CT logs for newly issued certificates for any domain of his. To verify that the new certificate was indeed obtained by one of his servers/devices he would like to ask them.

If the server does not list the cert as incoming, someone else might have spoofed the CA into issueing it.

This helps if a new cert is not immediately activated on the device running ACME. A delay of such activation is practically 0 on many servers, but can extend to days on others. With Apache, it is controlled by the admin. A server with several hundred or thousands hosted domains will aggregate restarts most likely, for example.

The idea of an automated domain monitor that can warns you within a short time that a renewal was not done by the box handling the domain, seems legit.

- Stefan

> Am 10.05.2019 um 19:48 schrieb Ryan Sleevi <[email-masked]>:
> 
> 
> 
>> On Fri, May 10, 2019 at 6:50 AM Stefan Eissing <[email-masked]> wrote:
> I'm not sure I understand the CT use case. Are you attempting to verify that a certificate with embedded SCTs has been incorporated within a logs MMD? The discussion of detecting very early if someone hijacked one of your domains seems largely orthogonal to providing information about your present certificate, since the attacker/adversary would simply not provide this information. In CT, this is fine, because the reliance is upon the SCTs (whether from TLS, embedded, or OCSP) being proof of inclusion within a log, and, as Ilari mentioned, client verification and/or gossip of those SCTs (and related STHs) to ensure presence within a log.
> 
> While I don't think there's any harm in exposing information about upcoming certificates, particularly if they've already been logged (by the server, in the case of TLS, or by the CA, in the case of embedded SCTs or OCSP responses), it doesn't seem to fit with a very clear threat model, and I worry I'm missing something that's supposed to be obvious here.

---

From: Stefan Eissing <[email-masked]>
Date: Tue, 21 May 2019 15:39:50 +0200

Just FYI: https://github.com/icing/mod_md#certificate-status 

for a description of the current implementation. Moved it underneath /.httpd
for now since I am too lazy to write a draft for /.well-known/...

> Am 11.05.2019 um 14:37 schrieb Stefan Eissing <[email-masked]>:
>

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 22 May 2019 09:02:26 +0000

> for now since I am too lazy to write a draft for /.well-known/...

If it's the case that things like the above happen because some people 
see the registration requirements for .well-known as too exacting, then 
I think we have made a mistake. .well-known shouldn't become something 
that gets avoided because the registration requirements are too high.

We have had similar discussions e.g. for mime media types, URI 
schemes,... in the past, and we should have learned something from them.

Regards,   Martin.