[openssl-users] Interoperating with a legacy client.
Ryan Murray
rjkmurray40 at gmail.com
Sat Feb 4 07:38:52 UTC 2017
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 support at hackerone.com 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" <tkirby at hotlink.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170204/7251079b/attachment-0001.html>
More information about the openssl-users
mailing list