On 05/12/2016 23:03, Christopher Schultz wrote: > Mark, > > On 12/4/16 3:24 PM, Mark Thomas wrote: >>>>> It looks like the ProtocolHandler is really the place where >>>>> the TLS configuration is taking effect, and not the >>>>> Connector, so I'm largely ignoring the Connector for now. Is >>>>> that the right choice to make, here? > >> It depends. What you actually need to do is swap out the >> SSLContext. This is in the SSLHostConfigCertificate. > > It looks like the only place the SSLContext is actually set is from > Nio(2?)Endpoint.bind(). So that means that, with the current Tomcat > implementation, changing the SSLContext means an unbind() followed by > a bind(). Do I have that correct?
Yes. > This would be for JSSE only... for OpenSSL/APR, I suspect it will be > the same thing, but any change would have to take both into account. > > What I'd really like to be able to do is replace the SSLContext > without dropping any in-flight requests, while new requests wait to be > serviced until the new configuration was available. Something like this: > > 1. Stop processing incoming connections (e.g. still accept(), but > don't handshake, yet... or at least stay bound to the port, but don't > yet accept() and allow the TCP stack backlog to queue incoming > connections) > > 2. Load the new TLS configuration > > 3. Resume accepting connections with the updated TLS configuration > > 4. Requests accepted before step #1 continue to use the configuration > effective at the time > > I'm not sure how all that squares with that JSSE is willing to do. It should be as simple as: 1. Construct a new SSLContext 2. Replace the old SSLContext with the new one. It gets slightly trickier with APR/native as you need to explicitly clean up the old one and you can't do that until all the connections using it have closed. JSSE doesn't have that requirement. > Once the TLS handshake occurs, presumably it means that the connection > will continue to be valid until it's closed. If a connection as > mentioned in #4 above is long-running, the old SSLContext etc. will be > GC'd after the connection finally closes. If that assumption is not > correct, I don't think any of the above is even possible. > > What probably is possible is pausing all incoming connections, waiting > X ms for them to complete, then unbind(), then bind(). Client > observation would be that the service seems to stall, then fail. > Presumably, immediately re-trying would connect and get the new > configuration. > > How difficult do you think it would be to implement such a "graceful" > shutdown of the connector? It would be the same as "stop" except that > it would first allow all in-flight requests to complete (with some > reasonable timeout... say, as specified by a parameter to a > gracefulShutdown(int) call?) and then, in the case of the > bindOnInit="false", it would unbind(). I think that is the wrong approach. Just leave everything running and just replace the SSLContext on the fly. With the caveat that APR/native is a little trickier. We might need to add usage counting or similar. > That would allow a JMX client to say "shut down gracefully", waiting > for an OK response (which would indicate that the connector had in > fact shut down), then immediately request a "start" and the connector > would come back up. At this point, I'd probably argue that we should > add a "restart gracefully" to the list of JMX-callable actions which > just does both of those calls on the server without a second HTTP > roundtrip from the JMX client. I think what we need is a refreshTLSConfig() method. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
