1628878 - No common cipher suites for https://usphs.gov

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, enhancement)

Description

[Chris Konger - NOAA]

Attachment: usphs-firefox.pcapng

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:74.0) Gecko/20100101 Firefox/74.0

Steps to reproduce:

Visit https://usphs.gov which results in a "Secure Connection Failed" message with details "PR_CONNECT_RESET_ERROR". All other browsers tested work for both Mac and PC (Chrome, Safari, Edge, etc.) Firefox fails on both Mac and PC. Versions 74.x

Confirmed that the U.S. Public Health Service server cannot find any common cipher suites. The other browsers seem to work because they support ...
TLS_RSA_WITH_AES_256_GCM_SHA384
which isn't in the list advertised in the Firefox TLS Client Hello. This results in the USPHS server immediately sending back a RST (packet capture attached).

Also have comparable Chrome capture (which is how I compared what cipher suites were presented and accepted/rejected). It looks like I can only upload one ... so am attaching the Firefox.

Actual results:

Cannot view U.S. Public Health Service website (except by using anything other than Firefox).

Also notifying the USPHS sysadmins so they are aware that Firefox users cannot view their website.

Expected results:

Should be able to view the U.S. Public Health Service website.

Also notifying the USPHS sysadmins so they are aware that Firefox users cannot view their website.

Comment 1

[Chris Konger - NOAA]

Attachment: usphs-chrome.pcapng

Aha ... can upload the other capture file after the bug has been created. Here's the Chrome capture showing successful negotiation of cipher suite TLS_RSA_WITH_AES_256_GCM_SHA384

That's the only thing I see which prevents Firefox from viewing the U.S. Public Health Service site (no common cipher).

Not an emergency, since I can use EVERY OTHER browser to look at the USPHS site. :P

Thanks!!

Comment 2

[Chris Konger]

Also confirmed the same behavior on newly upgraded Firefox (75.0 on Windows 10 ... just upgraded Mac from 74.0.1 to 75.x as well).

Comment 3

[Marcela (Please NI request to Brindusa Tot)]

Hi!,
Thanks for taking the time to add this issue. I will set product and a component to have a starting point for this
Desktop team, if this is not the right component please feel free to route this ticket to the corresponding team, thanks!

Comment 4

[Mike Taylor [:miketaylr]]

(In reply to Chris Konger - NOAA from comment #0)

Confirmed that the U.S. Public Health Service server cannot find any common cipher suites. The other browsers seem to work because they support ...
TLS_RSA_WITH_AES_256_GCM_SHA384
which isn't in the list advertised in the Firefox TLS Client Hello. This results in the USPHS server immediately sending back a RST (packet capture attached).

Martin, I assume this would be an outreach issue, given Bug 1029179 is WONTFIX, but just want to confirm. Do we have documented advice for folks to fix these types of issues on a wiki somewhere?

I'll try to get in touch with someone, but success rates for Government websites are pretty low.

Comment 5

[Chris Konger - NOAA]

I did get confirmation from the USPHS Commissioned Corps folks (morning of 10-Apr) that they had received my report of accessibility info and had forwarded it to their IT/Web group. This Bugzilla ticket number was included as part of the info sent over. So hopefully they are aware of the issue or at least are looking at this thread. ;)

Chris Konger
NOAA N-Wave

Comment 6

[Martin Thomson [:mt:]]

Thanks for raising this Chris, and for contacting USPHS.

I'm surprised that this has gone so long without us noticing, though it might be a recent change on the server end. We recently stopped compatibility scans for this specific sort of problem, so it is possible that a server change escaped our notice.

This server supports only TLS 1.2, which is good, but the set of supported cipher suites is a little broken. The server has support for ECDHE, but only enables it for CBC suites, which are a poor choice relative to the GCM suite mentioned in comment 0.

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

The best outcome here would be for the server to enable the following two ciphersuites:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

These are already clearly possible with the server, as they are just disabled combinations from the above list. So this should be a relatively trivial configuration change. Ideally, these two would be preferred over all of the previous suites as they provide both forward-secure key exchange and authenticated encryption. Mozilla provides help regarding TLS configuration of common servers.

As Mike observes, this is a long-standing policy on our end not to support old ciphers with new protocol versions. We could avoid this issue by enabling the CBC modes that are paired with ECDHE, but we don't believe that is a good strategy.

We have the code for all of the above ciphersuites, but there is a cost to advertising these that is paid for every TLS connection we make (8 bytes per connection stacks up). As these are also less secure, we would rather not make the change. Changes like this also likely take more than a few weeks, so the server changes are likely faster.

Let's first see whether a polite request to fix the server configuration has the desired effect.

Comment 7

[Oana Arbuzov [:oanaarbuzov]]

I can't reproduce the issue, for me the site loads correctly.
https://prnt.sc/xdpts0

Tested with:
Browser / Version: Firefox Nightly 86.0a1 (2021-01-20)
Operating System: Windows 10 Pro

Chris Konger can you still reproduce it?

Comment 8

[Chris Konger - NOAA]

We did report this issue to the https://usphs.gov support folks. I haven't looked at the cipher list currently being exchanged ... I do know my Firefox client has been upgraded a couple times in the past 9 months (so not sure if it's the client or the server side that has changed ... but the site DOES seem to be reachable now). :)

When I get a few extra cycles ... probably tomorrow Fri 22-Jan ... I'll see if I can spot what changed. Thanks!!

Chris Konger