[openssl-users] Interoperating with a legacy client.

[Tim Kirby]

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.

Is there something I can do on the server side to be compatible with 
this client?  Is it possible that I'm
causing the client's behavior through something I'm doing as the server?

I may be able to provide a sanitized packet trace or packet dissections 
showing the exact behavior I'm seeing, if that would be
helpful or interesting.

Any further troubleshooting options would be welcome.

--
Tim Kirby