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

[Anders Rundgren <[e-mail]>]

On 2011-07-26 01:51, Martin Rex wrote:
> Anders Rundgren wrote:
>>
>> I don't believe that TLS CCA (Client Certificate Authentication) in the
>> form of HTTPS as implemented in current browsers has much of a future.
> 
> It works perfectly fine and we've been using it >10 years for
> all of our intranet (50.000 employees these days) web servers
> accessed via HTTPS, using TLS client certs for Single Sign-On.
> (similar to how Kerberos is used by others).

I'm sure about that.  My perspective are consumers.


>> In fact, quite a bunch of the entities in the EU working with consumer PKI
>> have replaced HTTPS CCA with an application level scheme which wasn't such
>> a big deal since they anyway were forced writing a browser PKI client more
>> or less from scratch since the ones shipped with browsers doesn't support
>> PKI as defined by banks and government (like mandatory PIN codes also
>> for on-line enrolled keys).
> 
> I think you're confusing things.
> 
> What you're looking at here is scenarios for individually authenticated
> transactions.  That is an entirely different problem domain and not
> addressed by TLS at all.  You would have to address that with
> a browser plugin that accesses a completely different PKI credential
> that has signature qualities, with a clearly defined protocol that
> describes what data gets signed, and which requires seperate per-transaction
> authorization for every signature operation.

There was even a Danish e-government standard for PKI authentication
that rides on top of server-auth-only HTTPS.  They also have a
companion scheme doing web signatures which indeed uses another
key.  There are lots of similar systems out there.

Are all these guys morons?  I believe they are rather dissatisfied
with how HTTPS CCA works.  So am I.


>> That the TLS CCA protocol doesn't even support "Logout" haven't made
>> it a logical choice for web developers either.
> 
> Huh?  I have no clue what you're talking about.
> 
> If the server wants to perform a logout operation,
> it can delete the TLS session cache entry on the server.
> 
> But the Single Sign-On capability of the TLS client cert means
> that as long as the client credential is still available to the
> TLS client, the client will perform "transparent" reauthentication.

Doesn't this actually lead to what I'm saying from a practical
point of view?  What you can do at the TLS layer is BTW very little
at least if you are using Servlets.  For other authentication
methods logout (HttpSession.invalidate) works as expected.

There is nothing authoritative to read either on this subject
that works for all browsers and servers.  Unless you are a
MOD-SSL hacker you probably get nowhere.


>> The button "Clear SSL state" in MSIE is an indication how horribly bad it
>> can go when security experts design systems for "people".
> 
> Is your intention to get prompted again?
>>From a usability standpoint, we prefer the "select automatically"
> setting and spare our users the client certificate selection popup.

I don't really want to know what it does actually.  The mere existence
of such a button signals that something is terribly wrong :-)


>> There's no way you can hide the fact that TLS CCA is only truly useful
>> securing tunnels between "boxes".
> 
> The purpose of the TLS CCA is the same as the purpose of Kerberos,
> to provide a non-disclosing Single Sign-On convenience.

But Kerberos is built on using a ticket after primary auth and
that's exactly what most "Web Programmers" would like to do
because then you just have to invalidate the ticket to force
reauth.  Services should time-out but most HTTPS CCA-
based services do not.  I noted this first when logging in to
the Swedish Tax authority.  They are all morons?  Maybe.
But the TLS WG has nothing to offer AFAICT.

Anders
"Web Programmer" and some more...