I tried on 1.8dev and was still able to reproduce the problem. It appears Java is strictly interpreting the TLS spec with regards to "Closure Alerts". The section specifies that:
Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice. (https://tools.ietf.org/html/rfc5246#section-7.2.1) Java does not allow session resumption in that case. I haven't been able to reproduce the issue by running requests through the actual proxy (i.e. not check-related), but it certainly might be possible to trigger this case. I have a simple test case here: https://github.com/steved/haproxy-java-ssl-check I thought earlier that changing shutw_hard to shutw works, but now it appears I need this patch: diff --git a/src/checks.c b/src/checks.c index 49bd886b..75aa222b 100644 --- a/src/checks.c +++ b/src/checks.c @@ -2168,6 +2168,7 @@ static struct task *process_chk_conn(struct task *t) * server state to be suddenly changed. */ conn_sock_drain(conn); + conn_data_shutw(conn); conn_force_close(conn); } On Mon, Mar 6, 2017 at 10:48 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Mon, Mar 06, 2017 at 06:34:09PM -0800, Steven Davidovitz wrote: > > Interestingly, as far as I can tell, we are running into the problem > > described in this forum post: > > http://discourse.haproxy.org/t/backend-encryption-and-reusin > g-ssl-sessions/503/4 > > Switching the conn_data_shutw_hard call to conn_data_shutw in checks.c > > decreased CPU usage completely. Forcing SSLv3 as in this email ( > > https://www.mail-archive.com/haproxy@formilux.org/msg09105.html) also > > worked. > > This is very interesting! The problem with not using conn_data_shutw_hard() > is that conn_data_shutw() will only *try* to notify the other side about > an imminent close but at the same time we're going to close with > SO_NOLINGER > resulting in the close notification to be lost in the middle. And not using > SO_NOLINGER is not an option as we can end up with tons of TIME_WAIT > sockets > on haproxy which clearly is not acceptable. But more importantly it means > that we probably have a similar problem with production traffic if you > don't > use persistent connections to the server. > > But now I'm thinking about something, I'm wondering if in fact it would > not be the lack of call to SSL_shutdown() which causes the connection > not to be kept in haproxy's SSL context. In 1.8-dev this function changed > a bit so that we first call SSL_set_quiet_shutdown() then SSL_shutdown(). > > > I haven't had time to dig further, and it may certainly be client > > misconfiguration, but could you shed any light on why that might be a > > problem? > > It might be useful to use another haproxy after the checks instead of > your server to see if you observe the same effect. And if you can run > a test with 1.8-dev it would be great. I'd rather backport just the > change to ssl_sock_shutw() to 1.7 if it fixes the problem :-) > > BTW, given that only the checks are causing the trouble it's easy to > start an independant process for this. Just change all bind addresses > and let the backends run their checks to see the effect. > > Willy >
