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]