Re: [openssl-users] Interoperating with a legacy client.

[Tim Kirby]

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

[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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users