idnits 2.17.1 draft-nottingham-http-proxy-problem-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-24 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft October 15, 2013 4 Intended status: Informational 5 Expires: April 18, 2014 7 Problems with Proxies in HTTP 8 draft-nottingham-http-proxy-problem-00 10 Abstract 12 This document discusses the use and configuration of proxies in HTTP, 13 pointing out problems in the currently deployed Web infrastructure 14 along the way. It then offers a few principles to base further 15 discussion upon, and lists some potential avenues for further 16 exploration. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 18, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 54 2. Why Proxy? . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Application Layer Gatewaying . . . . . . . . . . . . . . . 4 56 2.2. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Network Policy Enforcement . . . . . . . . . . . . . . . . 4 58 2.4. Content Filtering (a.k.a. Content Policy Enforcement) . . 5 59 2.5. Content Modification . . . . . . . . . . . . . . . . . . . 5 60 3. How Proxies are Interposed . . . . . . . . . . . . . . . . . . 6 61 3.1. Manual Configuration . . . . . . . . . . . . . . . . . . . 6 62 3.2. proxy.pac and WPAD . . . . . . . . . . . . . . . . . . . . 6 63 3.3. Interception . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.4. Configuration As Side Effect . . . . . . . . . . . . . . . 8 65 4. Second-Order Effects of Proxy Deployment . . . . . . . . . . . 8 66 4.1. Proxies and HTTP . . . . . . . . . . . . . . . . . . . . . 8 67 4.2. Proxies and TLS . . . . . . . . . . . . . . . . . . . . . 8 68 5. Principles for Consideration . . . . . . . . . . . . . . . . . 9 69 5.1. Proxies Have a Legitimate Place . . . . . . . . . . . . . 10 70 5.2. Security Should be Encouraged . . . . . . . . . . . . . . 10 71 5.3. Interoperability is Important Too . . . . . . . . . . . . 10 72 5.4. Users Need to be Informed of Proxies . . . . . . . . . . . 10 73 5.5. Users Need to be able to Tunnel through Proxies . . . . . 10 74 5.6. Proxies Can say "No" . . . . . . . . . . . . . . . . . . . 11 75 5.7. Changes Need to be Detectable . . . . . . . . . . . . . . 11 76 5.8. Proxies Need to be Easy . . . . . . . . . . . . . . . . . 11 77 5.9. Proxies Need to Communicate to Users . . . . . . . . . . . 11 78 5.10. Users Require Simple Interfaces . . . . . . . . . . . . . 12 79 5.11. User Agents Are Diverse . . . . . . . . . . . . . . . . . 12 80 5.12. Choices are Context-Specific . . . . . . . . . . . . . . . 12 81 5.13. RFC2119 Doesn't Define Reality . . . . . . . . . . . . . . 13 82 5.14. It Needs to be Deployable . . . . . . . . . . . . . . . . 13 83 6. Areas to Investigate . . . . . . . . . . . . . . . . . . . . . 13 84 6.1. Living with Interception . . . . . . . . . . . . . . . . . 13 85 6.2. Improving Proxy.Pac and WPAD . . . . . . . . . . . . . . . 13 86 6.3. TLS Errors for Proxies . . . . . . . . . . . . . . . . . . 13 87 6.4. HTTP Errors for Proxies . . . . . . . . . . . . . . . . . 14 88 6.5. TLS for Proxy Connections . . . . . . . . . . . . . . . . 14 89 6.6. TLS for HTTP URIs . . . . . . . . . . . . . . . . . . . . 14 90 6.7. Improving Trust . . . . . . . . . . . . . . . . . . . . . 14 91 6.8. HTTP Signatures . . . . . . . . . . . . . . . . . . . . . 15 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Introduction 101 HTTP/1.1 [RFC2616] was designed to accommodate proxies. It allows 102 them (and other components) to cache content expansively, and allows 103 for proxies to break "semantic transparency" by changing message 104 content, within broad constraints. 106 As the Web has matured, more networks have taken advantage of this by 107 deploying proxies for a variety of reasons, in a number of different 108 ways. Section 2 is a survey of the different ways that proxies are 109 used, and Section 3 shows how they are interposed into communication. 111 Some uses of proxies cause problems (or the perception of them) for 112 origin servers and end users. While some uses are obviously 113 undesirable from the perspective of an end users and/or origin 114 server, other effects of their deployment are more subtle; these are 115 examined in Section 4. 117 These tensions between the interests of the stakeholders in every 118 HTTP connection - the end users, the origin servers and the networks 119 they use - has led to decreased trust for proxies, then increasing 120 deployment of encryption, then workarounds for encryption, and so 121 forth. 123 Left unchecked, this escalation can erode the value of the Web 124 itself. Therefore, Section 5 proposes straw-man principals to base 125 further discussion upon. 127 Finally, Section 6 proposes some areas of technical investigation 128 that may yield solutions (or at least mitigations) for some of these 129 problems. 131 Note that this document is explicitly about "proxies" in the sense 132 that HTTP defines them. Intermediaries that are interposed by the 133 server (e.g., gateways and so-called "Reverse Proxies", as used in 134 Content Delivery Networks) are out of scope. 136 1.1. Notational Conventions 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 2. Why Proxy? 144 HTTP proxies are interposed between user agents and origin servers 145 for a variety of purposes; some of them are with the full knowledge 146 and consent of end users, to their benefit, and some are solely for 147 the purposes of the network operator - sometimes even against the 148 interests of the end users. 150 This section attempts to identify the different motivations networks 151 have for deploying proxies. 153 2.1. Application Layer Gatewaying 155 Some networks do not have direct Internet connectivity for Web 156 browsing. These networks can deploy proxies that do have Internet 157 connectivity and then configure clients to use them. 159 Such gatewaying between networks were some of the first uses for 160 proxies. 162 2.2. Caching 164 An extremely common use of proxies is to interpose a HTTP cache, in 165 order to save bandwidth, improve end-user perceived latency, increase 166 reliability, or some combination of these purposes. 168 HTTP defines a detailed model for caching (see 169 [I-D.ietf-httpbis-p6-cache]); however, some lesser-known aspects of 170 the caching model can cause operational issues. For example, it 171 allows caches to go into an "offline" mode where most content can be 172 served stale. 174 Also, proxy caches sometimes fail to honor the HTTP caching model, 175 reusing content when it should not have been. This can cause 176 interoperability issues, with the end user seeing overly "stale" 177 content, or applications not operating correctly. 179 2.3. Network Policy Enforcement 181 Some proxies are deployed to aid in network policy enforcement; for 182 example, to control access to the network, requiring a login (as 183 allowed explicitly by HTTP's proxy authentication mechanism), 184 bandwidth shaping of HTTP access, quotas, etc. This includes so- 185 called "Captive Portals" used for network login. 187 Some uses of proxies for policy enforcement cause problems; e.g., 188 when a proxy uses URL rewriting to send a user a message (e.g., a 189 "blocked" page), they can make it appear as if the origin server is 190 sending that message - especially when the user agent isn't a browser 191 (e.g., a software update process). 193 2.4. Content Filtering (a.k.a. Content Policy Enforcement) 195 Some networks attempt to filter HTTP messages (both request and 196 response) based upon network-specific criteria. For example, they 197 might wish to stop users from downloading content that contains 198 malware, or that violates site policies on appropriate content, or 199 that violates local law. 201 Intermediary proxies as a mechanism for enforcing content 202 restrictions are often easy to circumvent. For example, a device 203 might become infected by using a different network, or a VPN. 204 Nevertheless, they are commonly used for this purpose. 206 Some content policy enforcement is also done locally to the user 207 agent; for example, several Operating Systems have machine-local 208 proxies built in that scan content. 210 Content filtering is often seen as controversial, often depending on 211 the context it is used within and how it is performed. 213 2.5. Content Modification 215 Some networks modify HTTP messages (both request and response) as 216 they pass through proxies. This might include the message body, 217 headers, request-target, method or status code. 219 Motivation for content modification varies. For example, some mobile 220 networks interpose proxies that modify content in an attempt to save 221 bandwidth, improve perceived performance, or transcode content to 222 formats that limited-resource devices can more easily consume. 224 Modifications also include adding metadata in headers for accounting 225 purposes, or removing metadata such as Accept-Encoding to make virus 226 scanning easier. 228 In other cases, content modification is performed to make more 229 substantial modifications. This could include inserting 230 advertisements, or changing the layout of content in an attempt to 231 make it easier to use. 233 Content modification is very controversial, often depending on the 234 context it is used within and how it is performed. Many feel that, 235 without the explicit consent of either the end user or the origin 236 server, a proxy that modifies content violates their relationship, 237 thereby degrading trust in the Web overall. 239 However, it should be noted that [RFC2616] explicitly allows "non- 240 transparent" proxies that modify content in certain ways. Such 241 proxies are required to honor the "no-transform" directive, giving 242 both user agents and origin servers a mechanism to "opt out" of 243 modifications; however, it is not technically enforced. 245 [W3C.CR-ct-guidelines-20100617] is a product of the W3C Mobile Web 246 Best Practices Working Group that attempts to set guidelines for 247 content modification proxies. Again, it is a policy document, 248 without technical enforcement measures. 250 3. How Proxies are Interposed 252 How a proxy is interposed into a network flow often has great affect 253 on perceptions of its operation by end users and origin servers. 254 This section catalogues the ways that this happens, and potential 255 problems with each. 257 3.1. Manual Configuration 259 The original way to interpose a proxy was to manually configure it 260 into the user agent. For example, most browsers still have the 261 ability to have a proxy hostname and port configured for HTTP; many 262 Operating Systems have system-wide proxy settings. 264 Unfortunately, manual configuration suffers from several problems: 266 o Users often lack the expertise to manually configure proxies. 267 o When the user changes networks, they must manually change proxy 268 settings, a laborious task. This makes manual configuration 269 impractical in a modern, mobile-driven world. 270 o Not all HTTP stacks support manual proxy configuration. 271 Therefore, a proxy administrator cannot rely upon this method. 273 3.2. proxy.pac and WPAD 275 The limitations of manual configuration were recognized long ago. 276 The solution that evolved was a format called "proxy.pac" [proxypac] 277 that allowed the proxy configuration to be automated, once the user 278 agent had loaded it. 280 Proxy.pac is a JavaScript format; before each request is made, it is 281 dispatched to a function in the file that returns a string that 282 denotes whether a proxy is to be used, and if so, which one to use. 284 Discovery of the appropriate proxy.pac file for a given network can 285 be made using a DHCP extension, [wpad]. WPAD started as a simple 286 protocol; it conveys a URL that locates the proxy.pac file for the 287 network. 289 Unfortunately, the proxy.pac/WPAD combination has several operational 290 issues that limit its deployment: 292 o The proxy.pac format does not define timeouts or failover behavior 293 precisely, leading to wide divergence between implementations. 294 This makes supporting multiple user agents reliably difficult for 295 the network. 296 o WPAD is not widely implemented by user agents; some only implement 297 proxy.pac. 298 o In those user agents where it is implemented, WPAD is often not 299 the default, meaning that users need to configure its use. 300 o Neither proxy.pac nor WPAD have been standardized, leading to 301 implementation divergence and resulting interoperability problems. 302 o There are DNS-based variants of WPAD, adding to to confusion. 303 o DHCP options generally require tight integration with the 304 operating system to pass the results to HTTP-based applications. 305 While this level of integration is found between O/Ses and their 306 provided applications, the interface may or may not be available 307 to third parties. 308 o WPAD can be spoofed, allowing attackers to interpose a proxy and 309 intercept traffic. 311 3.3. Interception 313 The problems with manual configuration and proxy.pac/WPAD have led to 314 the wide deployment of a third style of interposition; interception 315 proxies. 317 Interception occurs when lower-layer protocols are configured to 318 route HTTP traffic to a host other than the origin server for the URI 319 in question. It requires no client configuration (hence its 320 popularity over other methods). See [RFC3040] for an example of an 321 interception-related protocol. 323 Interception is also strongly motivated when it is necessary to 324 assure that the proxy is always used, e.g., to enforce policy. 326 Interception is problematic, however, because it is often done 327 without the consent of either the end user or the origin server. 328 This means that a response that appears to be coming from the origin 329 server is actually coming from the intercepting proxy. This makes it 330 difficult to support features like proxy authentication, as the 331 unexpected status code breaks many clients (e.g., non-interactive 332 applications like software installers). 334 In addition, as adoption of multi-path TCP (MPTCP)[RFC6824] 335 increases, the ability of intercepting proxies to offer a consistent 336 service degrades. 338 3.4. Configuration As Side Effect 340 More recently, it's become more common for a proxy to be interposed 341 as a side effect of another choice by the user. 343 For example, the user might decide to add virus scanning - either as 344 installed software, or a service that they configure from their 345 provider - that is interposed as a proxy. Indeed, almost all desktop 346 virus scanners and content filters operate in this fashion. 348 This approach has the merits of both being easy and obtaining 349 explicit user consent. However, in some cases, the end user might 350 not understand the consequences of use of the proxy, especially upon 351 security and interoperability. 353 4. Second-Order Effects of Proxy Deployment 355 4.1. Proxies and HTTP 357 Deployment of proxies has an effect on the HTTP protocol itself. 358 Because a proxy implements both a server and a client, any 359 limitations or bugs in their implementation impact the protocol's 360 use. 362 For example, HTTP has a defined mechanism for upgrading the protocol 363 of a connection, to aid in the deployment of new versions of HTTP 364 (such as HTTP/2.0) or completely different protocol (e.g., 365 [RFC6455]). 367 However, operational experience has shown that a significant number 368 of proxy implementations do not correctly implement it, leading to 369 dangerous situations where two ends of a HTTP connection think 370 different protocols are being spoken. 372 Anothr example is the Expect/100-continue mechanism in HTTP/1.1, 373 which is often incorrectly implemented. Likewise, differences in 374 support for trailers limits protocol extensions. 376 4.2. Proxies and TLS 378 It has become more common for Web sites to use TLS [RFC5246] in an 379 attempt to avoid many of the problems above. Many have advocated use 380 of TLS more broadly; for example, see the EFF's HTTPS Everywhere 381 [https-everywhere] program, and SPDY's default use of TLS 382 [I-D.mbelshe-httpbis-spdy]. 384 However, doing so engenders a few problems. 386 Firstly, TLS as used on the Web is not a perfectly secure protocol, 387 and using it to protect all traffic gives proxies a strong incentive 388 to work around it, e.g., by deploying a certificate authority 389 directly into browsers, or buying a sub-root certificate. 391 Secondly, it removes the opportunity for the proxy to inform the user 392 agent of relevant information; for example, conditions of access, 393 access denials, login interfaces, and so on. User Agents currently 394 do not display any feedback from proxy, even in the CONNECT response 395 (e.g., a 4xx or 5xx error), limiting their ability to have inform 396 users of what's going on. 398 Finally, it removes the opportunity for services provided by a proxy 399 that the end user may wish to opt into. For example, consider when a 400 remote village shares a proxy server to cache content, thereby 401 helping to overcome the limitations of their Internet connection. 402 TLS-protected HTTP traffic cannot be cached by intermediaries, 403 removing much of the benefit of the Web to what is arguably one of 404 its most important target audiences. 406 It is now becoming more common for a proxy to man-in-the-middle TLS 407 connections (see [tls-mitm] for an overview), to gain access to the 408 application message flows. This represents a serious degradation in 409 the trust infrastructure of the Web. 411 Worse is the situation where proxies provide a certificate where they 412 inure the user to a certificate warning that they must then ignore in 413 order to receive service. 415 5. Principles for Consideration 417 Every HTTP connection has at least three major stakeholders; the user 418 (through their agent), the origin server (possibly using gateways 419 such as a CDN) and the networks between them. 421 Currently, the capabilities of these stakeholders are defined by how 422 the Web is deployed. Most notably, networks sometimes change 423 content. If they change it too much, origin servers will start using 424 encryption. Changing the way that HTTP operates therefore has the 425 potential to re-balance the capabilities of the various stakeholders. 427 This section proposes several straw-man principles for consideration 428 as the basis of those changes. Their sole purpose here is to provoke 429 discussion. 431 5.1. Proxies Have a Legitimate Place 433 As illustrated above, there are many legitimate uses for proxies, and 434 they are a necessary part of the architecture of the Web. While all 435 uses of proxies are not legitimate - especially when they're 436 interposed without the knowledge or consent of the end user and the 437 origin - undesirable intermediaries (i.e., those that break the 438 reasonable expectations of other stakeholders) are a small portion of 439 those deployed used. 441 5.2. Security Should be Encouraged 443 Any solution needs to give all stakeholders - end users, networks and 444 origin servers - a strong incentive towards security. 446 This has subtle implications. If networks are disempowered 447 disproportionately, they might react by blocking secure connections, 448 discouraging origin servers (who often have even stronger profit 449 incentives) from deploying encryption, which would result in a net 450 loss of security. 452 5.3. Interoperability is Important Too 454 Security at the expense of long-term interoperability is not a good 455 trade. 457 For example, if networks decide to only allow secure connections to 458 well-known, large origin servers, it creates a "walled garden" that 459 favours big sites at the expense of less well-known ones. 461 Likewise, if a jurisdiction cannot use standard-conformant browsers 462 to impose their legal requirements upon network users, they might 463 decide to create a separate Web based upon competing technology. 465 5.4. Users Need to be Informed of Proxies 467 When a proxy is interposed, the user needs to be informed about it, 468 so they have the opportunity to change their configuration (e.g., 469 attempt to introduce encryption), or not use the network at all. 471 Proxies also need to be strongly authenticated; i.e., users need to 472 be able to verify who the proxy is. 474 5.5. Users Need to be able to Tunnel through Proxies 476 When a proxy is interposed, the user needs to be able to tunnel any 477 request through it without its content (or that of the response) 478 being exposed to the proxy. 480 This includes both "https://" and "http://" URIs. 482 5.6. Proxies Can say "No" 484 A proxy can refuse to forward any request. This includes a request 485 to a specific URI, or from a specific user, and includes refusing to 486 allow tunnels as described above. 488 The "no", however, needs to be explicit, and explicitly from the 489 proxy. 491 5.7. Changes Need to be Detectable 493 Any changes to the message body, request URI, method, status code, or 494 representation header fields of an HTTP message needs to be 495 detectable by the origin server or user agent, as appropriate, if 496 they desire it. 498 This allows a proxy to be trusted, but its integrity to be verified. 500 5.8. Proxies Need to be Easy 502 It must be possible to configure a proxy extremely easily; the 503 adoption of interception over proxy.pac/WPAD illustrates this very 504 clearly. 506 5.9. Proxies Need to Communicate to Users 508 There are many situations where a proxy needs to communicate with the 509 end user; for example, to gather network authentication credentials, 510 communicate network policy, report that access to content has been 511 denied, and so on. 513 Currently, HTTP has poor facilities for doing so. The proxy 514 authentication mechanism is extremely limited, and while there are a 515 few status codes that are define as being from a proxy rather than 516 the origin, they do not cover all necessary situations. 518 The Warning header field was designed as a very limited form of 519 communication between proxies and end users, but it has not been 520 widely adopted, nor exposed by User Agents. 522 Importantly, proxies also need a limited communication channel when 523 TLS is in use, for similar purposes. 525 Equally as important, the communication needs to clearly come from 526 the proxy, rather than the origin, and be strongly authenticated. 528 5.10. Users Require Simple Interfaces 530 While some users are sophisticated in their understanding of Web 531 security, they are in a vanishingly small minority. The concepts and 532 implications of many decisions regarding security are subtle, and 533 require an understanding of how the Web works; describing these 534 trade-offs in a modal dialogue box that gets in the way of the 535 content the user wants has been proven not to work. 537 Similarly, while some Web publishers are sophisticated regarding 538 security, the vast majority are not (as can be proven by the 539 prevalence of cross-site scripting attacks). 541 Therefore, any changes cannot rely upon perfect understanding by 542 these parties, or even any great effort upon their part. This 543 implies that user interface will be one of the biggest challenges 544 faced, both in the browser and for any changes server-side. 546 Notably, the most widely understood indicator of security today is 547 the "lock icon" that shows when a connection is protected by TLS. 548 Any erosion of the commonly-understood semantics of that indicator, 549 as well as "https://" URIs, is likely to be extremely controversial, 550 because it changes the already-understood security properties of the 551 Web. 553 Another useful emerging convention is that of "Incognito" or 554 "private" mode, where the end user has requested enhanced privacy and 555 security. This might be used to introduce higher requirements for 556 the interposition of intermediaries, or even to prohibit their use 557 without full encryption. 559 5.11. User Agents Are Diverse 561 HTTP is used in a wide variety of environments. As such there can be 562 no assumption that a user is sitting on the other end to interpret 563 information or answer questions from proxies. 565 5.12. Choices are Context-Specific 567 Getting consent from users, as well as informing them, can take a 568 variety of forms. For example, if we require that users consent to 569 using a proxy, that consent could be obtained through a modal dialog 570 in the browser, or through a written agreement between an employer 571 and their employee. 573 Likewise, a browser vendor may choose not to implement some optional 574 portions of the specification, based upon how they want to position 575 their product with their audience. 577 5.13. RFC2119 Doesn't Define Reality 579 It's very tempting for a committee to proclaim that proxies MUST do 580 this and SHOULD NOT do that, but the reality is that the proxies, 581 like any other actor in a networked system, will do what they can, 582 not what they're told to do, if they have an incentive to do it. 584 Therefore, it's not enough to say that (for example), "proxies have 585 to honor no-transform" as HTTP/1.1 does. Instead, the protocol needs 586 to be designed in a way so that either transformations aren't 587 possible, or if they are, they can be detected (with appropriate 588 handling by User Agents defined). 590 5.14. It Needs to be Deployable 592 Any improvements to the proxy ecosystem MUST be incrementally 593 deployable, so that existing clients can continue to function. 595 6. Areas to Investigate 597 Finally, this section lists some areas of potential future 598 investigation, bearing the principles suggested above in mind. 600 6.1. Living with Interception 602 The IETF has long fought against interception proxies, as they are 603 indistinguishable from Man-In-The-Middle attacks. Nevertheless, they 604 persist as the preferred method for interposing proxies in many 605 networks. 607 Unless another mechanism can be found or defined that offers equally 608 attractive properties to network operators, we ought to consider that 609 they'll continue to be deployed, and work to find ways to make their 610 operation both more verifiable and unnecessary (or at least 611 legitimate). 613 6.2. Improving Proxy.Pac and WPAD 615 Many of the flaws in proxy.pac and WPAD can be fixed by careful 616 specification and standardization, with active participation by both 617 implementers and those that deploy them. 619 6.3. TLS Errors for Proxies 621 HTTP's use of TLS [RFC2818] currently offers no way for an 622 interception proxy to communicate with the user agent on its own 623 behalf. This might be necessary for network authentication, 624 notification of filtering by hostname, etc. 626 The challenge in defining such a mechanism is avoiding the opening of 627 new attack vectors; if unauthenticated content can be served as if it 628 were from the origin server, or the user can be encouraged to "click 629 through" a dialog, it has severe security implications. As such, the 630 user experience would need to be carefully considered. 632 6.4. HTTP Errors for Proxies 634 HTTP currently defines two status codes that are explicitly generated 635 by a proxy: 637 o 504 Gateway Timeout [RFC2616] - when a proxy (or gateway) times 638 out going forward 639 o 511 Network Authentication Required [RFC6585] - when 640 authentication information is necessary to access the network 642 It might be interesting to discuss whether a separate user experience 643 can be formed around proxy-specific status codes, along with the 644 definition of new ones as necessary. 646 6.5. TLS for Proxy Connections 648 While TLS can be used end-to-end for "https://" URIs, support for 649 connecting to a proxy itself using TLS (e.g., for "http://" URIs) is 650 spotty. Using a proxy without strong proof of its identity 651 introduces security issues, and if a proxy can legitimately insert 652 itself into communication, its identity needs to be verifiable. 654 6.6. TLS for HTTP URIs 656 To allow users to tunnel any request through proxies without 657 revealing its contents, it must be possible to use TLS for HTTP URIs. 659 Proxies can then choose whether to allow such tunneled traffic, and 660 if not, the user can choose whether to trust the proxy. 662 6.7. Improving Trust 664 Currently, it is possible to exploit the mismatched incentives and 665 other flaws in the CA system to cause a browser to trust a proxy as 666 authoritative for a "https://" URI without full user knowledge. This 667 needs to be remedied; otherwise, proxies will continue to man-in-the- 668 middle TLS. 670 6.8. HTTP Signatures 672 Signatures for HTTP content - both requests and responses - has been 673 discussed on and off for some time. 675 Of particular interest here, signed responses would allow a user- 676 agent to verify that the origin's content has not been modified in 677 transit, whilst still allowing it to be cached by intermediaries. 679 Likewise, if header values can be signed, the caching policy (as 680 expressed by Cache-Control, Date, Last-Modified, Age, etc.) can be 681 signed, meaning it can be verified as being adhered to. 683 Note that properly designed, a signature mechanism could work over 684 TLS, separating the trust relationship between the UA and the origin 685 server and that of the UA and its proxy (with appropriate consent). 687 There are significant challenges in designing a robust, widely- 688 deployable HTTP signature mechanism. One of the largest is an issue 689 of user interface - what ought the UA do when encountering a bad 690 signature? 692 7. Security Considerations 694 Plenty of them, I suspect. 696 8. Acknowledgements 698 This document benefits from conversations and feedback from many 699 people, including Amos Jeffries, Willy Tarreau, Patrick McManus, 700 Roberto Peon, Guy Podjarny, Eliot Lear, Brad Hill and Martin Nilsson. 702 9. References 704 9.1. Normative References 706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 707 Requirement Levels", BCP 14, RFC 2119, March 1997. 709 9.2. Informative References 711 [I-D.ietf-httpbis-p6-cache] 712 Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 713 Transfer Protocol (HTTP/1.1): Caching", 714 draft-ietf-httpbis-p6-cache-24 (work in progress), 715 September 2013. 717 [I-D.mbelshe-httpbis-spdy] 718 Belshe, M. and R. Peon, "SPDY Protocol", 719 draft-mbelshe-httpbis-spdy-00 (work in progress), 720 February 2012. 722 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 723 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 724 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 726 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 728 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 729 Replication and Caching Taxonomy", RFC 3040, January 2001. 731 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 732 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 734 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 735 RFC 6455, December 2011. 737 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 738 Codes", RFC 6585, April 2012. 740 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 741 "TCP Extensions for Multipath Operation with Multiple 742 Addresses", RFC 6824, January 2013. 744 [W3C.CR-ct-guidelines-20100617] 745 Rabin, J., "Guidelines for Web Content Transformation 746 Proxies 1.0", World Wide Web Consortium CR CR-ct- 747 guidelines-20100617, June 2010, 748 . 750 [https-everywhere] 751 EFF, ., "HTTPS Everywhere", 2013, 752 . 754 [proxypac] 755 various, ., "Proxy Auto-Config", 2013, 756 . 758 [tls-mitm] 759 Jarmoc, J., "SSL/TLS Interception Proxies and Transitive 760 Trust", 2012, . 763 [wpad] Cohen, J., "Web Proxy Auto-Discovery Protocol", 1999, 764 . 766 Author's Address 768 Mark Nottingham 770 Email: mnot@mnot.net 771 URI: http://www.mnot.net/