Closed Bug 1137677 Opened 9 years ago Closed 8 years ago

Some geotrust.com subdomains are TLS intolerant

Categories

(Web Compatibility :: Site Reports, defect)

Product:
Web Compatibility
Component:
Site Reports
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: emk, Unassigned)

References

(
URL
)

Details

Attachments

(1 file)

WebConsole.JPG
69.75 KB, image/jpeg
Details 
canadaca.geotrust.com
services.geotrust.com
smarticon.geotrust.com
Are you asking us to do something to address this?
Upgrade these servers just like how you upgraded products.geotrust.com
By when? And if we can't do it in time?
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.
Firefox 37 will be released around the week of April 8 I think, though note that for now these domains are whitelisted.
Also services.geotrust.com still uses the old 1024-bit Equifax root, which should be fixed at the same time if possible.
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.
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)
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)
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.
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)
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)
(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.
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)
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.
The problem no longer reproduces because the server has been fixed to put RC4 at the bottom.
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?
I think so.
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.
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)
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)
Can you post an example URL?
Flags: needinfo?(VYV03354)
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.
(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.
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".
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?
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.
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?
It is supposed to be logged in Web Console or Browser Console. Strange...
Are you enabling OCSP?
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.
I can't explain more of comment #21, sorry.
Attached image WebConsole.JPG — 
Web Console warning about use of SHA-1 in Bugzilla
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
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.
smarticon.geotrust.com was fixed. Other subdomains are still broken.
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.
URL: https://canadaca.geotrust.com/
These servers *already* stopped working with Chrome 45. Maybe Geotrust does not care those servers.
Looks like all subdomains are fixed or stopped to provide a secure connection.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: