Certificate Transparency / Expect-CT

[Jan Schaumann]

Hi,

I'm looking for information about in how far ATS supports Certificate
Transparency and the Expect-CT header.

My understanding is that a web server can provide the Signed Certificate
Timestamps (SCTs) -- if they are not embedded in the certificate via an
x509 extension by the CA -- either via a TLS extension or via OCSP
stapling.

I know that ATS can enable OCSP stapling, but I don't know whether that
requires additional settings to include the SCTs, nor do I know the
status of using the TLS extension in ATS.

Does anybody here know if this is available in ATS?

Related to this: is there work to add a simple configuration setting to
set the 'Expect-CT' header? I'd think it'd make sense to have that be
configurable similar to the way HSTS is enabled in ATS.

Thanks in advance for any pointers on this,
-Jan

[Dave Thompson]

A quick read through the 7.1.1 ATS code for OCSP handling, looks like we're
using the OpenSSL API to handle interaction with CA, and then passing the
response into our OpenSSL context for stapling in handshake. So, I
believe the SCT is in the CA's response, though to ATS the response is an
unparsed, effectively opaque data buffer, it passes along to/from the
various OpenSSL API's.

Regarding Expect-CT header, perhaps header rewrite plugin might be a good
way to enable.

Dave Thompson

Post by Jan Schaumann
Hi,
I'm looking for information about in how far ATS supports Certificate
Transparency and the Expect-CT header.
My understanding is that a web server can provide the Signed Certificate
Timestamps (SCTs) -- if they are not embedded in the certificate via an
x509 extension by the CA -- either via a TLS extension or via OCSP
stapling.
I know that ATS can enable OCSP stapling, but I don't know whether that
requires additional settings to include the SCTs, nor do I know the
status of using the TLS extension in ATS.
Does anybody here know if this is available in ATS?
Related to this: is there work to add a simple configuration setting to
set the 'Expect-CT' header? I'd think it'd make sense to have that be
configurable similar to the way HSTS is enabled in ATS.
Thanks in advance for any pointers on this,
-Jan

[Jan Schaumann]

Post by Dave Thompson
A quick read through the 7.1.1 ATS code for OCSP handling, looks like we're
using the OpenSSL API to handle interaction with CA, and then passing the
response into our OpenSSL context for stapling in handshake. So, I
believe the SCT is in the CA's response, though to ATS the response is an
unparsed, effectively opaque data buffer, it passes along to/from the
various OpenSSL API's.

Yeah, I did some more reading, too, and OCSP is a no-work-needed
approach for ATS (just like if the SCTs are included in the cert). This
works well for e.g. DigiCert and Symantec, which both support CT via
either x509 or OCSP (or both).

I still believe it would be useful for ATS to support CT via the TLS
extension. For example, Let's Encrypt does not currently support CT in
certs nor via OCSP, so for all the millions of sites using LE, a TLS
extension is currently the only option to enable CT.

Post by Dave Thompson
Regarding Expect-CT header, perhaps header rewrite plugin might be a good
way to enable.

Yes, that would work. However, I view Expect-CT to be similar to HSTS
in functionality and complexity. Since ATS supports HSTS via a config
option, it seems reasonable to me as a user to expect to be able to set
the Expect-CT in similar manner without having to fall back to a
header-rewrite plugin.

-Jan