Re: Kernel TLS for http/2

[Emmanuel Hocdet]

Hi,

> Le 14 sept. 2017 à 19:34, Lukas Tribus  a écrit :
> 
> Hello,
> 
> 
> Am 05.09.2017 um 10:00 schrieb Willy Tarreau:
>> 
>> As I already mentionned (I don't remember to whom), I really don't see *any*
>> benefit in this approach and only problems in fact. By the way, others have
>> attempted it in the past and failed.
> 
> I agree, when we are talking about the haproxy use case (which is
> always network to network).
> 
> I do find the combination between sendfile and ktls is very interesting
> though, for web servers that are waiting for the disk, especially
> event-loop based software like nginx.
> 
> 
> For haproxy on the other side symmetric crypto performance is not the
> problem; asymmetric crypto performance (the handshake) is, because it
> it is blocking the event-loop.
> 
> Pushing the handshake to worker thread(s) is a possible solution to this,
> and I guess would probably eliminate the main reason people have to use
> nbproc > 1 today.
> 

This is an excellent improvement. And traffic for established connections
is no longer disturbed by handshake.

> I believe this was discussed before and is indeed something Willy has
> on his mind.

I think is the case with ssl-mode-async in 1.8. It depend on openssl-version.
I hope this will be generalisable in a native async HS.

> 
> How difficult the OpenSSL API makes this, I'm not sure. The documentation
> certainly leaves "room for improvement" in regard to threading:
> 
> https://www.openssl.org/blog/blog/2017/02/21/threads/ 
> 
> https://github.com/openssl/openssl/issues/2165 
> 
> 
> 

++
Manu

Re: Kernel TLS for http/2

[Lukas Tribus]

Hello,


Am 05.09.2017 um 10:00 schrieb Willy Tarreau:
> Hi Aleks,
>
> On Mon, Sep 04, 2017 at 09:34:07AM +0200, Aleksandar Lazic wrote:
>> Hi,
>>
>> Have anyone seen KTLS also?
>>
>> https://lwn.net/Articles/666509/
>>
>> https://netdevconf.org/1.2/papers/ktls.pdf
>>
>> looks pretty interesting.
> As I already mentionned (I don't remember to whom), I really don't see *any*
> benefit in this approach and only problems in fact. By the way, others have
> attempted it in the past and failed.

I agree, when we are talking about the haproxy use case (which is
always network to network).

I do find the combination between sendfile and ktls is very interesting
though, for web servers that are waiting for the disk, especially
event-loop based software like nginx.


For haproxy on the other side symmetric crypto performance is not the
problem; asymmetric crypto performance (the handshake) is, because it
it is blocking the event-loop.

Pushing the handshake to worker thread(s) is a possible solution to this,
and I guess would probably eliminate the main reason people have to use
nbproc > 1 today.

I believe this was discussed before and is indeed something Willy has
on his mind.

How difficult the OpenSSL API makes this, I'm not sure. The documentation
certainly leaves "room for improvement" in regard to threading:

https://www.openssl.org/blog/blog/2017/02/21/threads/
https://github.com/openssl/openssl/issues/2165



cheers,

lukas

Re: Kernel TLS for http/2

[Aleksandar Lazic]

Hi Willy,

Willy Tarreau wrote on 05.09.2017:

> Hi Aleks,

> On Mon, Sep 04, 2017 at 09:34:07AM +0200, Aleksandar Lazic wrote:
>> Hi,
>> 
>> Have anyone seen KTLS also?
>> 
>> https://lwn.net/Articles/666509/
>> 
>> https://netdevconf.org/1.2/papers/ktls.pdf
>> 
>> looks pretty interesting.

> As I already mentionned (I don't remember to whom), I really don't see *any*
> benefit in this approach and only problems in fact. By the way, others have
> attempted it in the past and failed.

> The intended purpose is to save memory copies. But memory copies cost very
> little compared to AES encryption, so the savings are very marginal, as the
> graph shows. The reality is that in order to increase the performance by
> only 5% :

>   - existing TLS application code will require modifications to be able to
> use both openssl and ktls

>   - as new algorithms are deployed, you'll have to switch back to openssl
> and disable kernel offloading for the time it takes to upgrade to a
> new kernel. FWIW we're seeing people install openssl 1.0.2 or 1.1.0
> on centos 7. This proves that userland moves faster than kernels. This
> problem could slow down adoption of new algorithms by the way, which is
> exactly what QUIC is fighting by moving all the TCP stack into the
> browser :-(

>   - the data to be encrypted are now transferred to the kernel and visible
> using strace. One could argue that it will help with debugging, but it
> is also sometimes useful on some production systems to know that strace
> remains a safe tool to use because you don't see clear text data.

>   - the application has less control over the TLS record size, which is
> critical to page load time as it allows browsers to parse contents on
> the fly without having to wait for a full transfer before decrypting.

> So for me it's attacking a non-problem and will cause new problems. I'm
> still not seeing any real benefit, I'm sorry. And you know that usually
> I'm the one trying to push stuff into the kernel to make things faster.
> It's just that *this* specific thing doesn't bring any obvious savings
> to me.

Thank you for the detailed answer.

I think that for some use cases could the solution fit, let's see how 
this feature will evolve.

> Cheers,
> Willy

-- 
Best Regards
Aleks

Re: Kernel TLS for http/2

[Willy Tarreau]

Hi Aleks,

On Mon, Sep 04, 2017 at 09:34:07AM +0200, Aleksandar Lazic wrote:
> Hi,
> 
> Have anyone seen KTLS also?
> 
> https://lwn.net/Articles/666509/
> 
> https://netdevconf.org/1.2/papers/ktls.pdf
> 
> looks pretty interesting.

As I already mentionned (I don't remember to whom), I really don't see *any*
benefit in this approach and only problems in fact. By the way, others have
attempted it in the past and failed.

The intended purpose is to save memory copies. But memory copies cost very
little compared to AES encryption, so the savings are very marginal, as the
graph shows. The reality is that in order to increase the performance by
only 5% :

  - existing TLS application code will require modifications to be able to
use both openssl and ktls

  - as new algorithms are deployed, you'll have to switch back to openssl
and disable kernel offloading for the time it takes to upgrade to a
new kernel. FWIW we're seeing people install openssl 1.0.2 or 1.1.0
on centos 7. This proves that userland moves faster than kernels. This
problem could slow down adoption of new algorithms by the way, which is
exactly what QUIC is fighting by moving all the TCP stack into the
browser :-(

  - the data to be encrypted are now transferred to the kernel and visible
using strace. One could argue that it will help with debugging, but it
is also sometimes useful on some production systems to know that strace
remains a safe tool to use because you don't see clear text data.

  - the application has less control over the TLS record size, which is
critical to page load time as it allows browsers to parse contents on
the fly without having to wait for a full transfer before decrypting.

So for me it's attacking a non-problem and will cause new problems. I'm
still not seeing any real benefit, I'm sorry. And you know that usually
I'm the one trying to push stuff into the kernel to make things faster.
It's just that *this* specific thing doesn't bring any obvious savings
to me.

Cheers,
Willy

Re: Kernel TLS for http/2

[Aleksandar Lazic]

Hi Aleksandar Lazic,

Aleksandar Lazic wrote on 04.09.2017:

> Hi,

> Have anyone seen KTLS also?

> https://lwn.net/Articles/666509/

> https://netdevconf.org/1.2/papers/ktls.pdf

> looks pretty interesting.


In the slides is haproxy mentioned ;-)

https://github.com/ktls/af_ktls
=> Feb 5th 2017, Brussels, Belgium: FOSDEM
https://fosdem.org/2017/schedule/event/af_ktls/attachments/slides/1767/export/events/attachments/af_ktls/slides/1767/slides

-- 
Best Regards
Aleks

Kernel TLS for http/2

[Aleksandar Lazic]

Hi,

Have anyone seen KTLS also?

https://lwn.net/Articles/666509/

https://netdevconf.org/1.2/papers/ktls.pdf

looks pretty interesting.

-- 
Best Regards
Aleks