W3C home > Mailing lists > Public > public-identity@w3.org > September 2011

Re: Javascript Cryptography Considered Harmful

From: Dave Raggett <dsr@w3.org>
Date: Thu, 22 Sep 2011 09:44:48 +0100
Message-ID: <4E7AF580.90309@w3.org>
To: John Kemp <john@jkemp.net>
CC: David Dahl <ddahl@mozilla.com>, Henry Story <henry.story@bblfish.net>, public-identity@w3.org
On 22/09/11 03:33, John Kemp wrote:
> I think the gist of the Matasano blog post (this is my interpretation anyway) is that you can given them (Javascript developers) these things and it doesn't solve the essential problem of trust between client and server. In other words, it is still possible for an MITM to make the client believe it is interacting with a trustworthy entity, in which case, the encryption part itself is very much less useful. Or, at least, it is no more useful than SSL/TLS.

Establishing trust with an online entity is hard without an out of band 
means to support it, e.g. your bank handing you a brochure with the URL 
to enter when setting up an online account. Establishing that you are 
connecting to the same website as the one that you set up an account 
with, would be a step forward. MITM can be frustrated if the browser 
checks that the public key for the site is the same as on previous 
occasions. This doesn't require DOMCrypt.

Of course, you could still be socially engineered into clicking on a 
link in an email and being taken to a spoofed site, and it is relatively 
easy for such a site to get a certificate to ensure the browser displays 
the padlock icon, and appear to be a trustworthy entity. However, the 
origin displayed would be different from the one you may or may not 
remember. Users may be falsely assured if they see the familiar favicon 
next to the origin. Disclosing critical personal information via web 
pages therefore remains a risk.

Nonetheless, providing web page scripts with access to fast high-level 
cryptographic functions would have many uses.

  Dave Raggett<dsr@w3.org>  http://www.w3.org/People/Raggett
Received on Thursday, 22 September 2011 08:45:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:47 UTC