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
