[cryptography] server-signed client certs (Re: SSL is not "broken by design")

Adam Back adam at cypherspace.org
Mon Sep 26 02:49:46 EDT 2011


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.  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.

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.

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...
>_______________________________________________
>cryptography mailing list
>cryptography at randombit.net
>http://lists.randombit.net/mailman/listinfo/cryptography



More information about the cryptography mailing list