FS#52080 - [firefox] 50.0.2-1 SSL errors behind ssl scanning proxy

Attached to Project: Arch Linux
Opened by Ido van Verseveld (idovitz) - Thursday, 08 December 2016, 10:54 GMT
Last edited by Evangelos Foutras (foutrelis) - Monday, 16 April 2018, 23:12 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Evangelos Foutras (foutrelis)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

From firefox 50+ i got ssl errors on my work-pc:

configuration:
firefox 50+ <= proxy 8080 => SOPHOS UTM ssl scanning <= ssl connection => webserver
I added a signing proxy CA cert in firefox..

On some sites is ssl going well on some sites:
error 1:
An error occurred during a connection to accounts.google.com. The server uses key pinning (HPKP) but no trusted certificate chain could be constructed that matches the pinset. Key pinning violations cannot be overridden. Error code: MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE

error 2:
Normal ssl error about the match cert common vs domain. See attached screenshot (bugs.archlinux.org). I checked the cert, the proxy is generating a valid cert.

This is only the case when using a 50+ arch build. Releases Linux/Windows downloaden on mozilla.com are working fine. Is there a certain patch or build option different, causing this?
This task depends upon

Closed by  Evangelos Foutras (foutrelis)
Monday, 16 April 2018, 23:12 GMT
Reason for closing:  Fixed
Additional comments about closing:  Probably fixed since Firefox 54.
Comment by Ido van Verseveld (idovitz) - Thursday, 08 December 2016, 10:56 GMT
extra information;
when switching the proxy setting to "no proxy" in firefox, the Firewall is still MITM attacking in a transparent way, all ssl sites are working well.
Comment by Jeremy M. (jskier) - Friday, 09 December 2016, 21:48 GMT
@idovitz, setting to no proxy and all ssl sites work for you? I can only work around the pinning error by setting security.cert_pinning.enforcement_level to 0 (instead of 1).

Additionally, I would like to confirm the pinning errors since 50 hit the repos whilst using a transparent proxy. This occurs for some sites (primarily google.com, and it's other web services like YouTube and GMail are also causing this error). If I don't use the proxy at all (or change enforcement to 0), no problems at all.
Comment by Jan de Groot (JGC) - Sunday, 11 December 2016, 09:10 GMT
Isn't the purpose of pinning that a MitM can't forge the connection with a false certificate.
Comment by Jan Alexander Steffens (heftig) - Sunday, 11 December 2016, 15:11 GMT
See the discussion at https://bugzilla.redhat.com/show_bug.cgi?id=1207335 . Seems we've been working around a "feature" that prevents HPKP from working so that corporate firewalls can break TLS.
Comment by Jeremy M. (jskier) - Monday, 12 December 2016, 15:29 GMT
@JGC Correct, however why is this only an issue with ArchLinux package and not Debian, FF binaries, or Windows?
Comment by Malte Rabenseifner (Zearan) - Thursday, 22 December 2016, 06:53 GMT
We have a similar setup, I have used security.cert_pinning.enforcement_level to prevent error 1 with Google, etc.
What is a bigger problem: I am also experiencing error 2 and our own custom internal CA. The update to FF 50 causes SSL_ERROR_BAD_CERT_DOMAIN errors even though the certificate is matching the URL (FF 49, openssl and epiphany have no problems and verify the certificate as valid). This only occurs on Arch and FF 50, Windows/Debian/Ubuntu builds of FF 50 are fine.
Comment by Fedor Piecka (piecka) - Wednesday, 04 January 2017, 13:25 GMT
I'm also experiencing the problem number 2 (SSL_ERROR_BAD_CERT_DOMAIN).

I'm attaching a screenshot where you can see the CN of the certificate matches the web server IP address.

The certificate used is signed by a private CA which is trusted in the browser.

I noticed the erroneous behavior after installing a newly signed certificate as the original certificate was about to expire. Both certificates are signed by the same CA. The problem is present even if I generate a certificate with identical extensions and other fields. The certificates differ only in dates, keys and key IDs and the new one still doesn't work in the current Arch Firefox. The old one works without a problem. We don't use certificate pinning. This happens on all services where I install a new certificate. Old certificates work, the new don't.

The old certificate as well as the current one work in vanilla Firefox binary (downloaded from www.firefox.com as tar archive) and also in Chrome.

EDIT: Attached a better screenshot.
Comment by Malte Rabenseifner (Zearan) - Sunday, 22 January 2017, 19:38 GMT
How can we proceed with 'error 2' in this report? This is not a problem with ssl scanning proxies but with matching the certificate's subject to the website's URL (possibly only when using custom certificates, which would explain the problems with ssl scanning proxies). I could not reproduce this problem with FF 49 or with other browsers (including FF 50 on Ubuntu or Windows). Has anything changed in the Arch Linux build of Firefox from 49 to 50?
Comment by Cedric Bellegarde (gnumdk) - Wednesday, 25 January 2017, 16:02 GMT
Can confirme the issue with Firefox 51 package from staging
Comment by Malte Rabenseifner (Zearan) - Thursday, 23 February 2017, 17:47 GMT
I could solve my problems by issuing new certificates with Subject Alternate Name extension in my CA. This (https://bugzilla.mozilla.org/show_bug.cgi?id=1261919) got me on the right track.
Comment by Fedor Piecka (piecka) - Monday, 27 February 2017, 16:36 GMT
I can confirm too that the issue 2 was caused by a missing SAN extension in the used certificates.

The SAN requirement is a part of CA-Browser Forum Baseline Requirements and it is required since october 2016 (https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf chapter 7.1.4.2.1).

It looks like Mozilla has started enforcing the rule in nightly/aurora builds of Firefox some time ago. Maybe it is enabled in the source tarball too.


In any case - the issue 2 was not a bug in my case.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 08 March 2017, 07:29 GMT
Everything from https://bugzilla.redhat.com/show_bug.cgi?id=1207335 but the backports to NSS and Firefox are now in [testing]. This should be fixed in Firefox 54 at the latest.

Can someone please test if the Firefox 54.0a2 prerelease at https://pkgbuild.com/~heftig/packages/firefox-developer-edition/ (grab one of the built packages) behaves better in combination with [testing]?
Comment by Jan Alexander Steffens (heftig) - Wednesday, 15 March 2017, 21:33 GMT
Anyone? The packages in question (except for firefox-developer-edition, of course) are now in [core].
Comment by Johannes Pointner (h4nn35) - Thursday, 16 March 2017, 07:36 GMT
I tested your packages from https://pkgbuild.com/~heftig/packages/firefox-developer-edition/ and as far as I can tell I have no MOZILLA_PKIX_ERROR_KEY_PINNING_FAILURE anymore.
Comment by Jeremy M. (jskier) - Thursday, 16 March 2017, 14:01 GMT
Turning security.cert_pinning.enforcement_level back to 1 and going to google.com and I still get the error. Firefox 52.

Loading...