trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Schaumann <jscha...@netmeister.org>
Subject Re: Certificate Transparency / Expect-CT
Date Wed, 08 Nov 2017 15:03:20 GMT
Dave Thompson <davet@oath.com> wrote:
> 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.

> 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

Mime
View raw message