Subject: [TLS] TLS browser bugs

From: Henry Story <[email-masked]>
Date: Mon, 6 Sep 2010 15:48:36 +0100

I have been investigating issues with browser side SSL logout, which become clearly evident when one tries to put whole web sites behind HTTPS.  Here is a summary of my investigations. Perhaps people here will know to point others to these issues, and also guide me to other solutions if there are any.

The issues are essentially browser bugs and UI problems that are easily 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. There is just so much that can be done here if these issues are fixed!

1. Identity in the Browser
==========================

The main User Interface issue I summarised in the Google Chrome bug 29784 [0]. 

Read the following with the following picture in mind

   http://bit.ly/aXDqUs  

[[
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 to 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.
]]

You can see on the bug 29784 [0] the fix they are working on. But their work seems to have stalled for the past few months. The same issue was reported to Firefox [0.5]. All browsers have this bugs, but not all have open bug tracking systems....

2. Logout on the Server
=======================

While waiting for the above fix to be implemented correctly, I have been investigation how one could get server side logout to work. Using the return codes described in section 7.2 of the TLS spec I put together the following test server:
http://github.com/bblfish/TLS_test/blob/master/src/main/java/net/bblfish/test/SSLTestServer.java

This makes it easy to see which browsers implement paragraph 7.2 of the TLS spec.

The good news is that this works nicely for Safari (well except that it does not allow one to login anonymously - ie: one always needs to send a certificate) - which is really important because once one chooses a certificate for safari there is no UI way for the user to change it.  (ie, Safari really needs the Identity in the Browser fix!) As a result Safari becomes useable again for client side certs, allowing one to change identity, or just to rectify an error in case one has sent a bad certificate. 

The bad news is that there are issues with Chromium (but they are quite quick to fix things) [1] and Firefox 593066 [2]. Opera also has an issue here. I have not yet tested these browsers on other OSes, or IExplorer.

Are there any other tricks I could use for server side logout, people here would know about?

Is there anything we can do as a community to get this up on the browser vendors priority list?

Thanks in advance,

	Henry Story
	http://bblfish.net/

[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
[0.5] List of UI issues with Firefox 
  https://bugzilla.mozilla.org/show_bug.cgi?id=396441
[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/

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Sep 2010 20:58:59 +0200 (MEST)

Henry Story wrote:
> 
> 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!

That looks like a normal bug in the browser.  Restarting the
browser should never be necessary, just open a new network
connection and perform a new TLS handshake without proposing
session resumption.

Many years ago, MSIE would always try to access https:// resources
without sending a client cert on initial connect, and only when
the server terminated the handshake with a fatal error, MSIE
would repeat the SSL handshake, Prompt the User interactively
when receiving a CertificateRequest handshake message and close
the network communication channel while prompting the user
and then re-connect and perform the full handshake with the
memorized users decision whether and which client cert to
send to the server.  The problem with the old MSIE behaviour
was, that a server that allowed anonymous plus client-cert
access and sent a CertificateRequest in the initial handhshake
would never result in a ClientCert selection popup.

The old MSIE behaviour with the bug of not offering client-cert
selection for servers that allowed no-cert acces might have been
the reason why Microsoft started implementing the
"request client certificate through renegotiation" approach.

> 
> 2. Logout on the Server
> =======================
> 
> While waiting for the above fix to be implemented correctly,
> I have been investigation how one could get server side logout
> to work.

I don't know what this is supposed to mean.  To delete/destroy
application-level backend state, you would need application
level functionality.

There is not necessarily a link between a cached TLS session
and backend session state.  Potentially, there could be
a backend reverse proxy in between that terminates and
reencrypts the application data, in which case the application
state may be completely detached from the TLS session state.

For servers, where the backend-state is tied to the TLS session,
purging the TLS session from the server side TLS session cache
should do (most of) the trick.  Terminating active network
connections that are currently using a resumed copy of the TLS session
will usually continue to exist.

-Martin