idnits 2.17.1 draft-loreto-httpbis-trusted-proxy20-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TLSALPN' is mentioned on line 662, but not defined == Unused Reference: 'I-D.ietf-httpbis-http2' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-p1-messaging' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'RFC2616' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC2817' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 716, but no explicit reference was found in the text == Unused Reference: 'RFC3040' is defined on line 727, but no explicit reference was found in the text == Unused Reference: 'RFC4732' is defined on line 730, but no explicit reference was found in the text == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-24 == Outdated reference: A later version (-01) exists of draft-nottingham-http-proxy-problem-00 ** Downref: Normative reference to an Informational draft: draft-nottingham-http-proxy-problem (ref. 'I-D.nottingham-http-proxy-problem') ** Downref: Normative reference to an Informational draft: draft-rpeon-httpbis-exproxy (ref. 'I-D.rpeon-httpbis-exproxy') ** Downref: Normative reference to an Informational draft: draft-vidya-httpbis-explicit-proxy-ps (ref. 'I-D.vidya-httpbis-explicit-proxy-ps') ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPBis Working Group S. Loreto 3 Internet-Draft J. Mattsson 4 Intended status: Standards Track R. Skog 5 Expires: August 18, 2014 H. Spaak 6 Ericsson 7 G. Gus 8 D. Druta 9 M. Hafeez 10 AT&T 11 February 14, 2014 13 Explicit Trusted Proxy in HTTP/2.0 14 draft-loreto-httpbis-trusted-proxy20-01 16 Abstract 18 The purpose of this Internet Draft is to continue the discussion on 19 explicit and trusted proxy as intermediary of HTTP2 traffic. 21 The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or 22 without TLS, without any constraints from the standard (see: issue 23 314). 25 To distinguish between an HTTP2 connection meant to transport "https" 26 URIs resources and an HTTP2 connection meant to transport "http" URIs 27 resource, the draft proposes to 29 register a new value in the Application Layer Protocol negotiation 30 (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 31 to transport "http" URIs resources: h2clr. 33 This document describes two alternative methods for an user-agent to 34 automatically discover and for an user to provide consent for a 35 Trusted Proxy to be securely involved when he or she is requesting an 36 HTTP URI resource over HTTP2 with TLS. The consent is supposed to be 37 per network access. The draft also describes the role of the Trusted 38 Proxy in helping the user to fetch HTTP URIs resource when the user 39 has provided consent to the Trusted Proxy to be involved. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on August 18, 2014. 58 Copyright Notice 60 Copyright (c) 2014 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Explicit and Trusted Proxy . . . . . . . . . . . . . . . . 5 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. How a Forward Proxy establishes the trust . . . . . . . . . . 6 79 3.1. Proxy certificate . . . . . . . . . . . . . . . . . . . . 6 80 3.1.1. TLS Handshake with Proxy certificate . . . . . . . . . 7 81 3.1.2. Opt Out . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.2. Captive Proxy . . . . . . . . . . . . . . . . . . . . . . 9 83 3.2.1. Opt Out . . . . . . . . . . . . . . . . . . . . . . . 11 84 4. Explicit Proxy behaviour . . . . . . . . . . . . . . . . . . . 12 85 4.1. Secure Forward Proxy towards HTTP2 origin server . . . . . 13 86 4.2. Secure Forward Proxy towards HTTP/1.1 Origin Server . . . 14 87 4.3. Secure Forward Proxy and https URIs . . . . . . . . . . . 15 88 5. Signalling the presence of a Proxy in between . . . . . . . . 16 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 17 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 The current (i.e. HTTP/1.1) and previous HTTP protocol versions have 101 provided room and made it possible to create a Web ecosystem of 102 various kind of proxies and intermediaries: cache servers, security 103 gateways, web accelerators, content filters, and many others. In 104 some cases their presence is explicit (i.e. configured proxies), and 105 in other they are completely transparent to the end user (i.e. 106 transparent proxy, reverse proxy). 108 The success and the presence of those intermediaries is also a 109 problem for the evolution of the HTTP protocol as the intermediary 110 behaviour on protocol extension and especially on alternative wire 111 format of the protocol is not predictable. This not predictable 112 behaviour can lead to difficulties to deploy a new version of the 113 protocol before the intermediate are themselves update to support it 114 (see the difficult in deploying the WebSocket Protocol [RFC6455] in 115 clear). Relying on establishing an HTTPS tunnel has then become the 116 popular way to bypass the intermediate proxies as it provides 117 reliable deployment model for web protocols: the encrypted tunnel 118 obfuscates the data from all intermediaries. 120 HTTPS tunnels, while speeding up the deployment, makes it difficult 121 for a forward proxy and other intermediaries to be used to allow 122 caching, to provide anonymity to a User-Agent, or to provide security 123 by using an application-layer firewall to inspect the HTTP traffic on 124 behalf of the User-Agent (e.g. to protect it against cross-site 125 scripting attacks). HTTPS tunnels also remove the possibility to 126 enhance delivery performance based on the knowledge of the network 127 status, and this become an important limitation especially with HTTP2 128 when multiple streams are multiplexed on top of the same TCP 129 connection. 131 In the presence of HTTPS tunnels the only possibility to have a 132 trusted intermediary (and still providing confidentiality towards not 133 trusted elements in the network) is then to have separate TLS 134 sessions between the User-Agent and the proxy, on one side, and the 135 proxy and the server on the other side (see Figure 1). 137 UserAgent Proxy Server 138 TLS Session #1 TLS Session #2 139 <------------> <-------------> 140 HTTP 141 <-----------------------------------> 143 Figure 1: A proxied HTTPS session, with two independent TLS sessions 145 Several drafts analysing the role and the requirements for proxy have 146 been submitted: 148 1. [I-D.nottingham-http-proxy-problem] discusses the use and 149 configuration of proxies in HTTP, pointing out problems in the 150 currently deployed Web infrastructure along the way 152 2. [I-D.vidya-httpbis-explicit-proxy-ps] describes the issues with 153 HTTP proxies for TLS protected traffic and motivates the need for 154 explicit proxying capability in HTTP. It also presents the goals 155 that such a solution would need to satisfy and some example 156 solution directions. 158 3. [I-D.rpeon-httpbis-exproxy] describes a method for connecting to 159 a proxy via a secure channel, allowing, disallowing, and 160 detecting any transforms that the proxy may perform, and allowing 161 the proxy to connect via secure channel to another site on the 162 user's behalf.. 164 Use cases in form of stories for proxies are also listed in the wiki 165 Proxy-User-Stories [1] and analysed in a matrix form in Trusted Proxy 166 Use Case Analysis and Alternatives [2]. 168 1.1. Explicit and Trusted Proxy 170 The httpbis wg has agreed on the HTTP2 usage with HTTP URIs, with or 171 without TLS, without any constraints from the standard (see issue 172 314 [3]), however the role of explicit and trusted proxy as 173 intermediary in HTTP2 is still to be specified in the standard. 175 The main aim for this document is to analyse and define the role of 176 an Explicit and Trusted proxy for HTTP URI resources transported over 177 HTTP2 with TLS. 179 To distinguish between an HTTP2 connection meant to transport "https" 180 URIs resources and an HTTP2 connection meant to transport "http" URIs 181 resource, the draft proposes to 183 register a new value in the Application Layer Protocol negotiation 184 (ALPN) Protocol IDs registry specific to signal the usage of HTTP2 185 to transport "http" URIs resources: h2clr. 187 This document describes two alternative methods for an user-agent to 188 automatically discover and then for an user to provide consent for a 189 Trusted Proxy to be securely involved when an HTTP URI resource is 190 requested. 192 Section 3.1 proposes a solution based on sending a proxy certificate 193 in the TLS handshake. 195 Section 3.2 proposes a solution based on the presence of a Captive 196 Proxy. 198 The consent is supposed to be per network access. 200 Section 4 describes the role of the Trusted Proxy in helping the user 201 to fetch HTTP URIs resource when the user has provided consent to the 202 Trusted Proxy to be involved. 204 2. Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 This document defines the following terms: 212 Explicit proxy: an intermediary that explicit signals its presence 213 to the User-Agent and eventually also to the Origin Server. 215 Trusted proxy: an intermediary that in order to authenticate itself 216 provides a proxy certificate issued by a trusted certification 217 authority, where the root certificate is assumed to be 218 preinstalled in the User-Agent. 220 3. How a Forward Proxy establishes the trust 222 An explicit and trusted proxy is preferable to a transparent MITM 223 proxy as an intermediary of HTTP2 traffic. However how a proxy is 224 interposed into a network flow often has great affect on perceptions 225 of its operation by end users and origin servers. 227 The following sections describe two mechanisms by which a proxy can 228 establish trust. 230 3.1. Proxy certificate 232 To help HTTP User-Agents identify and distinguish proxies from other 233 servers (e.g. web servers), a certification authority can issue 234 special public key certificates to trusted proxies. More 235 specifically, the certification authority can use the Extended Key 236 Usage extension as specified in [RFC5280] to indicate a key purpose 237 "proxyAuthentication" (a new object identifier needs to be assigned 238 by IANA for this key purpose). The certification authority also 239 marks this Extended Key Usage extension as critical. As the user 240 needs to have high trust in the Proxy, the validation procedure for 241 proxy certificates should be more rigorous than for ordinary SSL 242 certificates. All proxy certificates should therefore be Extended 243 Validation (EV) SSL Certificates. 245 3.1.1. TLS Handshake with Proxy certificate 247 When a (TLS and HTTP) User-Agent receives a Server Certificate 248 message, it checks whether the certificate contains an Extended Key 249 Usage extension and if so whether the "proxyAuthentication" key 250 purpose id is included. If it is included, the User-Agent concludes 251 that the certificate belongs to a proxy. It then verifies that the 252 proxy certificate is a valid EV certificate. The user-agent then 253 SHOULD secure user consent. 255 When the user has given consent to the use of a proxy, the User-Agent 256 SHOULD store this consent so that the user does not have to give 257 consent for each new TLS connection involving the proxy. The consent 258 SHOULD be limited to the specific access and MAY be limited to a 259 single connection to that access or limited in time. How the consent 260 information is stored is implementation specific, but as a network 261 may have several proxies (for network resilience) it is RECOMMENDED 262 that the consent is only tied to the Subject field of the proxy 263 certificate so that the consent applies to all proxy certificates 264 with the same name. 266 If the user has previously given consent to use the specific proxy 267 and the user-agent has stored that, the user-agent may conclude that 268 the user has given consent without asking the user again. 270 If the user provides consent, the User-Agent continues the TLS 271 handshake with the proxy. 273 +--------------+ +------------+ +-------------+ 274 | user-agent | | Proxy | | Server | 275 +--------------+ +------------+ +-------------+ 276 | | | 277 | | | 278 | (1) ClientHello | | 279 |--------------------------->| | 280 | (ALPN ProtocolName: h2clr) | | 281 | | | 282 | | | 283 | | | 284 |(2) ServerHello, ServerCert | | 285 |<---------------------------| | 286 | (Proxy-specific cert) | | 287 | | | 288 | | | 289 (3) User consent | | 290 | | | 291 | (4) Rest of TLS handshake | | 292 |<-------------------------->| | 293 | | | 294 | (5) HTTP2 over TLS |(5) HTTP2 (may be over TLS) | 295 |<-------------------------->|<---------------------------->| 296 | | | 297 | | | 299 Figure 2: TLS Handshake with Proxy certificate 301 3.1.2. Opt Out 303 If the user does not give consent, or decides to opt out from the 304 proxy for a specific connection, the user-agent will negotiate HTTP2 305 connection using "h2" value in the Application Layer Protocol 306 Negotiation (ALPN) extension field. The proxy will then notice that 307 the TLS connection is to be used for a https resource or for a http 308 resource for which the user wants to opt out from the proxy. The 309 proxy will then forward the ClientHello message to the Server and the 310 TLS connection will be end-to-end between the user-agent and the 311 Server. 313 +--------------+ +------------+ +-------------+ 314 | user-agent | | Proxy | | Server | 315 +--------------+ +------------+ +-------------+ 316 | | 317 | (1) TLS ClientHello | 318 |---------------------------------------------------------->| 319 | (ALPN ProtocolName: h2) | 320 | | 321 | (2) ServerHello, ServerCert | 322 |<----------------------------------------------------------| 323 | (3) Rest of TLS handshake | 324 |<--------------------------------------------------------->| 325 | | 326 | (4) HTTP 2 over TLS | 327 |<--------------------------------------------------------->| 328 | | 330 Figure 3: Opt Out 332 3.2. Captive Proxy 334 The Captive Proxy mechanism suggests that a Secure Proxy may indicate 335 its presence and identity by intercepting a TLS ClientHello message, 336 analysing the application layer protocol negotiation extension field 337 and if it contains "h2clr" value forcing the User-Agent to redirect 338 to a secure page on a Portal where the user is request to consent to 339 the presence of the Secure Proxy for all the request towards "http" 340 URI resources while it stays in that network (see Figure 4). 342 +--------------+ +------------+ +--------+ +-------------+ 343 | user-agent | | Proxy | | Portal | | Server | 344 +--------------+ +------------+ +--------+ +-------------+ 345 | | | | 346 | | | | 347 | (1) TLS ClientHello \|/ | | 348 |----------------------------| | | 349 | (ALPN ProtocolName: h2clr)/|\ | | 350 | | | | 351 | (2) GET HTTP/1.1 | | | 352 |--------------------------->| | | 353 | (3) 302 | | | 354 |<---------------------------| | | 355 | (4) GET HTTPS/1.1 | | | 356 |------------------------------------------>| | 357 | (5) 200 | | | 358 |<------------------------------------------| | 359 | (6) download certificate+file.pac | | 360 |<------------------------------------------| | 361 | (7) GET /1.1 | | | 362 |--------------------------->|------------------------------>| 363 | (8) 200 Alternate | | | 364 |<---------------------------|<------------------------------| 366 Figure 4: Captive Proxy flow 368 Figure 4 steps are explained below 370 (1) A User-Agent that makes a request to an "http" URI without prior 371 knowledge about support for HTTP2 uses TLS, with the application 372 level protocol negotiation extension inserting the h2clr tag, to 373 start the HTTP2 connection. The Proxy intercepts the TLS 374 ClientHello analyses the application layer protocol negotiation 375 extension field and if it contains "h2clr" value it blocks the TLS 376 ClientHello. 378 (2), (3), (4) The User-Agent receives an TLS Alert (e.g. 379 unsupported_extension) indicating that that the resource does not 380 support HTTP2 and it will fall back to HTTP/1.1 and will issue a 381 GET /1.1. The proxy intercepts the GET and redirects the User- 382 Agent to a portal secure page. 384 Note that the portal page is an https URI resource, so that the 385 user can be sure of the identity of the portal. 387 (5) When the User-Agent arrives to the portal page it becomes aware 388 of the existence of a Proxy in the access network and receives a 389 consent request for the proxy to stay in the path for HTTP URI 390 resources. The user-agent then SHOULD secure user consent. 392 When the user has given consent to the use of a proxy, both the 393 User-Agent and the Proxy SHOULD store this consent so that the 394 user does not have to give consent for each new TLS connection 395 involving the proxy. 397 (6) If the user provides consent, then it will start to download a 398 certificate identifying the proxy. The proxy certificate should 399 be issued by a trusted certification authority, where the root 400 certificate is assumed to be preinstalled in the User-Agent. The 401 proxy certificate SHOULD be stored in a proxy certificate 402 repository distinct from the repository for the server 403 certificates. 405 The portal page may also offer the possibility to download a 406 signed (with the proxy certificate) pac file that contains all the 407 information to automatically configure the proxy in the User- 408 Agent. 410 (7) (8) The User-Agent is then forwarded to the origin initially 411 requested and it receives the requested content, however the Proxy 412 will insert an Alternate header that will tell the User-Agent to 413 asynchronously upgrade to HTTP2. 415 The presence of the pac file or of the proxy certificate for that 416 access network will automatically configure the User-Agent in the 417 Proxy mode. 419 3.2.1. Opt Out 421 This section specifies how an user can opt out (i.e. refuse) the 422 presence of a Proxy for all the subsequent requests toward "http" URI 423 resources while it stays in that network (see Figure 5). 425 If the user decides to opt out from the proxy, the User-Agent will 426 start (step 6 in the figure below) to negotiate HTTP2 connection only 427 using "h2" vale in the Application Layer Protocol Negotiation (ALPN) 428 extension field, while staying in that access network. 430 +--------------+ +------------+ +--------+ +-------------+ 431 | user-agent | | Proxy | | Portal | | Server | 432 +--------------+ +------------+ +--------+ +-------------+ 433 | | | | 434 | | | | 435 | (1) TLS ClientHello \|/ | | 436 |----------------------------| | | 437 | (ALPN ProtocolName: h2clr)/|\ | | 438 | | | | 439 | (2) GET HTTP/1.1 | | | 440 |--------------------------->| | | 441 | (3) 302 | | | 442 |<---------------------------| | | 443 | (4) GET HTTPS/1.1 | | | 444 |------------------------------------------>| | 445 | (5) 200 | | | 446 |<------------------------------------------| | 447 | (6) TLS ClientHello | 448 |----------------------------------------------------------->| 449 | (ALPN ProtocolName: h2) | 450 | (7) ServerHello | 451 |<-----------------------------------------------------------| 452 | (8) ChangeCipherSpec | 453 |----------------------------------------------------------->| 454 | (9) ChangeCipherSpec | 455 |<-----------------------------------------------------------| 456 | | 457 |---(10)-stream(X)---GET------------------------------------>| 458 | | 459 |<------------------------(11)--stream(Z)---200 OK-----------| 461 Figure 5: Proxy Opt Out 463 4. Explicit Proxy behaviour 465 This section describes the role of the Trusted Proxy in helping the 466 user to fetch HTTP URI resources when the user has provided consent 467 to the Trusted Proxy to be involved. 469 4.1. Secure Forward Proxy towards HTTP2 origin server 471 +--------------+ +--------------+ +--------------+ 472 | user-agent | | Proxy | | Server | 473 +--------------+ +--------------+ +--------------+ 474 | | | 475 (TLS Proxy certificate or Captive proxy) | 476 (mechanism has taken place) | 477 | | | 478 | (1) TLS ClientHello | | 479 |--------------------------->| | 480 | (2) ServerHello | | 481 |<---------------------------| | 482 | (3) ChangeCipherSpec | | 483 |--------------------------->| | 484 | (4) ChangeCipherSpec | | 485 |<---------------------------| | 486 | | | 487 | | | 488 |/==========HTTP2===========\| | 489 | | | 490 |(5)-stream(X)---GET-------->| | 491 | | (6) TLS ClientHello | 492 | |----------------------------->| 493 | | (7) TLS ServerHello | 494 | |<-----------------------------| 495 | | (8) ChangeCipherSpec | 496 | |----------------------------->| 497 | | (9) ChangeCipherSpec | 498 | |<-----------------------------| 499 | | | 500 | |/=========(HTTP2)============\| 501 | |-(10)--stream(Z)---GET------->| 502 | | | 503 | | | 504 | |<(11)--stream(Z)---200 OK-----| 505 |<-(12)--stream(X)---200 OK--| | 506 | | | 507 |\========(HTTP2)===========/|\==========(HTTP2)===========/| 508 | | | 510 Figure 6: requesting an HTTP resource 512 (0) The TLS Proxy Announcement (Section 3.1) or Captive Proxy 513 (Section 3.2) mechanism has already taken place, so the User-Agent 514 is now configure in the proxy mode. 516 (1). . .(4) For each "http" URI resource towards a not yet contacted 517 Server Origin, then the User-Agent negotiates a new TLS session, 518 using the ALPN extension containing the "h2clr" tag, to establish 519 an HTTP2 connection. 521 (5) The User-Agent will then use the streams in the HTTP2 connection 522 to request any resources hosted on that Origin Server. 524 (6),(7),(8),(9) In the case the Proxy receives a request for an URI 525 resource towards a not yet contacted Server Origin, then the 526 trusted Proxy negotiates a new TLS session, using the ALPN 527 extension containing the "h2clr" tag, to establish an HTTP2 528 connection. 530 (10) Once the Proxy has established the HTTP2 connection toward the 531 origin, then it picks one stream to forward the request 533 (11) (12) The Proxy forward the answer it receives from the Origin 534 Server to the User-Agent. 536 4.2. Secure Forward Proxy towards HTTP/1.1 Origin Server 538 In the case the "http" URI resources requested by the user-agent will 539 be only available over HTTP/1.1 or the proxy does not have a previous 540 knowledge about it, the proxy will then attempt to contact the 541 resource based on its knowledge. If the proxy does not know if the 542 resource is a HTTP2 or not it will contact it using HTTP1.1 (see 543 Figure 7). 545 +--------------+ +--------------+ +--------------+ 546 | user-agent | | Proxy | | Server | 547 +--------------+ +--------------+ +--------------+ 548 | | | 549 (TLS Proxy announcement or Captive proxy) | 550 (mechanism has taken place) | 551 | | | 552 | (1) TLS ClientHello | | 553 |--------------------------->| | 554 | (2) ServerHello | | 555 |<---------------------------| | 556 | (3) ChangeCipherSpec | | 557 |--------------------------->| | 558 | (4) ChangeCipherSpec | | 559 |<---------------------------| | 560 | | | 561 |/--------------------------\| | 562 |(5)-stream(X)---GET-------->| | 563 | | | 564 | HTTP2 |-(6)-------GET /1.1---------->| 565 | | | 566 | |<-(7)-------200 OK------------| 567 |<--(8)--stream(X)---200 OK--| | 568 | | | 569 |\--------------------------/| | 570 | | | 572 Figure 7: Origin server with only HTTP/1.1 support 574 4.3. Secure Forward Proxy and https URIs 576 The Proxy intercepts the TLS ClientHello analyses the application 577 layer protocol negotiation extension field and if it contains "h2" 578 value it does not do anything and let the TLS handshake continue and 579 the TLS session be established between the User-Agent and the Server 580 (see Figure 8). 582 +--------------+ +------------+ +--------+ +-------------+ 583 | user-agent | | Proxy | | Portal | | Server | 584 +--------------+ +------------+ +--------+ +-------------+ 585 | | | | 586 | | | | 587 | (1) TLS ClientHello | 588 |----------------------------------------------------------->| 589 | (ALPN ProtocolName: h2) | 590 | (2) ServerHello | 591 |<-----------------------------------------------------------| 592 | (3) ChangeCipherSpec | 593 |----------------------------------------------------------->| 594 | (4) ChangeCipherSpec | 595 |<-----------------------------------------------------------| 596 | | 597 |---(5)-stream(X)---GET------------------------------------->| 598 | | 599 |<-------------------------(6)--stream(X)---200 OK-----------| 601 Figure 8: Trusted Proxy and HTTPS URI resources 603 5. Signalling the presence of a Proxy in between 605 The Via general-header field MUST be used by the user-agent to 606 indicate the presence of the secure proxy between the User-Agent and 607 the server on requests, and between the origin server and the User- 608 Agent on responses. 610 6. Security Considerations 612 This document addresses proxies that act as intermediary for HTTP2 613 traffic and therefore the security and privacy implications of having 614 those proxies in the path need to be considered. MITM [4], 615 [I-D.nottingham-http-proxy-problem] and 616 [I-D.vidya-httpbis-explicit-proxy-ps] discuss various security and 617 privacy issues associated with the use of proxies. Users should be 618 made aware that, different than end-to-end HTTPS, the achievable 619 security level is now also dependent on the security features/ 620 capabilities of the proxy as to what cipher suites it supports, which 621 root CA certificates it trusts, how it checks certificate revocation 622 status, etc. Users should also be made aware that the proxy has 623 visibility to the actual content they exchange with Web servers, 624 including personal and sensitive information. 626 By requiring proxy certificates to be extended validation 627 certificates the barrier to attaining a proxy certificate is 628 significantly increased. To further increase the security, the 629 validation by the CA could also include technical details and 630 processes relevant for the security. The owner could for example be 631 obliged to apply security patches in a timely fashion. 633 This document proposes two alternative approaches to making the 634 presence of proxy explicit to users and letting them decide whether 635 they accept that. A user can opt out and choose to bypass the proxy. 636 This ensures that a proxy never acts as intermediary for HTTP2 637 traffic unless authorized by the user. 639 When the user has given consent to the presence of the proxy, the 640 User-Agent switches to a Proxy mode in which it does not check the 641 hostname of the origin server against the server's identity as 642 presented in the Server Certificate message. However if any of the 643 following checks fails the User-Agent should immediately exit this 644 Proxy mode: 646 1. the server's certificate is issued by a trusted CA and the 647 certificate is valid; 649 2. the Extended Key Usage extension is present in the certificate 650 and indicates the owner of this certificate is a proxy; 652 3. the server possesses the private key corresponding to the 653 certificate. 655 7. Privacy Considerations 657 8. IANA Considerations 659 This document creates a registration for the identification of HTTP2 660 used to transport "http" URIs resources in the "Application Layer 661 Protocol Negotiation (ALPN) Protocol IDs" registry established in 662 [TLSALPN]. 664 Protocol: HTTP2 used to transport "http" URIs resources 666 Identification Sequence: 0x68 0x32 0x63 0x6C 0x72 ("h2clr") 668 9. Acknowledgments 670 The authors wish to thank Yi Cheng, Goran Eriksson, Stefan Hakansson, 671 Nicolas Mailhot and Salman Taj for their ideas, technical suggestions 672 and comments. 674 10. References 676 10.1. Normative References 678 [I-D.ietf-httpbis-http2] 679 Belshe, M., Peon, R., Thomson, M., and A. Melnikov, 680 "Hypertext Transfer Protocol version 2.0", 681 draft-ietf-httpbis-http2-08 (work in progress), 682 November 2013. 684 [I-D.ietf-httpbis-p1-messaging] 685 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 686 (HTTP/1.1): Message Syntax and Routing", 687 draft-ietf-httpbis-p1-messaging-24 (work in progress), 688 September 2013. 690 [I-D.nottingham-http-proxy-problem] 691 Nottingham, M., "Problems with Proxies in HTTP", 692 draft-nottingham-http-proxy-problem-00 (work in progress), 693 October 2013. 695 [I-D.rpeon-httpbis-exproxy] 696 Peon, R., "Explicit Proxies for HTTP/2.0", 697 draft-rpeon-httpbis-exproxy-00 (work in progress), 698 June 2012. 700 [I-D.vidya-httpbis-explicit-proxy-ps] 701 Narayanan, V., "Explicit Proxying in HTTP - Problem 702 Statement And Goals", 703 draft-vidya-httpbis-explicit-proxy-ps-00 (work in 704 progress), October 2013. 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, March 1997. 709 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 710 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 711 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 713 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 714 HTTP/1.1", RFC 2817, May 2000. 716 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 717 Resource Identifier (URI): Generic Syntax", STD 66, 718 RFC 3986, January 2005. 720 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 721 Housley, R., and W. Polk, "Internet X.509 Public Key 722 Infrastructure Certificate and Certificate Revocation List 723 (CRL) Profile", RFC 5280, May 2008. 725 10.2. Informative References 727 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 728 Replication and Caching Taxonomy", RFC 3040, January 2001. 730 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 731 Service Considerations", RFC 4732, December 2006. 733 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 734 RFC 6455, December 2011. 736 URIs 738 [1] 740 [2] 743 [3] 745 [4] 749 Authors' Addresses 751 Salvatore Loreto 752 Ericsson 753 Hirsalantie 11 754 Jorvas 02420 755 Finland 757 Email: salvatore.loreto@ericsson.com 759 John Mattsson 760 Ericsson 761 Kista 762 Sweden 764 Email: john.mattsson@ericsson.com 765 Robert Skog 766 Ericsson 767 Kista 768 Sweden 770 Email: robert.skog@ericsson.com 772 Hans Spaak 773 Ericsson 774 Kista 775 Sweeden 777 Email: hans.spaak@ericsson.com 779 Gus Bourg 780 AT&T 782 Phone: 783 Email: 785 Dan Druta 786 AT&T 788 Phone: 789 Email: dd5826@att.com 791 Mohammad Hafeez 792 AT&T 794 Phone: 795 Email: mh2897@att.com