HTTPBis Working Group S. Loreto
Internet-Draft J. Mattsson
Intended status: Standards Track R. Skog
Expires: August 18, 2014 H. Spaak
Ericsson
G. Gus
D. Druta
M. Hafeez
AT&T
February 14, 2014
Explicit Trusted Proxy in HTTP/2.0
draft-loreto-httpbis-trusted-proxy20-01
Abstract
The purpose of this Internet Draft is to continue the discussion on
explicit and trusted proxy as intermediary of HTTP2 traffic.
The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or
without TLS, without any constraints from the standard (see: issue
314).
To distinguish between an HTTP2 connection meant to transport "https"
URIs resources and an HTTP2 connection meant to transport "http" URIs
resource, the draft proposes to
register a new value in the Application Layer Protocol negotiation
(ALPN) Protocol IDs registry specific to signal the usage of HTTP2
to transport "http" URIs resources: h2clr.
This document describes two alternative methods for an user-agent to
automatically discover and for an user to provide consent for a
Trusted Proxy to be securely involved when he or she is requesting an
HTTP URI resource over HTTP2 with TLS. The consent is supposed to be
per network access. The draft also describes the role of the Trusted
Proxy in helping the user to fetch HTTP URIs resource when the user
has provided consent to the Trusted Proxy to be involved.
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-
Loreto, et al. Expires August 18, 2014 [Page 1]
Internet-Draft Trusted Proxy 2.0 February 2014
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 August 18, 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
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.
Loreto, et al. Expires August 18, 2014 [Page 2]
Internet-Draft Trusted Proxy 2.0 February 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Explicit and Trusted Proxy . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. How a Forward Proxy establishes the trust . . . . . . . . . . 6
3.1. Proxy certificate . . . . . . . . . . . . . . . . . . . . 6
3.1.1. TLS Handshake with Proxy certificate . . . . . . . . . 7
3.1.2. Opt Out . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Captive Proxy . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Opt Out . . . . . . . . . . . . . . . . . . . . . . . 11
4. Explicit Proxy behaviour . . . . . . . . . . . . . . . . . . . 12
4.1. Secure Forward Proxy towards HTTP2 origin server . . . . . 13
4.2. Secure Forward Proxy towards HTTP/1.1 Origin Server . . . 14
4.3. Secure Forward Proxy and https URIs . . . . . . . . . . . 15
5. Signalling the presence of a Proxy in between . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Loreto, et al. Expires August 18, 2014 [Page 3]
Internet-Draft Trusted Proxy 2.0 February 2014
1. Introduction
The current (i.e. HTTP/1.1) and previous HTTP protocol versions have
provided room and made it possible to create a Web ecosystem of
various kind of proxies and intermediaries: cache servers, security
gateways, web accelerators, content filters, and many others. In
some cases their presence is explicit (i.e. configured proxies), and
in other they are completely transparent to the end user (i.e.
transparent proxy, reverse proxy).
The success and the presence of those intermediaries is also a
problem for the evolution of the HTTP protocol as the intermediary
behaviour on protocol extension and especially on alternative wire
format of the protocol is not predictable. This not predictable
behaviour can lead to difficulties to deploy a new version of the
protocol before the intermediate are themselves update to support it
(see the difficult in deploying the WebSocket Protocol [RFC6455] in
clear). Relying on establishing an HTTPS tunnel has then become the
popular way to bypass the intermediate proxies as it provides
reliable deployment model for web protocols: the encrypted tunnel
obfuscates the data from all intermediaries.
HTTPS tunnels, while speeding up the deployment, makes it difficult
for a forward proxy and other intermediaries to be used to allow
caching, to provide anonymity to a User-Agent, or to provide security
by using an application-layer firewall to inspect the HTTP traffic on
behalf of the User-Agent (e.g. to protect it against cross-site
scripting attacks). HTTPS tunnels also remove the possibility to
enhance delivery performance based on the knowledge of the network
status, and this become an important limitation especially with HTTP2
when multiple streams are multiplexed on top of the same TCP
connection.
In the presence of HTTPS tunnels the only possibility to have a
trusted intermediary (and still providing confidentiality towards not
trusted elements in the network) is then to have separate TLS
sessions between the User-Agent and the proxy, on one side, and the
proxy and the server on the other side (see Figure 1).
UserAgent Proxy Server
TLS Session #1 TLS Session #2
<------------> <------------->
HTTP
<----------------------------------->
Figure 1: A proxied HTTPS session, with two independent TLS sessions
Several drafts analysing the role and the requirements for proxy have
Loreto, et al. Expires August 18, 2014 [Page 4]
Internet-Draft Trusted Proxy 2.0 February 2014
been submitted:
1. [I-D.nottingham-http-proxy-problem] discusses the use and
configuration of proxies in HTTP, pointing out problems in the
currently deployed Web infrastructure along the way
2. [I-D.vidya-httpbis-explicit-proxy-ps] describes the issues with
HTTP proxies for TLS protected traffic and motivates the need for
explicit proxying capability in HTTP. It also presents the goals
that such a solution would need to satisfy and some example
solution directions.
3. [I-D.rpeon-httpbis-exproxy] describes a method for connecting to
a proxy via a secure channel, allowing, disallowing, and
detecting any transforms that the proxy may perform, and allowing
the proxy to connect via secure channel to another site on the
user's behalf..
Use cases in form of stories for proxies are also listed in the wiki
Proxy-User-Stories [1] and analysed in a matrix form in Trusted Proxy
Use Case Analysis and Alternatives [2].
1.1. Explicit and Trusted Proxy
The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or
without TLS, without any constraints from the standard (see issue
314 [3]), however the role of explicit and trusted proxy as
intermediary in HTTP2 is still to be specified in the standard.
The main aim for this document is to analyse and define the role of
an Explicit and Trusted proxy for HTTP URI resources transported over
HTTP2 with TLS.
To distinguish between an HTTP2 connection meant to transport "https"
URIs resources and an HTTP2 connection meant to transport "http" URIs
resource, the draft proposes to
register a new value in the Application Layer Protocol negotiation
(ALPN) Protocol IDs registry specific to signal the usage of HTTP2
to transport "http" URIs resources: h2clr.
This document describes two alternative methods for an user-agent to
automatically discover and then for an user to provide consent for a
Trusted Proxy to be securely involved when an HTTP URI resource is
requested.
Section 3.1 proposes a solution based on sending a proxy certificate
in the TLS handshake.
Loreto, et al. Expires August 18, 2014 [Page 5]
Internet-Draft Trusted Proxy 2.0 February 2014
Section 3.2 proposes a solution based on the presence of a Captive
Proxy.
The consent is supposed to be per network access.
Section 4 describes the role of the Trusted Proxy in helping the user
to fetch HTTP URIs resource when the user has provided consent to the
Trusted Proxy to be involved.
2. Terminology
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].
This document defines the following terms:
Explicit proxy: an intermediary that explicit signals its presence
to the User-Agent and eventually also to the Origin Server.
Trusted proxy: an intermediary that in order to authenticate itself
provides a proxy certificate issued by a trusted certification
authority, where the root certificate is assumed to be
preinstalled in the User-Agent.
3. How a Forward Proxy establishes the trust
An explicit and trusted proxy is preferable to a transparent MITM
proxy as an intermediary of HTTP2 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 sections describe two mechanisms by which a proxy can
establish trust.
3.1. Proxy certificate
To help HTTP User-Agents identify and distinguish proxies from other
servers (e.g. web servers), a certification authority can issue
special public key certificates to trusted proxies. More
specifically, the certification authority can use the Extended Key
Usage extension as specified in [RFC5280] to indicate a key purpose
"proxyAuthentication" (a new object identifier needs to be assigned
by IANA for this key purpose). The certification authority also
marks this Extended Key Usage extension as critical. As the user
needs to have high trust in the Proxy, the validation procedure for
Loreto, et al. Expires August 18, 2014 [Page 6]
Internet-Draft Trusted Proxy 2.0 February 2014
proxy certificates should be more rigorous than for ordinary SSL
certificates. All proxy certificates should therefore be Extended
Validation (EV) SSL Certificates.
3.1.1. TLS Handshake with Proxy certificate
When a (TLS and HTTP) User-Agent receives a Server Certificate
message, it checks whether the certificate contains an Extended Key
Usage extension and if so whether the "proxyAuthentication" key
purpose id is included. If it is included, the User-Agent concludes
that the certificate belongs to a proxy. It then verifies that the
proxy certificate is a valid EV certificate. The user-agent then
SHOULD secure user consent.
When the user has given consent to the use of a proxy, the User-Agent
SHOULD store this consent so that the user does not have to give
consent for each new TLS connection involving the proxy. The consent
SHOULD be limited to the specific access and MAY be limited to a
single connection to that access or limited in time. How the consent
information is stored is implementation specific, but as a network
may have several proxies (for network resilience) it is RECOMMENDED
that the consent is only tied to the Subject field of the proxy
certificate so that the consent applies to all proxy certificates
with the same name.
If the user has previously given consent to use the specific proxy
and the user-agent has stored that, the user-agent may conclude that
the user has given consent without asking the user again.
If the user provides consent, the User-Agent continues the TLS
handshake with the proxy.
Loreto, et al. Expires August 18, 2014 [Page 7]
Internet-Draft Trusted Proxy 2.0 February 2014
+--------------+ +------------+ +-------------+
| user-agent | | Proxy | | Server |
+--------------+ +------------+ +-------------+
| | |
| | |
| (1) ClientHello | |
|--------------------------->| |
| (ALPN ProtocolName: h2clr) | |
| | |
| | |
| | |
|(2) ServerHello, ServerCert | |
|<---------------------------| |
| (Proxy-specific cert) | |
| | |
| | |
(3) User consent | |
| | |
| (4) Rest of TLS handshake | |
|<-------------------------->| |
| | |
| (5) HTTP2 over TLS |(5) HTTP2 (may be over TLS) |
|<-------------------------->|<---------------------------->|
| | |
| | |
Figure 2: TLS Handshake with Proxy certificate
3.1.2. Opt Out
If the user does not give consent, or decides to opt out from the
proxy for a specific connection, the user-agent will negotiate HTTP2
connection using "h2" value in the Application Layer Protocol
Negotiation (ALPN) extension field. The proxy will then notice that
the TLS connection is to be used for a https resource or for a http
resource for which the user wants to opt out from the proxy. The
proxy will then forward the ClientHello message to the Server and the
TLS connection will be end-to-end between the user-agent and the
Server.
Loreto, et al. Expires August 18, 2014 [Page 8]
Internet-Draft Trusted Proxy 2.0 February 2014
+--------------+ +------------+ +-------------+
| user-agent | | Proxy | | Server |
+--------------+ +------------+ +-------------+
| |
| (1) TLS ClientHello |
|---------------------------------------------------------->|
| (ALPN ProtocolName: h2) |
| |
| (2) ServerHello, ServerCert |
|<----------------------------------------------------------|
| (3) Rest of TLS handshake |
|<--------------------------------------------------------->|
| |
| (4) HTTP 2 over TLS |
|<--------------------------------------------------------->|
| |
Figure 3: Opt Out
3.2. Captive Proxy
The Captive Proxy mechanism suggests that a Secure Proxy may indicate
its presence and identity by intercepting a TLS ClientHello message,
analysing the application layer protocol negotiation extension field
and if it contains "h2clr" value forcing the User-Agent to redirect
to a secure page on a Portal where the user is request to consent to
the presence of the Secure Proxy for all the request towards "http"
URI resources while it stays in that network (see Figure 4).
Loreto, et al. Expires August 18, 2014 [Page 9]
Internet-Draft Trusted Proxy 2.0 February 2014
+--------------+ +------------+ +--------+ +-------------+
| user-agent | | Proxy | | Portal | | Server |
+--------------+ +------------+ +--------+ +-------------+
| | | |
| | | |
| (1) TLS ClientHello \|/ | |
|----------------------------| | |
| (ALPN ProtocolName: h2clr)/|\ | |
| | | |
| (2) GET HTTP/1.1 | | |
|--------------------------->| | |
| (3) 302 | | |
|<---------------------------| | |
| (4) GET HTTPS/1.1 | | |
|------------------------------------------>| |
| (5) 200 | | |
|<------------------------------------------| |
| (6) download certificate+file.pac | |
|<------------------------------------------| |
| (7) GET /1.1 | | |
|--------------------------->|------------------------------>|
| (8) 200 Alternate | | |
|<---------------------------|<------------------------------|
Figure 4: Captive Proxy flow
Figure 4 steps are explained below
(1) A User-Agent that makes a request to an "http" URI without prior
knowledge about support for HTTP2 uses TLS, with the application
level protocol negotiation extension inserting the h2clr tag, to
start the HTTP2 connection. The Proxy intercepts the TLS
ClientHello analyses the application layer protocol negotiation
extension field and if it contains "h2clr" value it blocks the TLS
ClientHello.
(2), (3), (4) The User-Agent receives an TLS Alert (e.g.
unsupported_extension) indicating that that the resource does not
support HTTP2 and it will fall back to HTTP/1.1 and will issue a
GET /1.1. The proxy intercepts the GET and redirects the User-
Agent to a portal secure page.
Note that the portal page is an https URI resource, so that the
user can be sure of the identity of the portal.
Loreto, et al. Expires August 18, 2014 [Page 10]
Internet-Draft Trusted Proxy 2.0 February 2014
(5) When the User-Agent arrives to the portal page it becomes aware
of the existence of a Proxy in the access network and receives a
consent request for the proxy to stay in the path for HTTP URI
resources. The user-agent then SHOULD secure user consent.
When the user has given consent to the use of a proxy, both the
User-Agent and the Proxy SHOULD store this consent so that the
user does not have to give consent for each new TLS connection
involving the proxy.
(6) If the user provides consent, then it will start to download a
certificate identifying the proxy. The proxy certificate should
be issued by a trusted certification authority, where the root
certificate is assumed to be preinstalled in the User-Agent. The
proxy certificate SHOULD be stored in a proxy certificate
repository distinct from the repository for the server
certificates.
The portal page may also offer the possibility to download a
signed (with the proxy certificate) pac file that contains all the
information to automatically configure the proxy in the User-
Agent.
(7) (8) The User-Agent is then forwarded to the origin initially
requested and it receives the requested content, however the Proxy
will insert an Alternate header that will tell the User-Agent to
asynchronously upgrade to HTTP2.
The presence of the pac file or of the proxy certificate for that
access network will automatically configure the User-Agent in the
Proxy mode.
3.2.1. Opt Out
This section specifies how an user can opt out (i.e. refuse) the
presence of a Proxy for all the subsequent requests toward "http" URI
resources while it stays in that network (see Figure 5).
If the user decides to opt out from the proxy, the User-Agent will
start (step 6 in the figure below) to negotiate HTTP2 connection only
using "h2" vale in the Application Layer Protocol Negotiation (ALPN)
extension field, while staying in that access network.
Loreto, et al. Expires August 18, 2014 [Page 11]
Internet-Draft Trusted Proxy 2.0 February 2014
+--------------+ +------------+ +--------+ +-------------+
| user-agent | | Proxy | | Portal | | Server |
+--------------+ +------------+ +--------+ +-------------+
| | | |
| | | |
| (1) TLS ClientHello \|/ | |
|----------------------------| | |
| (ALPN ProtocolName: h2clr)/|\ | |
| | | |
| (2) GET HTTP/1.1 | | |
|--------------------------->| | |
| (3) 302 | | |
|<---------------------------| | |
| (4) GET HTTPS/1.1 | | |
|------------------------------------------>| |
| (5) 200 | | |
|<------------------------------------------| |
| (6) TLS ClientHello |
|----------------------------------------------------------->|
| (ALPN ProtocolName: h2) |
| (7) ServerHello |
|<-----------------------------------------------------------|
| (8) ChangeCipherSpec |
|----------------------------------------------------------->|
| (9) ChangeCipherSpec |
|<-----------------------------------------------------------|
| |
|---(10)-stream(X)---GET------------------------------------>|
| |
|<------------------------(11)--stream(Z)---200 OK-----------|
Figure 5: Proxy Opt Out
4. Explicit Proxy behaviour
This section describes the role of the Trusted Proxy in helping the
user to fetch HTTP URI resources when the user has provided consent
to the Trusted Proxy to be involved.
Loreto, et al. Expires August 18, 2014 [Page 12]
Internet-Draft Trusted Proxy 2.0 February 2014
4.1. Secure Forward Proxy towards HTTP2 origin server
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
(TLS Proxy certificate or Captive proxy) |
(mechanism has taken place) |
| | |
| (1) TLS ClientHello | |
|--------------------------->| |
| (2) ServerHello | |
|<---------------------------| |
| (3) ChangeCipherSpec | |
|--------------------------->| |
| (4) ChangeCipherSpec | |
|<---------------------------| |
| | |
| | |
|/==========HTTP2===========\| |
| | |
|(5)-stream(X)---GET-------->| |
| | (6) TLS ClientHello |
| |----------------------------->|
| | (7) TLS ServerHello |
| |<-----------------------------|
| | (8) ChangeCipherSpec |
| |----------------------------->|
| | (9) ChangeCipherSpec |
| |<-----------------------------|
| | |
| |/=========(HTTP2)============\|
| |-(10)--stream(Z)---GET------->|
| | |
| | |
| |<(11)--stream(Z)---200 OK-----|
|<-(12)--stream(X)---200 OK--| |
| | |
|\========(HTTP2)===========/|\==========(HTTP2)===========/|
| | |
Figure 6: requesting an HTTP resource
Loreto, et al. Expires August 18, 2014 [Page 13]
Internet-Draft Trusted Proxy 2.0 February 2014
(0) The TLS Proxy Announcement (Section 3.1) or Captive Proxy
(Section 3.2) mechanism has already taken place, so the User-Agent
is now configure in the proxy mode.
(1). . .(4) For each "http" URI resource towards a not yet contacted
Server Origin, then the User-Agent negotiates a new TLS session,
using the ALPN extension containing the "h2clr" tag, to establish
an HTTP2 connection.
(5) The User-Agent will then use the streams in the HTTP2 connection
to request any resources hosted on that Origin Server.
(6),(7),(8),(9) In the case the Proxy receives a request for an URI
resource towards a not yet contacted Server Origin, then the
trusted Proxy negotiates a new TLS session, using the ALPN
extension containing the "h2clr" tag, to establish an HTTP2
connection.
(10) Once the Proxy has established the HTTP2 connection toward the
origin, then it picks one stream to forward the request
(11) (12) The Proxy forward the answer it receives from the Origin
Server to the User-Agent.
4.2. Secure Forward Proxy towards HTTP/1.1 Origin Server
In the case the "http" URI resources requested by the user-agent will
be only available over HTTP/1.1 or the proxy does not have a 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 or not it will contact it using HTTP1.1 (see
Figure 7).
Loreto, et al. Expires August 18, 2014 [Page 14]
Internet-Draft Trusted Proxy 2.0 February 2014
+--------------+ +--------------+ +--------------+
| user-agent | | Proxy | | Server |
+--------------+ +--------------+ +--------------+
| | |
(TLS Proxy announcement or Captive proxy) |
(mechanism has taken place) |
| | |
| (1) TLS ClientHello | |
|--------------------------->| |
| (2) ServerHello | |
|<---------------------------| |
| (3) ChangeCipherSpec | |
|--------------------------->| |
| (4) ChangeCipherSpec | |
|<---------------------------| |
| | |
|/--------------------------\| |
|(5)-stream(X)---GET-------->| |
| | |
| HTTP2 |-(6)-------GET /1.1---------->|
| | |
| |<-(7)-------200 OK------------|
|<--(8)--stream(X)---200 OK--| |
| | |
|\--------------------------/| |
| | |
Figure 7: Origin server with only HTTP/1.1 support
4.3. Secure Forward Proxy and https URIs
The Proxy intercepts the TLS ClientHello analyses the application
layer protocol negotiation extension field and if it contains "h2"
value it does not do anything and let the TLS handshake continue and
the TLS session be established between the User-Agent and the Server
(see Figure 8).
Loreto, et al. Expires August 18, 2014 [Page 15]
Internet-Draft Trusted Proxy 2.0 February 2014
+--------------+ +------------+ +--------+ +-------------+
| user-agent | | Proxy | | Portal | | Server |
+--------------+ +------------+ +--------+ +-------------+
| | | |
| | | |
| (1) TLS ClientHello |
|----------------------------------------------------------->|
| (ALPN ProtocolName: h2) |
| (2) ServerHello |
|<-----------------------------------------------------------|
| (3) ChangeCipherSpec |
|----------------------------------------------------------->|
| (4) ChangeCipherSpec |
|<-----------------------------------------------------------|
| |
|---(5)-stream(X)---GET------------------------------------->|
| |
|<-------------------------(6)--stream(X)---200 OK-----------|
Figure 8: Trusted Proxy and HTTPS URI resources
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 User-
Agent on responses.
6. Security Considerations
This document addresses proxies that act as intermediary for HTTP2
traffic and therefore the security and privacy implications of having
those proxies in the path need to be considered. MITM [4],
[I-D.nottingham-http-proxy-problem] and
[I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and
privacy issues associated with the use of proxies. Users should be
made aware that, different than end-to-end HTTPS, the achievable
security level is now also dependent on the security features/
capabilities of the proxy as to what cipher suites it supports, which
root CA certificates it trusts, how it checks certificate revocation
status, etc. Users should also be made aware that the proxy has
visibility to the actual content they exchange with Web servers,
including personal and sensitive information.
By requiring proxy certificates to be extended validation
Loreto, et al. Expires August 18, 2014 [Page 16]
Internet-Draft Trusted Proxy 2.0 February 2014
certificates the barrier to attaining a proxy certificate is
significantly increased. To further increase the security, the
validation by the CA could also include technical details and
processes relevant for the security. The owner could for example be
obliged to apply security patches in a timely fashion.
This document proposes two alternative approaches to making the
presence of proxy explicit to users and letting them decide whether
they accept that. A user can opt out and choose to bypass the proxy.
This ensures that a proxy never acts as intermediary for HTTP2
traffic unless authorized by the user.
When the user has given consent to the presence of the proxy, the
User-Agent switches to a Proxy mode in which it does not check the
hostname of the origin server against the server's identity as
presented in the Server Certificate message. However if any of the
following checks fails the User-Agent should immediately exit this
Proxy mode:
1. the server's certificate is issued by a trusted CA and the
certificate is valid;
2. the Extended Key Usage extension is present in the certificate
and indicates the owner of this certificate is a proxy;
3. the server possesses the private key corresponding to the
certificate.
7. Privacy Considerations
8. IANA Considerations
This document creates a registration for the identification of HTTP2
used to transport "http" URIs resources in the "Application Layer
Protocol Negotiation (ALPN) Protocol IDs" registry established in
[TLSALPN].
Protocol: HTTP2 used to transport "http" URIs resources
Identification Sequence: 0x68 0x32 0x63 0x6C 0x72 ("h2clr")
9. Acknowledgments
The authors wish to thank Yi Cheng, Goran Eriksson, Stefan Hakansson,
Nicolas Mailhot and Salman Taj for their ideas, technical suggestions
Loreto, et al. Expires August 18, 2014 [Page 17]
Internet-Draft Trusted Proxy 2.0 February 2014
and comments.
10. References
10.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",
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.
Loreto, et al. Expires August 18, 2014 [Page 18]
Internet-Draft Trusted Proxy 2.0 February 2014
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
10.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.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011.
URIs
[1] <https://github.com/http2/http2-spec/wiki/Proxy-User-Stories>
[2] <https://github.com/bizzbyster/TrustedProxy/wiki/
Trusted-Proxy-Use-Case-Analysis-and-Alternatives>
[3] <https://github.com/http2/http2-spec/issues/314>
[4] <Jarmoc, J., SSL/TLS Interception Proxies and Transitive Trust,
2012
https://www.grc.com/miscfiles/HTTPS_Interception_Proxies.pdf>
Authors' Addresses
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
John Mattsson
Ericsson
Kista
Sweden
Email: john.mattsson@ericsson.com
Loreto, et al. Expires August 18, 2014 [Page 19]
Internet-Draft Trusted Proxy 2.0 February 2014
Robert Skog
Ericsson
Kista
Sweden
Email: robert.skog@ericsson.com
Hans Spaak
Ericsson
Kista
Sweeden
Email: hans.spaak@ericsson.com
Gus Bourg
AT&T
Phone:
Email:
Dan Druta
AT&T
Phone:
Email: dd5826@att.com
Mohammad Hafeez
AT&T
Phone:
Email: mh2897@att.com
Loreto, et al. Expires August 18, 2014 [Page 20]