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
