Closed Bug 1152377 Opened 5 years ago Closed 4 years ago
.acadiau .ca (redirected from accounts .acadiau .ca login) is TLS 1 .1/1 .2 intolerant
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36 Steps to reproduce: Go to accounts.acadiau.ca, hit the Login button in the top right to be redirected to sso.acadiau.ca. Actual results: Page fails to load: "The connection to sso.acadiau.ca was interrupted while the page was loading." Setting "security.tls.version.fallback-limit" to 1 resolves the issue. Expected results: Should be redirected to the login screen.
Other bugs here are not sec-sensitive, so this probably shouldn't be, either.
TLS intolerance, I guess.
(In reply to Loic from comment #2) > TLS intolerance, I guess. Looks like it. https://www.ssllabs.com/ssltest/analyze.html?d=sso.acadiau.ca : > TLS version intolerance TLS 1.1 TLS 1.2 TLS 1.3 TLS 1.98 TLS 2.98 and many connection failures in the Handshake Simulation section.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: sso.acadiau.ca (redirected from accounts.acadiau.ca login) not working due to insecure TLS version fallback. → sso.acadiau.ca (redirected from accounts.acadiau.ca login) is TLS 1.1/1.2 intolerant
Version: Firefox 37 → unspecified
Hi g33k_2_l33t, Thanks for the report. This is a server issue that needs to be fixed eventually. sso.acadiau.ca can be added to the static whitelist so that connections will work by default again, but the earliest that will hit the general user population is Firefox 38, which is scheduled to be released on the week of 2015-05-12. Are you able to contact whoever runs sso.acadiau.ca (and central.acadiau.ca , which fails in a different way that doesn't show up on SSL Labs) to get them to fix the servers? You can point them at this bug. If not, I can do it instead. Thanks!
I will contact them and let them know. Thanks!
Hi I am the site owner. Our server only supports up to TLS 1.0. Not having TLS 1.1 and 1.2 is valid since central.acadiau.ca works with only tls 1.0. Is there anyone that can explain what this firefox message means "The connection to sso.acadiau.ca was interrupted while the page was loading."? Initially we had a SSLv2 still supported and with the help of the ssllabs.com tester I have gotten it to a B rating yet firefox still won't work. Any help would be greatly appreciated.
Mozilla has some guidelines about TLS and its servers, maybe that could help you about finding a compromise between security and usage. https://wiki.mozilla.org/Security/Server_Side_TLS
In https://wiki.mozilla.org/Security/Server_Side_TLS they have a "Mozilla SSL Configuration Generator", so I choose one of the options, our http server is too old to use the SSLHonorCipherOrder. Besides that I am using their configuration, still not working. Looking at the ssllabs report central.acadiau.ca uses preferred order and sso.acadiau.ca doesn't for the ciphers. central.acadiau.ca uses ciphers in this order: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA sso.acadiau.ca has those same three but no specified order. At times I have had a configuration where TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher has been taken out leaving only two, so that cipher should be fine. I am wondering if TLS_RSA_WITH_AES_128_CBC_SHA is the problem. ssllabs says sso.acadiau.ca doesn't support secure renegotiation and central.acadiau.ca does. Where do I go from here?
Hi Richard, Thanks for replying, and for the effort you've put in! (In reply to Richard West from comment #6) > Hi I am the site owner. Our server only supports up to TLS 1.0. Not having > TLS 1.1 and 1.2 is valid since central.acadiau.ca works with only tls 1.0. The issue here is that sso.acadiau.ca and central.acadiau.ca are both TLS 1.1/1.2 *intolerant*. When a non-buggy (let's say TLS 1.0 only) server encounters a connection attempt from a client (such as a browser) negotiating TLS 1.1 or 1.2, it is supposed to reply with the highest version it supports (TLS 1.0). If the client accepts, then TLS 1.0 will be used. This is what sso.acadiau.ca fails to do - it chokes on the connection instead. central.acadiau.ca is a bit different in that it does do what I described above, but returns an incorrect Message Authentication Code (which results in a ssl_error_bad_mac_alert failure instead of a connection interrupted failure). > Is there anyone that can explain what this firefox message means "The > connection to sso.acadiau.ca was interrupted while the page was loading."? This is what the TLS 1.1/1.2 intolerance manifests as on Firefox. In previous Firefox versions connections to servers that are TLS 1.1/1.2 intolerant are retried with lower TLS versions in an attempt to increase compatibility. However, this practice enables MITM attacks to cause fallbacks to older, less secure versions. Hence, in Firefox 37 TLS version fallbacks have been disabled by default except for sites on a static whitelist, with the intent of eventually eliminating fallbacks entirely. You can see Bug 1084025 and Bug 1114816 for more details. > Initially we had a SSLv2 still supported and with the help of the > ssllabs.com tester I have gotten it to a B rating yet firefox still won't > work. That's still a good change, thanks! (In reply to Richard West from comment #8) > At times I have had a configuration where TLS_RSA_WITH_3DES_EDE_CBC_SHA > cipher has been taken out leaving only two, so that cipher should be fine. I > am wondering if TLS_RSA_WITH_AES_128_CBC_SHA is the problem. There shouldn't be an issue with TLS_RSA_WITH_AES_128_CBC_SHA. > ssllabs says sso.acadiau.ca doesn't support secure renegotiation and > central.acadiau.ca does. This is problematic and should also be fixed, but it's not as urgent at the moment. > Where do I go from here? I'm afraid the only thing you can do on your end is to update the servers (or figure out which configuration is problematic), or make use of reverse proxies. As I mentioned in comment 4, sso.acadiau.ca can be added to a static whitelist so that connections will work by default again, but the earliest that change will hit a release version is Firefox 38 (scheduled for release on the week of 2015-05-12). central.acadiau.ca is already on the whitelist, so it's not as urgent. In the mean time, these prefs (in most to least preferred) can be set so connections are possible again: security.tls.insecure_fallback_hosts = sso.acadiau.ca (a comma separated list of domains) security.tls.version.fallback-limit = 1 security.tls.version.max = 1 Again, thanks!
Cykesiopka, thanks for your response. Thanks for putting sso.acadiau.ca on the whitelist. To clarify, can you have a TLSv1.0 only and have firefox be ok with that or do you need to have a tls 1.2, 1.1, 1.0 server?
(In reply to Richard West from comment #10) > Cykesiopka, thanks for your response. No problem! > Thanks for putting sso.acadiau.ca on the whitelist. I should clarify that this hasn't happened yet - It'll be done in Bug 1145844 instead. This is a Tech Evangelism bug, so it'll track when the server itself is fixed. > To clarify, can you have a TLSv1.0 only and have firefox be ok with that or > do you need to have a tls 1.2, 1.1, 1.0 server? Yes, TLS 1.0 only is fine for now (and probably for a while). I do however recommend moving towards supporting TLS 1.1 and 1.2 to avoid future TLS 1.0 deprecation, and for the better security.
In Bug 1145844 should I be adding sso.acadiau.ca to the bug report?
(In reply to Richard West from comment #12) > In Bug 1145844 should I be adding sso.acadiau.ca to the bug report? You could, but you don't have to. TE bugs concerning TLS intolerance or RC4 only servers blocking Bug 1126620 and/or Bug 1138101 as appropriate will be added to the whitelist.
central.acadiau.ca was fixed, but sso.acadiau.ca is still broken.
Fixed.(In reply to Masatoshi Kimura [:emk] from comment #14) > central.acadiau.ca was fixed, but sso.acadiau.ca is still broken. Looks like sso.acadiau.ca is fixed now as well.
Status: NEW → RESOLVED
Closed: 4 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.