CT - Effect on SSL/TLS MITM Services

[Ishwinder Cheema]

Hello all,

I wanted to get an opinion from the community here on what the apparent effect of the CT mandate would be on Web Security and Proxy services that use MITM to inspect SSL/TLS traffic. The principle for operation for such services is to use a self-generated private CA certificate to generate certificates on the fly for websites the end client visits. This self-generated private CA certificate is then deployed to individual machines so that when the SSL/TLS session is intercepted using a server certificate signed by this private CA, the same is trusted by the end client. I do understand that the CT Policy doesn't impact private certificates and since the same certificates are installed on the individual machines, there should be no direct impact of this on the overall operating principle, however:

1. Is there any 'caching' factor that would ever be employed here? E.g. If a user on Chrome visits google.com on open internet and the session is validated by CT, would the same be 'remembered' by the browser for subsequent connections? The problem this gives rise to is when the user switches from a non-proxied environment to a proxied environment. In a non-proxied environment, google.com would have been validated by CT due to a Public CA certificate, however, in a proxied environment, issuer for google.com would change to the Private CA. I don't feel this should be a problem, however, would appreciate feedback here.

2. The new HTTP header being proposed for mandating CT enforcement, how would the same tie in with the operation of above said services? If I understand it correctly, the purpose of the header is to ask the client browser to verify the server certificate against CT log. Is my understanding correct?

Would love to hear thoughts on the above and thank you for your time.

Regards,

Ishwinder

[Tom Ritter]

On 30 November 2016 at 10:21, Ishwinder Cheema <ich...@zscaler.com> wrote:
> Hello all,
>
> I wanted to get an opinion from the community here on what the apparent
> effect of the CT mandate would be on Web Security and Proxy services that
> use MITM to inspect SSL/TLS traffic.

You're asking for feedback from the community, but some of these
answers can only be given accurately by the individual browsers.

> The principle for operation for such
> services is to use a self-generated private CA certificate to generate
> certificates on the fly for websites the end client visits. This
> self-generated private CA certificate is then deployed to individual
> machines so that when the SSL/TLS session is intercepted using a server
> certificate signed by this private CA, the same is trusted by the end
> client. I do understand that the CT Policy doesn't impact private
> certificates and since the same certificates are installed on the individual
> machines, there should be no direct impact of this on the overall operating
> principle, however:
>
> 1. Is there any 'caching' factor that would ever be employed here? E.g. If a
> user on Chrome visits google.com on open internet and the session is
> validated by CT, would the same be 'remembered' by the browser for
> subsequent connections? The problem this gives rise to is when the user
> switches from a non-proxied environment to a proxied environment. In a
> non-proxied environment, google.com would have been validated by CT due to a
> Public CA certificate, however, in a proxied environment, issuer for
> google.com would change to the Private CA. I don't feel this should be a
> problem, however, would appreciate feedback here.

Asking if something would 'ever' be employed can't really be answered
conclusively.

Currently, the only 'caching' mechanisms I can think of that relates
to CT are the Expect-CT header (which is your second point so I'll
address it there), and TLS session resumption. Session resumption can
only happen with the legit server, so it would not occur on a switch
from non-proxied to proxied or vice versa. CT, if required, will be
revalidated upon every TLS connection. And if the presented
certificate chain ends up at a local root, it would not be required.

> 2. The new HTTP header being proposed for mandating CT enforcement, how
> would the same tie in with the operation of above said services? If I
> understand it correctly, the purpose of the header is to ask the client
> browser to verify the server certificate against CT log. Is my understanding
> correct?

Expect-CT will not be enforced (in enforcement or report-only mode) if
the presented certificate chain ends up at a locally installed root.
At least, that's how we expect browsers to implement it, they could
always decide to change their mind on the general topic of 'Local
Roots override site security requests.'

-tom

[Ryan Sleevi]

On Wed, Nov 30, 2016 at 8:21 AM, Ishwinder Cheema <ich...@zscaler.com> wrote:

1. Is there any 'caching' factor that would ever be employed here? E.g. If a user on Chrome visits google.com on open internet and the session is validated by CT, would the same be 'remembered' by the browser for subsequent connections? The problem this gives rise to is when the user switches from a non-proxied environment to a proxied environment. In a non-proxied environment, google.com would have been validated by CT due to a Public CA certificate, however, in a proxied environment, issuer for google.com would change to the Private CA. I don't feel this should be a problem, however, would appreciate feedback here.

As Tom highlighted, this is... a complex and nuanced question, and one that depends on individual browsers' security posture and implementation. At present, and I expect for the forseeable future, Google Chrome treats any CT opt-in similar to how HPKP and HSTS are employed. Both HPKP and HSTS have policies that indicate the maximum duration, however, these enforcements are disabled whenever a user is switching to a 'private'/'proxied' connection.

This is covered in https://dev.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-

 

2. The new HTTP header being proposed for mandating CT enforcement, how would the same tie in with the operation of above said services? If I understand it correctly, the purpose of the header is to ask the client browser to verify the server certificate against CT log. Is my understanding correct?

I wouldn't phrase it as "verify against a log" - since this isn't an active/real time verification. Rather, it examines whether the certificate was disclosed in a manner that complies with policies. One such policy is that local trust anchors are always considered compliant with policies, regardless of CT status. Tom's answer hit the nail on the head, and is covered in https://dev.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-

[Ishwinder Cheema]

Thanks for your inputs Tom and Ryan, this is very helpful indeed and precisely the information that I was looking for. Much appreciated.