The following site loads fine in Fx34.0.5 and Fx35b6 - and Chrome - but not Fx36.0a2 build 20141230004009. https://corp.millenniumbcp.pt/ An error of "ssl_error_rx_unexpected_application_data" is encountered. SSL Labs' site says this site is TLS 1.3 intolerant, but I don't know if this is related to bug 1084025 or not.
Possibly fixed by bug 1116891.
status-firefox36: --- → affected
tracking-firefox36: --- → +
Works with 36.0b, 37.0a2, 38.0a1 for me.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
I guess they fixed their website...
This is happening on Firefox 3.6 oficial. Can you confirm wether this is a browser bug or a website bug?
This is not the same as bug 1116891. All https websites at bug 1116891 work on Firefox 36 but https://corp.millenniumbcp.pt/ does NOT. Using Firefox 36 on Ubuntu 12.04.
Looks like the site is broken again after comment #2.
Status: RESOLVED → REOPENED
Component: Security: PSM → Desktop
Product: Core → Tech Evangelism
Resolution: WORKSFORME → ---
Version: 36 Branch → Firefox 36
This web site seems to be working in all other major browsers, so it is probably not terrible unsafe. Yet, there is no way to access it in Firefox 36 as the option to add a security exception is gone from within the current page and trying to add a security exception via Preferences > Advanced > Certificates > View Certificates > Servers > Add Exception does not work either -- one gets the following error: No Information Available - Unable to obtain identification status for this site.
(In reply to miguel_ange from comment #7) > This web site seems to be working in all other major browsers, so it is > probably not terrible unsafe. This misperception is the very reason IETF had to publish RFC 7465.
It's not clear whose bug this is. Is it a website problem? Or will they suggest this is a Firefox bug? I would be great to have an explanation. Ref: https://developer.mozilla.org/en-US/Firefox/Releases/36#Security
This is a website problem. Although Firefox 36 has a workaround to avoid the problem, the workaround has no effect to this site. That said, bug 1139778 may fix the issue.
See Also: → bug 1139778
If it is a website problem, in what terms can we describe it to the website managers? We should be able to describe it if we are to tell them it's their problem, especially as it is hapenning only with Firefox. Or should we assume this will get fixed on Firefox? But even if it does, they should be informed if there is something wrong on their side.
I agree that this server is garbage, but its behavior is quite odd and it would be nice to know what's going on here. https://www.ssllabs.com/ssltest/analyze.html?d=corp.millenniumbcp.pt It supports TLS 1.0 only, with the following ciphers: TLS_RSA_WITH_RC4_128_MD5 (0x4) TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) It can properly version negotiate up to TLS 1.2, at least, so intolerance doesn't seem to be an issue here. Attempting to connect to it with RC4 disabled results in an ssl_error_rx_unexpected_application_data error, even if 3DES is the ONLY cipher enabled. Why? Of course the solution here is obviously for the server to upgrade to security protocols made this century. (literally; this '90s crap needs to die) That being said, I would like to know what's going on here.
If you want the most concrete and simple thing to tell the maintainers of the server, it's this: This server is using Microsoft IIS 6 on Windows Server 2003 (or possibly XP...), which is just barely still under extended support but not being properly maintained. Its maintainers have until July 14, 2015 to fully upgrade its operating system and server software before Microsoft finally officially declares it past its end-of-life and won't even provide minimal security updates, at which point it will go from pathetic to dangerous. Servers like this are the reason we can't have nice things.
Looks fixed now, so I guess it's too late to investigate the weird behaviour of this server. https://www.ssllabs.com/ssltest/analyze.html?d=corp.millenniumbcp.pt : > Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites always at the end) > TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) > TLS_RSA_WITH_AES_256_CBC_SHA (0x35) > TLS_RSA_WITH_3DES_EDE_CBC_SHA
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 3 years ago
Resolution: --- → FIXED
Summary: Secure site does not load in Aurora 36, error "ssl_error_rx_unexpected_application_data" → Connecting to corp.millenniumbcp.pt with RC4 disabled results in ssl_error_rx_unexpected_application_data
I confirm that this is fixed. I got a call from them, where they let me know they had fixed it. I suggested that they should test Firefox beta releases to avoid such problems in the future (seems that there was a flood of support requests as the website stopped working on Firefox 36). I also let them know that a global browser security push is here to stay so they should be prepared for that. Given the current ssl status of this server, is it likely that it will be broken for Firefox in the near term?
I think the status of this bug should be WONTFIX as nothing was done on Firefox.
(In reply to Gustavo Homem from comment #16) > I think the status of this bug should be WONTFIX as nothing was done on > Firefox. This is a Tech Evangelism bug. It's for tracking a site's issue, not Mozilla's handling of it. It's FIXED when they fix it. (unlike pretty much every other area of Bugzilla) More precisely, TE bugs are considered FIXED due to people working on the issue here, meaning contacting the site in question and getting them to fix it. That said, the domain currently redirects HTTPS to HTTP, which is quite horrible. This currently is not considered by Qualys' SSL Labs server test, however the developer of the test has assured me that fixing this is on the short-term todo list. In the future, this setup should fail the security test, but for the purposes of this issue in this bug, it's resolved.
Status: RESOLVED → VERIFIED
(In reply to Dave Garrett from comment #17) > This is a Tech Evangelism bug. It's for tracking a site's issue, not > Mozilla's handling of it. It's FIXED when they fix it. (unlike pretty much > every other area of Bugzilla) More precisely, TE bugs are considered FIXED > due to people working on the issue here, meaning contacting the site in > question and getting them to fix it. OK, thanks for the explanation. > > That said, the domain currently redirects HTTPS to HTTP, which is quite > horrible. This currently is not considered by Qualys' SSL Labs server test, > however the developer of the test has assured me that fixing this is on the > short-term todo list. In the future, this setup should fail the security > test, but for the purposes of this issue in this bug, it's resolved. Right. That behaviour is weird, in fact.
You need to log in before you can comment on or make changes to this bug.