Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-02-14 Thread Willy Tarreau
Hi Lukas, On Thu, Feb 14, 2019 at 06:28:29PM +0100, Lukas Tribus wrote: > Hello, > > > FYI the behavior was also changed on the openssl side (and will be in 1.1.1b): > https://github.com/openssl/openssl/commit/4af5836b55442f31795eff6c8c81ea7a1b8cf94b > > So applications fixes are only

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-02-14 Thread Lukas Tribus
Hello, FYI the behavior was also changed on the openssl side (and will be in 1.1.1b): https://github.com/openssl/openssl/commit/4af5836b55442f31795eff6c8c81ea7a1b8cf94b So applications fixes are only necessary for 1.1.1a. Lukas

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-23 Thread Janusz Dziemidowicz
śr., 23 sty 2019 o 11:53 Janusz Dziemidowicz napisał(a): > 1.14.2 is current version in Debian testing. Debian seems reluctant to > use "mainline" nginx versions (1.15.x) so 1.14.x might end in Debian > 10. I'll try to file Debian bug report later today.

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-23 Thread Janusz Dziemidowicz
śr., 23 sty 2019 o 10:41 Lukas Tribus napisał(a): > > I tested all my servers and I've noticed that nginx is broken too. I > > am running nginx 1.14.2 with OpenSSL 1.1.1a The nginx source contains > > exactly the same function as haproxy: > >

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-23 Thread Willy Tarreau
On Wed, Jan 23, 2019 at 10:40:09AM +0100, Lukas Tribus wrote: > Also, we need a big fat warning that all TLSv1.3 users must upgrade in > the next 1.8 and 1.9 stable version announcement containing this fix. That's a good point, this will also encourage distro maintainers to update their versions.

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-23 Thread Lukas Tribus
On Wed, 23 Jan 2019 at 09:52, Willy Tarreau wrote: > > On Wed, Jan 23, 2019 at 12:07:04AM -0800, Dirkjan Bussink wrote: > > Of course, you're right. New version of the patch attached! > > Now merged, thank you! It's obvious, but because the commit message doesn't not explicitly mention it: This

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-23 Thread Willy Tarreau
On Wed, Jan 23, 2019 at 12:07:04AM -0800, Dirkjan Bussink wrote: > Of course, you're right. New version of the patch attached! Now merged, thank you! Willy

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-23 Thread Dirkjan Bussink
Hi Willy, On 22 Jan 2019, at 23:17, Willy Tarreau wrote: > > As you can see it will enable this code when SSL_OP_NO_RENEGOTIATION=0, > which is what BoringSSL does and it needs this code to be disabled. Thus > I think it's better to simply do this : > > +#ifndef SSL_OP_NO_RENEGOTIATION > +

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-22 Thread Willy Tarreau
Hi Dirkjan, On Tue, Jan 22, 2019 at 11:07:07PM -0800, Dirkjan Bussink wrote: > I have adjusted the patch to make it more robust and more match the style of > how we use other options. How does this look to you? Unfortunately it does introduce the problem I feared for BoringSSL : +#if

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-22 Thread Dirkjan Bussink
Hi Willy, > On 22 Jan 2019, at 07:07, Willy Tarreau wrote: > > Hi guys, > > On Tue, Jan 22, 2019 at 03:22:38PM +0100, Emeric Brun wrote: >> I think you can merge this. > > OK. I still find it very fragile in that we usually don't make a > difference between an absent define and the same

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-22 Thread Willy Tarreau
Hi guys, On Tue, Jan 22, 2019 at 03:22:38PM +0100, Emeric Brun wrote: > I think you can merge this. OK. I still find it very fragile in that we usually don't make a difference between an absent define and the same declared as zero, and most SSL_OP_* entries are defined this way in ssl_sock.c,

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-22 Thread Emeric Brun
Hi Willy, On 1/21/19 6:38 PM, Dirkjan Bussink wrote: > Hi Emeric, > >> On 21 Jan 2019, at 08:06, Emeric Brun wrote: >> >> Interesting, it would be good to skip the check using the same method. >> >> We must stay careful to not put the OP_NO_RENEG flag on the client part >> (when haproxy

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-22 Thread Emeric Brun
Hi Willy, On 1/21/19 6:38 PM, Dirkjan Bussink wrote: > Hi Emeric, > >> On 21 Jan 2019, at 08:06, Emeric Brun wrote: >> >> Interesting, it would be good to skip the check using the same method. >> >> We must stay careful to not put the OP_NO_RENEG flag on the client part >> (when haproxy

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-22 Thread Emmanuel Hocdet
> Le 21 janv. 2019 à 19:31, Adam Langley a écrit : > > On Mon, Jan 21, 2019 at 10:16 AM Dirkjan Bussink wrote: >> Ah ok, I recently added support in HAProxy to handle the new >> SSL_CTX_set_ciphersuites option since OpenSSL handles setting TLS 1.3 >> ciphers separate from the regular ones.

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-22 Thread Emmanuel Hocdet
> Le 21 janv. 2019 à 19:07, Dirkjan Bussink a écrit : > > Hi Manu, > >> On 21 Jan 2019, at 09:49, Emmanuel Hocdet wrote: >> >> Boringssl does not have SSL_OP_NO_RENEGOTIATION and need KeyUpdate to work. >> As workaround, SSL_OP_NO_RENEGOTIATION could be set to 0 in openssl-compat.h. > >

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Adam Langley
On Mon, Jan 21, 2019 at 10:16 AM Dirkjan Bussink wrote: > Ah ok, I recently added support in HAProxy to handle the new > SSL_CTX_set_ciphersuites option since OpenSSL handles setting TLS 1.3 ciphers > separate from the regular ones. Are those things that BoringSSL would also > want to adopt

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Dirkjan Bussink
Hi Adam, > On 21 Jan 2019, at 10:09, Adam Langley wrote: > > HAProxy isn't a user that we have on our radar, but BoringSSL dislikes > pushing compatibility hacks into downstream projects. (You can always > ask for these things to be included in BoringSSL instead.) Ah ok, I recently added

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Adam Langley
On Mon, Jan 21, 2019 at 9:49 AM Emmanuel Hocdet wrote: > Boringssl does not have SSL_OP_NO_RENEGOTIATION and need KeyUpdate to work. > As workaround, SSL_OP_NO_RENEGOTIATION could be set to 0 in openssl-compat.h. HAProxy isn't a user that we have on our radar, but BoringSSL dislikes pushing

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Dirkjan Bussink
Hi Manu, > On 21 Jan 2019, at 09:49, Emmanuel Hocdet wrote: > > Boringssl does not have SSL_OP_NO_RENEGOTIATION and need KeyUpdate to work. > As workaround, SSL_OP_NO_RENEGOTIATION could be set to 0 in openssl-compat.h. Hmm, then we will need a different #define though since we can’t rely own

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Emmanuel Hocdet
Hi, > Le 21 janv. 2019 à 17:06, Emeric Brun a écrit : > > Interesting, it would be good to skip the check using the same method. > > We must stay careful to not put the OP_NO_RENEG flag on the client part (when > haproxy connects to server), because reneg from server is authorized > but i

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Dirkjan Bussink
Hi Emeric, > On 21 Jan 2019, at 08:06, Emeric Brun wrote: > > Interesting, it would be good to skip the check using the same method. > > We must stay careful to not put the OP_NO_RENEG flag on the client part (when > haproxy connects to server), because reneg from server is authorized > but i

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Emeric Brun
On 1/21/19 3:37 PM, Dirkjan Bussink wrote: > Hi all, > >> On 21 Jan 2019, at 02:01, Emeric Brun wrote: >> >> Is there a way to check this is a keyupdate message which trigger the >> callback (and not an other)? > > Sadly there is not. I had taken a look at the OpenSSL code and it triggers >

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Dirkjan Bussink
Hi all, > On 21 Jan 2019, at 02:01, Emeric Brun wrote: > > Is there a way to check this is a keyupdate message which trigger the > callback (and not an other)? Sadly there is not. I had taken a look at the OpenSSL code and it triggers the callback without any additional information available

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Janusz Dziemidowicz
pon., 21 sty 2019 o 00:10 Adam Langley napisał(a): > No idea, I'm afraid. If you have a server to test, it looks like one > can use OpenSSL 1.1.1's `openssl s_client` tool to send a KeyUpdate > message by writing "K" on a line by itself. I tested all my servers and I've noticed that nginx is

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-21 Thread Emeric Brun
Hi Adam, On 1/20/19 10:12 PM, Adam Langley wrote: > KeyUpdate messages are a feature of TLS 1.3 that allows the symmetric > keys of a connection to be periodically rotated. It's > mandatory-to-implement in TLS 1.3, but not mandatory to use. Google > Chrome tried enabling KeyUpdate and promptly

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-20 Thread Willy Tarreau
On Sun, Jan 20, 2019 at 03:08:23PM -0800, Adam Langley wrote: > On Sun, Jan 20, 2019 at 2:41 PM Willy Tarreau wrote: > > Just out of curiosity, if such out-of-band messages are enabled again in > > 1.3, do you think this might have any particular impacts on something like > > kTLS where the TLS

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-20 Thread Aleksandar Lazic
Thank you for clarification. Regard Aleks Ursprüngliche Nachricht Von: Adam Langley Gesendet: 21. Jänner 2019 00:12:59 MEZ An: Aleksandar Lazic CC: haproxy@formilux.org, Willy Tarreau , eb...@haproxy.com Betreff: Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-20 Thread Adam Langley
On Sun, Jan 20, 2019 at 3:04 PM Aleksandar Lazic wrote: > which refers to > https://www.openssl.org/docs/manmaster/man3/SSL_key_update.html > > instead of the suggested Patch? The SSL_key_update function enqueues a KeyUpdate message to be sent. The problem is that if a /client/ of HAProxy

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-20 Thread Adam Langley
On Sun, Jan 20, 2019 at 2:41 PM Willy Tarreau wrote: > Just out of curiosity, if such out-of-band messages are enabled again in > 1.3, do you think this might have any particular impacts on something like > kTLS where the TLS stream is deciphered by the kernel ? I don't know how > such messages

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-20 Thread Aleksandar Lazic
of the suggested Patch? Best regards Aleks Ursprüngliche Nachricht Von: Willy Tarreau Gesendet: 20. Jänner 2019 23:41:17 MEZ An: Adam Langley CC: haproxy@formilux.org, eb...@haproxy.com Betreff: Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used. Hi Adam, [ccing

Re: HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-20 Thread Willy Tarreau
Hi Adam, [ccing Emeric] On Sun, Jan 20, 2019 at 01:12:44PM -0800, Adam Langley wrote: > KeyUpdate messages are a feature of TLS 1.3 that allows the symmetric > keys of a connection to be periodically rotated. It's > mandatory-to-implement in TLS 1.3, but not mandatory to use. Google > Chrome

HAProxy with OpenSSL 1.1.1 breaks when TLS 1.3 KeyUpdate is used.

2019-01-20 Thread Adam Langley
KeyUpdate messages are a feature of TLS 1.3 that allows the symmetric keys of a connection to be periodically rotated. It's mandatory-to-implement in TLS 1.3, but not mandatory to use. Google Chrome tried enabling KeyUpdate and promptly broke several sites, at least some of which are using