[openssl-users] Interoperating with a legacy client.

[Matt Caswell]

On 04/02/17 04:56, Tim Kirby wrote:
> 
> I'm writing a server to support a legacy client that uses OpenSSL to
> secure its communication.  The client is using OpenSSL 1.0.1j, and I
> have no control over that.  I'm using the 1.0.1 version of OpenSSL
> supplied with my
> OS for the server side, but that is out of convenience rather than
> necessity.
> 
> My server appears to be working at least semi-correctly, but I have a
> problem with established
> connections being terminated by the server side, and I have run out of
> troubleshooting ideas.
> 
> The client will happily connect to my server, we complete the handshake,
> and start exchanging
> encrypted application data.  Then, it seems like the client wants to
> renegotiate, because it sends the
> server a ClientHello across the established connection.  But something
> is clearly not right, because
> the server responds with a fatal alert and terminates the connection.
> 
> I can watch the connection with wireshark, so I can see in detail what's
> going on, but the client's
> behavior doesn't make sense to me.
> 
> The typical interaction looks like this:
> 
> The client connects to the server.
> 
> The initial ClientHello advertises TLS 1.2 with a record version of 1.0,
> and includes TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> in the cipher suites. Our ServerHello response includes a zero-length
> renegotiation_info extension.  This all seems reasonable.
> 
> The negotiation settles on TLS 1.2, and subsequent application data
> records are sent at that version.  At this point, everything
> seems fine.
> 
> After sending some amount of application data, the client then seems to
> want to renegotiate.  It sends another ClientHello.
> 
> At this point, things have gone wrong.  The second ClientHello looks
> very, very similar to the one sent in the initial handshake.
> The record version is again 1.0, the TLS_EMPTY_RENEGOTIATION_INFO_SCSV
> is included in the cipher suites, and there's no
> renegotiation_info extension present.
> 
> So, if the connection is using TLS 1.2, the server terminates the
> connection with a
> version mismatch alert when it sees the second ClientHello.
> 
> If I force the server to use TLS 1.0, then the server terminates the
> connection because
> of the SCSV present in the ClientHello during renegotiation.
> 
> I'm at a loss.  It seems like the client is misbehaving, if the second
> ClientHello it sends is supposed to be
> a renegotiation attempt.  But misbehaving or not, I still need to
> interoperate with this client.

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.

Matt