1891113 - FxA and sync servers get a "B" on SSLlabs tests

Status: RESOLVED FIXED

(Firefox :: Sync, defect, P3)

Description

[David Durst [:ddurst]]

The core servers for the FxA connected experience all get a "B" rating from SSLLabs, e.g:

https://www.ssllabs.com/ssltest/analyze.html?d=accounts.firefox.com
https://www.ssllabs.com/ssltest/analyze.html?d=token.services.mozilla.com

The reason it gives is that:

"This server supports weak Diffie-Hellman (DH) key exchange parameters.
Grade capped to B."

Sadly I don't think we can do anything about that yet, but I wanted a bug on file to track it (and to point at when this topic comes up again).

The reasoning behind the current situation is that we have certain clients (e.g. old android devices, partner devices like Bug 1186900) that do not support the "modern" TLS configuration recommended in [1]. Instead we must use the "intermediate" configuration [2] which includes DH ciphers.

These ciphers are fine if you use secure DH parameters. But the TLS support for FxA and Sync is provided by Amazon's Elastic Load Balancers, which don't let you customize the DH parameters.

So I think we're stuck on a "B" grade until all our clients grow more modern TLS support, or Amazon gives us better tools to customize TLS on the ELBs.

[1] https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility
[2] https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29

Comment 1

[David Durst [:ddurst]]

I had hoped we would retain the history from the original bug 1219547, especially https://bugzilla.mozilla.org/show_bug.cgi?id=1219547#c9, for when we are done with browser ID support.

Comment 2

[JR Conlin [:jrconlin,:jconlin]]

As a bit of summary / outline of work:

Older versions of Firefox which used BrowserID did not have support for TLSv3 and therefore required that we keep the older, less secure DH key exchange protocols.
Since we've officially dropped all support for BrowserID, we should take this opportunity to remove the TLSv2 protocol support from the FxA and Sync/Tokenserver load handlers. (I believe that we have an explicit exception carved out of the various load balancers to handle this exact case, so removing that exception should be fairly easy for SRE.)

As I understand, the work should include

• [ ] Remove TLSv2 exceptions from the load balancer configurations for FxA and Sync systems
  * Note any changes in traffic from this removal.
• [ ] Remove code support for BrowserID from FxA (https://mozilla-hub.atlassian.net/browse/FXA-2715)
• [ ] Remove code support for BrowserID from Tokenserver (https://mozilla-hub.atlassian.net/browse/SYNC-4101)

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:markh, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[chris valaas [:cvalaas]]

Looks like we're using the "GCP Default" SSL policy for tokenserver and sync (which is the default if nothing is specified). We should be able to switch that to mozilla-intermediate which sets minimum TLS version to 1.2 and disables some ciphers (see here: https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28recommended.29)

I'm fine switching it.
Any concerns?

Comment 5

[JR Conlin [:jrconlin,:jconlin]]

No concerns. The only reason we were using the old policy (IIRC) was so that older browser that did not implement TLS 1.3, and which still used BrowserID as their default, could connect.

That is no longer an issue.

Please switch to the Mozilla-Intermediate policy at your convenience.

Comment 6

[chris valaas [:cvalaas]]

This has been done for tokenserver and sync.
https://www.ssllabs.com/ssltest/analyze.html?d=token.services.mozilla.com now shows "A"

Comment 7

[David Durst [:ddurst]]

Because they both show A, I'm going to resolve this bug.