[openssl-users] Interoperating with a legacy client.

[Matt Caswell]

On 07/02/17 09:46, Tim Kirby wrote:
> 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?

By the time you hit the message callback OpenSSL will already have read
the ClientHello record from the BIO. Therefore by the time you created a
new SSL object and attempted the handshake the ClientHello would no
longer be available for reading.

Are you able to detect this at an application level? Is there something
about the application level protocol which might indicate that the
client is about to end the connection?

I assume there is no close_notify alert coming from the client
indicating the closure of the connection.

Ideally you would detect the closure in one of the above ways. If the
closure comes completely randomly and unpredictably then that's a bit
more difficult to deal with - although still possible.

I would probably write a custom BIO that inspects the incoming TLS
records looking for a handshake record with an unencrypted ClientHello
in it. If it detects one then it signals the closure to libssl - before
libssl has read the data out. You can then reuse the same BIOs and
context for a new SSL object.

Care should be taken though to make sure that, at an application level,
you treat this as a completely new connection - not a continuation of a
previous connection (which would have security implications).

Matt