Re: [openssl-users] Interoperating with a legacy client.
On 07/02/17 09:46, Tim Kirby wrote: > On 2/6/2017 2:55 AM, Matt Caswell wrote: >> 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. > > Good question! > > I checked my traces again, and the second ClientHello is plaintext. > > Starting a new TLS connection over the same TCP connection as an > > existing, functional, TLS connection seems like a weird thing for the > > client to do, but that would explain a second ClientHello that looks > like an > > initial connection. > > > Assuming that's what's happening, is there a way I can detect it and start > > a new connection instead? Would it be safe to use a message callback to > look > > for a ClientHello, do an SSL_new() with the current context, and reuse > the same BIOs? By the time you hit the message callback OpenSSL will already have read the ClientHello record from the BIO. Therefore by the time you created a new SSL object and attempted the handshake the ClientHello would no longer be available for reading. Are you able to detect this at an application level? Is there something about the application level protocol which might indicate that the client is about to end the connection? I assume there is no close_notify alert coming from the client indicating the closure of the connection. Ideally you would detect the closure in one of the above ways. If the closure comes completely randomly and unpredictably then that's a bit more difficult to deal with - although still possible. I would probably write a custom BIO that inspects the incoming TLS records looking for a handshake record with an unencrypted ClientHello in it. If it detects one then it signals the closure to libssl - before libssl has read the data out. You can then reuse the same BIOs and context for a new SSL object. Care should be taken though to make sure that, at an application level, you treat this as a completely new connection - not a continuation of a previous connection (which would have security implications). Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Interoperating with a legacy client.
On 2/6/2017 2:55 AM, Matt Caswell wrote: 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. Good question! I checked my traces again, and the second ClientHello is plaintext. Starting a new TLS connection over the same TCP connection as an existing, functional, TLS connection seems like a weird thing for the client to do, but that would explain a second ClientHello that looks like an initial connection. Assuming that's what's happening, is there a way I can detect it and start a new connection instead? Would it be safe to use a message callback to look for a ClientHello, do an SSL_new() with the current context, and reuse the same BIOs? Thanks. -- Tim Kirby -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Interoperating with a legacy client.
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
