User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.89 Safari/537.36 Steps to reproduce: Attempted to connect to https://my.cwu.edu. Actual results: Secure Connection Failed error message Expected results: In order to permit connection to this site and its content providers, please add the following hosts to the TLS intolerance fallback whitelist: my.cwu.edu my-csprd.ea.cwu.edu my-hrprd.ea.cwu.edu my-fsprd.ea.cwu.edu my-fsrenprd.ea.cwu.edu my-fsrpt.ea.cwu.edu TLS for these sites is terminated on a legacy Cisco CSS11503 load balancer which does not support enhanced security. This system is scheduled for replacement but that will not occur before Firefox 37 is released.
https://www.ssllabs.com/ssltest/analyze.html?d=my.cwu.edu etc: > Cipher Suites (sorted by strength; the server has no preference) > TLS_RSA_WITH_RC4_128_MD5 (0x4) > TLS version intolerance TLS 1.2 TLS 1.3 TLS 1.98
David: thanks for the report. You might be interested in CCing yourself on Bug 1142769, which is where the work for the next whitelist update will occur.
Thanks for naming the affected load balancer.
If it's not too late, we may need these added as well: my-csrenprd.ea.cwu.edu my-hrrenprd.ea.cwu.edu
It was a bit too late, sorry.
From http://www.cisco.com/c/en/us/td/docs/app_ntwk_services/data_center_app_services/css11500series/v8-20/release/note/RN820_X.html : "CSCts77281—With a CSS configured with SSL termination, when the CSS receives an SSL CLIENT HELLO with TLS 1.1, it may did not properly fall back to TLS 1.0. The CSS would reset the connection, which was an incorrect action. "
Here's another one that we would like added to the whitelist in the next release: m.safari.cwu.edu Hopefully this will be the last one, as we should be bringing our new balancers online by the end of the summer. Thanks.
These servers were fixed at some point. They now use TLS 1.2 (obviously fixing the version intolerance) and dropped RC4 in favor of AES CBC & GCM, as well as 3DES to support old junk. The server config is still insecure; they have SSL3 enabled still. The test also whines that these support a DH_anon cipher suite, but I don't think that's quite as bad as it complains, though it doesn't need to be doing that. Closing. Open a new issue if there's something else/new here.
The cached SSL Labs results for cwu.edu from Aug 21 still showed the problems.
Also I noticed that for my.wsu.edu at least only AES-256 and 3DES was enabled and the browsers don't support AES-256-GCM. They should be replaced with AES-128 suites.
(In reply to Yuhong Bao from comment #9) > The cached SSL Labs results for cwu.edu from Aug 21 still showed the > problems. Sure.
Thanks for the alert. After adjusting the cipher suites, these all get an A from the SSL Labs test.
Change the AES-256 cipher suites to AES-128 please.
(In reply to Yuhong Bao from comment #13) > Change the AES-256 cipher suites to AES-128 please. There's no need to remove AES GCM 256 suites, just add 128. Specifically, Firefox likes to use something like: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
That works if you order it correctly, but AES-256 isn't that much more secure than AES-128 anyway.
(In reply to Yuhong Bao from comment #10) > the browsers don't support AES-256-GCM. At least IE11 and Edge support AES-256-GCM on Windows 10. At any rate, the server was fixed for the purpose of this bug.