Re: SSL acceleration

[Willy Tarreau]

On Sat, Jan 30, 2016 at 04:09:43PM +0100, Nenad Merdanovic wrote:
> 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.

I'd like to add that I tested a well-known acceleration card a few
months ago, and that RSA acceleration required a *lot* of processes
(more than 40) for the card to start to provide any benefit over
software, that the key generation latency was *much* higher than in
software, and that ECDSA was slowed down to an unusable rate around
2 or 3 keys per second. Not to mention that there were a lot of
patches to apply on top of openssl to make it barely usable, and
that prevented us from easily following openssl security updates. So
the only usage this card has is now to take space on the table in
the R lab next to the test machines.

The final point on this is that hardware doesn't follow specification
updates fast enough, and can very quickly end up being counter-productive.
I've already seen some SSL servers being limited by their hardware SSL
accelerators. CPUs are fast and cheap nowadays. Often you'd better
install a heavily multi-core CPU than waste a PCIe slot with such a
card, unless this card is extremely good and you are certain that it
can be flashed to support future algorithms efficiently.

Just my two cents,
Willy

Re: SSL acceleration

[Eric Chan]

Thanks Willy.

We also see very bad performance with HW acceleration (but better than what you 
said).
We attribute it to the fact that we can launch only 1 operation at a time in 
synchronous manner coupled with the high latency of getting data in and out of 
the VMs.
That is why we hope to enable asynchronous mode so we can launch multiple 
operations simultaneously to the HW and get much better overall throughput 
despite the latency problem.

Thanks,
Eric

Sent from my iPhone

> On Jan 31, 2016, at 12:16 AM, Willy Tarreau  wrote:
>
>> On Sat, Jan 30, 2016 at 04:09:43PM +0100, Nenad Merdanovic wrote:
>> 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.
>
> I'd like to add that I tested a well-known acceleration card a few
> months ago, and that RSA acceleration required a *lot* of processes
> (more than 40) for the card to start to provide any benefit over
> software, that the key generation latency was *much* higher than in
> software, and that ECDSA was slowed down to an unusable rate around
> 2 or 3 keys per second. Not to mention that there were a lot of
> patches to apply on top of openssl to make it barely usable, and
> that prevented us from easily following openssl security updates. So
> the only usage this card has is now to take space on the table in
> the R lab next to the test machines.
>
> The final point on this is that hardware doesn't follow specification
> updates fast enough, and can very quickly end up being counter-productive.
> I've already seen some SSL servers being limited by their hardware SSL
> accelerators. CPUs are fast and cheap nowadays. Often you'd better
> install a heavily multi-core CPU than waste a PCIe slot with such a
> card, unless this card is extremely good and you are certain that it
> can be flashed to support future algorithms efficiently.
>
> Just my two cents,
> Willy
>
>
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.

Re: SSL acceleration

[Malcolm Turnbull]

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) ?

Very happy to be told I'm wrong, because it would be great it it was.





On 29 January 2016 at 18:21, Björn Zettergren
 wrote:
> Hi Eric,
>
> If you use a hardware device supported by openssl library you'll have
> hardware acceleration, for example AES-NI extension is available on
> recent cpu's and recent versions of openssl.
>
> I don't know about your Coleto creek device, but i'm sure you can
> check with openssl :)
>
> /Björn
>
>
>
> On Fri, Jan 29, 2016 at 5:56 PM, Eric Chan  wrote:
>> Hi HAproxy team,
>>
>>
>>
>> Is there a plan to add HW acceleration to your SSL proxy?
>>
>> I am thinking of using HAproxy with Intel Coleto Creek in asynchronous mode,
>> wonder if anyone has done the patch work that needs to make that work.
>>
>>
>>
>> Thanks,
>>
>> Eric
>>
>> 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.
>



-- 
Regards,

Malcolm Turnbull.

Loadbalancer.org Ltd.
Phone: +44 (0)330 380 1064
http://www.loadbalancer.org/

RE: SSL acceleration

[Lukas Tribus]

> 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

  

Re: SSL acceleration

[Eric Chan]

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.

Thanks,
Eric

Sent from my iPhone

On Jan 30, 2016, at 4:09 AM, Lukas Tribus  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.

Re: SSL acceleration

[Nenad Merdanovic]

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  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.
> 

SSL acceleration

[Eric Chan]

Hi HAproxy team,

Is there a plan to add HW acceleration to your SSL proxy?
I am thinking of using HAproxy with Intel Coleto Creek in asynchronous mode, 
wonder if anyone has done the patch work that needs to make that work.

Thanks,
Eric
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.

Re: SSL acceleration

[Björn Zettergren]

Hi Eric,

If you use a hardware device supported by openssl library you'll have
hardware acceleration, for example AES-NI extension is available on
recent cpu's and recent versions of openssl.

I don't know about your Coleto creek device, but i'm sure you can
check with openssl :)

/Björn



On Fri, Jan 29, 2016 at 5:56 PM, Eric Chan  wrote:
> Hi HAproxy team,
>
>
>
> Is there a plan to add HW acceleration to your SSL proxy?
>
> I am thinking of using HAproxy with Intel Coleto Creek in asynchronous mode,
> wonder if anyone has done the patch work that needs to make that work.
>
>
>
> Thanks,
>
> Eric
>
> 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.

Re: SSL Acceleration

[Baptiste]

On Fri, Apr 17, 2015 at 9:32 AM, Kamran Malik kamranma...@cloudflow.net wrote:
 hi

 I have a rather simple question related to SSL acceleration. I have gone
 through some of the email archives but haven't been able to figure this out.

 On a server where among other things I am running the HAProxy application I
 want to be able to provide an accelerator card (say like a NITROX III
 security accelerator) to accelerate the SSL termination for Client
 connections. The question I have is that is this possible in HAProxy to use
 an accelerator?

 I know that natively if the server running HAProxy has the AVX2 instruction
 set then a certain amount of acceleration is achieved. My issue is can I use
 a separate accelerator card in the server and can HAProxy use that?

 Thanks in advance

 Regards,
 Kamran Malik

 PS just started using HAProxy and love it! Thanks!


Hi Kamran,

Actually, it does not depends only on HAProxy, but also on your openssl library.
If the library is able to take advantage of such device, then haproxy
will perform better.

Baptiste

SSL Acceleration

[Kamran Malik]

hi

I have a rather simple question related to SSL acceleration. I have gone
through some of the email archives but haven't been able to figure this out.

On a server where among other things I am running the HAProxy application I
want to be able to provide an accelerator card (say like a NITROX III
security accelerator) to accelerate the SSL termination for Client
connections. The question I have is that is this possible in HAProxy to use
an accelerator?

I know that natively if the server running HAProxy has the AVX2 instruction
set then a certain amount of acceleration is achieved. My issue is can I
use a separate accelerator card in the server and can HAProxy use that?

Thanks in advance

Regards,
Kamran Malik

​PS just started using HAProxy and love it! Thanks!​