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 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. Thus I'm attaching a patch to only enforce that check when > the version of a TLS connection is <= 1.2. > > 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. > > [1] https://github.com/haproxy/haproxy/blob/master/src/ssl_sock.c#L1472 > > > Thank you > > AGL
Is there a way to check this is a keyupdate message which trigger the callback (and not an other)? And what happen for natural i/o operation, are they return something receiving the message or is this completely hide by openssl (i.e. what returns a SSL_read/write for instance when a keyupdate has just been received) R, Emeric
