Re: [TLS] Asking the browser for a different certificate

[Martin Rex <[e-mail]>]

Story Henry wrote:
> 
> > IMHO there are a number of defects in the TLS protocol related
> > to client certificate authentication, and some of them should probably
> > be fixed at the TLS protocol level.  But fixes at the TLS protocol
> > level may take a huge amount of time before they become a useful
> > feature in the installed base...
> > 
> >  - the TLS client can not indicate that it posseses a client cert
> >    (so a server has to probe--and by probing create a
> >     bad user experience for users without client cert)
> >    TLS renegotiation has been abused in the past to reduce the
> >    bad user experience side of the problem.
> > 
> >  - the TLS client can not indicate that it does _not_ posess or
> >    is firmly determined to not send a client cert
> > 
> >  - the TLS server can not recommend to the TLS client that the client
> >    should offer a user a possibility to change his selection of
> >    client certificate for the current handshake.
> 
> Yes. I am now looking for hacks to help people with defective browsers 
> participate in a world of secure client certificates. The only one up 
> till now I found was to have multiple server ports open each with a 
> different server key. 

You mean a server listening on multiple TCP ports for HTTP-over-TLS
incoming requests, with different TLS server certificates for each
of these TCP ports and different requirement levels for client certificate?

The purpose of "different server certs for each TCP port" is not clear
to me.  rfc-2818 server endpoint identification does not distinguish
ports.

Depending on how much cross-referencing there is from the content
on those different ports, and how much parallel access there is
from a single user to contents on seperate ports, you may run into
a TLS session caching issue with some browsers.  Some Web Browsers
do not distinguish TCP server ports (present in the URL)
in their client side TLS session caching.  Some blindly assume
that servers on the same host share their TLS session cache
and therefore exhibit frequent full TLS handshakes when
multiple distinct servers on the same host are concurrently
accessed (and probably flushing each TLS session where TLS session
resume fails).


-Martin