Certificate Transparency / Expect-CT

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency / Expect-CT

Dave Thompson-2
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

On Tue, Nov 7, 2017 at 8:58 AM, Jan Schaumann <[hidden email]> wrote:
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

Reply | Threaded
Open this post in threaded view
|

Re: Certificate Transparency / Expect-CT

Jan Schaumann
Dave Thompson <[hidden email]> 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