Re: [TLS] Comments on TLS identity protection

home_pw@msn.com wrote:
> 
> > When the server-requested renegotiation is application triggered,
> > as in the Microsoft IIS case, then the server better caches the
> > result along with the SSL session.
> >
> > Microsoft IIS has a silly (performance-wasting) bug, where a client that
> > does either not have a client cert or does not show one (and requiring
> > the application to perform application level client authentication)
> > is continously forced through the renegotiation when the client
> > tries to resume the session from the session cache on a new connection.
> 
> This is not a bug. It is an explicitly permitted state within the SSL v3 
> conformance/state. Upon request, a client MAY send a client cert. What 
> happens if it doesn't, is server policy.

In my terminology it is a design flaw of Microsoft's IIS, and one
that can hardly be overlooked if the functionality is tested at
least once before shipping.

It might be the result of two things:

(a) IIS being stateless for independent connections

(b) the underlying SSL/TLS engine lacking to memorize/cache the
    answer on a (previous) client certificate and making this
    attribute available/visible for the application.

I don't know if any of the existing SSL/TLS stacks memorizes/caches
this meta-information along with the SSL session and make it available
to (stateless) applications, so that they do not bother clients over
and over with pointless renegotiations.

MSIE caches the answer on the client certificate request at the
application level on the client side and automatically applies
it without asking the user.  Netscape/Mozilla/Opera don't do
that and show popups for parallel/new connections (or even
every embedded object if no persistent connections are used).

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls