6.9 KiB

Mobile Hypertext Transfer Protocol, version 1.1


Mobile Hypertext Transfer Protocol (MHTTP) is a protocol that helps speed up the web and protect it from DDoS attacks, while providing strong security guarantees. It's heavily based on HTTPS, and also uses SCTP where available.

The "Mobile" in the name refers to mobile phones.

The MHTTP version tracks the corresponding HTTP version it's built on. As such, there's no MHTTP/1.0 or MHTTP/0.9 as there are no versions of MHTTP built on those HTTP versions.

This protocol builds on:

  • SCTP
  • TLS Application-Layer Protocol Negotiation (ALPN)
  • A new type of TLS certificate
  • HTTPS/1.1 (HTTP/1.1 over TLS)

This protocol shall define the TLS ALPN protocol ID "mhttp/1.1".

This protocol also makes use of the TLS ALPN protocol ID "http/1.1".

New certificate types (and new certificate authority types)

Two new kinds of certificates shall be created:

  • TBD], the public-facing certificate type in mhttp/1.1.
  • TBD], used by CAs to sign the above.

They have to be added so as to prevent Let's Encrypt from being able to issue them at the moment. This is a temporary measure and should be revised once certificate providers adjust to this new protocol.

The Network Model

This protocol is built upon the following network model:

client <--------> CDN <--------> server

Currently, existing protocols are used to provide CDN services like so:

client <--HTTPS-> CDN <--HTTP--> server

Securing communications between client and server

The MHTTP protocol attempts to secure communication between client and server through the whole path. It puts both the client and the server in control, as it should be, where the existing options put the CDN in control.

To be able to do this, it needs to cover a few different scenarios.

Backwards compatibility with HTTPS, TCP, client certificates.

For backwards compatibility with HTTPS, TCP, client certificates, the following section applies, but for all HTTP methods.

Client-to-server (private) data

The most basic scenario is when sending "private" data. This is used when modifying server data. This includes the following HTTP methods:

  • POST
  • PUT
  • TBD]

In this scenario, the client may use a TCP or SCTP connection and must use the "http/1.1" protocol. The CDN must pass this stream through unchanged, but may choose to restrict the client's bandwidth and/or connection limits. The CDN must use SCTP for any connections to the server.

This scenario should be used whenever the client would make a request using one of the above HTTP methods.

Client-to-CDN, cached data

In most cases, the client wants to request data from the [server/CDN] instead. In MHTTP/1.1, the client must use an SCTP connection, and request the "mhttp/1.1" and "http/1.1" protocols, in that order, in descending order of preference.

If a CDN exists and supports MHTTP/1.1, it must negotiate a TLS stream with the client using the CDN certificate mentioned in section 2.

MHTTP/1.1 requests look just like HTTP/1.1 requests, but with some key differences:

  • POST, PUT, DELETE, PATCH, [TBD] are not supported.
  • Cookies are not supported.
  • "MHTTP/1.1" is used instead of "HTTP/1.1".
  • TBD]

The CDN must cache based on at least:

  • Resource Path
  • Accept/Content-Type header
  • Accept-Language header

If the CDN has the response in its cache, it should just send that response out, without hitting the server.

The CDN should not choose to send the same response for different Accept headers, and should take preference into account if doing so. For example, if the first request contains the header:

Accept: */*

And the response contains:

Content-Type: text/html

But the second request contains:

Accept: application/xhtml+xml, text/html; q=0.5

Then the CDN should hit the server for an application/xhtml+xml. If one is found, a subsequent request with Accept: */* may retrieve an application/xhtml+xml instead of text/html.

If the CDN does not have the response in its cache, the next scenario applies.

Client-to-CDN, uncached data

If the CDN does not have the response in its cache, it must open a stream to the server, using the "mhttp/1.1" protocol and the CDN certificate as the TLS client certificate.

The CDN must then repeat the exact same request it was given, as in plain HTTP/1.1. [TODO: specify how to identify the client to the server] The server may then choose to send the CDN a response. However, the response has some key differences from HTTP/1.1.

First, the response starts with the server's certificate.

Second, the response must contain the server's domain name and the resource path. We don't rely on the server certificate's domain name because it may be valid for multiple domain names.

Third, the response must contain the cache control headers:

  • Expires
  • TBD]

It should also contain additional cache control headers for use by the CDN and client.

Fourth, the response (domain, path, headers and body) must be signed by the provided certificate's key (server's private key). The certificate itself is not included in this signature.

If the CDN provides an expired response to the client, as defined by the Expires header, or a response for another domain or resource path, the client must warn the user and discard the response. To account for network latency, the CDN may choose to expire the response a few seconds or a few minutes before the true expiry date.

If the server chooses not to send the CDN a response, it can do so in the next scenario.

CDN-mediated client-to-server, (true) private data

If the server doesn't want the CDN to cache a GET/[TBD] request, it can open a new SCTP stream for sending the data directly to the client.

If the server opens an SCTP stream to the CDN instead of responding to a request, the CDN must forward this new stream as a new stream to the client. The client should then start a TLS handshake with the server, using the "http/1.1" protocol, and run a normal HTTP request with all normal HTTP headers, including cookies. See the backwards compatibility section for details.

(This requires SCTP because TCP-based alternatives would either require the CDN to signal a connection closed, which could be caused by another network factor not involving the CDN, and thus unnecessarily increase server load as well as reducing the reliability of the backwards compatibility mechanisms, or it'd involve a reverse TCP connection and we already know how that went for FTP.)

Use by ISPs - transparent proxies

The CDN CA store is separate from the main CA store, and can only be used to sign CDN certs or other CDN CA certs. This means it's fairly safe to put arbitrary certs in it. ISPs may use this to provide transparent HTTPS proxies, in which case they act like a CDN as defined above, except they do not send their cert upstream, instead relying on their capabilities as an ISP and using the client's real IP address for the request.