idnits 2.17.1 draft-nottingham-http-proxy-problem-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 : ---------------------------------------------------------------------------- ** 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 (July 04, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7234 (Obsoleted by RFC 9111) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 4 Intended status: Informational July 04, 2014 5 Expires: January 05, 2015 7 Problems with Proxies in HTTP 8 draft-nottingham-http-proxy-problem-01 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 January 05, 2015. 35 Copyright Notice 37 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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) . . 4 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 . . . . . . . . . . . . . . . . . . . . . 9 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. Users Need to be Informed of Proxies . . . . . . . . . . 10 72 5.4. Users Need to be able to Tunnel through Proxies . . . . . 11 73 5.5. Proxies Can say "No" . . . . . . . . . . . . . . . . . . 11 74 5.6. Changes Need to be Detectable . . . . . . . . . . . . . . 11 75 5.7. Proxies Need to be Easy . . . . . . . . . . . . . . . . . 11 76 5.8. Proxies Need to Communicate to Users . . . . . . . . . . 11 77 5.9. Users Require Simple Interfaces . . . . . . . . . . . . . 12 78 5.10. User Agents Are Diverse . . . . . . . . . . . . . . . . . 12 79 5.11. RFC2119 Doesn't Define Reality . . . . . . . . . . . . . 12 80 5.12. It Needs to be Deployable . . . . . . . . . . . . . . . . 13 81 6. Potential Areas to Investigate . . . . . . . . . . . . . . . 13 82 6.1. Improving Proxy.Pac . . . . . . . . . . . . . . . . . . . 13 83 6.2. TLS Errors for Proxies . . . . . . . . . . . . . . . . . 13 84 6.3. HTTP Errors for Proxies . . . . . . . . . . . . . . . . . 13 85 6.4. TLS for Proxy Connections . . . . . . . . . . . . . . . . 14 86 6.5. Improved Network Information . . . . . . . . . . . . . . 14 87 6.6. Improving Trust . . . . . . . . . . . . . . . . . . . . . 14 88 6.7. HTTP Signatures . . . . . . . . . . . . . . . . . . . . . 14 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 9.2. Informative References . . . . . . . . . . . . . . . . . 15 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 96 1. Introduction 97 HTTP/1.1 [RFC7230] was designed to accommodate proxies. It allows 98 them (and other components) to cache content expansively, and allows 99 for proxies to break "semantic transparency" by changing message 100 content, within broad constraints. 102 As the Web has matured, more networks have taken advantage of this by 103 deploying proxies for a variety of reasons, in a number of different 104 ways. Section 2 is a survey of the different ways that proxies are 105 used, and Section 3 shows how they are interposed into communication. 107 Some uses of proxies cause problems (or the perception of them) for 108 origin servers and end users. While some uses are obviously 109 undesirable from the perspective of an end users and/or origin 110 server, other effects of their deployment are more subtle; these are 111 examined in Section 4. 113 These tensions between the interests of the stakeholders in every 114 HTTP connection - the end users, the origin servers and the networks 115 they use - has led to decreased trust for proxies, then increasing 116 deployment of encryption, then workarounds for encryption, and so 117 forth. 119 Left unchecked, this escalation can erode the value of the Web 120 itself. Therefore, Section 5 proposes straw-man principals to base 121 further discussion upon. 123 Finally, Section 6 proposes some areas of technical investigation 124 that might yield solutions (or at least mitigations) for some of 125 these problems. 127 Note that this document is explicitly about "proxies" in the sense 128 that HTTP defines them. Intermediaries that are interposed by the 129 server (e.g., gateways and so-called "Reverse Proxies", as used in 130 Content Delivery Networks) are out of scope. 132 1.1. Notational Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. Why Proxy? 140 HTTP proxies are interposed between user agents and origin servers 141 for a variety of purposes; some of them are with the full knowledge 142 and consent of end users, to their benefit, and some are solely for 143 the purposes of the network operator - sometimes even against the 144 interests of the end users. 146 This section attempts to identify the different motivations networks 147 have for deploying proxies. 149 2.1. Application Layer Gatewaying 151 Some networks do not have direct Internet connectivity for Web 152 browsing. These networks can deploy proxies that do have Internet 153 connectivity and then configure clients to use them. 155 Such gatewaying between networks were some of the first uses for 156 proxies. 158 2.2. Caching 160 An extremely common use of proxies is to interpose a HTTP cache, in 161 order to save bandwidth, improve end-user perceived latency, increase 162 reliability, or some combination of these purposes. 164 HTTP defines a detailed model for caching (see [RFC7234]); however, 165 some lesser-known aspects of the caching model can cause operational 166 issues. For example, it allows caches to go into an "offline" mode 167 where most content can be served stale. 169 Also, proxy caches sometimes fail to honor the HTTP caching model, 170 reusing content when it should not have been. This can cause 171 interoperability issues, with the end user seeing overly "stale" 172 content, or applications not operating correctly. 174 2.3. Network Policy Enforcement 176 Some proxies are deployed to aid in network policy enforcement; for 177 example, to control access to the network, requiring a login (as 178 allowed explicitly by HTTP's proxy authentication mechanism), 179 bandwidth shaping of HTTP access, quotas, etc. This includes so- 180 called "Captive Portals" used for network login. 182 Some uses of proxies for policy enforcement cause problems; e.g., 183 when a proxy uses URL rewriting to send a user a message (e.g., a 184 "blocked" page), they can make it appear as if the origin server is 185 sending that message - especially when the user agent isn't a browser 186 (e.g., a software update process). 188 2.4. Content Filtering (a.k.a. Content Policy Enforcement) 189 Some networks attempt to filter HTTP messages (both request and 190 response) based upon network-specific criteria. For example, they 191 might wish to stop users from downloading content that contains 192 malware, or that violates site policies on appropriate content, or 193 that violates local law. 195 Intermediary proxies as a mechanism for enforcing content 196 restrictions are often easy to circumvent. For example, a device 197 might become infected by using a different network, or a VPN. 198 Nevertheless, they are commonly used for this purpose. 200 Some content policy enforcement is also done locally to the user 201 agent; for example, several Operating Systems have machine-local 202 proxies built in that scan content. 204 Content filtering is often seen as controversial, often depending on 205 the context it is used within and how it is performed. 207 2.5. Content Modification 209 Some networks modify HTTP messages (both request and response) as 210 they pass through proxies. This might include the message body, 211 headers, request-target, method or status code. 213 Motivation for content modification varies. For example, some mobile 214 networks interpose proxies that modify content in an attempt to save 215 bandwidth, improve perceived performance, or transcode content to 216 formats that limited-resource devices can more easily consume. 218 Modifications also include adding metadata in headers for accounting 219 purposes, or removing metadata such as Accept-Encoding to make virus 220 scanning easier. 222 In other cases, content modification is performed to make more 223 substantial modifications. This could include inserting 224 advertisements, or changing the layout of content in an attempt to 225 make it easier to use. 227 Content modification is very controversial, often depending on the 228 context it is used within and how it is performed. Many feel that, 229 without the explicit consent of either the end user or the origin 230 server, a proxy that modifies content violates their relationship, 231 thereby degrading trust in the Web overall. 233 However, it should be noted that Section 5.7.2 of [RFC7230] 234 explicitly allows "non-transparent" proxies that modify content in 235 certain ways. Such proxies are required to honor the "no-transform" 236 directive, giving both user agents and origin servers a mechanism to 237 "opt out" of modifications ([RFC7234], Section 5.2.1.6); however, it 238 is not technically enforced. 240 [W3C.NOTE-ct-guidelines-20101026] is a product of the W3C Mobile Web 241 Best Practices Working Group that attempts to set guidelines for 242 content modification proxies. Again, it is a policy document, 243 without technical enforcement measures. 245 3. How Proxies are Interposed 247 How a proxy is interposed into a network flow often has great affect 248 on perceptions of its operation by end users and origin servers. 249 This section catalogues the ways that this happens, and potential 250 problems with each. 252 3.1. Manual Configuration 254 The original way to interpose a proxy was to manually configure it 255 into the user agent. For example, most browsers still have the 256 ability to have a proxy hostname and port configured for HTTP; many 257 Operating Systems have system-wide proxy settings. 259 Unfortunately, manual configuration suffers from several problems: 261 o Users often lack the expertise to manually configure proxies. 263 o When the user changes networks, they must manually change proxy 264 settings, a laborious task. This makes manual configuration 265 impractical in a modern, mobile-driven world. 267 o Not all HTTP stacks support manual proxy configuration. 268 Therefore, a proxy administrator cannot rely upon this method. 270 3.2. proxy.pac and WPAD 272 The limitations of manual configuration were recognized long ago. 273 The solution that evolved was a format called "proxy.pac" [proxypac] 274 that allowed the proxy configuration to be automated, once the user 275 agent had loaded it. 277 Proxy.pac is a JavaScript format; before each request is made, it is 278 dispatched to a function in the file that returns a string that 279 denotes whether a proxy is to be used, and if so, which one to use. 281 Discovery of the appropriate proxy.pac file for a given network can 282 be made using a DHCP extension, [wpad]. WPAD started as a simple 283 protocol; it conveys a URL that locates the proxy.pac file for the 284 network. 286 Unfortunately, the proxy.pac/WPAD combination has several operational 287 issues that limit its deployment: 289 o The proxy.pac format does not define timeouts or failover behavior 290 precisely, leading to wide divergence between implementations. 291 This makes supporting multiple user agents reliably difficult for 292 the network. 294 o WPAD is not widely implemented by user agents; some only implement 295 proxy.pac. 297 o In those user agents where it is implemented, WPAD is often not 298 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. 303 o There are DNS-based variants of WPAD, adding to to confusion. 305 o DHCP options generally require tight integration with the 306 operating system to pass the results to HTTP-based applications. 307 While this level of integration is found between O/Ses and their 308 provided applications, the interface may or may not be available 309 to third parties. 311 o WPAD can be spoofed, allowing attackers to interpose a proxy and 312 intercept traffic. This is a blocking issue for implementation. 314 3.3. Interception 316 The problems with manual configuration and proxy.pac/WPAD have led to 317 the wide deployment of a third style of interposition; interception 318 proxies. 320 Interception occurs when lower-layer protocols are configured to 321 route HTTP traffic to a host other than the origin server for the URI 322 in question. It requires no client configuration (hence its 323 popularity over other methods). See [RFC3040] for an example of an 324 interception-related protocol. 326 Interception is also strongly motivated when it is necessary to 327 assure that the proxy is always used, e.g., to enforce policy. 329 Interception is problematic, however, because it is often done 330 without the consent of either the end user or the origin server. 331 This means that a response that appears to be coming from the origin 332 server is actually coming from the intercepting proxy. This makes it 333 difficult to support features like proxy authentication, as the 334 unexpected status code breaks many clients (e.g., non-interactive 335 applications like software installers). 337 Furthermore, interception is a "layer violation"; i.e., misusing 338 lower-layer protocols to enforce a higher-layer (often expressed as 339 "layer 8") requirement. 341 In addition, as adoption of multi-path TCP (MPTCP) [RFC6824] 342 increases, the ability of intercepting proxies to offer a consistent 343 service degrades. 345 3.4. Configuration As Side Effect 347 More recently, it's become more common for a proxy to be interposed 348 as a side effect of another choice by the user. 350 For example, the user might decide to add virus scanning - either as 351 installed software, or a service that they configure from their 352 provider - that is interposed as a proxy. Indeed, almost all desktop 353 virus scanners and content filters operate in this fashion. 355 This approach has the merits of both being easy and obtaining 356 explicit user consent. However, in some cases, the end user might 357 not understand the consequences of use of the proxy, especially upon 358 security and interoperability. 360 4. Second-Order Effects of Proxy Deployment 362 4.1. Proxies and HTTP 364 Deployment of proxies has an effect on the HTTP protocol itself. 365 Because a proxy implements both a server and a client, any 366 limitations or bugs in their implementation impact the protocol's 367 use. 369 For example, HTTP has a defined mechanism for upgrading the protocol 370 of a connection, to aid in the deployment of new versions of HTTP 371 (such as HTTP/2) or completely different protocol (e.g., [RFC6455]). 373 However, operational experience has shown that a significant number 374 of proxy implementations do not correctly implement it, leading to 375 dangerous situations where two ends of a HTTP connection think 376 different protocols are being spoken. 378 Another example is the Expect/100-continue mechanism in HTTP/1.1, 379 which is often incorrectly implemented. Likewise, differences in 380 support for trailers limits protocol extensions. 382 4.2. Proxies and TLS 384 It has become more common for Web sites to use TLS [RFC5246] in an 385 attempt to avoid many of the problems above. Many have advocated use 386 of TLS more broadly; for example, see the EFF's HTTPS Everywhere 387 [https-everywhere] program, and SPDY's default use of TLS 388 [I-D.mbelshe-httpbis-spdy]. 390 However, doing so engenders a few problems. 392 Firstly, TLS as used on the Web is not a perfectly secure protocol, 393 and using it to protect all traffic gives proxies a strong incentive 394 to work around it, e.g., by deploying a certificate authority 395 directly into browsers, or buying a sub-root certificate. 397 Secondly, it removes the opportunity for the proxy to inform the user 398 agent of relevant information; for example, conditions of access, 399 access denials, login interfaces, and so on. User Agents currently 400 do not display any feedback from proxy, even in the CONNECT response 401 (e.g., a 4xx or 5xx error), limiting their ability to have informed 402 users of what's going on. 404 Finally, it removes the opportunity for services provided by a proxy 405 that the end user might wish to opt into. For example, consider when 406 a remote village shares a proxy server to cache content, thereby 407 helping to overcome the limitations of their Internet connection. 408 TLS-protected HTTP traffic cannot be cached by intermediaries, 409 removing much of the benefit of the Web to what is arguably one of 410 its most important target audiences. 412 It is now becoming more common for a proxy to man-in-the-middle TLS 413 connections (see [tls-mitm] for an overview), to gain access to the 414 application message flows. This represents a serious degradation in 415 the trust infrastructure of the Web. 417 Worse is the situation where proxies provide a certificate where they 418 inure the user to a certificate warning that they then need to ignore 419 in order to receive service. 421 5. Principles for Consideration 423 Every HTTP connection has at least three major stakeholders; the user 424 (through their agent), the origin server (possibly using gateways 425 such as a CDN) and the networks between them. 427 Currently, the capabilities of these stakeholders are defined by how 428 the Web is deployed. Most notably, networks sometimes change 429 content. If they change it too much, origin servers will start using 430 encryption. Changing the way that HTTP operates therefore has the 431 potential to re-balance the capabilities of the various stakeholders. 433 This section proposes several straw-man principles for consideration 434 as the basis of those changes. Their sole purpose here is to provoke 435 discussion. 437 5.1. Proxies Have a Legitimate Place 439 As illustrated above, there are many legitimate uses for proxies, and 440 they are a necessary part of the architecture of the Web. While all 441 uses of proxies are not legitimate - especially when they're 442 interposed without the knowledge or consent of the end user and the 443 origin - undesirable intermediaries (i.e., those that break the 444 reasonable expectations of other stakeholders) are a small portion of 445 those deployed used. 447 Note that while proxies have a legitimate place, it does not imply 448 that they are an equal stakeholder to other parties in all ways; 449 e.g., they do not have a natural right to access encrypted content, 450 for example. 452 5.2. Security Should be Encouraged 454 Any solution needs to give all stakeholders - end users, networks and 455 origin servers - a strong incentive towards security. 457 This has subtle implications. If networks are disempowered 458 disproportionately, they might react by blocking secure connections, 459 discouraging origin servers (who often have even stronger profit 460 incentives) from deploying encryption, which would result in a net 461 loss of security. 463 On the other hand, if networks are given carte blanche, it can 464 destroy trust in the Web altogether. In particular, making it too 465 easy to interpose a proxy (even if the user is "informed" by clicking 466 through a dialogue) degrades the infrastructure in an unacceptable 467 way. 469 5.3. Users Need to be Informed of Proxies 471 When a proxy is interposed, the user needs to be informed about it, 472 so they have the opportunity to change their configuration (e.g., 473 attempt to introduce encryption), or not use the network at all. 475 Proxies also need to be strongly authenticated; i.e., users need to 476 be able to verify who the proxy is. 478 5.4. Users Need to be able to Tunnel through Proxies 480 When a proxy is interposed, the user needs to be able to tunnel any 481 request through it without its content (or that of the response) 482 being exposed to the proxy. 484 This includes both "https://" and "http://" URIs. 486 5.5. Proxies Can say "No" 488 A proxy can refuse to forward any request. Currently, the 489 granularity of that "no" is per-URI for unencrypted requests, and 490 per-IP (perhaps per-SNI) for encrypted requests. 492 5.6. Changes Need to be Detectable 494 Any changes to the message body, request URI, method, status code, or 495 representation header fields of an HTTP message need to be detectable 496 by the origin server or user agent, as appropriate, if they desire 497 it. 499 This allows a proxy to be trusted, but its integrity to be verified. 501 5.7. Proxies Need to be Easy 503 It must be possible to configure a proxy extremely easily; the 504 adoption of interception over proxy.pac/WPAD illustrates this very 505 clearly. 507 5.8. Proxies Need to Communicate to Users 509 There are many situations where a proxy needs to communicate with the 510 end user; for example, to gather network authentication credentials, 511 communicate network policy, report that access to content has been 512 denied, and so on. 514 Currently, HTTP has poor facilities for doing so. The proxy 515 authentication mechanism is extremely limited, and while there are a 516 few status codes that are defined as being from a proxy rather than 517 the origin, they do not cover all necessary situations. 519 The Warning header field ([RFC7234], Section 5.5) was designed as a 520 very limited form of communication between proxies and end users, but 521 it has not been widely adopted, nor exposed by User Agents. 523 Importantly, proxies also need a limited communication channel when 524 TLS is in use, for similar purposes. 526 Equally as important, the communication needs to clearly come from 527 the proxy, rather than the origin, and be strongly authenticated. 529 5.9. Users Require Simple Interfaces 531 While some users are sophisticated in their understanding of Web 532 security, they are in a vanishingly small minority. The concepts and 533 implications of many decisions regarding security are subtle, and 534 require an understanding of how the Web works; describing these 535 trade-offs in a modal dialogue box that gets in the way of the 536 content the user wants has been proven not to work. 538 Similarly, while some Web publishers are sophisticated regarding 539 security, the vast majority are not (as can be proven by the 540 prevalence of cross-site scripting attacks). 542 Therefore, any changes cannot rely upon perfect understanding by 543 these parties, or even any great effort upon their part. This 544 implies that user interface will be one of the biggest challenges 545 faced, both in the browser and for any changes server-side. 547 Notably, the most widely understood indicator of security today is 548 the "lock icon" that shows when a connection is protected by TLS. 549 Any erosion of the commonly-understood semantics of that indicator, 550 as well as "https://" URIs, is likely to be extremely controversial, 551 because it changes the already-understood security properties of the 552 Web. 554 Another useful emerging convention is that of "Incognito" or 555 "private" mode, where the end user has requested enhanced privacy and 556 security. This might be used to introduce higher requirements for 557 the interposition of intermediaries, or even to prohibit their use 558 without full encryption. 560 5.10. User Agents Are Diverse 562 HTTP is used in a wide variety of environments. As such there can be 563 no assumption that a user is sitting on the other end to interpret 564 information or answer questions from proxies. 566 5.11. RFC2119 Doesn't Define Reality 568 It's very tempting for a committee to proclaim that proxies "MUST" do 569 this and "SHOULD NOT" do that, but the reality is that the proxies, 570 like any other actor in a networked system, will do what they can, 571 not what they're told to do, if they have an incentive to do it. 573 Therefore, it's not enough to say that (for example), "proxies have 574 to honor no-transform" as HTTP/1.1 does. Instead, the protocol needs 575 to be designed in a way so that either transformations aren't 576 possible, or if they are, they can be detected (with appropriate 577 handling by User Agents defined). 579 5.12. It Needs to be Deployable 581 Any improvements to the proxy ecosystem MUST be incrementally 582 deployable, so that existing clients can continue to function. 584 6. Potential Areas to Investigate 586 Finally, this section lists some areas of potential future 587 investigation, bearing the principles suggested above in mind. 589 6.1. Improving Proxy.Pac 591 Many of the flaws in proxy.pac can be fixed by careful specification 592 and standardization, with active participation by both implementers 593 and those that deploy it. 595 6.2. TLS Errors for Proxies 597 HTTP's use of TLS [RFC2818] currently offers no way for an 598 interception proxy to communicate with the user agent on its own 599 behalf. This might be necessary for network authentication, 600 notification of filtering by hostname, etc. 602 The challenge in defining such a mechanism is avoiding the opening of 603 new attack vectors; if unauthenticated content can be served as if it 604 were from the origin server, or the user can be encouraged to "click 605 through" a dialog, it has severe security implications. As such, the 606 user experience would need to be carefully considered. 608 6.3. HTTP Errors for Proxies 610 HTTP currently defines two status codes that are explicitly generated 611 by a proxy: 613 o 504 Gateway Timeout ([RFC7231], Section 6.6.5) - when a proxy (or 614 gateway) times out going forward 616 o 511 Network Authentication Required ([RFC6585], Section 6) - when 617 authentication information is necessary to access the network 619 It might be interesting to discuss whether a separate user experience 620 can be formed around proxy-specific status codes, along with the 621 definition of new ones as necessary. 623 6.4. TLS for Proxy Connections 625 While TLS can be used end-to-end for "https://" URIs, support for 626 connecting to a proxy itself using TLS (e.g., for "http://" URIs) is 627 spotty. Using a proxy without strong proof of its identity 628 introduces security issues, and if a proxy can legitimately insert 629 itself into communication, its identity needs to be verifiable. 631 6.5. Improved Network Information 633 Many of the use cases for proxies that modify content is transcoding 634 or otherwise adapting that which is too "heavy" for the network it is 635 transiting through. 637 If network operators made better, more fine-grained and timely 638 information about their operational characteristics freely available, 639 endpoints (server and client) could adapt requests and responses to 640 reflect it, thereby removing the need for intermediation. 642 6.6. Improving Trust 644 Currently, it is possible to exploit the mismatched incentives and 645 other flaws in the CA system to cause a browser to trust a proxy as 646 authoritative for a "https://" URI without full user knowledge. This 647 needs to be remedied; otherwise, proxies will continue to man-in-the- 648 middle TLS. 650 6.7. HTTP Signatures 652 Signatures for HTTP content - both requests and responses - have been 653 discussed on and off for some time. 655 Of particular interest here, signed responses would allow a user- 656 agent to verify that the origin's content has not been modified in 657 transit, whilst still allowing it to be cached by intermediaries. 659 Likewise, if header values can be signed, the caching policy (as 660 expressed by Cache-Control, Date, Last-Modified, Age, etc.) can be 661 signed, meaning it can be verified as being adhered to. 663 Note that properly designed, a signature mechanism could work over 664 TLS, separating the trust relationship between the UA and the origin 665 server and that of the UA and its proxy (with appropriate consent). 667 There are significant challenges in designing a robust, widely- 668 deployable HTTP signature mechanism. One of the largest is an issue 669 of user interface - what ought the UA do when encountering a bad 670 signature? 672 7. Security Considerations 674 Plenty of them, I suspect. 676 8. Acknowledgements 678 This document benefits from conversations and feedback from many 679 people, including Amos Jeffries, Willy Tarreau, Patrick McManus, 680 Roberto Peon, Guy Podjarny, Eliot Lear, Brad Hill, Martin Nilsson and 681 Julian Reschke. 683 9. References 685 9.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 9.2. Informative References 692 [I-D.mbelshe-httpbis-spdy] 693 Belshe, M. and R. Peon, "SPDY Protocol", draft-mbelshe- 694 httpbis-spdy-00 (work in progress), February 2012. 696 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 698 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 699 Replication and Caching Taxonomy", RFC 3040, January 2001. 701 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 702 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 704 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 705 6455, December 2011. 707 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status 708 Codes", RFC 6585, April 2012. 710 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 711 "TCP Extensions for Multipath Operation with Multiple 712 Addresses", RFC 6824, January 2013. 714 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 715 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 716 2014. 718 [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 719 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014. 721 [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext 722 Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June 723 2014. 725 [W3C.NOTE-ct-guidelines-20101026] 726 Rabin, J., "Guidelines for Web Content Transformation 727 Proxies 1.0", World Wide Web Consortium NOTE NOTE-ct- 728 guidelines-20101026, October 2010, 729 . 731 [https-everywhere] 732 EFF, ., "HTTPS Everywhere", 2013, . 735 [proxypac] 736 various, ., "Proxy Auto-Config", 2013, 737 . 739 [tls-mitm] 740 Jarmoc, J., "SSL/TLS Interception Proxies and Transitive 741 Trust", 2012, . 744 [wpad] Cohen, J., "Web Proxy Auto-Discovery Protocol", 1999, 745 . 747 Author's Address 749 Mark Nottingham 751 Email: mnot@mnot.net 752 URI: http://www.mnot.net/