Hello Eric, On 1/30/2016 3:44 PM, Eric Chan wrote: > Thank you all for your replies. > Yes I want to accelerate the RSA and DHE operations also, which needs approx > 2 million CPU cycles per key pair if done in pure SW. The Coleto Creek HW > will give big boost if we can get it to work. AES-NI can help the bulk > traffic but not very helpful for Session setup. >
You should really be checking out ECDSA given that HAproxy now transparently supports having both certificate types and serving appropriate ones to supporting clients. Next thing you want is making sure that you are correctly using TLS tickets and distributing their keys to the whole cluster of HAproxy nodes, as well as using keepalive to reuse existing connections instead of tearing them at the end of every request. In a decent;y sized environment getting several tens of millions requests per day, statistics I gathered show that there is about 85-88% of clients that support ECDSA. Using that and TLS keys, switching to full HTTPS was barely noticeable when examining the CPU usage. Regards, Nenad > Thanks, > Eric > > Sent from my iPhone > > On Jan 30, 2016, at 4:09 AM, Lukas Tribus <[email protected]> wrote: > >>> Now this is where I probably look stupid but... >>> >>> Am I correct in stating that the AES-NI is only really useful for file >>> encryption... and bugger all use for HTTPS/SSL encryption (which is >>> what we really want)? >> >> No, AES-NI is very useful for the symmetric part of HTTPS/TLS when >> using AES ciphers: >> >> http://www.ietf.org/mail-archive/web/tls/current/msg09847.html >> http://www.ietf.org/mail-archive/web/tls/current/msg09853.html >> https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html >> http://2013.diac.cr.yp.to/slides/gueron.pdf >> >> >> It doesn't help with the asymmetric part (the TLS handshake) though. >> >> >> Afaik major CDNs like Google and Cloudflare are not using TLS hardware, >> because the benefits are questionable. >> >> >> >> Lukas >> >> > This email and any attachments thereto may contain private, confidential, > and/or privileged material for the sole use of the intended recipient. Any > review, copying, or distribution of this email (or any attachments thereto) > by others is strictly prohibited. If you are not the intended recipient, > please contact the sender immediately and permanently delete the original and > any copies of this email and any attachments thereto. >
