incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Story <henry.st...@bblfish.net>
Subject Re: SSL browser issues
Date Tue, 07 Sep 2010 14:31:24 GMT

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 <henry.story@bblfish.net> 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 <henry.story@bblfish.net> 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/


Mime
View raw message