[openssl-users] Interoperating with a legacy client.
matt at openssl.org
Mon Feb 6 10:55:46 UTC 2017
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
> 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.
More information about the openssl-users