W3C W3C Incubator Report

MashSSL XG Final Report

W3C Incubator Group Report 27 July 2010

This Version:
Latest Published Version:
Previous version:
This is the first public version.
Siddharth Bajaj, VeriSign (Chair)
Ravi Ganesan, SafeMashups
Ben Wilson, Digicert
Thomas Hardjono, MIT
Allan McClure, MITRE
George Percivall, Open Geospatial Consortium
Jeff Shan, E*TRADE
Raj Singh, Open Geospatial Consortium


This report provides a summary of the work and results obtained by the MashSSL Incubator Group. This report describes MashSSL, a new security protocol that can be used to solve a fundamental Internet security problem: when two web applications communicate through a potentially un-trusted user they do not have any standard way of mutually authenticating each other and establishing a trusted channel. MashSSL uses the well studied SSL protocol as a starting point.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of Final Incubator Group Reports is available. See also the W3C technical reports index at http://www.w3.org/TR/.

This document was published by the MashSSL XG as an Incubator Group Report. If you wish to make comments regarding this document, please send them to public-xg-mashssl@w3.org (subscribe, archives). All feedback is welcome.

Publication of this document by W3C as part of the W3C Incubator Activity indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. Participation in Incubator Groups and publication of Incubator Group Reports at the W3C site are benefits of W3C Membership.

Incubator Groups have as a goal to produce work that can be implemented on a Royalty Free basis, as defined in the W3C Patent Policy. Participants in this Incubator Group have agreed to offer patent licenses according to the W3C Royalty-Free licensing requirements described in Section 5 of the W3C Patent Policy for any portions of the XG Reports produced by this XG that are subsequently incorporated into a W3C Recommendation produced by a Working Group which is chartered to take the XG Report as an input. Please see the IPR section of this document for more details

Table of Contents


This report describes a new security protocol, MashSSL, which can be used to solve a fundamental Internet security problem:  when two web applications communicate through a potentially un-trusted user they do not have any standard way of mutually authenticating each other and establishing a trusted channel. MashSSL uses the well studied SSL protocol as a starting point.

SSL [RFC5246] is a two-party protocol for mutual authentication and encryption that is typically used at the transport level. When used with mutual authentication, it is proven, trusted, and critically, has a well established and widely deployed trust and key management infrastructure in the form of certificate authorities who issue digital certificates.  However, it cannot be used directly for the problem we posed, which is inherently multi-party, and which needs a solution that runs ‘over’ HTTP, not ‘under’ HTTP.   

MashSSL is a new multi-party protocol that has been expressly designed to inherit, to the extent feasible, the security properties of SSL, and to be able to leverage its trust infrastructure.  It is based on the unique insight [GANE08] that the introduction of a legitimate man in the middle into the SSL protocol (aka Friend in the Middle or FITM) actually results in a powerful new protocol, which can solve the core problem we identified and has a number of other applications.  And, thanks to the work already done on SSL, MashSSL is lightweight with a short specification designed to be implemented in a RESTful fashion.

Use Cases

As described above, MashSSL is a common building-block that can be used in multiple use cases where this problem occurs. In this section we describe the abstract use case and real-world scenarios where MashSSL can be potentially used. For a more detailed motivation for the need for MashSSL please see Appendix – A: The Motivation for MashSSL.

3-Party MashSSL

This specification covers the use of MashSSL between two web applications communicating through a HTTP User Agent, as shown in the Figure-1 below.

Figure-1: 3-Party MashSSL

Figure 1: 3-Party MashSSL

In the above example, the user is accessing both web applications. However, there is a requirement that the two web applications need to establish trust between them in the context of the user (HTTP User Agent). This trust could be:

The above abstract use-cases can be seen in various real-world scenarios:

In some cases it is solved by using some form of backchannel communication with proprietary cryptographic protocols and key management. However, that approach is expensive and cannot be used in all the application scenarios.

2-Party MashSSL

The diagram below, Figure-2, describes a use case where two web nodes need to establish trust between them. This looks similar the standard SSL/TLS use case, but with one difference. The trust is established at the application layer and not at the transport layer.

Figure-2: 2-Party MashSSL

