There are four RC4 cyphers which are supposedly weak and should be disabled in firefox: security.ssl3.rsa_rc4_128_md5 security.ssl3.rsa_rc4_128_sha security.ssl3.ecdhe_ecdsa_rc4_128_sha security.ssl3.ecdhe_rsa_rc4_128_sha However, the second one ( security.ssl3.rsa_rc4_128_sha ) must not be disabled for the wiki to work (CSS-wise at least, and to be able to login) All others have no effect on the wiki, if disabled. Reproducible: Always Steps to Reproduce: 1. in firefox, about:config find: security.ssl3.rsa_rc4_128_sha and set to false 2. clear browser cache (or make sure whatever wiki CSS files that were cached are gone somehow) 3. load this page for example: https://wiki.gentoo.org/wiki/Handbook:AMD64 Actual Results: 4. observe how bad the page looks Expected Results: 5. clear browser cache 6. in about:config, set to true: security.ssl3.rsa_rc4_128_sha 7. refresh that webpage (in 3.) 8. all works well, page looks normal Speculation: that rackcdn.com may be serving those CSS files and requires that cypher. Failing that, no CSS files are downloaded and errors happen (seen in firefox console, Ctrl+Shift+K or Shift+F5, click Console minitab) I think youtube requires(or requireD, haven't tested) this same cypher to watch videos. Disclaimer: I don't develop websites or play with html/css/browser stuff, thus some information that I said may be incorrect/wrong/incomplete. (ie. don't assume that I know what I'm talking aboot;)
This is not specific to the wiki. (In reply to EmanueL Czirai from comment #0) > Steps to Reproduce: > 1. in firefox, about:config find: > security.ssl3.rsa_rc4_128_sha > and set to false > 2. clear browser cache (or make sure whatever wiki CSS files that were > cached are gone somehow) > 3. load this page for example: https://wiki.gentoo.org/wiki/Handbook:AMD64 > I cannot reproduce the issue, even with all 4 RC4 ciphers disabled. > > Speculation: that rackcdn.com may be serving those CSS files and requires > that cypher. Failing that, no CSS files are downloaded and errors happen > (seen in firefox console, Ctrl+Shift+K or Shift+F5, click Console minitab) It does not even do SSL3 anymore, just TLS, so the above settings should--per the name--not even affect anything. I suspect you have flipped other settings in Firefox as well. With everything working fine here, that's about all I can do.
Thanks for replying. The weird thing is: 1. I double checked all that before reporting and I could swear it was that cypher alone which fixed it and b0rked it. 2. Right now the site is broken even with that cypher disabled. I haven't checked the site since I've reported this though and it worked at that time. I agree with what you say however, that makes sense. (was using Firefox 34.0.5 so indeed ssl3 was disabled, even about:config security.enable.ssl3 was false AND security.tls.version.min was 1 which means TLS) I will continue to try and find out what happened here, how could I have been so wrong even after double checking and making sure that only by changing that cypher from true to false the site would stop looking normal and then from false to true and it would work again (I even used 2 different firefox profiles when testing, one was a new one) My double checking must've been wrong, somehow. But I must find out exactly how :) Merry Christmas!
tl;dr: Please replace step 2. Clear Cache with 2. Restart browser. (or, clear cache and wait 10 minutes before going to step 3.) Step 5. doesn't need the browser restarting though! Actually step 5. is unnecessary! ---------long read: My bad in my previous comment at 2. I said: 2. Right now the site is broken even with that cypher disabled. which is a true statement, but for some reason that cypher was disabled for me (set to false) which is why the website wasn't loading properly again. And the reason why I haven't noticed before, that it didn't load properly even though the cypher was disabled is because, step 2. in my original post, which says Clear cache, has no effect! So, once that cypher was enabled and the site loaded properly once, then it's harder to make it fail to load properly again: to make it fail to load again in that same browser sessions(ie. without restarting browser) you'd have to do something other than just step 2. Clear Cache. Step 2. Clear Cache does work however, only if you wait 10 minutes(kinda weird, but I tested this to be the case). OR you can instead just restart browser. (I am unsure why it worked for me in my tests, can't remember waiting 10 minutes, but then again, I was clearing everything not just the Cache part - which I currently avoid to do in this browser profile because I need the Cookies at least; maybe I don't remember correctly and I was in fact restarting browser TOO because I wanted to be sure) May I suggest replacing step 2 with: 2. Restart browser Because if it's only 2. Clear cache, then only after like 10 minutes of idle (without restarting browser) then loading that website, will show the effect. I apologize for my failure to provide proper reproducible steps. It's clearly my fault here. Happy holidays! :)
Here are the corrected steps: Reproducible: Always Steps to Reproduce: 1. in firefox, about:config find: security.ssl3.rsa_rc4_128_sha and set to false 2. restart browser 3. load this page for example: https://wiki.gentoo.org/wiki/Handbook:AMD64 Actual Results: 4. observe how bad the page looks Expected Results: 5. in about:config, set to true: security.ssl3.rsa_rc4_128_sha 6. refresh that webpage (in 3.) 7. page looks normal (almost: @font-face doesn't seem to be loaded, but works fine after restart browser!)
(In reply to EmanueL Czirai from comment #4) I'm sorry but the issue is still not reproducible here using various operating systems. The connection always uses TLS 1.2 with a much better ciphersuite anyway. I guess something's really not right with your browser.
tl;dr: a bunch of other ciphers were disabled, which is why my reproductions steps worked for me, because there were no better ciphers to choose from other than the one I enabled. Wow. You are right. I cannot believe how wrong I was. Looks like the mistake that I made (even in the newly created firefox profile! <- second mistake) was to install Calomel SSL Validation firefox extension AND set (the same) settings inside it. Most importantly in its Preferences (Tools->Calomel SSL Validation->Preferences) I selected Security->Cipher Restrictions: (o) "256 bit Perfect Forward Secrecy and GCM ciphers." and eventually clicked Apply. But later on, I deselected this and many others and clicked Apply. However, since that was selected(and Applied!) once in that firefox profile's lifetime, a ton of ciphers were set to false in firefox's about:config , and, later on, deselecting that (without selecting the below option `all ciphers allowed`) would let all those ciphers remain false. And in this case, that is why the specific security.ssl3.rsa_rc4_128_sha was behaving as I previously described. I am sorry and I really apologize for this and for wasting your time. I will be more careful next time. The actual error in console was: GET https://1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com/retina.min.js [25ms] 10:32:40.748 An error occurred during a connection to 1b9a50f4f9de4348cd9f-e703bc50ba0aa66772a874f8c7698be7.ssl.cf5.rackcdn.com:443. Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap) To fix that, in my case, selecting either "128 bit and stronger" (not the PFS one above) or "all ciphers allowed" and pressing Apply, then reloading page will work! Even when security.ssl3.rsa_rc4_128_sha is false it will still work (to keep it false, deselecting everything there in Restricted ciphers, in Calomel, is needed, otherwise the respective ciphers are set(by Calomel) to true again after browser restart) , because now those ciphers which were previously disabled (by the 256 bit... setting having been set once in this profile's lifetime) are now back to true. Again, I apologize. Best wishes, E.
