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.
- Secure timestamping,
- User authentication, and
- Digital signatures.
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
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.