Re: [TLS] TLS browser bugs

[Martin Rex <[e-mail]>]

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