Julien, On 9/12/2013 19:35, Julien Vehent wrote:
aes-256-cbc with AES-NI does 543763.11kB/s. That's 4.35Gbps of AES bandwidth on a single core. On a decent 8 core load balancer, dedicate 4 to TLS, and you get 17.40Gbps of AES bandwidth. I don't this AES is close to being the limiting factor here. Processing HTTP is probably 20 times more expensive than that.
That's not correct. Basic HTTP processing is much less CPU intensive than the overhead of SSL/TLS, regardless of which cipher suite used, usually by at least an order of magnitude. The crypto is very much the limiting factor. Choosing a more CPU intensive algorithm will result in more server hardware being required in general in data centers.
Of course, the server can always disable AES-256 cipher suites altogether if it doesn't want to spend cycles on it. It would then choose the AES-128 cipher suites if the client also had them enabled, which I believe is the case in this proposal. Only an ordering change is proposed.
Some servers also ignore the order of cipher suites in the Clienthelo anyway in some cases, and choose whatever they prefer among the client cipher suite list regardless of order, even though this doesn't follow the TLS specs.
Julien -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
