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
Re: Forcing SSL Renotiation
-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
RE: Forcing SSL Renotiation
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
RE: Forcing SSL Renotiation
Hi Steffen
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.
George
[1]
// 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
