On 7 Sep 2010, at 14:48, Reto Bachmann-Gmuer wrote: > 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.
Current browsers that understand the TLS exceptions seem to - correctly - not make the certificate unavailable. So the user can log in with the same cert again. But I have only tested some of the browsers. If people could test the other browsers that would be great. Henry > > 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/ >> >> Social Web Architect http://bblfish.net/
