One document matched: draft-huitema-tls-tlsoverhttp-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2026 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml'>
<!ENTITY rfc2246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2246.xml'>
<!ENTITY rfc2616 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY rfc2818 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml'>
<!ENTITY rfc5246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc6455 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml'>
<!ENTITY I-D.ietf-httpbis-http2 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-http2.xml">
<!ENTITY I-D.ietf-tls-tls13 PUBLIC ''
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-tls13.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<!-- Expand crefs and put them inline -->
<?rfc comments='yes' ?>
<?rfc inline='yes' ?>
<rfc category="exp"
docName="draft-huitema-tls-tlsoverhttp-00.txt"
ipr="trust200902">
<front>
<title abbrev="TLS over HTTP (HTLS)">
TLS over HTTP
</title>
<author fullname="Christian Huitema" initials="C." surname="Huitema">
<organization>Microsoft</organization>
<address>
<postal>
<street> </street>
<city>Redmond</city>
<code>98052</code>
<region>WA</region>
<country>U.S.A.</country>
</postal>
<email>huitema@microsoft.com</email>
</address>
</author>
<date year="2015" month="March"/>
<abstract>
<t>
We observe that attacks against HTTPS are getting more and more popular.
The attacks typically exploit weaknesses in PKI certificate verification
software. These weaknesses allow a third party to insert itself as a
Man-In-The-Middle in a TLS connection, accessing the content of messages
that were previously encrypted and in some case changing these messages.
</t>
<t>
TLS over HTTP allows clients and servers to carry a TLS conversation
on top of HTTP, and thus bypass the man-in-the-middle attackers.
Different deployment models are possible, e.g., HTTP over TLS over HTTP,
application-layer-protocol over TLS over HTTP, or HTTP over TLS over HTTP over TLS.
</t>
<t>
The proposed solution allows for reuse of the existing TLS
implementation, thus minimizing the development costs and risks. It includes
an optional obfuscation layer, to maximize the likelihood of working unnoticed
by firewalls and other MITM boxes.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro" >
<t>
Following the Snowden revelation, there has been an increased push to deploy
encryption over the Internet. The IAB reinforced this trend by publishing the
IAB Statement on Internet Confidentiality <xref target="IABConfidentiality" />.
Of course, every action brings a reaction, and the push for encryption
is countered by the deployment of encryption-breaking middleboxes.
The middle boxes typically use weaknesses in the Certificate Verification
system of popular TLS implementations to insert themselves as
"Man in the middle" (MITM). In another class of attacks, the middleboxes will simply block
encrypted communication, only allowing clear-text HTTP.
</t>
<t>
The MITM attacks against TLS can be detected in various ways. For example, the
TLS client might have obtained in advanced a good copy of the certificate used
by the TLS server. The client can then compare the value used in the TLS exchange
to the value in the good copy. If they differ, the MITM attack is detected. However,
in the current state of the art, the only choice of the client is either to abort the
connection, or to tolerate the encryption compromise by the middlebox.
</t>
<t>
Both the MITM attack and the clear-text only attacks can be mitigated by
running TLS on top of HTTP (HTLS).
</t>
</section>
<section title="TLS over HTTP architecture">
<t>
The basic TLS over HTTP architecture has four layers, including a framing
layer which is conceptually placed between TLS and HTTP.
</t>
<figure anchor="TLSHTTPDiagram">
<artwork><![CDATA[
+-------------+
| application |
+-------------+
| TLS |
+-------------+
| Framing |
+-------------+
| HTTP |
+-------------+
]]></artwork>
</figure>
<t>
The framing layer is responsible for encapsulating the TLS frames into the
HTTP protocol.
</t>
<t>
<xref target="TLSHTTPDiagram" /> describes the simplest stack, in which we assume
that HTTP is run "end to end." There are many possible variants, including in particular
the HTTPS variant, in which HTTP is run over TLS. In that case, we will effectively
see two instances of TLS running on top of each other.
</t>
<figure anchor="TLSHTTPSDiagram">
<artwork><![CDATA[
+-------------+
| application |
+-------------+
| TLS |
+-------------+
| Framing |
+-------------+
| HTTP |
+-------------+
| TLS |
+-------------+
]]></artwork>
</figure>
<t>
Having two instances of TLS obviously causes some amount of overhead. It is
however the price to pay in order to actually traverse series of middleboxes
while establishing end-to-end encryption.
</t>
<t>
This document defines framing of HTLS over web sockets <xref target="RFC6455" />.
There may be a need in the future to provide more options. For example, if
middleboxes started to deploy inspection software to detect and prevent usage of
HTLS over web sockets, there will be a need to define
some form of obfuscation, rendering the content as indistinguishable as possible
from regular HTTP content.
The new semantics introduced in HTTP/2.0 <xref target="I-D.ietf-httpbis-http2" />
will probably allow for efficient implementation of such encapsulations.
</t>
</section>
<section title="Framing with web sockets" >
<t>
The WebSocket protocol <xref target="RFC6455" /> enables applications to transmit
arbitrary binary messages over a channel that is initiated as HTTP or HTTPS. The WebSocket
protocol is compatible with HTTP/1.1
<xref target="RFC2616" />
and with HTTP over TLS
<xref target="RFC2818" />.
</t>
<t>
When using the web socket framing, the client will establish a web socket using the
URI reserved by the server for HTLS over web sockets. Once the web socket has
reached the OPEN state, both client and server will be able to send and receive
data frames, as defined in section 6 of <xref target="RFC6455" />. Each TLS frame
will be sent as a separate web socket data frame.
</t>
<t>
The client will start the TLS handshake as defined for the client-chosen version of TLS
in
<xref target="RFC2246" />,
<xref target="RFC5246" />,
or
<xref target="I-D.ietf-tls-tls13" />.
The client and server will then execute the TLS protocol, and carry the application protocol
inside TLS data frames.
</t>
<t>
We should note that, while the framing layer is conceptually layered above HTTP, the
WebSocket protocol really replaces HTTP after the initial negotiations. The architecture
diagram with WebSocket framing really looks like:
</t>
<figure anchor="TLSHTTPWSDiagram">
<artwork><![CDATA[
+-------------------+
| application |
+-------------------+
| TLS |
+-------------+-------------------+
| HTTP | WebSocket Framing |
+-------------+-------------------+
]]></artwork>
</figure>
</section>
<section title="HTLS parameters" >
<t>
An application that starts an HTLS connection will need to specify a the HTTP or HTTPS URI
used to establish the underlying HTTP connection and the type of framing required for the
encapsulation.
We assume that these parameters will be passed as an end to end exchange between
server and clients, prior to the establishment of the HTLS connection.
</t>
</section>
<section title="MITM bypass scenario" >
<t>
As stated in <xref target="intro" />, one of the main motivation for HTLS is to
offer a better choice to the user when a secure connection is compromised by an
MITM attack.
</t>
<figure anchor="MITMAttackBybass">
<artwork><![CDATA[
Client | MITM | Server
---------------+----------------+--------------
| |
Establish TLS | |
connection -----------> |
| intercept |
| --------------->
| | establish TLS
| <---------------
| modify |
<--------------- |
Detect | |
Modification | |
Establishes | |
WebSocket -------------------------->
<-----------------------------
Establish | |
HTLS ----------------------------->
<-----------------------------
Continue | |
application ------------------------->
<-----------------------------
| |
]]></artwork>
</figure>
<t>
The exchanges depicted in <xref target="MITMAttackBybass" /> are easy to
understand, but a few of the actions require further explanation:
</t>
<t>
<list style="symbols" >
<t>How does the client detect the modification?</t>
<t>How does the client know that the server can use HTLS, and what parameters should it use?</t>
<t>What about performance degradation?</t>
</list>
</t>
<t>
There is lots of work going on in the IETF and in the industry to detect
attacks against TLS. The most popular attack involves the forging of certificates
by the MITM, as done for example by the "Superfish" software <xref target="Superfish" />.
The MITM will generate a fake certificate for the target, have it signed by a
certificate authority under its control, and somehow convince the security
software on the client side to trust that certificate authority. The client
can detect the attack if it knows the "right" certificate for the server and
observes a mismatch. The client could also apply some logic to find suspicious
characteristics in the certificate provided by the MITM, and detect the fakery.
</t>
<t>
Once the client decides that the certificate is probably fake, it has to establish a
WebSocket session to the server, and for that it needs parameters. In fact, since the client
already knows the name of the server and has already decided to use the WebSocket protocol over
TLS, it needs just one parameter, the URI of the HTLS web socket service on
the server. The simplest solution is to use a constant value, "HTLS." Successful
establishment of a web socket through that URI indicates that the server
supports HTLS.
</t>
<t>
Clearly, using HTLS degrades performance. There are a number of additional handshakes
before any application data can be exchanged, some additional overhead due
to encapsulation errors, and a computing charge for running the encryption
twice. Running HTLS is thus a tradeoff. In the absence of HTLS, the client's
only choices are to drop the connection, or accept working in an insecure manner.
HTLS adds a third choice, a way to bypass the MITM attack at the cost of reduced
performance. There will be cases where secure and slow is better than either
no connection at all or an insecure connection.
</t>
</section>
<section title="Winning the cat and mouse game" >
<t>
Deceiving the MITM attacker is of course a game of "cat and mouse." The mice (the victims),
in that case, are taking evasive action to escape the cat (the MITM attacker).
HTLS is one of these evasive actions. It will work as long as the attackers
are not aware of it, but we have to assume that smarter mice beget smart cats.
That is the reason for having an optional "framing" layer as part of the
architecture.
</t>
<t>
The first instantiation of the framing uses web sockets and a standard URI
at the server, but it is reasonably easy for an attacker to detect that. The answer
is of course to include some level of obfuscation in the framing layer, so that
HTLS traffic is difficult to distinguish from other web traffic.
The simplest obfuscation is to keep the web socket encapsulation, but make the
URI parameter hard to discover by third parties. Instead of using the constant
string "HTLS," servers can come up with their own creative names. If the server
and the client cooperate, they can vary these names over time according to some
pre-established schedule. At that point, it becomes hard for the MITM to distinguish
HTLS from other types of web sockets. The MITM attacker now is left with two options:
block all web socket traffic, or allow HTLS to pass unmolested.
</t>
<t>
If it turns out that MITM attackers are willing to ban all web socket traffic,
we will have to study a different form of framing. This should probably be based
on HTTP/2.0 support for multiple streams and bidirectional transmissions. We could
imagine sending each TLS frame as a separate page, with the set of pages multiplexed
over the HTTP/2.0 connection. The frame will be encoded as page content, which
could be binary, but could also be some sophisticated text or image representation
designed to elude MITM censorship. This is of course for further study.
</t>
<t>
In the end game, the MITM attacker should be left with the choice of allowing
HTLS or blocking all web traffic. Some attackers may indeed choose to block
everything, but most will probably just give up.
</t>
</section>
<section title="Security Considerations">
<t>
The draft addresses a major security issue, the interception of
secure connections by middleboxes that break the end to end nature of encryption.
</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>
This draft does not require any IANA action.
</t>
</section>
<section title="Acknowledgments">
<t>
Thanks to Dave Thaler for suggesting the use of Web Sockets for encapsulating TLS in HTTPS.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc6455;
</references>
<references title="Informative References">
&rfc2246;
&rfc2616;
&rfc2818;
&rfc5246;
&I-D.ietf-httpbis-http2;
&I-D.ietf-tls-tls13;
<reference anchor="IABConfidentiality" target="http://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/">
<front>
<title>IAB Statement on Internet Confidentiality</title>
<author fullname="IAB" />
<date month="November" year="2014" />
<abstract>
<t>
Newly designed protocols should prefer encryption to cleartext operation.
</t>
</abstract>
</front>
</reference>
<reference anchor="Superfish" target="http://www.zdnet.com/article/lenovos-superfish-its-worse-than-we-thought/">
<front>
<title>Lenovo's Superfish spectacle: 'Catastrophic' security failures discovered</title>
<author fullname="Charlie Osborne" initials="C." surname="Osborne"/>
<date month="February" year="2015" />
<abstract>
<t>
Superfish isn't just adware -- it can also be a nightmare for those who value their privacy.
</t>
</abstract>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 17:56:20 |