HTTPBis Working Group S. Loreto
Internet-Draft J. Mattsson
Intended status: Standards Track R. Skog
Expires: July 14, 2014 H. Spaak
Ericsson
January 10, 2014
Explicit Trusted Proxy in HTTP/2.0
draft-loreto-httpbis-trusted-proxy20-00
Abstract
The purpose of this Internet Draft is to continue the discussion on
explicit and trusted proxy as intermediary of HTTP2S traffic.
This document describes a method for an user agent to automatically
discover, configure a proxy via a secure HTTP2.0 session. The draft
also proposes two alternative mechanisms allowing the presence of
HTTP2.0 secure proxies for TLS protected traffic when an user-agent
is requesting an http resource.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 14, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Loreto, et al. Expires July 14, 2014 [Page 1]
Internet-Draft Trusted Proxy 2.0 January 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. How the Proxy establish the trust . . . . . . . . . . . . . . 3
3.1. TLS Proxy Announcement . . . . . . . . . . . . . . . . . . 3
4. Use Explicit Proxy . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Tunelling . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Flow Control . . . . . . . . . . . . . . . . . . . . . 7
4.1.2. TLS Key Frame . . . . . . . . . . . . . . . . . . . . 7
4.2. Secure Forward Proxy . . . . . . . . . . . . . . . . . . . 8
4.2.1. Secure Forward: contacting HTTPS resource . . . . . . 11
5. Signalling the presence of a Proxy in between . . . . . . . . 13
6. Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Loreto, et al. Expires July 14, 2014 [Page 2]
Internet-Draft Trusted Proxy 2.0 January 2014
1. Introduction
This document describes two mechanisms that allows HTTP2.0 secure
proxies for TLS protected traffic when an user-agent is requesting an
http resource. The proposed solutions are based the first on the
ideas of [I-D.rpeon-httpbis-exproxy], the second on the experience
done while testing the Ericsson 2.0 Proxy draft-06 implementation
with the Chrome browser: this allows the user-agent to connect to the
proxy and then allowing the proxy in turn to connect via a secure
HTTP2.0 session to the origin server on the user-agent's behalf.
Moreover both the mechanisms try to meet the goals listed in
[I-D.vidya-httpbis-explicit-proxy-ps].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Terminology
3. How the Proxy establish the trust
An explicit and trusted proxy is preferable to a transparent MITM
proxy as an intermediary of HTTP2S traffic. However how a proxy is
interposed into a network flow often has great affect on perceptions
of its operation by end users and origin servers.
The following section describe a mechanism by which a proxy can
establish trust.
3.1. TLS Proxy Announcement
The following mechanism suggests that an HTTP Proxy could indicate
its presence and identity by intercepting a TLS ClientHello message
and sending an error message back to the (TLS and HTTP) client (see
Figure 1).
A Client that wishes to setup a HTTP2S connection with an intended
Server tries to setup a TLS connection to the Server by sending a TLS
ClientHello message indicating via the TLS application layer protocol
negotiation (ALPN) that HTTP 2.0 is to be sent over the TLS
connection.
The proxy intercept and does not forward the ClientHello message,
instead it returns a signed error message ("Here be proxies")
containing a certificate identifying the proxy. The error could for
e.g. be sent using the TLS Alert protocol, but this requires
Loreto, et al. Expires July 14, 2014 [Page 3]
Internet-Draft Trusted Proxy 2.0 January 2014
registration of a new error type.
The error message tells the client, or more specifically, the User
Agent (Browser) that a proxy is present and the additional provided
information enables a decision on whether the proxy can be trusted.
How the User Agent make a decision is not describe in this draft.
The proxy certificate should be issued by a trusted certification
authority, where the root certificate is assumed to be preinstalled
in the client. Just like an ordinary TLS server certificate, the
client checks whether the issuer is a trusted CA, whether the
certificate has expired, and ideally, whether the certificate has
been revoked.
TLS Proxy announcement is an automatic operation that does not
require any user configuration in the browser.
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
| | |
| TLS ClientHello \| |
|============================| |
| (ALPN ProtocolName: http) /| |
| | |
| | |
| | |
|/ (TLS Error) | |
|============================| |
|\ (Proxy Cert) | |
Figure 1: TLS Proxy Announcement
4. Use Explicit Proxy
The following two sections describe to alternative solutions to let
an user-agent interwork with the discovered and configured trusted
proxy when it wants to contact an http resource using HTTP2.0. Those
solutions do not change the IP destination address in the flow.
For both the mechanisms, whenever an user-agent wants to contact an
https resource it has to issue a HTTP/2.0 CONNECT method to establish
a tunnel over a single HTTP/2.0 stream to a remote host. Proxy will
then interpret this the same way as HTTP1.1 CONNECT; it will set-up a
tunnel inside the Proxy and all messages that comes on that tunnel
Loreto, et al. Expires July 14, 2014 [Page 4]
Internet-Draft Trusted Proxy 2.0 January 2014
will go through Proxy without any interference.
4.1. Tunelling
This mechanism is based the draft ideas of
[I-D.rpeon-httpbis-exproxy]. The mechanism proposes to tunnel,
within the existing HTTP2S session between the user-agent and the
secure proxy, all the 2.0 requests from the user-agent towards an
http resource on the server.
+-------+
|HTTP2.0|
+-------+
| TLS |
+-------+----+ +------------+ +------------+
| HTTP2.0 | | HTTP2.0 | | HTTP2.0 |
+------------+ +------------+ +------------+
| TLS | | TLS | | TLS |
+------------+ +------------+ +------------+ +------------+
| TCP | | TCP | | TCP | | TCP |
+------------+ +------------+ +------------+ +------------+
| IP | | IP | | IP | | IP |
+------------+ +------------+ +------------+ +------------+
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
| | |
| | |
|/--------------------------\| |
| | |
| HTTP2.0 | |
| | |
|\--------------------------/| |
| | |
Figure 2: protocol stacks and growers-proxy tunnel
In the case where the user-agent has been configured with the proxy
as a trusted-proxy, the user-agent has to establish its own point-to-
point HTTP2S session with trusted proxies (see Figure 2). The point-
to-point HTTP2.0 session is established using TLS with the
application layer protocol negotiation extension. Once TLS
Loreto, et al. Expires July 14, 2014 [Page 5]
Internet-Draft Trusted Proxy 2.0 January 2014
negotiation is complete, both the client and the server send a
connection header (Section 3.5).
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
| | |
| | |
|/--------------------------\| |
| | |
| | |
| HTTP2.0 |/__________HTTP1.1___________\|
|\--------------------------/|\ /|
| | |
Figure 3: contacting an http resource without previous knowledge
If the resource is not an HTTP2.0 resource or the user-agent does not
have a previous knowledge about it, the proxy issues a new HTTP2.0
request thru the proxy without creating a tunnel. The proxy will
then attempt to contact the resource based on its knowledge. If the
proxy does not know if the resource is a HTTP2.0 or not it will
contact it using HTTP1.1 (see Figure 3)
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
| | |
| | |
|/--------------------------\| |
| | |
| | |
|/---------------------------------------------------------\|
streamX | HTTP2.0 |
|\---------------------------------------------------------/|
streamY |:TLS Krypto FRAME | |
|\--------------------------/| |
| | |
Figure 4: contacting an http 2.0 resource
Whenever the user-agent tries to contact an http resource, it knows
to be a 2.0 resource, a tunnelled HTTP2S session will be created
towards the proxy directly with the origin resource (see Figure 4).
Loreto, et al. Expires July 14, 2014 [Page 6]
Internet-Draft Trusted Proxy 2.0 January 2014
The upper part of Figure 2 shows the different protocol stacks in the
user-agent, the server and in the side of the proxy.
The decryption key material should be provided to the proxy
immediately after the tunnel is established, and before any data
traverses the tunnel (see Figure 4).
For the sake of clarity it is worth to note that the decryption key
material will not be provided in the case of an https resource, or in
the scenario where the user-agent decide not to do so.
The tunnelled HTTP2S session uses an endless stream of the HTTP2S
session between the User-agent and the Proxy. DATA frames are used
to carry the tunnelled HTTP2S session. The DATA frame END_STREAM
flag is only set when the user-agent wants to terminate the tunnelled
HTTP2 session.
NOTE: How the user-agent extract the decryption key material from an
TLS session is not standardised and it will be user-agent
implementation specific, unless we want to standardise a new API for
it. Indeed inorder to support the above one would need to modify the
Client's TLS implementation and add two new functions:
1) Function to extract the TLS master or premaster secret. The TLS
specification requires that the premaster secret is deleted right
after the derivation of the master secret, so it's probably best
to use the master secret.
2) A callback function that notifies the HTTP 2.0 layer whenever the
TLS handshake is completed. When this callback occurs the HTTP
2.0 layer calls function (1) above. One could also combine the
two functions.
Adding these two functions in OpenSSL should not be too difficult.
The later versions of OpenSSL already contains a function to similar
to (1) which was was added after RFC 5705 was published. A function
similar to (2) probably also already exists.
4.1.1. Flow Control
ToDo...
4.1.2. TLS Key Frame
( REALLY preliminary... needs more work... ) and thoughts.
The TLS_KEY frame (type=0x11) is used to transport the decryption key
material from the user-agent to the Proxy. of the stream used to
Loreto, et al. Expires July 14, 2014 [Page 7]
Internet-Draft Trusted Proxy 2.0 January 2014
tunnel the HTTP2S session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS-Stream-ID (31) |
+-+-------------------------------------------------------------+
| decryption key material (*) ...
+---------------------------------------------------------------+
Figure 5: TLS_Key_Frame Payload Format
The payload of a TLS_Key_Frame includes a "TLS-Stream-ID". This
unsigned 31-bit integer identifies the stream the endpoint has used
to tunnel the HTTP2S session. The TLS stream identifier MUST be a
valid existing stream sent by the sender
Following the "TLS-Stream-ID" is the decryption key material.
4.2. Secure Forward Proxy
This mechanism proposes to tunnel, within one HTTP2S session between
the user-agent and the secure proxy all the user-agent request
towards the same web server. The proxy then in turn issues a new
request toward the Server establishing a new (or reusing an existing
one) HTTP2S session with the server.
Figure 6 steps are explained below
(1), (2) those initial two steps follow the TLS Proxy announcement
Section 3.1
(3), (4) .. the a TLS session is established between the user-agent
and the Secure Proxy, and the HTTP2.0 session is established using
ALPN.
(5) the user-agent issue a GET versus the Content Provider using the
stream:X of the established HTTP2.0 session with the Secure Proxy.
(6) the Secure Proxy establish in turn a HTTP2.0 session with the
Content Provider.
Loreto, et al. Expires July 14, 2014 [Page 8]
Internet-Draft Trusted Proxy 2.0 January 2014
(7) the Secure Proxy use the stream:Z of the established HTTP2.0
session with the content provider to forward the GET request.
(8) the Content Provider answer the get with the 200 OK using
stream:Z.
(9) the Secure Proxy forward back to the user-agent the 200 OK using
stream:Z.
Loreto, et al. Expires July 14, 2014 [Page 9]
Internet-Draft Trusted Proxy 2.0 January 2014
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
| (1) TLS ClientHello | |
|--------------------------->| |
| (ALPN ProtocolName: http) | |
| | |
| | |
| (2) (TLS Error) | |
|<---------------------------| |
| (Proxy Cert) | |
| | |
|---- | |
| | | |
(inform the user of the SecureProxy) | |
|<--- | |
| (3) TLS ClientHello | |
|--------------------------->| |
| (4) ServerHello | |
|<---------------------------| |
:............................: |
: : |
| | |
|/==========HTTP2.0)========\| |
| | |
|(5)-stream(X)---GET-------->| |
| | (6) TLS ClientHello |
| |----------------------------->|
| | TLS ServerHello |
| |<-----------------------------|
| :..............................:
| | |
| |/=========(HTTP2.0)==========\|
| |-(7)--stream(Z)---GET-------->|
| | |
| | |
| |<(8)--stream(Z)---200 OK------|
|<-(9)--stream(X)---200 OK---| |
| | |
|\========(HTTP2.0)=========/|\==========(HTTP2.0)=========/|
| | |
Figure 6: requesting an HTTP resource
In the case the http resources requested by the user-agent will be
only available over HTTP/1.1 or the user-agent does not have a
Loreto, et al. Expires July 14, 2014 [Page 10]
Internet-Draft Trusted Proxy 2.0 January 2014
previous knowledge about it, the proxy will then attempt to contact
the resource based on its knowledge. If the proxy does not know if
the resource is a HTTP2.0 or not it will contact it using HTTP1.1
(see Figure 7).
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
| | |
| | |
|/--------------------------\| |
| | |
| | |
| HTTP2.0 |/__________HTTP1.1___________\|
|\--------------------------/|\ /|
| | |
Figure 7: rcontacting an http resource without previous knowledge
4.2.1. Secure Forward: contacting HTTPS resource
This section explains how the mechanism works when the user-agent is
trying to contact an HTTPS resource.
Figure 8 steps are explained below
(1), (4) those initial steps are the same of Figure 6
(5) the user-agent issue a CONNECT versus the Proxy using the
stream:X of the established HTTP2.0 session with the Secure Proxy.
The CONNECT method establish a TLS session between the user-agent
and the Server and at same time using ALPN handshake a HTTP2.0
session between the user-agents and the Server.
(6) the user-agent use the stream:Z of the tunnelled HTTP2.0 session
with the content provider to forward the GET request.
(7) the Content Provider answer the get with the 200 OK using
stream:Z.
Loreto, et al. Expires July 14, 2014 [Page 11]
Internet-Draft Trusted Proxy 2.0 January 2014
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
| (1) TLS ClientHello | |
|--------------------------->| |
| (ALPN ProtocolName: http) | |
| | |
| | |
| (2) (TLS Error) | |
|<---------------------------| |
| (Proxy Cert) | |
| | |
|---- | |
| | | |
(inform the user of the SecureProxy) | |
|<--- | |
| (3) TLS ClientHello | |
|--------------------------->| |
| (4) ServerHello | |
|<---------------------------| |
:............................: |
: : |
| | |
|/=========(HTTP2.0)========\| |
| | |
|(5)-stream(X)---CONNECT---->| |
:............................:..............................:
| | |
|/===============(CONNECTED HTTP2.0)=======================\|
stream:X| |
|-(6)---stream(Z)----GET----------------------------------->|
| |
|<----(7)---stream(Z)----200OK----------------------------->|
| |
|\=========================================================/|
| | |
| | |
|\========(HTTP2.0)=========/| |
| | |
Figure 8: requesting an HTTPS resource
Loreto, et al. Expires July 14, 2014 [Page 12]
Internet-Draft Trusted Proxy 2.0 January 2014
5. Signalling the presence of a Proxy in between
The Via general-header field MUST be used by the user-agent to
indicate the presence of the secure proxy between the user agent and
the server on requests, and between the origin server and the client
on responses.
6. Cache
ToDo..
7. Acknowledgments
The authors wish to thank Gus Bourg, Mohammad Hafeez and Salaman Taj
for their comments and technical suggestions.
8. References
8.1. Normative References
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., Thomson, M., and A. Melnikov,
"Hypertext Transfer Protocol version 2.0",
draft-ietf-httpbis-http2-08 (work in progress),
November 2013.
[I-D.ietf-httpbis-p1-messaging]
Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-24 (work in progress),
September 2013.
[I-D.nottingham-http-proxy-problem]
Nottingham, M., "Problems with Proxies in HTTP",
draft-nottingham-http-proxy-problem-00 (work in progress),
October 2013.
[I-D.rpeon-httpbis-exproxy]
Peon, R., "Explicit Proxies for HTTP/2.0",
draft-rpeon-httpbis-exproxy-00 (work in progress),
June 2012.
[I-D.vidya-httpbis-explicit-proxy-ps]
Narayanan, V., "Explicit Proxying in HTTP - Problem
Statement And Goals",
Loreto, et al. Expires July 14, 2014 [Page 13]
Internet-Draft Trusted Proxy 2.0 January 2014
draft-vidya-httpbis-explicit-proxy-ps-00 (work in
progress), October 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
8.2. Informative References
[RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
Authors' Addresses
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
John Mattsson
Ericsson
Kista
Sweeden
Email: robert.skog@ericsson.com
Loreto, et al. Expires July 14, 2014 [Page 14]
Internet-Draft Trusted Proxy 2.0 January 2014
Robert Skog
Ericsson
Kista
Sweeden
Email: robert.skog@ericsson.com
Hans Spaak
Ericsson
Kista
Sweeden
Email: hans.spaak@ericsson.com
Loreto, et al. Expires July 14, 2014 [Page 15]