- From: Peter Lepeska <bizzbyster@gmail.com>
- Date: Tue, 26 Nov 2013 17:29:46 -0500
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CANmPAYETjKHcsBpan8r3S2-cwvkTg1vhUMBpBpnNcRZpAB90AQ@mail.gmail.com>
*Problem statement*:
As Mark, Roberto, and others have argued in multiple Internet Drafts, an
explicit, trusted proxy is preferable to a transparent MITM proxy as
intermediary of HTTP2S traffic (HTTP2 over TLS). One problem in developing
a standard for an explicit, trusted proxy is the process by which a proxy
establishes trust. We don't try to tackle that problem here but believe
that it should be *no easier* than the current process by which MITM
proxies establish trust, which is to install a CA certificate into the
browser's certificate database. So, for instance, one possibility is that
the browser will have a "trusted proxy partition" in its certificate
database and a proxy will only be trusted if its certificate is installed
there. Again, this problem is not solved here.
The harder problems in designing a standard for explicit trusted proxies
are 1) the need for message authentication and integrity, meaning the
browser and server can be confident that the proxy has not tampered with
the data and 2) any node refusal, by which I mean that all actors (browser,
proxy, and server) should both express their intentions and be able to
refuse participation on a per object basis. Three scenarios illustrate the
issue of any node refusal:
1) Web server says no: A cache (or optimizing proxy) improves end user
response times and network utilization. A user will often elect to trust
this proxy, allowing it to view HTTP2S traffic in the clear, in order to
receive the benefit of the optimization. Many content owners will also
allow this, especially when serving publicly accessible content. However,
some content owners (financial institutions, for instance) may not ever
want to allow a proxy to view traffic in the clear, even if the end user
allowed it.
2) Proxy says no: Enterprise anti-malware middleboxes do not want to
allow any traffic to pass into or out of the enterprise that cannot be
examined. In this case, a proxy wants to be able to inform the web server
that it will not pass traffic on to the end user that it cannot see.
3) User/Admin says no: Of course, the obvious scenario is where the user
says no. In this case, we have no trusted proxy.
In order for #1 to be true, allowing a web server to always say no, the
proxy must not be able to run in stealth mode. In order for #2 to be true,
the proxy server must be able to pass an indicator to the web server that
it requires the ability to see all traffic.
*Solution*:
The ideas in James’ Internet Draft Intra-connection
Negotiation<http://www.ietf.org/internet-drafts/draft-snell-httpbis-keynego-01.txt>
create
an opportunity for addressing these two problems. The proposed solution
consists of a) requiring trusted proxies to have their own point-to-point
HTTP2S session with the browser when processing traffic from an HTTP2S
content server and b) establishing an intra-connection, end-to-end, TLS
session using a NULL cipher (no encrypting but still authenticating and
data integrity checking) between browser and web server and using it to
send traffic through a trusted proxy. In this case, the traffic over the
air is encrypted by the point-to-point TLS sessions, while still being
viewable by the proxy, and, at the same time, the browser and web server
can authenticate and validate the integrity of the data and any node can
refuse participation.
The following diagram illustrates the idea:
Browser
Proxy Server
|
| |
|
| |
| 1)Establish HTTP2S (HTTP2 over TLS) session
| |
|<------------------------------------------->|
|
|
| |
| 2)CLIENT_HELLO over HTTP2S
| |
|============================================>|
|
|
| |
| | 3)Establish
HTTP2S session |
|
|<------------------------------------------>|
|
| |
| | 4)Forward
CLIENT_HELLO over HTTP2S |
|
|===========================================>|
| |
|
| | 5)SERVER_HELLO
over HTTP2S |
|
|<===========================================|
|
|
|
| 6)Forward SERVER_HELLO over HTTP2S
| |
|<============================================|
|
|
| |
|
| |
| 7)Complete TLS negotiation, specifying a NULL cipher, across two
HTTP2S sessions |
|<========================================================================================>|
|
| |
|
| |
|
| |
| 8)Unencrypted HTTP2 traffic includes MACs for auth and integrity
validation |
|<========================================================================================>|
Note: the “===” lines indicate a message sent over the Intra-Connection
HTTPS stream, so these are over HTTP2, over the point-to-point TLS
sessions, but they travel end-to-end between browser and server.
Because the browser receives the web browser’s certificate in the
SERVER_HELLO in step 6, it will be able to authenticate the server the same
as it would if the trusted proxy were not present. This removes the problem
of transitive trust caused by MITM proxies. One can imagine the browser
displaying a double lock to indicate that both the proxy and the content
server have certificates that have been authenticated – of course the proxy
needs an additional layer of validation but again we will not go into that
here. The important point is that the proxy is not able to view the traffic
unless the browser trusts it and also unless the browser itself has
authenticated the web server’s cert with its own database of CAs.
Message integrity and authentication between browser and web server prevent
the proxy from operating in stealth mode, where its presence is
undetectable by the web server. The web server can thus refuse to take part
in the trusted proxy session on a per object basis. For instance, requests
for the logo of a financial institution might be allowed to be viewed by a
proxy, but requests for sensitive financial information might be refused. This
is what really separates the proposal from simply standardizing MITM
because it means the web server will always be aware of the presence of the
proxy and because, if it decides to, it can say no. I think this is a
powerful feature and one that legitimate middleboxes should also be in
favor of, as it allows them to express their intention in an above board
way (I would like to optimize this traffic or I must see this traffic in
order to scan it for malware) and to be distinguished from rogue MITMs.
Additionally, the browser will always know when an object was manufactured
by the proxy and it can decide whether or not it wants to use it. For
instance, a proxy might send the browser a cached copy of an object the
browser requested. This cached copy will not contain the MAC proving that
it was generated by the web server so the browser will need to make the
decision whether or not to use this object. Again, in many cases the
browser will agree to because it provides a benefit to the end user.
Lastly, and this is not illustrated in the above drawing, the proxy can
flag the TLS data frames it uploads to the web server to indicate whether
or not it will allow encrypted responses. If not, as might be the case for
a security, malware-detecting appliance, then the web server can decide
whether or not it wants to send the data in a way that the proxy can see.
And, if not, then the user can be messaged that the site is not viewable
with appropriate messaging.
Received on Tuesday, 26 November 2013 22:30:13 UTC