I've been using IE, Chrome and Firefox as clients for a test SSL/TLS server. This works fine with Firefox, which uses a single TCP connection for the TLS handshake and subsequent communication. However, IE and Chrome seem often to send different parts of the handshake on different TCP connections. When this happens, the server fails. As an example, IE may connect and send a ClientHello. The server responds with a ServerHello on the same socket. IE then replies with ClientExchange/ChangeCipherSpec/Finished, but not necessarily on the same socket. Instead, IE may establish a brand new TCP connection and send the messages over that -- all while the server is expecting the messages on the original socket. The server remains blocked on a recv() for that socket, waiting for data that will never come through it. How does one deal with a handshake sent over multiple TCP connections? It's not clear how to determine which connections are sending data for which handshakes, especially when many clients hit the server hard. The server doesn't know whether to call recv() to receive handshake messages over the original connection, or to use accept()/recv() to take a new connection. If a new connection does come, can we simply terminate the original one? I might well be missing something here, or perhaps not correctly interpreting what I'm seeing in the debug spew. Any help much appreciated. Thanks, Paul T. Lambert
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
