On 06/12/2016 16:25, Christopher Schultz wrote: > On 12/6/16 4:17 AM, Mark Thomas wrote:
<snip/> >> It should be as simple as: > >> 1. Construct a new SSLContext > >> 2. Replace the old SSLContext with the new one. > > So if there were a reloadTLSConfiguration method on the Connector (or > similar component), it could simply call setSSLContext() on the > SSLHostConfigCertificate and wait for the next request to come in? In theory, yes. I haven't tested that though. >> I think what we need is a refreshTLSConfig() method. > > Perfect. > > If such a method were to be on the Connector (at least for the JMX > bean representing the Connector), it looks like a fairly simple call > (or calls.. for each SSLHostConfig) to > AbstractEndpoint.createSSLContext would do the trick. That method > seems to not only create the SSLContext but also set that new context > on the certificate (SSLHostConfigCertificate) object. > > I think there might be some thread-safety issues though with the > changing configuration of e.g. sslHostConfig.enabledProtocols and > sslHostConfig.enabledCiphers before the certificate is updated. As it > stands, the code seems to expect that, once initialized, no later > re-initializations occur. We'd need to make sure that we swap-out that > configuration in an atomic way. The SSLContext is built separately and > dropped-onto the certificate object. sslHostConfigs is a ConcurrentHashMap. It might be possible to construct the whole new SSLHostConfig (and associated SSLHostConfigCertificate and SSLContext objects) and then do an atomic update of the mapping in sslHostConfigs. > Finally, even for JSSE, there is a releaseSSLContext() that looks like > it should probably be called[1]. So I think for both OpenSSL and JSSE, > we'd want to use the same technique. Something like a list of > currently in-use SSLContext objects (it should be fairly limited) and > when one of them drops-out of the "in-use" list, we properly-dispose > of it. > > That essentially requires reference-counting around > connection-management: check-out an SSLContext and then release it > afterward. The last release for a shutting-down SSLContext will > release that context. > > Does that sound ... overly complicated or foolish? I'm sensitive to > the fact that there will be a performance impact for something like this > . I don't see any option other than reference counting. That could also get very tricky. It is worth considering keeping a list of all SSLContexts used and shutting them all down when the Connector stops. i.e. trade memory for complexity. > WDYT? Certainly worth exploring. > [1] After a little more reading, I see that the JSSESSLContext has a > no-op implementation of destroy(). So we could be a bit lazy for a > first implementation. The destroy() method is only there because APR/native needs it. It is certainly easier to try this out with JSSE but any solution is going to have to cover APR as well in the end. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
