back

by nate·15y ago·view on hn ↗
I was doing some load testing on a new project of ours and noticed that I couldn't break 50-60 reqs per second sending all the requests through stunnel-haproxy or apache-haproxy to a cluster of app servers that should have handled about 200ish reqs per second. This wasn't a problem if the traffic wasn't encrypted. Didn't seem like a CPU bottleneck with the machine doing the load test measurements either.

So I did some digging. And noticed that https://encrypted.google.com uses RC4_128 as a cipher. You know what Bank of America uses too? RC4_128. RC4 happens to be a much faster cipher.

RC4 has gotten some bad press as it was used in WEP encryption and was cracked. But I believe it was because their RC4 implementation had a flaw rather than RC4 at 128 bis being a terrible choice for encryption? I'm not positive and would love to hear your input.

I switched our load balancer to make sure we were using RC4_128 instead of AES_256, and bam I had 3-4 times more throughput of encrypted requests going through just fine.

1 comments
The attacks used against RC4 as used in WEP are not applicable to RC4 as used in TLS connections. If you do not use related keys and discard at least the first 256 bytes, RC4 is fine. It is not that they implemented RC4 incorrectly, but that they did not account for its known weaknesses.