Figure 2: 2-Party MashSSL

Initially, this use case was conceived as a practical optimization between the two web-applications described above. However, this pattern can be used by itself in several application scenarios. For e.g. Mutual authentication between the user’s browser and a web site, at a finer granularity than the domain name. e.g. blog or shared hosting scenarios.

Design Goals

For a single generic protocol to address the problem, we have identified the following design goals or guiding principles:

  1. Solve it once:  We believe that we should solve this problem once at the fabric level, and not in a piecemeal fashion for the various situations in which the absence of a fundamental solution manifests as a problem. This is not a cross-domain XHR,  OAuth, OpenID,  etc. problem, it is a fundamental Internet security component that is missing in action!
  2. Solve it at the application level: In a sense HTTP has become the new ‘transport’ protocol for the web, and we believe that the protocol must run on top of HTTP.
  3. No browser changes:  Any protocol that requires browser changes will be faced with an adoption challenge. Further, in our situation we are dealing with web service to web service security, and requiring changes at the browser does not appear necessary.
  4. Do not use user authentication as a proxy for server authentication:  We consider it a poor choice to use the fact that a user can authenticate into a web service as a proxy for actual web service to web service authentication.
  5. Minimize new cryptography: Where possible we wish to use protocol constructs that have been well studied in the past. While the security of crypto building blocks cannot provide a guarantee on the security of a composite protocol, it is certainly the case that it is usually better to start with proven primitives.
  6. If possible leverage existing trust infrastructures: Perhaps the hardest part of any solution would be to distribute trustworthy credentials to applications. This is a problem of business processes, trust, insurance, indemnity, etc., and it is infinitely preferable to use an existing infrastructure, and existing credentials.
  7. Plan for scale: Finally, we believe that the solution should anticipate that in many practical situations the same two web apps will need to repeatedly authenticate each other, but through different users, and it needs to scale well under those circumstances (for instance repeating expensive PKI operations would not be a good idea).

Solution Overview

Our solution, MashSSL, is a multi-party variant of the SSL protocol that is designed to run over HTTP. It adds an important optimization to the SSL Abbreviated Handshake in order to complete that handshake in two steps instead of three steps. To make this document self contained, we first provide a generic description of SSL and then describe MashSSL within that context.

SSL Overview

The SSL protocol [RFC5246] is tried and tested. The cryptography has been extensively analyzed and the community went through a multi-year process of working out the kinks. Further, the trust infrastructure for SSL, namely digital certificates issued by Certificate Authorities (CA) is in place and working today. Organizations know how to obtain, deploy, and manage certificates for their servers.  And there is a concerted effort [CABFRM] to further improve standards for issuance of SSL certificates.

Let us examine SSL more closely to understand its elegance. In this paper we are only presenting SSL at a conceptual level; we refer the interested reader to the most recent specification [RFC5246] for more details. The SSL protocol can be thought of as having two phases: a handshake during which authentication and session key exchange happens, followed by the exchange of application data encrypted with the newly agreed upon session key.

The SSL handshake is shown in Figure-3 below. In our example Web App 1 serves as the “SSL Client” (the party that initiates the protocol) and Web App 2 serves as the “SSL Server”.   We will use the words Client and Server to refer to two web applications (not a user at a browser).

Figure-3: SSL Full Handshake

Figure 3: SSL Full Handshake

Let us assume that both parties have digital certificates. The process plays out as follows:

The two sides have now mutually authenticated, exchanged a session key (the master_secret) and can send each other messages encrypted with the session key.

A key part of the design is that SSL, when used with mutual authentication, eliminates man in the middle attacks. This happens because:

So a MITM who does not change what it received from the genuine server in Step 2, and simply forwards the genuine server’s certificate on to the Client, cannot retrieve R3. And a MITM who substitutes its own certificate for the real server’s in Step 2 will get a signature on a rhash that will not be the same as the rhash the real server expects to see signed. 

The ability to claim that a mutual authentication and key exchange protocol is MITM safe is possibly one of the most important cryptographic claims that can be made for such protocols, and SSL, when used with mutual authentication, has withstood the test of time in this regard.

Another elegant part of SSL is that it has been designed with a well thought out mechanism for session reuse. This protocol is shown in Figure-4.

