Wiki CSS files over HTTPS use only RC4

B-Con · 2011-01-17 19:33:58

I finally found the answer to my problem of why the wiki CSS files wouldn't load.

It turns out that the wiki forces an HTTPS connection and it retrieves the CSS files from https://d11xdyzr0div58.cloudfront.net. The encryption used for those CSS files uses 128-bit RC4 with MD5. In Firefox, the about:config parameter name is

security.ssl3.rsa_rc4_128_md5

I had turned off all RC4-based encryption for SSL3 in about:config because RC4 is old and not appropriate for secure use in the modern day. Since SSL works by the server offering to the client all of the encryption algorithms it's willing to use, and then the client selects the ones it likes, my assumption was that if the encryption parameters for a connection include RC4 Firefox would just not ever pick one of the RC4 options. However, I had no idea that there would be a website that ONLY offered RC4. My guess is that this is the case for the wiki's CSS file server, because only by turning on the about:config parameter mentioned above can I get the CSS files to load.

Is there a way to address this issue? Preferably, either the CSS file server needs to support alternative algorithms (it looks like a cloud host, is that under our control at all?), or the wiki needs a way to be viewed in non-HTTPS mode. I don't care about the security of the wiki CSS files, I care about having RC4 turned on in Firefox -- I shouldn't have to enable it.

I considered filing a feature request, but I wanted feedback first.

MkFly · 2011-01-26 05:27:28

A couple of years ago, I wrote an extension for Firefox called CipherFox (see my sig below). One of its features is disabling RC4 in about:config. I've had RC4 disabled all this time, and the Arch Wiki is the first time I've ran into trouble with it being disabled.

I too don't care much about the CSS files being encrypted. Here's what I did a couple of months ago as a crappy, hacked-up workaround:

(1) A Greasemonkey script to change link and script href's to point to http instead of https:

// ==UserScript==
// @name          Archwiki Cloudfront SSL
// @description   Removes SSL from Cloudfront href's
// @version       1.0.0
// @author        MkFly
// @include       http://wiki.archlinux.org/*
// @include       https://wiki.archlinux.org/*
// ==/UserScript==

var head = document.getElementsByTagName('head')[0];
var link = head.getElementsByTagName('link');
var script = head.getElementsByTagName('script');

var cloudfront = "d11xdyzr0div58.cloudfront.net";

for (var i in link) {
    link[i].href = link[i].href.replace("https://" + cloudfront, "http://" + cloudfront);
}

for (var i in script) {
    script[i].src = script[i].src.replace("https://" + cloudfront, "http://" + cloudfront);
}

(2) With that installed, loading the Wiki pages was still delayed while it tried to connect via SSL and waited to time out. I worked around that by blocking them with Adblock Plus:

|https://d11xdyzr0div58.cloudfront.net/*

I know this is a hacky way to do it, but it works for now. Hopefully Cloudfront will let us use something better than RC4 in the future.

Last edited by MkFly (2011-01-26 05:29:22)

B-Con · 2011-01-31 05:33:14

Good, someone else with the same problem.

Thanks for the work-around, MkFly.

hoschi · 2011-03-28 11:17:06

I am using Midori (Webkit) with default configuration, since the last weekend Midori doesn't load the CSS.
Any idea for a sane fix?

sironitomas · 2011-04-14 23:00:33

I'm also having this issue. It's very uncomfortble to see the wiki in plain text!

toofishes · 2011-04-15 19:07:45

This sounds like a Cloudfront fail for sure- if you haven't contacted them and let them know you would prefer they allow better ciphers, I would encourage you to.

cactus · 2011-04-15 19:54:51

B-Con wrote:

I had turned off all RC4-based encryption for SSL3 in about:config because RC4 is old and not appropriate for secure use in the modern day.

This isn't exactly true.
RC4 is a fine algorithm for streaming encryption, if used appropriately.
You have to be careful of key re-used for multiple streams, and you must discard an initial portion of the stream before transmission.
It is also extremely fast and places low load on the server, which is why extremely large sites and CDNs tend to use it.

Check many of the very large https sites you visit, and you will likely see them using rc4 (eg. google rc4_128+sha1, amazon rc4_128+md5, facebook rc4_128+md5, ebay rc4_128+md5). Now, if you were saying 3des, I would agree.

Now, WEP (notoriously insecure) used rc4, but it used it very poorly (re-using the key for multiple streams I think).

Given all that, I think using something like AES in CTR mode would be better for security, but it would also place a much larger burden on the server as well as end users. However, it should be noted that rc4 is certainly not the weak link of security (in the case of ssl/tls) you make it out to be, and there are far more serious concerns with regard to poor CA security than focusing on a stream cipher used appropriately.

EDIT: It should also be noted that in this case amazon cloudfront is only serving static content, and arch's site is not leaking cookie information since the static files are served from a separate domain.

Last edited by cactus (2011-04-15 20:02:33)

litemotiv · 2011-04-15 20:16:29

cactus wrote:

Arch Linux

#1 2011-01-17 19:33:58

Wiki CSS files over HTTPS use only RC4

#2 2011-01-26 05:27:28

Re: Wiki CSS files over HTTPS use only RC4

#3 2011-01-31 05:33:14

Re: Wiki CSS files over HTTPS use only RC4

#4 2011-03-28 11:17:06

Re: Wiki CSS files over HTTPS use only RC4

#5 2011-04-14 23:00:33

Re: Wiki CSS files over HTTPS use only RC4

#6 2011-04-15 19:07:45

Re: Wiki CSS files over HTTPS use only RC4

#7 2011-04-15 19:54:51

Re: Wiki CSS files over HTTPS use only RC4

#8 2011-04-15 20:16:29

Re: Wiki CSS files over HTTPS use only RC4

Board footer