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


Reply via email to