Figure-4: SSL Abbreviated Handshake

Figure 4: SSL Abbreviated Handshake

A Client and Server that have previously carried out the SSL handshake over a particular socket can reuse  those values on a new connection. While the number of steps appears to be the same, the cryptographic processing is significantly reduced. And, this mechanism is not just meant to resume older sessions, it can also be used to start multiple sessions.

In this case the SSL handshake is said to be abbreviated and works as follows:

  1. The Client sends a sessionID used in a previous handshake with the Server.
  2. The Server decides if it is willing or not to reuse the parameters from the prior session.
    1. If it decides not to reuse the parameters it simply responds with the same messages as in the full handshake and both parties can proceed as before.
    2. If it does decide to reuse the parameters it simply responds with the server.verify message (which is a function of the master_secret from the previous message).
  3. If the Client is able to successfully verify the server.verify message then at that point it has authenticated the Server. It then sends a client.verify.
  4. If the Server is able to successfully verify the client.verify then at that point it has authenticated the Client.
  5. The two parties can then exchange data encrypted with the master_secret.

In addition to these well thought out features, SSL also has been tweaked to defend against more esoteric but potentially serious attacks (some which were discovered several years after SSL was widely used). Further, the protocol has well-defined mechanisms for accommodating different types of cryptographic algorithms.

MashSSL Overview

Mash SSL is a multi-party variant of SSL that runs over HTTP.  We largely reuse the SSL messages, which are exchanged between the web services as HTTP name-value pairs.  Similar to SSL, MashSSL supports and defines both the full and abbreviated handshake messages, though we introduce an optimization in the latter which we will describe.  MashSSL runs in two steps, first the web services directly carry out a MashSSL full handshake to establish a shared master-secret.  Once this is done, they can communicate through a user’s browser using the MashSSL abbreviated handshake.   This approach is extremely efficient as after one full handshake which requires PKI operations, the two sites can do a very large number of abbreviated handshakes which are efficient and only require symmetric key operations.  So, for instance, if two web services communicate via users a hundred thousand times a day, they might choose to perform the full handshake once a day and leverage that across the hundred thousand transactions.

MashSSL Full Handshake

The MashSSL handshake closely follows the SSL handshake messages described above. The two web services exchange the handshake messages and at the end of the handshake a common master_secret is established between them. The actual messages are described in the next Section. The figure shows a layered view of the different protocols. Note that the security of MashSSL does not rest on the use of the optional SSL pipe.

Figure-5: MashSSL Full Handshake Layered View

Figure 5: MashSSL Full Handshake Layered View

MashSSL Abbreviated Handshake

Once the two web services have established a master-secret, they can run the MashSSL abbreviated handshake through a user’s browser, serving to cryptographically bind all three parties together.

Figure-6: MashSSL Abbreviated Handshake Layered View

Figure 6: MashSSL Abbreviated Handshake Layered View

As shown in the figure, the SSL abbreviated handshake consists of three sets of messages, Client to Server, Server to Client and Client to Server. While MashSSL can mimic this structure, and in fact the earlier versions of the specification describe MashSSL in this fashion, we have since chosen to propose an optimization, which reduces the number of round trips. Specifically, the first set of Client to Server messages contain all the information needed for the Server to authenticate the Client. The Server then (if the Client requests it) responds with a set of Server to Client messages which completes the handshake. Referring again to the figure, it will quickly become evident that to achieve this, the Client needs to pick the server random number, and in the next Section we describe how this is done. There has been discussion of introducing a very similar optimization into TLS itself and the interested reader is referred to this thread [MLLIST] on the TLS mailing list.

Protocol Specification

As described above, the MashSSL protocol consists of first running the MashSSL Full Handshake directly between the two web services, and then the MashSSL Abbreviated Handshake through the user’s browser. We describe the messages that make up both sets of handshakes below. In order to make analysis and comparison to the SSL protocol simpler we:

MashSSL Full Handshake

The MashSSL protocol begins by the Client sending the Server the client_hello message. This message consists of six parameters: 

