-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 George,
On 6/26/15 12:34 PM, George Stanchev wrote: > Agree on point 2 & 3. Since we are in control of the application > server, we have the luxury of managing the SSL engine and the > Security Manager settings. I guess I should've provided a link to > the ssl-howto doc [1] that describes that solution. I went the > reflection way to avoid having to link with Tomcat in our build > scripts. There is discussion [2] on this issue referenced by [1]. Yeah, I think reflection is the way to go, given the current requirements for accessing that object and working with it. It might make sense to have a setting in Tomcat that invalidates the SSL session when a CLIENT-CERT-based user session is invalidated (i.e. HttpSession.invalidate() -> SSLSessionManager.invalidate()). > Regarding 1 - I also found it odd but I guess that’s not mandated > by the standard so they have to return something. Well, it seems reasonable to make an object of this type available, even if it can only really invalidate the session, currently. > It is better to return abstraction than concrete JSSE object in > case the underlying implementation changes. +1 Really, my only objection was to using the javax.servlet namespace. I don't recall the Servlet spec prohibiting such practices, but because the object is stored under that namespace, it may suggest to the user that it's a Servlet spec-defined object/behavior/etc. when it clearly isn't. > BTW why is this not working with OpenSSL/native? Is there a > technical reason or just not implemented? I didn't even try it; I just opened the SSLSessionManager interface and asked Eclipse where it was used in the rest of the project. The only result was a class in the jsse package, which led me to believe that there is no analog for APR. I may be wrong, but I'd be surprised if a JSSE-related class is being used along with the APR/native connecto r. (Of course, there's a new OpenSSL-based JSSE provider in trunk right now. Who knows what will be possible in the future. I for one will be quite happy to use OpenSSL crypto along with an NIO or NIO2 connector within Tomcat.) - -chris > -----Original Message----- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Friday, June 26, 2015 > 10:06 AM To: Tomcat Users List Subject: Re: Forcing SSL > Renotiation > > George, > > On 6/26/15 10:04 AM, George Stanchev wrote: >> You didn't specify your Tomcat version. In Tomcat 7 or 8 or 9 we >> use the following code. Not sure if it will work on 6. For a >> long time until very recently we were stuck on 5.5 and the >> attribute below is not available. So I had to write a reflection >> introspection to drill down to the SSLSessionManager held by the >> Tomcat objects under the server request. > >> Keep in mind the client cert implementation on the browsers is >> not uniform in behavior (in respect of resetting a session and >> letting the user chose another cert on relogin). We support FF, >> Chrome and IE and by far so far IE has been the most consistent. >> Later releases of Chrome cache the smartcard connection and >> resubmit the same cert on reconnect and nothing you can do on the >> server can change this (as far as I know). The JS-side crypto >> support (to reset the state) is poor, FF-specific and unreliable. >> Firefox has it's own set of issues. > > A couple of things: > > 1. I find it odd that Tomcat is using the javax.servlet namespace > for an implementation-specific class. I would argue this doesn't > belong under the key that's currently being used. > > 2. The SSLSessionManager seems to be unique to JSSE-based > implementations of TLS in Tomcat, which means that this technique > isn't going to work if you are using tcnative and OpenSSL-based > crypto. > > 3. This code isn't going to work under a SecurityManager unless > you make arrangements to configure the privileges for your code > properly. > > -chris > >> // Invalidate the SSL Session >> (org.apache.tomcat.util.net.SSLSessionManager) Method >> invalidateSessionMethod = null; Object mgr = >> httpRequest.getAttribute("javax.servlet.request.ssl_session_mgr"); >> if (mgr != null) { try { invalidateSessionMethod = >> mgr.getClass().getMethod("invalidateSession"); if >> (invalidateSessionMethod == null) { log.error("Failed to reset >> SSL session: Method invalidateSessionMethod = >> mgr.getClass().getMethod(\"invalidateSession\") failed to return >> method"); } invalidateSessionMethod.setAccessible(true); } catch >> (Throwable t) { log.error("Failed to reset SSL session: " + >> t.getMessage(), t); } > >> // Invalidate the session try { >> invalidateSessionMethod.invoke(mgr); log.trace("SSL session reset >> successfully"); return true; } catch (Throwable t) { >> log.error("Failed to reset SSL session: invalidateSession() threw >> exception: " + t.getMessage(), t); } > >> -----Original Message----- From: Steffen Heil (Mailinglisten) >> [mailto:li...@steffen-heil.de] Sent: Friday, June 26, 2015 2:43 >> AM To: Tomcat Users List Subject: Forcing SSL Renotiation > >> Hi > > >> My tomcat installation offers pages through https only. So when >> accessing these pages, an ssl connection is established. Later >> on, a user may decide to "log in", hence hitting a page, that >> requires client certificates, and the browser pops up a selection >> dialog for a certificate. Once chosen, the server recognized the >> user by its certificate, and everything is fine. So far, so >> good. > >> Now I have 2 problems: > >> 1. When clicking "logout" in the application, the server >> terminates its internal session for that user, but the ssl >> connection is not terminated. That means, as soon as anyone >> clicks login again, the old certificate is reused. So the user >> cannot login using another certificate. > >> 2. The second problem with that is, that if the certificate was >> on a smartcard and that card was removed, that cannot be >> detected. > >> Is there any way to tell tomcat to tell the browser to drop the >> tls session state and "restart"? > > >> Regards, Steffen > > >> --------------------------------------------------------------------- > >> >> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjYSvAAoJEBzwKT+lPKRYX4MP/idWO/X7MoiPXsmMvL6Cat6C abfDPbpKAdaWGXBgLNUE71BC494SyxuoTlqN1QuyJ1eSNPAZvIjhVxIaZZ8Xe0P3 IBqT9euszjAkQC7ZLVU97KcScNvNcCZpzoPyu8zyxmqITapdxWFEDRO/32/qMFQz eG3AR7oVA65HgFP5PSPGuQf6qaAJoov/isXjqif62qA6AV2B5yPYqPN3I5+obtzG MGZHemUMZTm/V2RjNqLD2py554CMzIw92DV8PwW0cdlG8nkcON331fCnoIg79jGg j55zEEcRGwes8+EvVEDL2HsKElS5RxO6gXN0DYwUox2bseXJUpdzd2CAsYn+Jv32 TUp+5keMKxETkdqZuM4FpWcl4xvi+tpEzog+ASbDSQIrSp8Yzy4njd3AWRg9m+7R eUJ7f+TT+wHClIWBn6YvQH0DmVm1+yJigEts96B2xJ1xaoLJOdTLk9v9A8mfUuJn 0nk6jmWmybrcJ27v42nvQbK+iUa5vT+7Zip8BL9D0kZyVHoMQ9rd279ojI7N85/Y cB/XRB1RZSL3BIWhlMjHpWDB4DeDN2CubO0OVyams/5qlR+BtW6ttlU7AgFR9grh WKCLfzr9bI0CEVYNFBDOsGdKRT25FZ3vYaEqiaPb5Zmu3g3fbziHW9fXvkM+9xkw 7+5YdavO09Tfy8tQPw9z =XK2W -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
