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

On 25 Jul 2011, at 15:38, Anders Rundgren wrote:

> On 2011-07-25 15:05, Henry Story wrote:
> 
>>> If there had been a *single* mainstream service of US origin who used
>>> HTTPS CCA this would be fixed in record time.
>> 
>> What about the army? They are pretty big in the US, representing a huge portion
>> of the budget I believe.
> 
> Yes, but the army has IT-staff that takes care of "issues", consumers
> do not.  The army is also much less fuzzy about inconvenience.

Most of all the army have a huge namespace, so that one certificate can do
a lot of work. This proves that if one can grow the user of a certificate
the benefits will grow too. So the first issue to solve with certs is
to make them useful across the whole internet. That then changes the game.

If you look at what Facebook connect is doing you will see how that works.
And it also proves that the attempt to be completely anonymous is not what
people are looking for.

> 
>>> The tenths of millions of users of "homegrown" PKI authentication schemes
>>> in the EU and Asia apparently don't think HTTPS CCA is particularly useful,
>>> neither do I.  
> 
> 
>> I believe that is only because of the naming problem. Distinguished Names of companies
>> don't scale to the world.
> 
> There are actually several other problems that are much worse.
> On my wife's firefox the bank have deployed two certs and
> both of the show up when she is going to login.  If she
> takes the one marked "non-repudiation" you get a security
> error that only experts understand.

Firefox has the worst UI of all. Banks should set up incentives
for people to move to more secure browsers. They also have enough
money to pay for the changes directly.

The bank should probably have signed those certificates with different
distinguished names, then it could have asked for the right one.

Does the bank also really have to throw such an ugly exception? Could it
not be more intelligent in the web server on how that is processed?
> 
> 
>>> TLS' session context is incompatible with web sessions.
> 
>> Why?  A TLS Session can work very well with web sessions. You can 
>> just make your TLS session be a web session.
> 
> AFAIK HttpSession.invalidate in Tomcat/JBoss has no effect whatsoever
> on a TLS session.

They are two different things. I think you  cannot logout the client from
the server, though recently you pointed to some javascript that could allow that.

This may be something the server vendors need to work on. The question first has
to be asked: is this a necessary limitation, or is it just not implemented well?

> 
> 
>>> For our mutual interest, PKI for consumers, it doesn't really matter what
>>> the end-solution will be, but an educated guess is that will not build
>>> on HTTPS CCA, but on HTTPS with + an application.  This is BTW pretty
>>> much what has happened with HTTP auth versus form-based auth.
>> 
>> yes, but there is no argument for why this is the case. And you don't 
>> even consider http://webid.info/
> 
> WebID isn't diminished by this.  It just gets better :-)

Well WebID type auth can be used in BrowserId, as I explained in detail 
http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid/5424#5424

But TLS client certs have a very nice advantage is that they are very efficient, and work in many
other areas too, especially server to server. So other means are good, but don't give up TLS -
well improve it.

> 
> 
>>> Fortunately this can be introduced without redeploying PKI so it is a
>>> true "migration solution".
> 
>> IT's odd that people want to move away from something that is close to working.
>> I wonder why... What is the agenda?
> 
> They have given up on this.
> "Close to working" isn't good enough.

I agree. They need to finish the job. But they won't do it unless it is shown why it is useful.
And there it just needs a few companies to make a good demo.

Henry

> 
> Anders
> 
>> 
>> 
>>    Henry
>>> 
>>> Anders
>>> 
>>>> 
>>>> Henry
>>>> 
>>>> On 25 Jul 2011, at 14:06, Anders Rundgren wrote:
>>>> 
>>>>> Hi Guys,
>>>>> I don't really know who "owns" this question but presumably you do...
>>>>> 
>>>>> HTTPS client-certificate-authentication in browsers
>>>>> ===================================================
>>>>> 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.
>>>>> 
>>>>> 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).
>>>>> 
>>>>> That the TLS CCA protocol doesn't even support "Logout" haven't made
>>>>> it a logical choice for web developers either.  Well, there are some
>>>>> workarounds but they are by no means straightforward, supported
>>>>> out-of-the-box by server authentication schemes, and are (of course)
>>>>> entirely undocumented.
>>>>> 
>>>>> The button "Clear SSL state" in MSIE is an indication how horribly bad it
>>>>> can go when security experts design systems for "people".
>>>>> 
>>>>> There's no way you can hide the fact that TLS CCA is only truly useful
>>>>> securing tunnels between "boxes".
>>>>> 
>>>>> Anders
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> TLS@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
> 

Social Web Architect
http://bblfish.net/