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@xxxxxxxxxxxxx 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@xxxxxxxxxxx> 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
