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

On 28 Jul 2011, at 08:11, Peter Gutmann wrote:

> Martin Rex <mrex@sap.com> writes:
>> Anders Rundgren wrote:
>>> Lots of banks wants to use CCA for their users.
>> 
>> That is a non sequitur.
>> 
>> Banks (here in Germany) have abandoned tradtional TANs based on the 
>> unconditional presumption that client PCs are infested with malware, and 
>> most banks in Germany are currently replacing indexed TANs (iTAN) presumably 
>> based on the perception that malware on clients (trojans/phishing) has caught 
>> up with iTAN procedure complexity.
>> 
>> At this point, with the presumption that all client PCs are thoroughly 
>> infested with malware, going for a Single Sign-On mechanism would be 
>> completely braindead and irresponsible.
> 
> That was my feeling as well.  Moving from TANs (or plain passwords if you're a 
> US bank) to client certs is at best pointless and at worst a step backwards in 
> security.  Even if you could overcome the monumental usability problems (and 
> there's no evidence that we can do this), you end up with a mechanism that's 
> even less secure than basic TANs because use of a TAN requires human 
> intervention while a MITB (man-in-the-browser) can use your private key to 
> sign whatever they want as often as they want without your knowledge.  Client- 
> side PKI was designed for an attack model invented by cryptographers to 
> justify the use of fun crypto stuff, but it has little (if anything) to do 
> with the threats that we're actually facing today.

Security like knowledge is not absolute. It is a context relative, modal notion. Above you sound very much like the skeptic, who argues that since we don't know we were not captured by some Alpha Centaurians, who took our brain, put it in a vat, and started feeding us perceptions of the way the world is to make it look like  what we see, since we don't know that, we don't and can't know anything. The answer to that is to see that skeptical claims are not transitive on our claims to knowledge. Just as hopeless security scenarios are not a proof that we are not secure. "A gang of thieves could torture me until I reveal the TAN (Transaction authentication number), so TANs are not secure" would be an example of such reasoning.

So I think we should look at where we are now. Currently the biggest security problem is people using passwords for everything, and often using the same password for every site. One time passwords can work for banks but not for most other  applications. Imagine one time passwords for every site you go into. What would happen? You would end up with one massive site controlling the whole internet, because the biggest site with the most content, would be the only one people would bother having passwords for (sound familiar?) And having one site - or just a few of them - provide all the content, is the beginning of  a modern dictatorship, since that site will inevitably be taken over by the most power hungry interests. So I am weary of arguments that proceed from fear, to denying us technology that can help us bypass monopolies of information. There are huge interests at stake to make us believe those types of arguments, and so we should analyse each one very carefully looking for flaws.

Of course the solution to man in the browser scenarios is keys built in hardware that cannot be read by any application, and also notifications or log files for how and when they are used. Furthermore in higher security contexts they can be combined with other authentication techniques, such as TANs.  But as you point out, it is difficult to get those deployed and useable if one does not first start with less secure but easier to deploy solutions: like software based keychains. This is not such a problem anyway. Operating systems are getting more and more secure. Compare the latest windows, with Windows95 when the web started.  So man in the browser is less of a problem for the moment. By the time it is we will have proven the value of these technologies and have methods for placing the keys into hardware, be it on our computer or in our watch speaking to our computer wirelessly.

So client certs can be used with TANs. Would that make client certs for banks useless? Not necessarily. Not if the client cert can be used to connect to other web sites too (as http://webid.info/ allows you to do) - say shopping web sites. You could use your regularly TAN verified certificate to set up payments quickly on shopping sites.  That is the argument that Client certificates are useless is correct only on the assumption that it is used by one web site only: the web site that gave you the certificate. But that need not be the case. The web site that gave you the certificate should be the one you use one time passwords and certificates on, all the others you would use certificates only. Monetary transactions could be initiated using certificates, but should be finalised only with a TAN transaction at your banking web site. (Or your bank could just send you an SMS, when such a transaction occurs to notify you, and give you some time to deny it, though that would require you to create a new certificate. A one click operation ) If you look at it this way, and you use the network, you can see that this can in fact help improve computer security, since viruses can be detected in many more ways.

Similar verification procedures could be set up in social web examples. Your Freedom box would ask you more regularly for one time passwords - though we can assume it has a hardware based private key. You use a certificate to log into other sites. If messages that other sites send you are done via an HTTP POST to your freedom box, then the damage a virus who has stolen your key can do is going to be limited. 

Those are the types of things should can look into, before shouting all too easily about the death of client side certificates.

Henry


> 
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

Social Web Architect
http://bblfish.net/

Received on Thursday, 28 July 2011 08:14:23 UTC