Re: [TLS] HTTPS client-certificate-authentication in browsers

[Martin Rex <[e-mail]>]

Anders Rundgren wrote:
> 
> You have a rather elitist way of discussing things.
> 
> It actually quite hard writing an HTTPS CCA based web app that
> has similar login and session characteristics as one using password
> authentication.

But that is a clear abuse of the TLS client certificate technology
and _not_ supposed to be usable in this fashion.
 

> 
> In your opinion this is an advantage; in my world it represents a
> hurdle for adoption.

If you are _not_ looking for seamless single Sign-On, then
TLS client certs are not the right tool for what you want to
accomplish (square peg, round hole).


> 
> Anyway, banks are investing huge in app-level PKI authentication
> so there is apparently a huge ignorant crow out there.

But if the "frontend" they are using something as security-broken
as a plain web browser, then the technology they would need
is a "frontend signing" browser plugin to produce PKCS#7/CMS signed data
over well-definied application protocol units.


>
> The there are some really interesting differences in path building
> (which of course is NOT specified at all by TLS) that for example
> have forced people importing immediate CAs to PC before being able
> to login using a smart card.

What particular problem are you facing?


The TLS protocol is _very_ clear that a Certificate message must
contain a FULL path, omitting _at_most_ the self-signed certificate
at the end.  There are several TLS implementations out there with
significant brokeness with respect to the Certificate handshke
message (e.g. OpenSSL) which will omit more than just the
self-signed certificate at the end of the certification path,
send certificates out-of-order and even include arbitrary
non-path certificates.  Things that could be trivially checked
and reported as configuration errors on the server side upfront,
instead of dumping garbage on communication peers in clear
violation of the specification.


-Martin