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.
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 email@example.com (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
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.
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.
This specification covers the use of MashSSL between two web applications communicating through a HTTP User Agent, as shown in the Figure-1 below.
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:
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.
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.
For a single generic protocol to address the problem, we have identified the following design goals or guiding principles:
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.
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).
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.
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:
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.
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.
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.
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.
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.
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:
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.
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:
If the client_hello.response_required is set to true, then the Server computes its response as follows:
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.
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.
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.
There are at least three areas of future work to advance the standard:
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.
We define the following types of certificates:
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.
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?
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.
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.
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.
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.