3 ms·
These services always dock me for including RC4 ciphers. I understand that these are bad because RC4 is broken or near broken; I shouldn't be using it. However
by deathanatos 12y ago
These services always dock me for including RC4 ciphers. I understand that these are bad because RC4 is broken or near broken; I shouldn't be using it.
However, I'm simply using load balancering sevices provided by AWS and Rackspace; my understanding is that (since they perform SSL termination) it is their software on the load balancer that chooses the ciphers, and as far as I know, I cannot change this. Are they misconfigured? (why?) Is there any way to work around it short of doing the load balancing myself?
- wampus 12y agoIt appears AWS lets you configure this[1]. You may have chosen a policy and never changed it. A note on that page says if you don't choose a policy, you'll always use the latest one. It looks like you can create a custom one, as well. [1]http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/configure-ssl-ciphers.html http://docs.aws.amazon.com/ElasticLoadBalancing/latest/Devel...
- spydum 12y agorc4 may be "bad", but if you notice, it is so densely deployed on clients, it's hard to avoid.
- simon_vetter 12y agoUse these services as tcp load balancers and terminate SSL on your backends. Using a LB to offload SSL termination might seem like a good idea (you save a bit of CPU, really not more than a few percent in practice), but you expose your customer traffic to capture/inspection between the LB and your backends. This network can span multiple hops or even datacenters. Also, when the next openssl vuln hits, you can patch your setup in no time and do not need to wait for the LBs to be patched at your vendor's will.