When the Server receives this message, it verifies that the Client is using a supported protocol version and that there is at least one cipher-suite in the list that it can support. It then creates a server_hello message with the following eight parameters:

The Client examines the message and if it can proceed, it first creates the following three parameters:

Each of the parameters above MUST be represented as a key/value pair of the form namei=valuei, delimited by an ampersand. The Client takes the parameters above (from the beginning of the protocol up to this point), orders them alphabetically based on the name of the parameter, and forms the string handshake_messages_up_to_this_point = name1=value1&name2=value2&...&namen=valuen, for n key/value pairs.  The Client then computes the next parameter.

The Client then computes the master_secret by using a Pseudo-Random Function (PRF) (see RFC 5246 [RFC5246], Pg. 13). The master_secret is the first 48 bytes derived from the output of the PRF taking as input the pre_master_secret, the string literal “master secret”, and the concatenation of the client_helloand server_hello random numbers (that is, master_secret = PRF(pre_master_secret, “master secret”, client_hello.client_hello.random +server_hello.server_hello.random). The Client then updates the handshake_messages_up_to_this_point to include the client_key_exchange.certificate_verify.signature. The Client then computes the next parameter.

The Client sends these five parameters together to the Server.  The Server verifies that the Client’s certificate chains up to a root it trusts. It then verifies the signature in the client_key_exchange.certificate_verify.signature using the public key in the Client certificate. If this is successful then the Server has successfully authenticated the Client. If the above signature was verified successfully, the Server uses its own private key to recover the pre_master_secret from the client_key_exchange.encrypted_pre_master_secret.  If either the version_number or the length  of the expected message is incorrect, the Server MUST compute a random 48 byte value, set it equal to the pre_master_secret, and proceed with the rest of the protocol. The reader is invited to study the explanation for this action in RFC5246 [RFC5246], Pg. 57 and in the papers referenced there.  The Server then computes the master_secret using PRF(pre_master_secret, “master secret”, client_hello.client_hello.random +server_hello.server_hello.random). It then verifies the client_key_exchange.finished.verify_data by re-computing it using the exact same steps the Client followed (the handshake_messages_up_to_this_point must be equal to when the Client computed it). The Server then computes the server_finished message, which has three parameters.

The Server sends the server_finished message to the Client. The Client verifies that this message was computed correctly by re-computing the server_finished.finished.verify_data value. If this verification proceeds correctly, then the Client has authenticated the Server.  At this point, the Client and the Server have mutually authenticated and  share the master_secret. This completes the MashSSL Full Handshake.

MashSSL Abbreviated Handshake

Once a Client and a Server have established a master-secret using the MashSSL Full Handshake, they are now ready to initiate an abbreviated handshake via a user’s browser.  The handshake is described below. We only describe in detail the parameters that are different from the full handshake. The handshake traverses the user’s browser, and this standard does not limit the manner in which this happens (redirects, POSTs, XHR, etc.). Under certain circumstances, logic in the browser may manipulate the bits in ‘extension’ parameter, however all other parameters must be passed as-is.

The Client starts by sending the client_hello to the Server via the user’s browser:

Upon receiving the client_hello message the Server:

  1. Ensures that is has not received this message before (the size of the cache for preventing replays must at least accommodate messages received within the clock slew that is tolerated)
  2. Checks if client_hello.client_hello.gmt_unix_time is within five minutes of its own clock. 
  3. If so, it recomputes  the suggest_Server_hello_finished.server_hello.random and verifies that it is identical to that sent by the Client.
  4. If so, it recomputes the client_hello.finished.verify_data, and if it is correct, then at this point it has successfully authenticated the Client.

If the client_hello.response_required is set to true, then the Server computes its response as follows:

These parameters are sent to the Client via the Browser. With the possible exception of the server_hello.finished.extension, the browser must send the other parameters as-is to the Client. The Client recomputes the server_hello_finished.finished.verify_data, and if it matches it has authenticated the Server. In the event the Client authentication fails for some reason, and a Server response is asked for, the server should respond with the exact same messages as above, except that the server_hello_finished.finished.verify_data should consist of 12 random bytes.

Encryption of Data Using MashSSL Keys

MashSSL currently does not contain the analogue of the TLS record protocol, and hence we do not describe the key calculation for encryption. Applications desiring to create an encrypted record protocol can use the key calculation described in TLS RFC 5246 [RFC5246] Page 24.

Leveraging Existing SSL Certificate Infrastructures

The protocol as currently defined will work with existing SSL certificates without any changes. We believe however that we need to move towards “application certificates” where certificates are issued to an application URL. So for instance http://www.example.com/mail and http://www.example.com/calendar should require separate certificates. For now, however, we do require that any implementation of the MashSSL protocol be able to recognize and handle certificates issued to application URLs and to extract a Fully Qualified Domain Name (FQDN) from them. However, we do not as yet expect them to be able to differentiate between separate applications that resolve to the same FQDN.

We do recommend that if possible, organizations should embed the application URI in the Subject Alternate Name field in the certificate.

Security Considerations

By starting with TLS, MashSSL is able to leverage the existing security infrastructure of SSL certificates. The analysis of the cryptography can also use the analysis of TLS as a starting point. However, it is a different protocol, most notably in its introduction of the optimized abbreviated handshake, and hence it cannot be assumed that it automatically inherits all the security properties of TLS.

To prevent cut and paste attacks the application must ensure cryptographic binding between the MashSSL header in the abbreviated handshake and the body. This is best achieved by encrypting the payload.

Future Work

There are at least three areas of future work to advance the standard:

  1. The optimization in the abbreviated handshake makes some of the parameters superfluous. We have retained these for now, but it is clear that the abbreviated handshake can be further simplified.
  2. A standard mechanism for generating keys for privacy and integrity based on the MashSSL handshakes, and the equivalent of the SSL record protocol, should be specified to make this standard more self contained.
  3. Perhaps the most interesting future work is based on the observation that the MashSSL handshakes we have described could well be run between a browser and a web application, allowing for application level mutual authentication and encryption. 


The authors would like to thank Erhan Kartaltepe, Ramakrishna Menon and Todd Wolff who worked on earlier versions of the MashSSL specification and software, and Lynn Terwoerds for a careful review. We are also grateful to all those who have been a part of the SSL community over the years for their hard work that we are able to leverage.

IPR Statement

Certificate Definitions

We define the following types of certificates:

Licensing Commitment

Any Essential Claims will be licensed for use with Self Issued Certificates in accordance with W3C Royalty-Free Licensing Requirements. Licenses for use with 3rd Party Certificates (e.g., implementations relying on certificates issued by third party commercial CAs) may be provided on reasonable and non-discriminatory terms and conditioned on payment of royalties, fees or other consideration.


Verified by Visa: 3-D Secure, http://en.wikipedia.org/wiki/3-D_Secure
W3C Cross-Origin Resource Sharing, http://www.w3.org/TR/cors/
The CA Browser Forum, http://www.cabforum.org
R. Ganesan. MashSSL: Towards Multi-Party Trust in the Internet, http://www.safemashups.com/downloads/MashSSL_Towards_Multi_Party_Trust_in_the_Internet.pdf
Single round trip abbreviated handshake, IETF TLS mailing list, http://www.ietf.org/mail-archive/web/tls/current/msg05728.html
OAuth, http://oauth.net/
OAuth Security Advisory: 2009.1, http://oauth.net/advisories/2009-1/
OpenID, http://openid.net/
Ashish Jain, Andrew Nash, Jeff Hodges. OpenID Security Issues, http://www.slideshare.net/itickr/open-id-security-issues-2468599
J. Jonsson, B. Kaliski. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1, http://tools.ietf.org/html/rfc3447
PayPal Website Payments Standard Integration Guide, https://www.paypalobjects.com/en_US/pdf/PP_WebsitePaymentsStandard_IntegrationGuide.pdf
T. Dierks and E. Rescorla. “The Transport Layer Security (TLS) Protocol Version 1.2, http://tools.ietf.org/html/rfc5246

Appendix: The Motivation for MashSSL

We first present several motivating examples and then generalize the problem.


As our first example, let us consider a hypothetical situation where a web service receives a cross domain XHR request which purports to originate from a partner web service.   In our example, illustrated in Figure-7, the web service is willing to provide video content of classic movies to any subscriber of a partner movie site.  The question immediately arises: Is the request coming from a genuine subscriber of the movie site, or is it a content pirate who is substituting ORIGIN tags in the requests?

Figure-7: Site to Site Authentication for Cross Domain XHR

Figure 7: Site to Site Authentication for Cross Domain XHR

When such a situation manifest in practice, web services often resort to proprietary cryptographic  mechanisms, and requiring signatures on some proprietary tickets. The immediate consequence of such a solution is that there is yet another potentially weak security protocol that has been ginned up to solve a specific problem, and, both sides have another set of keys to manage to solve this particular problem.  Another suggestion for solving the above problem might be to use an identity federation protocol. While that might certainly be apropos for many situations, in this particular example the classic clips site has no interest in user identity, the requirement is simple, it wants to be able to authenticate the origin of the cross domain request without having to trust the intermediary. We note that the W3C Cross-Origin Resource Sharing specification [CORS] is intended to solve the complementary problem of protecting the user from a malicious web service, whereas our focus is to protect the web service from a malicious user.

For our second example we turn to a very common situation, shown in Figure-8, of an eCommerce site implementing payment options on their site. To maximize business the merchant is likely to want to offer multiple options. While every payment option has its own semantics, and it would be unrealistic to imagine a standard covering them all, we do note one commonality in many of these situations (e.g. PayPal [PPIG], VISA 3D Secure [3DS], etc.). Specifically, the user is redirected to a payment site, and then redirected back to the merchant after payment. 

Figure-8: Site to Site Authentication for Payment Buttons

Figure 8: Site to Site Authentication for Payment Buttons

Both web services in this situation have to ensure that a malicious user does not tamper with the information flowing back and forth. Consequently they typically implement some proprietary cryptography and require special credentials. From the stand point of the merchant who implements multiple such options, there is soon a profusion of crypto protocols and a credential management headache.

For our third example we consider identity federation protocols like OpenID [OPID].  Almost all of these protocols follow the identity ‘dance’ shown in Figure-9, wherein a user is redirected to an identity provider who authenticates the user and then makes assertions about the user. 

Figure-9: The Federation Identity Dance

Figure 9: The Federation Identity Dance

Central to the security of these protocols is the mutual authentication of the IP and the RP and the establishment of a secure channel, and this is a challenge for these protocols. For instance, in their analysis of the security of the OpenID protocol [OPIDS], the authors observe: “browser is de facto MITM….vulnerability to active attacks (session swapping)…association establishment (MITM)”.  Solving these problems requires new crypto and the introduction of yet another credential.

For our final example we turn to the OAuth delegated authorization protocol [OAUTH] which, combined with OpenID, is becoming a fundamental piece of the security puzzle for securing mashup APIs. Currently OAuth is used widely in applications such as social networks. However, it is expected that OAuth or similar protocols will be used in mashups of even more sensitive information such as financial or healthcare data is likely to follow. An example is shown in Figure-10.

OAuth Use Case

Figure 10: The OAuth Use Case

When OAuth was first designed, the familiar problem of how the two web services would mutually authenticate and establish a trusted session was encountered. The initial solution was found to suffer from a classic man-in-the-middle session fixation attack [OAUTHS], and has subsequently been altered.  The crypto to solve this problem is again proprietary to OAuth and a web service needs an OAuth specific credential.


We have described four situations in which web services communicating through a potentially untrusted user (or browser) have to resort to proprietary crypto and have to issue or obtain and maintain special purpose credentials. This is not a new problem for web services, but is a problem that is growing. We are rapidly transitioning to a world where the end user’s web experience is typically a composite or mashup of several web services. The need for these web services to mutually authenticate and establish a trusted channel is going to arise again and again in many different contexts. Consequently there is a growing need to solve this problem once with a standard protocol that can be reused in any applicable context.

It must be emphasized that our goal is not to replace any of the protocols we described above. Rather, our goal is to provide for a standard way of mutual authentication and establishment of a secure pipe between the two web services, which can then be used by various protocols. Just as SSL is the default underlying security protocol for browser to web server security, we see MashSSL evolving to be the default underlying security protocol for web server to browser to web server communications.