https://bz.apache.org/bugzilla/show_bug.cgi?id=64437
--- Comment #10 from Armin Abfalterer <[email protected]> --- I've applied your new patch (v2) to 2.4.43 and did the test with s_server. The renegotiation works IF s_server is patched with your proposed change. Otherwise the behavior is still the same as mentioned in comment #7. I've tested the v2 patch also against our "proprietary" server software. The observation there is that renegotiation sometimes works... but most often not. As the behavior looks to me like a timing-issue (handshake data sometimes delay, sometimes not) I've changed the server by repeatably calling SSL_do_handshake() as long as SSL_renegotiate_pending() is true, additionally by peeking for data. Before the change SSL_do_handshake() was called again only on SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. Note that the server uses non-blocking sockets. SSL_renegotiate(ssl); while (goahead) { SSL_do_handshake(ssl); if (SSL_renegotiate_pending(ssl)) { char peekbuf[1]; SSL_peek(ssl, peekbuf, 0); goahead = 1; } // also repeat on SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE ... // otherwise we are finished with renegotiation ... } Doing so the renegotiation always works. Whether the workaround is right or not remains to be seen, but in my opinion it clearly shows what the problem is about. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
