User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20070220 Firefox/184.108.40.206 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20070220 Firefox/18.104.22.168 I cannot checkout on this website. Steps: - Go to http://www.6ave.com/ - Click on any product. - Select "Add to cart" - When it shows the cart, select "Proceed To Checkout" Alert Dialog popus up: "Firefox can't connect securely to www.6ave.com because the site uses a security protocol which isn't enabled." (I have a screenshort of the alert box) I was able to complete the purchase using Safari on Mac. Reproducible: Always
Created attachment 258734 [details] Screenshot of issue on Windows Screenshot of dialog on Windows Vista
Kinda lame that the error message doesn't tell you the name of the the disabled protocol... Loading https://www.6ave.com/ on trunk gives me an error page (not an error dialog!) saying: "An error occurred during a connection to www.6ave.com. Can't connect securely because the site uses a security protocol which isn't enabled. (ssl_error_no_cypher_overlap)"
I encountered another site yesterday that threw up a dialog that was a bit different (I will try to find the exact error message I got). Is this something that might be fallout from one of the recent bugs we fixed?
comment 3 is something else. This bug is about this site not working, because we've set security.ssl3.rsa_1024_des_cbc_sha to false as part of bug 236933 -- disable weak ciphers (this is a 56-bit cipher). [workaround, go into about:config and set that pref true.] Primarily this should be a Tech Evangelism bug: this site is doing its customers no favors using "protection" that was considered weak in 1998. They've got a modern Verisign cert, this is simply a server option they could easily change. This does raise some UI considerations though, since sites like this (and sites using SSL2) do exist. For weak ciphers would it be better to let the user connect and remove all the security indications? But then sites might try to point at the "https" part of the address and claim we're just wrong.
My inclination here is that Firefox should be trending away from the "indicating encryption status" game as a matter of general principle, talking instead about identity, about whether the site is identified meaningfully (e.g. with a high assurance cert of some kind.) As this transition happens, and we stop signalling encryption status so prominently, I think dveditz is right that it does little if any harm to just go ahead and connect with the weaker algo/keylength. Basically, bug 236933 made the case (quite rightly at the time, I think) that we shouldn't be calling small keylength encryption "secure" and giving it padlock status. If we stop relying on the padlock as a symbol of "safety," though, then we mightn't need to worry so much about small keys. The downside argument I can hear coming is that if we start allowing these connections again, while just quietly removing any indication of encryption, we remove any incentive the sites had for changing (i.e. update your encryption so that firefox will work again). Was this really a big incentive? I'm not presupposing the answer to that question, I don't know if it was or not. And how does our desire to create incentive structures that reward conscientious admins play against our desire to create an easy and appealing (and safe) user experience?
Here is what I got from the webadmin when I told him of this ticket: >>>>>>>>>>>>>>>>>>>>>> Dear Ajay, Thank you for your e-mail. In regards to your concerns, we are currently upgrading our site security to the highest security certificate available. We thank you for pointing out this issue and we appreciate customer feedback in regards to our website's design. Thank you. Sincerely, Helpdesk@6ave.com Customer Service 1-877-684-2831
Problem not found Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:22.0) Gecko/20100101 Firefox/22.0