Some geotrust.com subdomains are TLS intolerant

RESOLVED FIXED

Status

Tech Evangelism
Desktop
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: emk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
canadaca.geotrust.com
services.geotrust.com
smarticon.geotrust.com

Comment 1

3 years ago
Are you asking us to do something to address this?

Comment 2

3 years ago
Upgrade these servers just like how you upgraded products.geotrust.com

Comment 3

3 years ago
By when? And if we can't do it in time?
(Reporter)

Comment 4

3 years ago
These sites will be added to the whitelist, so you don't have to hurry. If you know other subdomains are TLS 1.1/1.2 intolerant, please tell me. I'll add them to the whitelist, too.

Comment 5

3 years ago
Firefox 37 will be released around the week of April 8 I think, though note that for now these domains are whitelisted.

Comment 6

3 years ago
Also services.geotrust.com still uses the old 1024-bit Equifax root, which should be fixed at the same time if possible.
Duplicate of this bug: 1138712
(Reporter)

Comment 8

3 years ago
The urgency was higher than I thought. Firefox 36 will show a warning icon when visiting websites with geotrust ssl site seal. See bug 1138712.
(Reporter)

Comment 9

3 years ago
I consider to *remove* smarticon.geotrust.com from the whitelist without waiting for the server fix. The ssl site seal will no longer be displayed until smarticon.geotrust.com is fixed, but it will no longer interfere the lock icon.
Rick, does it make sense?
Flags: needinfo?(rick_andrews)

Comment 10

3 years ago
I can't tell if it makes sense, because I don't understand what the whitelist is. What are the implications of being in the whitelist or not in the whitelist?
Flags: needinfo?(rick_andrews)

Comment 11

3 years ago
By default, TLS version fallback will be disabled in Firefox 37 and RC4 fallback will be disabled in Firefox 38. The whitelist reenables these fallbacks for the listed domains.
(Reporter)

Comment 12

3 years ago
If a site has geotrust ssl site seal, Firefox 36 will display a warning icon instead of the lock icon on the location bar because the ssl site seal server (smarticon.geotrust.com) uses RC4, an insecure encryption algorithm. This change is explained in Site Compatibility for Firefox 36 [1].

