4

I have a machine behind corporate BlueCoat's proxy server. For any HTTPS site I get a certificate signed by BlueCoat's CA, for example:

BlueCoat
  *.duckduckgo.com

The only exceptions are sites owned by Google for which I get the proper certificate for google.com and most of its SANs (youtube.com goes unaffected, android.com gets intercepted):

GeoTrust Global CA
  Google Internet Authority G2
    *.google.com
      expires on 2016-08-17
      fingerprint 66:05:80:34:2A:DC:33:B8:92:78:5D:2C:F9:C9:69:F6:19:81:4A:35:DB:FF:19:89:3B:FA:5F:6B:33:37:58:FD

I get the same results for browsers using Microsoft and Mozilla certificate stores (although that shouldn't matter).

I doubt proxy administrator deliberately added an exception for Google domains, but I cannot exclude that (and I have no means of confirming).

Is there any other explanation for bypassing the BlueCoat proxy when accessing Google sites? Or a way to figure it out?

Certificate pinning shouldn't have anything to do with it (and all other sites like twitter.com come with a BlueCoat-signed certificates).

4
  • If you have a corporate certificate manually imported into your trust store, it would essentially disable certificate pinning anyway. Does the company use any Google provided services (e.g. Google Apps for Business type things)? If so, an administrator might be more likely to turn off interception on those addresses, to prevent accidental storage of passwords to corporate data.
    – Matthew
    Commented Jun 6, 2016 at 8:21
  • Interesting suggestion. It's hard to tell, but policy-wise it is rather a no no and many of Google services are administratively blocked.
    – techraf
    Commented Jun 6, 2016 at 8:36
  • 1
    Probably related to this
    – paj28
    Commented Jun 6, 2016 at 8:40
  • Both suggestions: using Google services and problem remediation are valuable and although speculative, they could be answers along the definite one that there is nothing special about Google and this certificate that determines this proxy behaviour.
    – techraf
    Commented Jun 6, 2016 at 9:19

1 Answer 1

3

My guess is that your proxy administrator has turned off ssl-inspection for google domains because of an update of Chrome, and what ciphersuites it will attempt to use for google domains.

https://forums.bluecoat.com/forum/security-policy-enforcement-center/proxysg/37493-proxysg-is-offering-unknown-elliptic-curves-chrome-google-connect-failure

Unfortunately, bluecoat does not currently support the ciphers requested by Google Chrome, and the SSL connections fails.

One workaround, is to whitelist google sites from SSL-inspections - which in my opinion is bad. The other would be to turn off support for the new EC ciphers in Google Chrome.

This problem only affects Chrome - not other browsers.

2
  • Also, Chrome has hard-coded public key pinning for Google's domains, so intercepting those connections will only cause Chrome to give errors.
    – billc.cn
    Commented Jun 6, 2016 at 9:44
  • 2
    @billc.cn: pinning does not matter if the MITM-CA is not a built-in one but one which got explicitly added. See security.stackexchange.com/questions/124998/… Commented Jun 6, 2016 at 10:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .