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 - 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? 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/ > > >
