hi all!
In the hope i'm not clubbing a diseased donkey, i'd like to share an idea i ran across: we could use the RC4-128 cypher for secure.wikimedia.org, instead of AES256. RC4 is reportedly a lot faster (3 to 4 times the throughput). Since CPU capacity for encryption has been mentioned as one of the problems with making secure.wikimedia.org reliable, I thought it might help.
Note that even though the use of RC4 in WEP led to WEP being broken, RC4 is still fine for use with SSL. The attacks that broke WEP don't apply there http://www.rsa.com/rsalabs/node.asp?id=2009, http://blog.ivanristic.com/2009/08/is-rc4-safe-for-use-in-ssl.html. Google and BankOfAmerica, among others, seem to trust in this :)
-- daniel
Daniel Kinzler daniel@brightbyte.de wrote:
hi all!
In the hope i'm not clubbing a diseased donkey, i'd like to share an idea i ran across: we could use the RC4-128 cypher for secure.wikimedia.org, instead of AES256. RC4 is reportedly a lot faster (3 to 4 times the throughput). Since CPU capacity for encryption has been mentioned as one of the problems with making secure.wikimedia.org reliable, I thought it might help.
% openssl s_client -connect secure.wikimedia.org:443 -CApath /usr/local/share/certs/ -cipher RC4-SHA
(...)
New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: 23D5071FD392363CB3215134418219F083866583174FC2809795C4AB373F4EDC (...)
seems to work for me.
If you want to give up benefts brought to you by the Diffie-Hellman ephemeral key exchange, anyone may turn it off in their browser. In Seamonkey I have at hand it's going into "about:config", and setting a whole bunch of modes in "security.ssl3" to "false".
Not sure if this should be done server-side, though. Unless there is a dire need and we can't support more sessions than we already do.
//Marcin
On Mon, Mar 21, 2011 at 8:21 AM, Daniel Kinzler daniel@brightbyte.de wrote:
In the hope i'm not clubbing a diseased donkey, i'd like to share an idea i ran across: we could use the RC4-128 cypher for secure.wikimedia.org, instead of AES256. RC4 is reportedly a lot faster (3 to 4 times the throughput). Since CPU capacity for encryption has been mentioned as one of the problems with making secure.wikimedia.org reliable, I thought it might help.
I was told that the real CPU cost is in setting up the connection, in Diffie-Hellman or RSA, not in the symmetric encryption once a shared secret is established.
wikitech-l@lists.wikimedia.org