I think a getSession:SSLSerrsion method could be added to a WRHAPI request. A bit problematic seems the invalidation of the certificate, the user should be able to log back in again with the same certificate, but denying the certificate only one might be a usable workaround.
cheers, reto On Tue, Sep 7, 2010 at 12:40 PM, Henry Story <[email protected]> wrote: > > On 7 Sep 2010, at 09:51, Reto Bachmann-Gmuer wrote: > >> Hi Henry >> >> Thanks for this detailed overview! >> >> A couple of remarks: >> - Similar logout problem also occur with http-basic auth, if you get a >> browser login dialog (which happens e.g. when the first action >> requiring permissions is a post-request) you won't be able to log out > > that is bad. Amazing how little attention the browser vendors put in this. > >> - as the clerezza jax-rs implementation (triaxrs) bases on WRHAPI and >> not (or only indirectly) on servlets support for something like >> javax.servlet.request.ssl_session_id has to be added in WRHAPI first, >> could you describe how the client server interaction work to force >> logout given the ssl session id? > > The code for a server showing how it works is here: > http://github.com/bblfish/TLS_test/blob/master/src/main/java/net/bblfish/test/SSLTestServer.java > > In short the logout button component when pressed would do the following > > 1. register an exception to be thrown for the given WebID with the > TrustManager. > When the trust manager receives a connection request with a certificate > with the given > WebID, it will throw the CertificateException subclass instance. > > These exceptions are designed to allow servers to reject invalid > certificates. > Of course browsers should not remove such certificates from the browser > because a server claims them to be invalid. > > 2. get the ssl_session for the current connection and invalidate it. This > will force the browser to send a certificate to re-establish a session > > String sslsessStr = (String) > request.getAttribute("javax.servlet.request.ssl_session_id"); > SSLSession s = cntxt.getSession(new BigInteger(sslsessStr, > 16).toByteArray()); > if (null == s) { > System.out.println("could not find session " + sslsession); > } else { > s.invalidate(); > } > > >> >> Cheers, >> reto >> >> >> On Mon, Sep 6, 2010 at 9:41 PM, Henry Story <[email protected]> wrote: >>> I have been investigating issues with browser side SSL logout last week. >>> The issue is a lot more visible with the way we have set up Clerezza at >>> present with foaf+ssl (the WebID protocol), as we have put the whole site >>> behind HTTPS. >>> >>> The issues are essentially browser bugs and UI problems that need to be >>> fixed. So if people here can help vote on the issues, or if they know ways >>> of creating a coalition of people who can help us move the browser vendors >>> in the right direction please let me know. >>> >>> 1. Identity in the browser >>> -------------------------- >>> >>> The main User Interface issue I summarised in the Google Chrome bug 29784 >>> [0], would be fixed >>> by making the client certificate visible and selectable as shown in this >>> initial prototype fix >>> >>> >>> >>> >>> (keep the above picture in mind when reading the following) >>> >>> [[ >>> Let us imagine a future secure web where everything is behind https. (Why >>> not? it's cheap now!) So some friend sends you an https link to content on >>> some site. You arrive at the site and the server is set up for optional >>> client certificate usage. Bang! Up pops your browser asking you to select a >>> certificate. >>> >>> Problem: you don't yet know which site you have arrived on! And it is >>> asking you for a certificate. So really what you want to do is click >>> "Cancel" to first check out the site. But then without this patch that >>> @snej is working on, you won't be able to login to the site later to see >>> the classified content - well not without restarting your browser! >>> >>> So one could even go one step further and allow you, the browser user, to >>> select an option that would let the browser automatically login without >>> certificate on sites that ask for certificates optionally. The location bar >>> would then show a logo for the anonymous user - An icon of a guy with >>> sunglasses perhaps, with anonymous written next to it - that would be a >>> hint to you that you can log in whenever you wants to by selecting the >>> button. >>> >>> If done correctly the certificate selection box, could be designed so that >>> the user understands after that box appearing a few times too often, how he >>> can set this behaviour to be automatically so. >>> >>> This would essentially then have fully integrated identity into the browser >>> at very little cost. >>> ]] >>> >>> 2. Server side logout >>> --------------------- >>> >>> While waiting for the above fix to be fully implemented (hopefully one >>> browser vendor will be up to the task) I have been investigation how one >>> could get server side logout to work. Following Reto's trick of placing the >>> foaf+ssl logic inside the SSL TrustManager, it turns out that one can in >>> fact use some TLS tricks. I put the code to test this here >>> http://github.com/bblfish/TLS_test/blob/master/src/main/java/net/bblfish/test/SSLTestServer.java >>> >>> The good news is that this works very nicely for Safari - which is really >>> important because once one chooses a certificate for safari there is no UI >>> way for the user to change it. As a result Safari becomes useable again for >>> foaf+ssl. The bad news is that there are issues with Chromium (but they are >>> quick to fix things) [1] and Firefox 593066 [2] (but they don't seem to >>> care). Opera also has an issue here. I have not yet tested these browsers >>> on other OSes, or IExplorer. >>> >>> I have sent an e-mail to the TLS list to see if there is extra feedback or >>> ideas to be had from that part of the world >>> http://www.ietf.org/mail-archive/web/tls/current/msg06963.html >>> >>> If anyone could try it out on other browsers on other OSes that would be >>> great. Does this work with IE? >>> >>> 3. Issues with Clerezza >>> ----------------------- >>> >>> 3.1 Server side logout >>> ---------------------- >>> >>> Though this only works with Safari on the browsers I have tested, this is >>> already very good news. >>> >>> To get the server side logout patch to work with Clerezza - at least on the >>> browsers that support it - we need to be able to get the SSL Session id as >>> shown in the java code linked to above, with the following line: >>> >>> sslsession = (String) >>> request.getAttribute("javax.servlet.request.ssl_session_id"); >>> >>> But the jax-rs library Clerezza is using does not allow one to get hold of >>> the HTTPServletRequest to get hold of the Servlet 3.0 spec standard >>> attribute >>> javax.servlet.request.ssl_session_id >>> >>> The other thing needed would be to register the logout component with the >>> TrustManager, so as to put the certificate on a list to be refused access >>> on the next session request by the browser. >>> >>> 3.2 Initial Login Problem >>> ------------------------- >>> >>> So the other issue is the initial login problem. Because currently the way >>> we have set up WebID all pages are served up using SSL - and in a safe >>> world, this should be the default I believe we can see this with Clerezza >>> very clearly. A user will be asked for his certificate on arriving on the >>> Clerezza home page. >>> On OSX: >>> - With Firefox if he does not choose the certificate, he cannot log in >>> (without restarting his browser) >>> - With Safari if he chooses a certificate he will never be able to not >>> give a certificate. >>> Though we can get him to use a different one! >>> - With Opera he can cancel, and we can later ask him for a cert. Cool! >>> (But if he chooses one, he can no longer log out) >>> >>> But the main problem is that the user is asked for his certificate by >>> default - if he has a certificate at all of course. >>> >>> The good thing is that we can make the problem very visible with Clerezza, >>> and perhaps this will lead to fixed being found faster. But we probably >>> also need to think of some pragmatic solutions, such as perhaps splitting >>> the site into https and non-https pieces more clearly. >>> >>> Sadly the browser vendors seem to be forcing the world to live insecurely! >>> >>> Henry >>> >>> >>> >>> [0] Google Chrome UI issue, where they are working on the beginning of a fix >>> http://code.google.com/p/chromium/issues/detail?id=29784 >>> [1] Google Chrome http://code.google.com/p/chromium/issues/detail?id=54405 >>> [2] Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=593066 >>> >>> Social Web Architect >>> http://bblfish.net/ >>> >>> >>> > > Social Web Architect > http://bblfish.net/ > >
