- From: Dave Raggett <dsr@w3.org>
- Date: Thu, 22 Sep 2011 09:44:48 +0100
- 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