MashSSL Overview

MashSSL removes the objections to using SSL for our problem by:

  1. Introducing a cryptographic innovation (described below) to make SSL a multi-party protocol without any change whatsoever in the security of the underlying SSL protocol.
  2. By running the resulting protocol on top of HTTP in the protocol stack. i.e. the MashSSL messages are carried within HTTP.
  3. The specification itself is defined in a simple RESTful fashion and is short and simple.

The reader is referred to the standard for more information on how the protocol is specified. This White Paper describes the cryptography in greater detail, but we do cover the core concepts below.

MashSSL Cryptography

We start by observing that one can make a very strong claim about the SSL protocol (handshake shown below) when used with mutual authentication. Namely, it is believed to be secure even in the presence of multiple Man-In-The-Middles (MITMs) who can manipulate the messages. By secure we mean that they cannot impersonate the parties at either end, nor can they learn the shared session secret (the master-secret) that is established.

Having accepted this premise, let us now ask the seemingly impossible question. In what situation can the MITMS:

  1. Be allowed to manipulate messages.
  2. The protocol successfully execute.
  3. And yet, the security of SSL not be compromised?

There is only one situation where this is possible: If the changes made by the MITMs en route the servers cancel each other out!

As an example consider a scenario with three MITMs LEFT, CENTER and RIGHT.

Imagine if Web App 1 sends the initial SSL handshake message, LEFT manipulates the random number R1 by encrypting it with a password it shares with CENTER. CENTER decrypts it and passes on the original R1, and RIGHT gives it to Web App 2 without further changes. Similarly on the way back, the random number R2 is encrypted by RIGHT with a password it shares with CENTER. Now CENTER decrypts it and sends it to LEFT who simply gives it to Web App1. In this scenario the SSL protocol will play out correctly. Manipulations did occur, but did not result in the MITMs being able to impersonate either Web App, nor learn their shared session key, the master-secret. So how do we use this construct?

The MashSSL protocol essentially introduces three "legitimate MITMs" (or FITMs) into the standard SSL protocol. LEFT and RIGHT reside at Web App 1 and Web App 2 respectively, and MIDDLE is in the browser. The Web Apps generate and consume SSL messages, but at the appropriate points in the protocol, they also manipulate the message (henceforth termed "scrambling") before sending on. If they do this the browser must "unscramble" the message before sending it on to the other Web App.

In the example above the random number R1 is scrambled (e.g. encrypted with Alice's password) by Web App 1 before sending on, and she successfully unscrambles it en route to Web App2. Similarly Web App2 scrambles R2, which Alice unscrambles and sends on to Web App 1.

We choose this method of explaining MashSSL because it conclusively shows that the security of MashSSL, from the perspective of mutual authentication of the two Web Apps, and the privacy of their shared master-secret, is exactly the same as SSL. i.e. the introduction of MITMs cannot break MashSSL.

We can immediately observe one major benefit. If after establishing trust via Alice, the two Web Apps are involved in another 'mashup' with a different user Fran, then they simply use the abbreviated handshake which does not involve any public key operations and is hence extremely efficient.

So how exactly must the scrambling work? The MashSSL Protocol explicitly does not specify any pre-determined way of performing scrambling. We somewhat lightheartedly observe that in Googling "recipes for scrambled eggs" we found hundreds of entries. Similarly there are countless ways in which the scrambling and unscrambling can be achieved. For instance one can use existing authentication methods like passwords, one time passwords, smartcards, device IDs, etc. The White Paper discusses this in greater depth and addresses some of the security points to be kept in mind while picking a method of scrambling. Finally, we observe that if the user is already logged in, and the Web App receives a session cookie attesting to this, then it can perform "virtual scrambling" wherein it does not do any scrambling at all.