Hi Chris, 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].
Regarding 1 - I also found it odd but I guess that’s not mandated by the standard so they have to return something. It is better to return abstraction than concrete JSSE object in case the underlying implementation changes. BTW why is this not working with OpenSSL/native? Is there a technical reason or just not implemented? George [1] https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html [2] https://bz.apache.org/bugzilla/show_bug.cgi?id=22679 -----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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVjXhSAAoJEBzwKT+lPKRYBMYP/is27kGjYPqNxO8krxNxf9iO 0Y2BG9Qw/TJT0UKrT3jiBGo05UCJZ7stnvgybc0ZO3ImDigzOfW86c93lG6AjvXM 9XpwM/zAUvt5wHlftX/71eguhE1pqKLxFxLHcDBovmRV1rPVo2fn5+t9+rFpgX12 SIMCmZp8m9pjLYutryiWTjIwi96QduYAb/wKDFxhJGF/pibLFwUH9YxqUbScWJwe FbhKjEC8RsfMgh3/UCEJDuRdPGjQlF/o5SInR7NNc92msYMEu2ruftKjG69BPxL4 +57hauBz1qfDtFjAAkb3oPtWrg/oLgqvCxiHifiWxmbp15q2kKWzTkZ5f8WegurB xa1tJVWVKsosaWvTeRFJwDE2nMco1WYHXcm7kzhXbLvhjv7ElIDdinK8yWeAedL0 2nYQ6dzl41r/xRoPsaHkloxQMzzWSI8sCmETxEpa9GgzIdl+NPiflKA4chVWbJFe YXOTbSCOS7WJ4JlE2l/tqeV6vzTshgb+z6eQWWKddKdu/pt4T+UuZt7NJMluV5/2 W05fWdIiZ4k3rDk4p+T7xbgGPv1sTwPWGtgNZt2CNq6vBhtwlHjNNQ/Faa56Cque jomH8gkjjQg7eQ1W0f70aUaykVHkTK57oqjEFKn7o5xc4c3mN0oHmyyMlt23wq8g mNoKnBMa0Zw9nNTvykcz =0xVF -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
