The openssl 0.9.8k implementation (later versions ?) have a bug that results in failed renegotiation whenever a data record is received instead of the expected handshake record; this can happen with full-duplex protocols. When this happens, the SSL/TLS session dies with "error:140940F5:SSL routines:SSL3_READ_BYTES:unexpected record" being reported to the initiator of renegotiation. The other side may see something like "error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message" and "error:140940E5:SSL routines:SSL3_READ_BYTES:ssl handshake failure".
The above scenario occurs when peer A initiates the SSL Renegotiate procedure while peer B is still sending data to peer A. In this test, the following cipher list was used: "ALL:!ADH:!LOW:!EXP:!MD5:@STRENGTH". Both client and server were running openssl 0.9.8k. I haven't had the resources to test on a newer build. The _ONLY_ reliable scenario occurs with the half-duplex model: peer A initiates the renegotiation handshake, while peer B is reading and no data records are received by peer A until the renegotiation is completed; this implies that there also MUST NOT be any data records in transit from peer B to peer A (in socket buffer(s) or on the network) during the renegotiation procedure. Best regards, Vitaly ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
