# SSL Session-ID killen



## hoinz_p (19. Februar 2008)

Hallo, Kollegen,

ich habe erneut ein Problem mit Sessions. 

Gegeben ist eine Client - Server - Beziehung (Servlet/Tomcat - Server) mit Verwendung von SSL.

Nun möchte ich per "Logout" - Button die aktuelle SSL -Session - ID löschen, um den User später zur erneuten Eingabe seiner Benutzer - Daten aufzufordern.

Problem: Ich komme zwar an die SSL - Session-ID per 

_request.getAttribute("javax.servlet.request.ssl_session")_

heran, aber _"invalidate()"_ funktioniert so leider nicht. 

Es ist zum Haare ausraufen... Solange ich Sessions selbst erstelle, kann ich sie löschen wie ich will; *aber da ich diese SSL - Session ja nicht explizit erstelle, komme ich irgendwie nicht an sie heran!*

Ich habe schon überlegt, eigene Sessions anzulegen und alles weitere über sie zu realisieren; aber solange diese SSL - Session noch existiert, kann ich den User nicht wirklich ausloggen

Hat jemand eine Idee für mich?

Vielen Dank,

H. Plett


----------



## hoinz_p (21. Februar 2008)

*Hilfe ... SSL Session-ID killen*

Könnte jemand Feed - Back geben, ob mein o. g. Anliegen machbar ist?

Gruß,

Hoinz


----------



## Thomas Darimont (21. Februar 2008)

Hallo,

woher weist du denn das die SSL Session noch aktiv ist? Weiterhin hast du schon probiert den user nach dem Logout mal auf eine http URL umzuleiten? Bleibt dabei die SSL Session erhalten?

Ansonsten:
        how to access ssl session ID out of tomcat to prevent session hijacking and allow for phishing protection:
http://issues.apache.org/bugzilla/show_bug.cgi?id=22679

document how to use certificate-based "clientAuth" on a per user or per session basis also with self-signed/expired client certs           
http://issues.apache.org/bugzilla/show_bug.cgi?id=34643

Gruß Tom


----------



## hoinz_p (21. Februar 2008)

Danke für den "response".

Ja, die SSL - Session existiert definitiv noch weiter. So bin ich vorgegangen:

//SSL - ID anzeigen:

_System.out.println("Nach Login lautet die Session: " + request.getAttribute("javax.servlet.request.ssl_session"));_

//Session instantiieren
//Hier dürfte wohl auch die SSL - ID mit abgefragt werden, oder?

_HttpSession session=request.getSession();_

//Session - Ids löschen:

_try{
//Aktuelle Session löschen
*session.invalidate()*;
catch_ ... usw.

//Und jetzt kommts:

_System.out.println("Nach Logout lautet die Session: " + request.getAttribute("javax.servlet.request.ssl_session"));_

In der Konsole sehe ich die gleiche ID, die auch vor dem Login angezeigt wurde.

Was die Links angeht: Es ist "nah dran", aber mir fehlt ein Statement wie _"SSLSession,invalidate()"_ Dazu habe ich nichts gefunden.

Hast Du noch eine Idee?

Gruß,

Hoinz_p


----------



## Thomas Darimont (21. Februar 2008)

Hallo,

bist du sicher das du wirklich die selbe SSL Session bekommst? Vielleicht bekommt der user automatisch eine neue SSL Session mit der alten Session Id... was sagt denn System.identityHashCode(ssslSession)? Ist das jedesmal die selbe Session Instanz oder eine andere (wobei eigentlich Käse, wenn die Session im Cluster Repliziert oder Persistiert wird ists ja auch ne neue... also wirds wohl wirklich an der ID hängen... na ja wär'n Versuch wert)

Ansonsten:
http://osdir.com/ml/encryption.bouncy-castle.devel/2006-11/msg00173.html

Gruß Tom


----------



## hoinz_p (21. Februar 2008)

Hallo, Tom,

Über Deine Links habe ich jemand gefunden, der mir aus der Seele spricht ... der Eintrag ist vom 28.03.07:

The forum exactly illustrates the point I am trying to make. The existing
SSL-session will let the user (or worse, some other user) back in to the
application without really loging in. The only way to prevent this is by closing
all browser windows which will clear the SSL cache on the client side. *But of
course we can't expect our users to close all browser windows every time they
log off.*

A possible solution is to invalidate the SSL-session on the server side. The
SSL-stack provides methods to find a particular SSL-session and invalidate it.
The problem is that you can't find the right SSLContext from a web application.
I agree that there is no Servlet Specification that specifies this but it would
be nice if Tomcat could solve this problem. *The best way to do this would be
invalidating the SSL-session when the HTTP-session is invalidated.* That would
make it transparent to the application developer and does not require a
proprietary extension on the Servlet API.

Ob die comitter zwischenzeitlich etwas unternommen haben? ...

Gruß,

Hoinz_p


----------

