[WEB SECURITY] Ajax and secure web communications

Wed May 18 18:17:59 EDT 2005

Lyal,

Thank you, earnestly, for your feedback. By "client-side 
authentication", I was referring to the authentication of entities 
on the client side of the equation. Specifically, this is assuring 
the identity of either the client machine or the end user. The 
former can be accomplished using TLS client-side certificates, 
which is effective if not user friendly, but TLS, by design, offers 
no solution to the latter (although there are some interesting 
proposals on this subject under discussion at IETF TLS Working 
Group).

As for your other points, I have tried to clarify my argument in a 
follow-up blog post at:

http://thrashor.blogspot.com/2005/05/more-on-ajax-and-secure-
web.html

But here is the text for convenience:

It has been brought to my attention that I need to clarify my 
earlier post on the potential of Ajax for secure web communications.

The main point that I want to get across is that embedding 
cryptographic services in the Ajax engine layer of an Ajax modeled 
web application may be an outstanding approach for some 
applications. And that this is a true statement even though every 
web browser has perfectly good cryptographic capabilities built in 
already - namely SSL/TLS (I'll just say TLS from here on).

First, let's understand what TLS is for. TLS offers essentially 
three cryptographic services:

    * Message confidentiality - only the intended recipient can see 
plaintext;
    * Message integrity - the message arrives intact and cannot be 
modified without detection; and
    * End-point verification - users can be certain that they are 
communicating with the intended server and, if client-side 
certificates are used, the client machine is also verified.

This is great. In fact, it is spectacular. TLS is the most commonly 
used cryptographic protocol on the web and has no known serious 
deficiencies, and it is all most web applications need. However, 
what if your web application needs other cryptographic services 
beyond those provided by TLS such as the following?

    * Nonrepudiation,
    * Secure timestamping,
    * User authentication, and
    * Digital signatures.

And these are just a few possibilities. What if your web 
application needs, as was the case with hushmail, to interoperate 
with a cryptographic technology other than TLS such as 
openpgp/gnupg?

My argument is that the "Ajax engine" layer of the Ajax model is a 
promising place to embed cryptographic services in web applications 
when something other than TLS is needed.

Imagine, as an illustrative example, that you had a web site for 
providing legal advice. On this system, all legal advice has to be 
digitally signed by the originating lawyer in order to ensure the 
integrity of the advice, and all advise must be encrypted so that 
only the intended recipient, and not even the system administrator, 
can read it. There are at least two cryptographic functions needed 
here, neither of which can be fulfilled by TLS in this context:

    * Signing/verifying signatures, and
    * Encryption/decryption.

<diagram>
Legal advice scenario 1: Crypto services on the server side

As the architect of this application, you have two choices. First, 
the standard solution would be to deploy all cryptographic 
functions on the server side then use TLS to secure all 
communications with browsers. Second, you could deploy the crypto 
on the browser side of the equation. These two scenarios have very 
different risk profiles and there may be reasons to choose one over 
the other. Since the plain text of the legal advice is produced on 
the server side in the first scenario, there is a risk of 
disclosure at the server. Whereas that risk is transferred to the 
browser side of the equation in the second scenario.

<diagram>
Legal advice scenario 2: Crypto services in the Ajax engine

Now this brings me to the crux of my argument. If the risk profile 
of the second scenario is acceptable, Ajax is an ideal web 
application architecture. All communications between server and 
browser could be in XML format, and signed and encrypted XML in the 
case of legal advice. Crypto services would reside in the Ajax 
engine layer, and asynchronous communications could be used to 
provide an outstanding user experience through prefetching of 
required cryptographic keys and assorted user interface goodness. 
As I have said before, when it comes to security technology, 
diversity is good.

-CHT

Chris Hammond-Thrasher  MLIS, CISSP
http://thrashor.blogspot.com/

On Tue, 17 May 2005 17:00:20 -0700 Lyal Collins 
<lyal.collins at key2it.com.au> wrote:
>I'm not sure of you definition of "client-side authentication", 
>but there
>are at least 2 situations
>A. Verifying the user is someone permitted to access some service 
>or content
>B. the remote client verifying the server is the expected one.
>
>PKI and SSL/TLS might be useful for low security uses in case B, 
>since that
>is all browsers do today.  Since the user is abstracted from Ajax 
>layer
>certs, client side certs in the Ajax engine does, at best, tell 
>the server
>this is the same client that connected recently, provided the 
>client-side
>cert hasn't changed somehow.  Until clients that are trusted, 
>locked down
>and 'only functionality permitted by the manufacturer' come along, 
>that is -
>just like the old bank ATM and POS devices.
>
>In the case A situation, anything that is based upon password 
>authentication
>or eventually biometrics will work fine, which includes PKI, 
>Kerberos,
>Radius etc in the near term (PKI is just a password verifying 
>tool, albeit
>remote verification of password and local trust of the cert used, 
>which is
>not the same as trusting the user).  SSL may still play a role of 
>minimal
>confidentiality, but not user authentication.
>
>In short, Ajax allows passwords and existing application trust 
>processes to
>remain valid, regardless of the extra technology wrapped around 
>passwords,
>such as high cost PKI and at a less costly level, Kerberos, radius 
>etc, or
>simply use the same password rust processes that backend systems 
>have done
>for the past 30 years.
>
>
>If you are looking for better mechanisms than SSL/TLS, then the 2-
>party
>trust model works much better and lest costly that the multi-party 
>PKI model
>(federated identity is simply a sub-component of 2-party trust - 
>relying
>parties have always been able to use added trust indicators in 
>addition to
>password + ID).
>However, the 2party trust model is more reliable, security wise, 
>than
>distributed multi-party models, and far easier to implement
>cryptographically.  
>
>If you are seeking innovative ideas on the latter, then we need a 
>new
>industry approach to look at existing models and solutions.
>
>Lyal
>
>
>
>
>-----Original Message-----
>From: Chris Hammond-Thrasher [mailto:chris.hammond-
>thrasher at hushmail.com] 
>Sent: Wednesday, 18 May 2005 8:38 AM
>To: websecurity at webappsec.org
>Subject: [WEB SECURITY] Ajax and secure web communications
>
>
>Hi,
>
>I recently blogged about Ajax and secure web communications. While 
>
>SSL/TLS is great, sometimes another cryptographic solution is 
>needed to solve the problem at hand - I use Hushmail as an example 
>
>of this. I would appreciate comments on the idea that I put 
>forward. Here is an excerpt:
>
>"While the Ajax model was not conceived by the geniuses at Google, 
>
>Adaptive Path, or wherever, as an information security tool, I 
>believe it may hold the key to reconceiving secure web 
>communications... With encryption and signature services, and key 
>management and/or client side authentication services embedded in 
>the Ajax Engine layer, combined with identity management and 
>access 
>control on the server side, one can envision a powerful new class 
>of secure web communications. And authentication could be handled 
>through a PKI-based mechanism, kerberos, or something else."
>
>http://thrashor.blogspot.com/2005/05/ajax-and-secure-web-
>communications.html
>
>-CHT
>
>blog - http://thrashor.blogspot.com
>
>
>-------------------------------------------------------------------
>--
>The Web Security Mailing List 
>http://www.webappsec.org/lists/websecurity/
>
>The Web Security Mailing List Archives
>http://www.webappsec.org/lists/websecurity/archive/

---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/