You will have to stop using RC4 on smarticon.geotrust.com to fix the problem fundamentally. (Honestly, I thought this was teaching a fish to swim because it is geotrust's business to sell ssl certificates.)

However, if you can take time to fix the server, I can introduce a workaround to Firefox 37 to mitigate the issue. If I introduce the workaround, the lock icon will be restored on websites that use geotrust ssl site seal, but geotrust ssl site seal it self will no longer be displayed in the page until smarticon.geotrust.com is fixed.

My question is whether it is really desirable to introduce the workaround.

[1] https://developer.mozilla.org/en-US/Firefox/Releases/36/Site_Compatibility#Security
Flags: needinfo?(rick_andrews)

Comment 13

3 years ago
Masatoshi, I'd appreciate it if you would keep your judgments out of this technical discussion.

We're working to remove the use of RC4 from those domains. I think there's a typo in your Comment 12 - I think you meant to say "if you _can't_ fix the server, I can introduce a workaround". Please confirm.

Also, what is the timeframe by which we must make the fix, assuming that's the ultimate solution?
Flags: needinfo?(rick_andrews)
(Reporter)

Comment 14

3 years ago
(In reply to Rick Andrews from comment #13)
> Also, what is the timeframe by which we must make the fix, assuming that's
> the ultimate solution?

The problem already happens on Firefox 36, sorry. So the sooner, the better.
Regarding the workaround, I can introduce it in Firefox 37 that will be released around mid April.

Comment 15

3 years ago
I can't reproduce this in Firefox 36. Is the warning icon shown if RC4 is in the chosen ciphersuite, or just if it's the list of ciphersuites offered by the web site?

smarticon.geotrust.com does offer RC4 but it also offers others, including TLS_RSA_WITH_AES_256_CBC_SHA. Why would this trigger a warning icon?

And is the warning icon shown only if RC4 is negotiated with the primary web server, or if it's negotiated with any of the ancillary web servers that FF connects to in order to retrieve other content?
Flags: needinfo?(VYV03354)

Comment 16

3 years ago
If RC4 is the chosen ciphersuite. What Firefox and IE11 does is trying a TLS 1.2 handshake without RC4 first then a fallback adding RC4 back to the list.

Comment 17

3 years ago
The problem no longer reproduces because the server has been fixed to put RC4 at the bottom.

Comment 18

3 years ago
So just to be clear: When I visit an EV site, FF might pull in content from lots of other web servers. If RC4 is chosen with any of those connections, that results in the loss of EV treatment?

Or if it's not an EV cert, the lock icon changes to a warning icon?

Comment 19

3 years ago
I think so.

Comment 20

3 years ago
Is there a way to tell which of the many SSL connections used RC4 and led to the UI degradation? This may be very hard for customers to diagnose.
(Reporter)

Comment 21

3 years ago
Looks like smarticon.geocities.com no longer prefers RC4, thanks. So you don't have to harry the fix anymore.
But servers should still stop using RC4 eventually. Someone may find a way to trick clients into using RC4 in the future, like the FREAK attack.
Also, the server is still TLS intolerant. See bug 1111354 comment #14 about TLS intolerance.

(In reply to Rick Andrews from comment #20)
> Is there a way to tell which of the many SSL connections used RC4 and led to
> the UI degradation? This may be very hard for customers to diagnose.

Web Console (press Ctrl+Shift+K to open) will display what URL uses RC4. Normally only developers have to tell the information. If any of subresources is using RC4, we should not consider it is secure, just like mixed content pages.
Flags: needinfo?(VYV03354)

Comment 22

3 years ago
I'm looking in the Security tab of the Console. I've checked both Errors and Warnings. I don't see any messages, but the EV site does not show the EV Treatment.

I don't see anywhere in the Console to view the negotiated ciphersuite, so I'm assuming that I should see a Security Error or Warning saying that the EV Treatment was disabled.

I'd appreciate some guidance in where to look. Thanks.
Flags: needinfo?(VYV03354)
(Reporter)

Comment 23

3 years ago
Can you post an example URL?
Flags: needinfo?(VYV03354)

Comment 24

3 years ago
I'm hitting https://www.geotrust.com and I don't see the EV treatment. My colleague, however, has the same version of FF (36.0.1) and he does see the EV bar. I'm trying to track down why I don't see it.
(Reporter)

Comment 25

3 years ago
(In reply to Rick Andrews from comment #24)
> I'm hitting https://www.geotrust.com and I don't see the EV treatment. My
> colleague, however, has the same version of FF (36.0.1) and he does see the
> EV bar. I'm trying to track down why I don't see it.

I also see the EV bar.

Comment 26

3 years ago
Check the cert chain and make sure the root shown is "GeoTrust Primary Certification Authority - G3" and the root shows as a "Builtin Object Token".

Comment 27

3 years ago
Yes, it chains to "GeoTrust Primary Certification Authority - G3" and the root shows as a "Builtin Object Token". What are the other possible reasons for disabling the EV treatment?
(Reporter)

Comment 28

3 years ago
Please clear the cache and use super-reload (Ctrl+F5). The warning message will not be displayed if the resource is loaded from the cache.

Comment 29

3 years ago
I've cleared the cache, both before and after restarting, did super-reload and still no green bar.

I'm not interested in restoring the green bar; I'm more interested in learning how I can determine why the green bar is not showing. Isn't this written to a log somewhere?
(Reporter)

Comment 30

3 years ago
It is supposed to be logged in Web Console or Browser Console. Strange...
Are you enabling OCSP?

Comment 31

3 years ago
Yes, OCSP is enabled, although since it's an EV cert, FF should make the OCSP request regardless.

Please explain how I find the right log message in the Web Console.
(Reporter)

Comment 32

3 years ago
I can't explain more of comment #21, sorry.

Comment 33

3 years ago
Created attachment 8600121 [details]
WebConsole.JPG

Web Console warning about use of SHA-1 in Bugzilla

Comment 34

3 years ago
I see that the Web Console warns about SHA-1 in the primary connection (see attachment - it's a bit ironic). But I don't see any way to see what ciphersuite is negotiated in sub-connections.

If Masatoshi's comment in correct in https://bugzilla.mozilla.org/show_bug.cgi?id=1137677#c21 that "If any of subresources is using RC4, we should not consider it is secure" I'd like to see Firefox dump some helpful info to the Web Console. Otherwise, this will be very difficult for a customer to figure out.
(In reply to Rick Andrews from comment #34)
> I see that the Web Console warns about SHA-1 in the primary connection (see
> attachment - it's a bit ironic). But I don't see any way to see what
> ciphersuite is negotiated in sub-connections.

Open the Developer Tools, open the Network tab, and then do your page load. Pull out the right hand sidebar if necessary, so you have tabs "Headers", Cookies" etc. Pick the "Security" tab. You can now see the SSL parameters for each load in the list.

> If Masatoshi's comment in correct in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1137677#c21 that "If any of
> subresources is using RC4, we should not consider it is secure" I'd like to
> see Firefox dump some helpful info to the Web Console. Otherwise, this will
> be very difficult for a customer to figure out.

Notwithstanding the above, +1 to that.

Gerv

Comment 36

3 years ago
Thanks, Gerv; that helps a lot. I see that I can view every subresource connection and view the cert and ciphersuite into.

The additional request is to "connect the dots" and provide an unambiguous statement (perhaps in the Web Console) that the security UI was degraded because of this particular deficiency in the connection for this particular subresource.
(Reporter)

Comment 37

3 years ago
smarticon.geotrust.com was fixed. Other subdomains are still broken.

Comment 38

3 years ago
Just as a friendly notice, these servers will need to be fixed before Firefox 44 is released (currently scheduled for 2016-01-26) if Geotrust wants connections to these servers to not fail for the general public.

In particular:
- These servers are TLS 1.1/1.2 intolerant. See e.g. https://www.ssllabs.com/ssltest/analyze.html?d=canadaca.geotrust.com
- Currently, the relevant domains are on a whitelist (https://hg.mozilla.org/integration/mozilla-inbound/file/tip/security/manager/ssl/IntolerantFallbackList.inc), which means (with the correct prefs set) that Firefox works around these broken servers, and connections go through.
- (I guess out of convenience), this whitelist is also shared for RC4 only servers.
- Per https://groups.google.com/d/msg/mozilla.dev.platform/JIEFcrGhqSM/CIjtpwxoLQAJ, this whitelist will be disabled for Firefox 44.
- AFAIK, no UI (or error/warning output) exists to say whether fallback had to be performed.
(Reporter)

Comment 39

3 years ago
These servers *already* stopped working with Chrome 45. Maybe Geotrust does not care those servers.
(Reporter)

Comment 40

2 years ago
Looks like all subdomains are fixed or stopped to provide a secure connection.
(Reporter)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.