RE: Post 1.1 xpath functions

Following is a bit of a rant...

There are a variety of OSS JavaScript implementations of RSA, but they
(and an xpath encryptfunction as well) all suffer from one problem; they
are vulnerable to man-in-the-middle attacks and, unless used in
conjunction with HTTPS, provide the illusion of the security with none
of the guarantees, which in my opinion is worse than useless.

Most customers who ask for the ability to embed crypto into XForms or
JavaScript think they are getting something more secure, when in reality
they aren't.  Unless the client side has its own form and already knows
the public key, the downloaded crypto provides no security against
man-in-the-middle attacks.  Only HTTPS can provide security for the
general case of content loaded from a server, because it provides
end-to-end security over the entire contents, and also has an
independent means for validating the keys.  

Consider this:
1. Alice wants to get Bob to log in using his password.
2. Bob contacts Alice's server via HTTP and gets the login page.
3. Alice's server sends send Bob a web page containing her public key
and a JavaScript program or XForms data model referring to the proposed
encrypt XPath function.
4. Bob posts the encrypted data back to Alice's server.
5. Alice uses her private key to decrypt it.

Unfortunately, it all goes wrong between step 2 and step 3.  Bob has no
way to know he's got Alice's public key.  Milton might have intercepted
the HTTP GET request and fetched Alice's page, substituted a different
key, and be in a position to decrypt the response from Bob, read it, and
re-encrypt it with Alice's key.  (If you want to try this yourself at
home, use EtherApe.  It transparently implements MIM attacks on switched
Ethernets via ARP poisoning for a variety of protocols.)

Furthermore, Bob has no way to know he's even gotten the correct
JavaScript program or XForms model for RSA encryption.
Milton might have completely altered the JavaScript or XPath
expressions, but the browser will still show the same presentation, and
since there's no built-in way for the browser to know about the content
the way that there is for showing HTTP vs HTTPS, Bob is none the wiser.

In fact, Milton might just have removed the whole thing, leaving Bob
with a form that sends everything in the clear and simply has a
presentation containing "<span class='notice'>Protected by RSA
Crypto.</span>".

Bob's only recourse is to visually inspect the XHTML page he's been
given, validate the JavaScript or the XForms and xpath, and then use
some independent means (such as a key server) to validate that the
public key enclosed is indeed Alice's.

Or, Alice could use HTTPS.

Now, if he uses HTTPS, the story changes, and both can know that the
key, and the algorithm or calls, are as Alice wrote them. So if Bob
trusts Alice to do as she says, then all is well, and assuming Alice can
get the data at the end of the HTTPS stream, she'll be able to decrypt
it using her key.  In this case, the second encruption can provide
additional security because Alice and Bob already know it's been
correctly encrypted with her public key and nobody in the middle has
messed with it, so an encrypt function or JavaScript program lets Alice
handle the password in encrypted form and decrypt it later when she
wants the plaintext.

But this functionality must be used to provide additional security on
top of HTTPS; otherwise, it's vulnerable to MIM attack and worse than
useless.

Leigh.

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Peter Nunn
Sent: Wednesday, April 18, 2007 4:08 PM
To: www-forms@w3.org
Subject: Post 1.1 xpath functions

I am working on implementing the functions for MozzIE to make it 1.1 
compliant.  I have already found that there is a proposal for a post 1.1

function called bind() which I have added as an extension function.  
What other post 1.1 functions are on the table?
In particular I am looking at adding an extension function called 
encrypt() that will encrypt an element/attribute using a public key.  I 
have a particular requirement to allow a form to post a fragment back to

a server where the contents (a new password) needs to be encrypted using

the server's public rsa key.
The footprint would be the same as the hmac() function, only the 
algorithm would be some form of encryption algorithm rather than an hmac

and the result would be an encryption of the data.
Has this been discussed at all? If so is there a thread I can see what 
the thoughts were.

regards

Received on Friday, 20 April 2007 18:47:34 UTC