Re: TLS session renegotiation in java

>    - if when renegotiating browsers ask their users for a new certificate
>  (they don't seem to - so this may be a bug in my code , the server, or a
>  bug in the browsers)

None of the above - it's a bug in your expectations.

TLS renegotiation is not strictly tied to renegotiating identity
(certificates), it's tied to the overall process of renegotiating security
parameters. Though this may include identity - and indeed, commonly does
when using something like mod_ssl + vhosts + directory-specific
certificate requests - that is not all that is renegotiated. Further,
there is no requirement for the browser (or any other TLS implementation)
to invalidate the previous identity selection - it's up to the server to
reject it.

Speaking from first-hand experience with Chromium and second-hand with
Firefox, both browsers cache identity selections to minimize the number of
times the user is prompted. From the browser perspective, this is a "good"
and "correct" thing, for a few reasons:

1) There may be multiple TLS handshakes in-flight with the same endpoint.
Prompting the user each time the endpoint sends a CertificateRequest
message may result in many spurious prompts to the user (from 6 to upwards
of 100).
2) As previously mentioned, frequently server implementations may request
"spurious" renegotiations. Spurious in this sense because the list of
acceptable parameters on the server end hasn't changed, but it performs
renegotiation as a way to pass parameters between its internal
implementation (again, mod_ssl comes to mind)

Typically, these caches are not invalidated until a response is received
from the server that is interpreted as if the identity was unacceptable. A
renegotiation message is NOT such a response. Rather, they look for
appropriate handshake errors. In addition to explicit errors, and again
due to various legacy server implementations, the spontaneous disconnect
of the channel is also interpreted as a "certificate unacceptable"
response.

These responses will typically flush the browser-side cache and thus allow
re-selection to happen. Of course, "re-selection" doesn't necessarily mean
"re-prompting", since there may be other sources of certificate selection
beyond direct user interaction (extensions, cached preferences,
administrative policies).

As I've mentioned previously on this list, if you want to implement "Log
Out" functionality, you need to both reject the TLS session cache (as
browsers will attempt TLS session resumption, which implicitly includes
client identity) and reject TLS connections that attempt to use the
"existing" certificate.

Because TLS is a transport protocol, and not really at the application
layer, such "Log Out" is hardly reliable, and as I've mentioned before,
prone to breakage for any number of reasons.

That's why mechanisms such as TLS Origin Bound Certificates (
http://tools.ietf.org/html/draft-balfanz-tls-obc-00 ) instead work to bind
the certificate to the cookie (an application-layer construct), and let
the cookie handle "Log Out".

I should further add that "spontaneous disconnect" only works before the
handshake is completed. If you accept the handshake with the ("old")
identity, but then display an error page and spontaneously disconnect at
the end, that's certainly not going to flush any identity cache.

>    - to see how this can be done in java
>    - to improve html users login experience, so that when they reach a site
>  they don't get asked immediately for a certificate but only once they
>  have been able to look around a bit

If you want this to even remotely work in browsers, you'll want to look at
binding different host names between anonymous and secured access. If a
CertificateRequest message comes in (whether or not the server "requires"
a cert), the browser will prompt. Further, if the user declines to provide
such a cert (thus causing an empty Certificate message to be sent back),
and the server accepts it, the "null" or anonymous identity will be cached
for that server. Meaning future requests will not prompt - it'll
automatically send no certificate.

If you wish to flush that caching, see above, you'll need to flush it as
if the user actually selected an identity.

The use of separate domains is recommended so that you can have one domain
never request for the certificate (the "browse" site), and the other
domain always request & require a certificate (the "login" site).

>    - which browsers support the TLS rengotiation fix

You may be interested in
http://blog.ivanristic.com/Qualys_SSL_Labs-A_Study_of_Really_Breaks_SSL-HITB_Amsterdam_2011.pdf
(particularly, Slide 24). As far as browser support goes, all of your
"major" browser support it. IE just requires the proper security patch to
Windows ( http://support.microsoft.com/kb/977377 )

Received on Monday, 10 October 2011 23:42:03 UTC