More on Ajax and secure web communications

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.

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.


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.