<div dir="auto">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 <a href="mailto:support@hackerone.com">support@hackerone.com</a> 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.<div dir="auto">Thanks KS for passing message along</div><div dir="auto">Best regards</div><div dir="auto">Sincerely,</div><div dir="auto">Ryan Murray </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Feb 4, 2017 1:36 AM, "Tim Kirby" <<a href="mailto:tkirby@hotlink.com">tkirby@hotlink.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I'm writing a server to support a legacy client that uses OpenSSL to<br>
secure its communication.  The client is using OpenSSL 1.0.1j, and I<br>
have no control over that.  I'm using the 1.0.1 version of OpenSSL supplied with my<br>
OS for the server side, but that is out of convenience rather than necessity.<br>
<br>
My server appears to be working at least semi-correctly, but I have a problem with established<br>
connections being terminated by the server side, and I have run out of troubleshooting ideas.<br>
<br>
The client will happily connect to my server, we complete the handshake, and start exchanging<br>
encrypted application data.  Then, it seems like the client wants to renegotiate, because it sends the<br>
server a ClientHello across the established connection.  But something is clearly not right, because<br>
the server responds with a fatal alert and terminates the connection.<br>
<br>
I can watch the connection with wireshark, so I can see in detail what's going on, but the client's<br>
behavior doesn't make sense to me.<br>
<br>
The typical interaction looks like this:<br>
<br>
The client connects to the server.<br>
<br>
The initial ClientHello advertises TLS 1.2 with a record version of 1.0, and includes TLS_EMPTY_RENEGOTIATION_INFO_S<wbr>CSV<br>
in the cipher suites. Our ServerHello response includes a zero-length renegotiation_info extension.  This all seems reasonable.<br>
<br>
The negotiation settles on TLS 1.2, and subsequent application data records are sent at that version.  At this point, everything<br>
seems fine.<br>
<br>
After sending some amount of application data, the client then seems to want to renegotiate.  It sends another ClientHello.<br>
<br>
At this point, things have gone wrong.  The second ClientHello looks very, very similar to the one sent in the initial handshake.<br>
The record version is again 1.0, the TLS_EMPTY_RENEGOTIATION_INFO_S<wbr>CSV is included in the cipher suites, and there's no<br>
renegotiation_info extension present.<br>
<br>
So, if the connection is using TLS 1.2, the server terminates the connection with a<br>
version mismatch alert when it sees the second ClientHello.<br>
<br>
If I force the server to use TLS 1.0, then the server terminates the connection because<br>
of the SCSV present in the ClientHello during renegotiation.<br>
<br>
I'm at a loss.  It seems like the client is misbehaving, if the second ClientHello it sends is supposed to be<br>
a renegotiation attempt.  But misbehaving or not, I still need to interoperate with this client.<br>
<br>
Is there something I can do on the server side to be compatible with this client?  Is it possible that I'm<br>
causing the client's behavior through something I'm doing as the server?<br>
<br>
I may be able to provide a sanitized packet trace or packet dissections showing the exact behavior I'm seeing, if that would be<br>
helpful or interesting.<br>
<br>
Any further troubleshooting options would be welcome.<br>
<br>
--<br>
Tim Kirby<br>
<br>
-- <br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailma<wbr>n/listinfo/openssl-users</a><br>
</blockquote></div></div>