Hi. As far as I understood the keyupdate
https://tools.ietf.org/html/rfc8446 4.6.3 which you refer proper isn't it also a option to use https://wiki.openssl.org/index.php/TLS1.3#Renegotiation which refers to https://www.openssl.org/docs/manmaster/man3/SSL_key_update.html instead of the suggested Patch? Best regards Aleks -------- Ursprüngliche Nachricht -------- Von: Willy Tarreau <w...@1wt.eu> Gesendet: 20. Jänner 2019 23:41:17 MEZ An: Adam Langley <a...@imperialviolet.org> 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 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 tried enabling KeyUpdate and promptly broke several sites, at > least some of which are using HAProxy. > > The cause is that HAProxy's code to disable TLS renegotiation[1] is > triggering for TLS 1.3 post-handshake messages. But renegotiation has > been removed in TLS 1.3 and post-handshake messages are no longer > abnormal. Interesting! > Thus I'm attaching a patch to only enforce that check when > the version of a TLS connection is <= 1.2. I think that it makes sense. I'll wait for Emeric's check regarding any possibly overlooked impact anywhere else if some other parts would assume that this didn't happen anymore. > Since sites that are using HAProxy with OpenSSL 1.1.1 will break when > Chrome reenables KeyUpdate without this change, I'd like to suggest it > as a candidate for backporting to stable branches. Sure! OpenSSL 1.1.1 is supported on 1.9 and 1.8 so this should be backported there. 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 can safely be delivered to userland in this case, nor if they're needed there at all. > [1] https://github.com/haproxy/haproxy/blob/master/src/ssl_sock.c#L1472 > > > Thank you > > AGL > > -- > Adam Langley a...@imperialviolet.org https://www.imperialviolet.org Thanks! Willy