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