Interoperating with a legacy client.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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
Reply | Threaded
Open this post in threaded view
|

Re: Interoperating with a legacy client.

Ryan Murray
I made writing to you to ask the team to dispatch some much more then needed assets for hardware upgrades. I have created a way bill under hacker one or [hidden email] and desperately need this as soon as possible rather then the back burner. Much more breaking news and head when I get out of the stone age.
Thanks KS for passing message along
Best regards
Sincerely,
Ryan Murray 

On Feb 4, 2017 1:36 AM, "Tim Kirby" <[hidden email]> 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.

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

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Interoperating with a legacy client.

Matt Caswell-2
In reply to this post by Tim Kirby


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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: 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
Reply | Threaded
Open this post in threaded view
|

Re: Interoperating with a legacy client.

Matt Caswell-2


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
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users