Any SSL inspection product is totally blocked on this issue

Deleted: Screenshot from 2016-08-11 13-56-58.png 156 KB

	Screenshot from 2016-08-11 13-56-58.png 156 KB View Download

The specific error message we get is:
net::ERR_CERT_INVALID

Can you provide the MITM certificate being presented for the site, as well as the intermediate interception CA. ERR_CERT_INVALID typically means there's something wrong with the presented cert, instead of a pinning violation.

I will be able to give you these details only a week from now since I'm going tonight on a week vacation and will not be near my desktop the coming week.

However, I'm quite sure there is nothing wrong in the MITM certificate being presented for the site, neither with the intermediate interception CA.

so why I think so?
Well, the same setup, with exactly the same certificates & interception CA, as well as many other similar configurations like this, all work perfectly with Google Chrome for Windows (and for Mac as well).

As much as I can see, the pinning bypass simply doesn't work on the linux version. IMHO this is where you need to focus you efforts.
our uppper managers say that Chrome for Linux is an important use case and urge us to find a solution.

Thanks
Nadav

Nadav: There's no reason to assume that success on Windows means there's nothing wrong with the certificate. It's almost certainly correct that it's encoded in a way that violates RFC 5280, which is why NSS (not Chrome) is rejecting it. Other platforms can be more lax or more strict.

I've confirmed just now that pinning bypass works fine, so if you're able to get us your certificate, I'm sure we'd be happy to help diagnose and indicate what's wrong with its construction, or whether you should file a bug against NSS.

Cheers

Thank you for providing more feedback. Adding requester "svaldez@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi,
-what does it mean having those last two comments?
Thanks,
Nadav

Tommorrow I will provide examples of the certificates
Thanks

new files attached -
-Local Interception CA certificate
-mail.google.com certificate signed by it
-Windows screenshots vs.
-Linux screenshots 

Thanks,
Nadav

Deleted: SSL_Inpsection_Test_CA.cer 747 bytes

SSL_Inpsection_Test_CA.cer 747 bytes Download

Deleted: ssl_inspection_mail.google.com.cer 782 bytes

ssl_inspection_mail.google.com.cer 782 bytes Download

Deleted: ssl_windows.PNG 258 KB

	ssl_windows.PNG 258 KB View Download

Deleted: ssl_ubuntu_view.PNG 336 KB

	ssl_ubuntu_view.PNG 336 KB View Download

Deleted: ssl_ubuntu_chain.PNG 273 KB

	ssl_ubuntu_chain.PNG 273 KB View Download

Deleted: ssl_ubuntu_root_ca_list.PNG 240 KB

	ssl_ubuntu_root_ca_list.PNG 240 KB View Download

A chrome://net-internals will confirm, but from the looks of it, the vendor isn't following RFC 5280. Marking as WontFix.

We regularly see interception vendors make mistakes with certificates. What vendor are you using that provides such a certificate, so we can see about filing a bug report? It's also worth noting that, in addition to the general insecurity of using SSL interception, your vendor is using weak keys (RSA 1024-bit), which support will be removed in the future.

This has nothing to do with pinning.

1. where should I look exactly in chrome://net-internals ?  many options..
2. we are the SSL interception vendor, so that's what we are doing for livinig. 
3. Yet, I used this time XCA for creating the interception CA to be sure that it's our default CA is not the source of problem.
4. we use 1024 keys only toward the internal clients and it will be change soon.                  anyway it should not cause troubles unless Linux chrome is sensitive to that.
5. as far as I can tell our PKI code is fully following RFC 5280.
6. since it happens only with google/facebook sites, only on Linux, I still think it's related to pinning on the Linux version.

you still need to exaplain section 6 - how is windows chrome OK with our code? how is linux chrome OK with other sites?

1) Attach a chrome://net-internals export to this bug, which will show the OS (really, NSS) error code, which I would bet will be either duplicate issuer+serial or invalid keyUsage.
2) Read the keyUsage section of RFC 5280 and TLS, in particular. Also, since it sounds like you're comfortable developing, you can almost certainly debug (e.g. with GDB) the issue within NSS.
3) Your choice of serial number (1) for the intermediate CA, with the same subject, causes significant issues for clients if they have ever seen a matching subject/ID pair

6) It's not.

As indicated previously, we use entirely different cryptographic validation stacks on Linux and Windows. It's apples to oranges. Both have different sensitivities, different configuration options, and different bugs.

A chrome://net-internals will confirm two things:
1) The ciphersuite being negotiated. digitalSignature is not appropriate, for example, for an RSA key exchange. Given that you're using 1024-bit certificates, you're almost certainly negotiating non-PFS ciphersuites for similar performance reasons, which means that you minimally need keyEncipherment
2) Your choice of serial number 1 for your 'trusted' CA almost certainly is causing issues in NSS's parsing code, because if there has *ever* been a (different) certificate whose name+serial number matches, it returns an invalid certificate. This is based on NSS's interpretation of RFC5280 (for better or worse), which itself 'assumed' the X.500 uniqueness model held and that no two certificates would ever exist with the same issuer name and serial number (but they totally can and do, if the issuer s are independent CAs).

hi,

what I did all day is changing the code to check your suggestions.

first regarding (3), it's not valid since the CA was fresh and with a unique ID never seen before, and I did not see the serial number errors anywhere.

regarding PFS & keyUsage:
you're correct assuming that we prefer non-PFS cipher-suites on the internal segment, and that's in order to save ECDHE derive operation
(it will have to change in TLS 1.3 or even before).
so I would expect that when working with PFS only we would not have any problem with keyUsage which is digitalSignature only.
that was the first test.

However, the Linux Chrome still prints same errors.
I'm adding the requested chrome debug of Facebook, when only PFS is allowed by our SSL inspection engine.

I will upload debug of other tests separably.

Deleted: facebook.json 226 KB

facebook.json 226 KB View Download

Hi,

at last good news,
On the second test I added always digitalSignature & keyEncipherment to the SSL inspection certificate - 
now it finally works, no matter what cipher-suite is negotiated.

Thanks a lot!
Nadav


 

BTW, generating more informative error codes or even better debug prints would save a lot of time for similar case in the future..
I looked over all debugs in the json debug file and did not find any useful info there as well..

thanks anyway
nadav