On 2/6/2017 2:55 AM, Matt Caswell wrote:
This does look like the client is misbehaving for some reason. It's not
behaviour I can reproduce with a 1.0.1j version of s_client.

The second ClientHello should have a TLS1.2 record version, not have the
SCSV ciphersuite, but instead have a renegotiation_info extension.

Is the second ClientHello encrypted or in plaintext? If it is a
renegotiation then it would be encrypted. I am wondering whether for
some reason the client has forgotten its original connection, and is
attempting a second completely new TLS connection over the same
underlying TCP connection.

Good question!

I checked my traces again, and the second ClientHello is plaintext.

Starting a new TLS connection over the same TCP connection as an

existing, functional, TLS connection seems like a weird thing for the

client to do, but that would explain a second ClientHello that looks like an

initial connection.


Assuming that's what's happening, is there a way I can detect it and start

a new connection instead? Would it be safe to use a message callback to look

for a ClientHello, do an SSL_new() with the current context, and reuse the same BIOs?


Thanks.


--

Tim Kirby

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to