1286681 - sha-1 certificate hash in mozilla.org

Status: RESOLVED WONTFIX

(www.mozilla.org :: General, defect)

Description

[fdsc]

User Agent: Mozilla/5.0 (Windows NT 6.1;  Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36

Steps to reproduce:

Enter https://mozilla.org to address bar and go to first url



Actual results:

Sometimes.
Redirect from https://mozilla.org/ to https://www.mozilla.org/ and from https://www.mozilla.org/ to https://www.mozilla.org/ru/
with server IP 63.245.215.20

I see sha-1 certificates:
(names and sha2 256 hashes)
www.mozilla.org
B4:D0:23:24:CF:8A:B6:BB:6B:32:66:BE:D8:87:F6:45:A3:12:48:24:67:C9:37:0D:0D:00:F9:3E:9D:DE:65:30
DigiCert High Assurance EV CA-1
54:1A:F0:19:96:17:60:EF:19:E8:FB:41:34:E6:D4:30:85:B5:E5:E0:87:F3:01:97:DC:42:B2:09:7E:10:48:7E
DigiCert High Assurance EV Root CA
74:31:E5:F4:C3:C1:CE:46:90:77:4F:0B:61:E0:54:40:88:3B:A9:A0:1E:D0:0B:A6:AB:D7:80:6E:D3:B1:18:CF



Expected results:

sha-1 must not be use in mozilla.org

Comment 1

[April King [:April]]

We use SHA-1 certs because we have to service XP SP2 clients.  Note that this cert is only served to these older clients.

Comment 2

[fdsc]

Excuse me, but how the server knows that such certificates must be submitted?
I have Windows 7 and I can see these certificates.

I see that my security is violated because customer support for long-obsolete machines.

Comment 3

[Josh Mize [:jgmize]]

(In reply to fdsc from comment #2)
> Excuse me, but how the server knows that such certificates must be submitted?
> I have Windows 7 and I can see these certificates.
> 
> I see that my security is violated because customer support for
> long-obsolete machines.

The sha1 cert is conditionally served based on the TLS client hello; modern clients should get a sha256 cert. For more details, please see https://blog.cloudflare.com/tls-certificate-optimization-technical-details/. Depending on how you were checking the cert, you may have been seeing a sha1 cert due to not passing in the necessary options to your command line tools to send a TLS client hello that indicates support for a sha256 cert, but if you visit www.mozilla.org with a browser on your win7 machine and inspect the cert you should see that it is sha256. If this is not actually the case please reopen this bug and provide more details about the specific browser and ideally a screenshot of the cert inspection screen.

Comment 4

[fdsc]

> but if you visit www.mozilla.org with a browser on your win7 machine and inspect the cert you should see that it is sha256

The fact that the redirect goes to www.mozilla.org . It's on a different IP and there are right certificate.
However, at the time of the http redirection, I see a sha-1 certificate with machines to Win 7 (FireFox 47.0.1). This certificate is not displayed in the browser (there is a certificate after redirection). I see it by another way.

Comment 5

[Paul [:pmac] McLanahan]

Two team members resolved this bug. Feel free to continue the discussion but please leave it resolved until one of said team members decides it can be reopened.

Comment 6

[April King [:April]]

Attachment: mozilla.org.pcapng

Comment 7

[April King [:April]]

Okay, I can confirm the bug report: the request to mozilla.org goes to the ZLB, and there it is served a SHA-1 certificate, regardless of client.  That is, even the latest versions of Firefox and Chrome get a SHA-1 certificate.

This is surprisingly hard to test, because every browser ever caches those 301 Redirects, meaning that they almost never actually make a request for mozilla.org.  I've attached a pcap of the latest Chrome, cleared session everything, and in incognito mode.  The certificate that it receives is the SHA-1 cert.

This still might be expected behavior; :ulfr or :jgmize, can you verify?  I know that www sits in CloudFlare, but we're still doing the redirection for mozilla.org out of SCL3 and that will break once SHA-1 certs are fully deprecated.

Comment 8

[fdsc]

> This is surprisingly hard to test, because every browser ever caches those 301 Redirects

I see it quite often.
Install
http://fxprivacy.8vs.ru/http_useragent_cleaner_o-0.8.4-b05-fx.xpi
(or https://addons.mozilla.org/firefox/addon/http-useragent-cleaner/ )

In "HTTP" tab of the Extension options set state in a first and in a second columns in "Cache" filter from disabled (green) to enabled (red).

Then go to https:/mozilla.org
In Extension in "TLS log" tab see:
Remote address is 63.245.215.20:443
And sha-1 is used
TLS estimate is 4% on red background

To test again, press in the "FireFox" the "reset data" button and try again.

Comment 9

[fdsc]

> filter from disabled (green) to enabled (red).

Error. to "no cache" state.

Comment 10

[Julien Vehent]

> we're still doing the redirection for mozilla.org out of SCL3 and that will break once SHA-1 certs are fully deprecated.

download.m.o is in the same boat. We only enabled cert switching on pages rendered in Firefox to avoid the bad UI, but we're still using SHA-1 on a number of sites that need WinXP compatibility. I expect this to change toward the end of the year, but for now I'd consider it a wontfix.

Comment 11

[April King [:April]]

Sounds good, just wanted to verify.  :)