[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography-randombit
Subject:    [cryptography] server-signed client certs (Re: SSL is not
From:       thierry.moreau () connotech ! com (Thierry Moreau)
Date:       2011-09-26 17:05:33
Message-ID: 4E80B0DD.4010604 () connotech ! com
[Download RAW message or body]

ianG wrote:
> On 26/09/11 16:49 PM, Adam Back wrote:
>> What about introducing the concept of server signed client certs.  A 
>> server
>> could recognize its own server key pair signature on the client cert, 
>> even
>> though the server cert is not a proper CA cert.
> 
> Hmmm... interesting idea!
> 

The term I used for this concept is "first party certification".

> Typically, the server application will store the entire cert in its db 
> as account info.  So analysing the signature as own-CA would save that 
> database lookup.  This might make sense if we are relying on say Apache 
> to do all the processing, because it is automatable, and Apache doesn't 
> have much in the way of database processing capabilities.
> 

Apache allows a PHP application to retrieve the whole X.509 certificate 
used by the client. In the proof-of-concept validation I made, I 
extracted the client public RSA modulus and that was (almost) it about 
client authentication (SSL done by the apache module). By "almost", I 
mean the database management workload amounts to the mapping 
RSA_modulus<==>account.

Thus the client need not even a certificate signed by a "own-CA", any 
certificate would do (certificate used only because mainstream SSL does 
not support bare public keys).

To fully appreciate the potential of these ideas require to go back to 
the essential properties of digital signatures, and get rid of PKI trust 
model almost completely.

("Details available on request" ... but no spare time to provide them on 
the foreseeable future.)

> Although typically, I would suggest that Apache should be put in 
> pass-thru mode and let the application do *all* the login processing.  
> By this I mean, analyse the crypto results from the certs, and put it 
> all in the PHP variables.  Never ever drop the connections on its own 
> decisions, in my experience, letting Apache make security decisions like 
> that always results in lousy user performance, which reduces overall 
> security (user does it another way).
> 
> (It's an interesting idea ... )
> 

Yes, but ...

you need to switch clients to using (a more or less degenerate form of) 
client certificates, which historically has failed,

and maybe more subtly, you start giving end-users something for their 
own security which is not branded by the service operator: ultimately it 
is the client private key protection that counts, and once the user 
mental model is well understood, there is no barrier for the client to 
move to another service operator without any loss in security.

Don't get me wrong, I would like to see this usage of client key pairs. 
The above are my understanding of the objections when trying to put 
forward this concept.

>> Then the password request
>> on the client goes to the browser/os key store.  So long as you had CA
>> pinning that would help the phishing situation.
> 
> Yes.
> 
Yes.

>> Of course there is still the UI problem to somehow have the user 
>> detect the
>> difference between the key store password dialog and a fake dialog put 
>> up by
>> a hostile web page.  There are some things that can help like user 
>> cutomized
>> dialogs where the hostile site cant know the customization.
> 
> Right.
> 

Hey, don't forget that the enemy needs the 
encrypted-client-private-key-file. The hostile web page needs a Trojan 
to get it. This raises the bar.

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

> iang
> 
> 
>> Adam
>>
>> On Mon, Sep 26, 2011 at 07:52:20AM +1000, ianG wrote:
>>> On 25/09/11 10:09 AM, James A. Donald wrote:
>>>> On 2011-09-25 4:30 AM, Ben Laurie wrote:
>>>>> I'm just saying I think its hard to detect when a password is being
>>>>> asked for as part of the risk assessment.
>>>>
>>>> http and https do not know there are such things as logons.  Logons 
>>>> need to be built into the protocol, rather than added on top.  Your 
>>>> browser should know you are logged on.
>>>
>>> When using client certs, it works: the browser, the server and https 
>>> do know if you're logged on [0].
>>>
>>> The problem with HTTPS login is that it was sacrificed at the alter 
>>> of some unworkable commercial dream, thus forcing developers to rely 
>>> on passwords.  Any client cert is better than the current best saved 
>>> password situation, because the technical security of a public key 
>>> pair always exceeds a password [1].  But while vendors will slave to 
>>> make saving passwords easier (so as to cope with the explosion of 
>>> sites & contexts) ... they won't work to make client certs better.
>>>
>>> All of this (again) aligns well with key continuity / pinning / and 
>>> various other buzzwords.  But, really, you have to try it. There's no 
>>> point in talking about it.
>>>
>>>
>>>
>>> iang
>>>
>>>
>>> [0]  Where, logged in means, is using an appropriate client cert.  
>>> This involves an amount of code in the application to figure out, but 
>>> it seems about the same amount of code as doing the login the other 
>>> way, via passwords and so forth.  There are some additional 
>>> complications such as new certs, but this is just coding and matching 
>>> on the names.
>>>
>>> [1] this deliberately ignores 1980s advice to remember your password...


[prev in list] [next in list] [prev in thread] [next in thread]