idnits 2.17.1 draft-richsalz-httpbis-https-downgrade-02.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.) ** The abstract seems to contain references ([RFC7258]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 19, 2019) is 1674 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPWG B. Sniffen 3 Internet-Draft M. Bishop 4 Intended status: Best Current Practice E. Nygren 5 Expires: March 22, 2020 R. Salz 6 Akamai Technologies 7 September 19, 2019 9 Best practices for TLS Downgrade 10 draft-richsalz-httpbis-https-downgrade-02 12 Abstract 14 Content providers delivering content via CDNs will sometimes deliver 15 content over HTTPS (or both HTTPS and HTTP) but configure the CDN to 16 pull from the origin over cleartext and unauthenticated HTTP. From 17 the perspective of a client, it appears that their requests and 18 associated responses are delivered over HTTPS, while in reality their 19 requests are being sent across the network in-the-clear and responses 20 are delivered unauthenticated. This exposes user request data to 21 pervasive monitoring [RFC7258]; it also means response data may be 22 tampered with by active adversaries. Terminating TLS connections on 23 a load balancer and contacting a backend over cleartext has long been 24 common within data centers, but doing this TLS termination and 25 downgrade to HTTP at a CDN introduces additional risk when the 26 unprotected traffic is sent over the general Internet, sometimes 27 across national boundaries. 29 While it would be nice to say "never do this," customer demand, 30 content provider use-cases, and market forces today make it 31 impossible for CDNs to not support downgrade. However, following a 32 set of best practices can provide visibility into when this is 33 happening and can reduce some of the risks. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on March 22, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Background and Motivation . . . . . . . . . . . . . . . . . . 2 69 2. Recommended alternatives . . . . . . . . . . . . . . . . . . 4 70 3. Potential risk mitigations . . . . . . . . . . . . . . . . . 4 71 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Alternative approaches . . . . . . . . . . . . . . . . . . . 5 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 6.1. Risks of doing downgrade . . . . . . . . . . . . . . . . 6 75 6.2. Control of the network between the cache and the origin . 6 76 6.3. Confused-deputy issues at the browser or origin . . . . . 6 77 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Background and Motivation 83 Browsers are helping drive a push to universal HTTPS through a 84 variety of mechanisms, including: 86 o Show HTTP as "not secure" 88 o Showing mixed-content warnings when images or advertisements are 89 HTTP on an HTTPS base page 91 o Making "powerful" new web features available only for HTTPS 93 On mobile, app stores sometimes require HTTPS for acceptance. 95 These factors have pushed many content providers to quickly enable 96 HTTPS, even when their origin infrastructure is not ready or not 97 perceived as being ready. Being able to use a CDN to convert HTTPS 98 to HTTP has been looked at as a fast path for getting onto HTTPS 99 quickly. Doing this has value in protecting requests and responses 100 over the last mile, but admittedly does not address or worsens some 101 other types of attacks (such as pervasive monitoring, or corruption 102 and manipulation of content crossing national boundaries). 104 Delivering content over HTTPS but fetching it insecurely over HTTP is 105 done for a variety of reasons, some of which have historic 106 motivations with better alternatives today, but where content 107 providers are resistant to change. This includes: 109 o Lack of HTTPS support in origin infrastructure, such as due to 110 using load balancing hardware that does not support HTTPS, has bad 111 performance characteristics with HTTPS, or which only supports 112 SSLv3. 114 o A perception that HTTPS is more expensive to deliver. In some 115 cases content providers may have origin infrastructure using old 116 hardware where this is a real challenge and they lack the budget 117 to upgrade to servers or load balancers that can handle HTTPS 118 well. 120 o A perception that using HTTPS introduces performance issues, such 121 as due to the additional round trips required to establish 122 connections. This can be a real issue for origins that lack 123 persistent connection or session resumption support. 125 o Challenges in managing origin certificates, or a perception that 126 it is hard to get TLS certificates. Automation with providers 127 such as LetsEncrypt help here, but some content provider origins 128 may be using software or hardware elements that don't yet 129 integrate well with Auto-DV or may have organizational policies 130 against using DV certificates. 132 o Delivering the same library of content to end-users over both HTTP 133 and HTTPS, but wanting the CDN to cache any given object only 134 once. This can be better addressed by always fetching content via 135 HTTPS and storing in a cache accessible for both HTTP and HTTPS 136 requests, but this faces challenges for transitioning from an 137 entirely HTTP-fetched-and-served content library to one that is 138 served over a mixture of HTTP and HTTPS. 140 o A perception that there is no risk to their users or brand 141 reputation, sometimes due to thinking of pervasive monitoring and 142 content manipulation as esoteric threats that don't apply in their 143 case. For example, content providers delivering on-demand 144 streaming movies may not see a threat from using HTTP and may view 145 DRM as addressing most of their immediate concerns. 147 There is also a closely-related issue where content delivered over 148 HTTPS has been pushed to origin infrastructure over an insecure 149 protocol. For example, content uploaded to a storage service over an 150 insecure protocol such as FTP, or live streams pushed from encoders 151 to ingest entry points over an insecure protocol. This has the added 152 risk that authenticators may be unprotected on-the-wire. 154 2. Recommended alternatives 156 The "right thing" to do is to use modern secure protocols and 157 cryptography for secrecy and authentication for the request and the 158 response when interacting with content origin sources: HTTPS for 159 pull-through caches, and protocols such as SCP or SFTP or FTP-over- 160 TLS or HTTPS POSTs for pushed data. 162 Origin sites that avoided TLS for fear of a performance hit should 163 collect data on the actual costs with modern implementations and 164 modern crypto-support hardware. These are expected to be under 2% 165 CPU overhead, especially when persistent connections are enabled. 166 Auto-DV certificate management can make origin certificate management 167 straight-forward and automateable. 169 3. Potential risk mitigations 171 An intermediate cache can take several actions to reduce the risk of 172 unpleasant consequences from using TLS downgrade - though these 173 practices do not eliminate that risk. They take two general 174 strategies: 176 1. Informing the endpoints that this downgrade is in place. End 177 points have more information about the details of the connection, 178 and can expose details to human controllers. For example, 179 returning a response header such as "Protocol-To-Origin: 180 cleartext" and preventing customers from removing it. Clients 181 may then choose some manner in which to expose this to end-users. 182 (Some other proprietary implementations of this response header 183 have included "X-Forward-Proto: http" and "CDN-Origin-Protocol: 184 http".) 186 2. Restricting the sort of data in transit when downgrading from 187 HTTPS to cleartext HTTP. Examples of this include: 189 * Limiting to GET methods. This prevents unauthenticated writes 190 to the origin. 192 * Refusing to downgrade requests for "/" , "/index/", or 193 "/index.html". This prevents accidental delivery of the 194 entire site. The goal is to rapidly detect a misconfiguration 195 with too much downgrading by breaking the site. 197 * Limiting the content types or file extensions (e.g., to 198 streaming media or other static media assets). 200 * Stripping outgoing request headers containing potential 201 identifiers (Cookie, etc) 203 * Stripping query strings 205 In practice, stripping query strings breaks an enormous amount of Web 206 traffic: searches, beacons, and the selection apparatus of streaming 207 media clients. Mechanisms that rely on lists of what is allowed 208 (file extensions) or what is banned (such as "Cookie" headers) rely 209 on an implausibly detailed and up-to-date models of Web use. 211 Other headers that may wish to be stripped from outgoing requests 212 include "X-Forwarded-For", "Origin", "Referer", "Cookie", "Cookie2", 213 and those starting with "Sec-" or "Proxy-". 215 4. Recommendations 217 It is recommended that CDNs do at least the following as default 218 behaviors as part of TLS downgrade: 220 o Providing and encouraging better alternatives (such as always 221 fetching securely over HTTPS but making static objects available 222 in a shared cache that can also be accessed via HTTP requests). 224 o Returning a "Protocol-To-Origin: cleartext" response header (which 225 may be a comma-separated list of protocols when multiple hops are 226 involved). 228 o Limiting downgrade requests to GET. 230 o Refusing requests for "/" , "/index/",or "/index.html". 232 o Strip at least some headers that may include personal identifiers 233 or sensitive information. 235 5. Alternative approaches 237 Some other approaches may also help address the risks: 239 o Use a VPN or IPSEC or other secure channel between the CDN and the 240 origin. 242 o Validate asymmetric signatures of content at the CDN before 243 serving, such as for software downloads. This helps with 244 integrity, but still exposes confidentiality risks. 246 6. Security Considerations 248 6.1. Risks of doing downgrade 250 Downgrades allow protection of last-mile connections to end-users, 251 but they make it easier for adversaries who control the network 252 between CDN caches and origin (such as at national boundaries) to 253 poison caches or perform surveillance (as correlation attacks are 254 possible, even if ostensible PII information is stripped at the CDN.) 256 6.2. Control of the network between the cache and the origin 258 ISPs on the HTTP path, including nation states at their borders, can 259 surveil traffic. They can expect to get end-user IP information from 260 "X-Forwarded-For" or similar. In some circumstances, they can learn 261 more from correlated timing and sizes. This is principally a risk to 262 _secrecy_. 264 Active adversaries can also corrupt or modify content. 266 For executable content (such as software downloads or javascript) 267 this can be used to compromise clients or web pages, especially if no 268 end-to-end secure integrity validation is performed. Even when 269 software downloads have signature validation performed, this can 270 provide a potential exposure for downgrade attacks, depending on 271 client-side implementations. 273 For site and media content, modification can be used to make content 274 appear as authoritative to a user (delivered via HTTPS from a 275 "trusted site") while actually containing selective modifications of 276 the attackers choice, such as for the financial or political benefit 277 of the attacker. 279 6.3. Confused-deputy issues at the browser or origin 281 HTTP clients make different decisions based on whether they are using 282 HTTPS or HTTP - for example, they send Secure cookies (cite), they 283 enable certain Web features (high-resolution location, Service 284 Workers). This is principally a risk to _authentication_. 286 This attack is only available with downgrade. A related attack is 287 available in the case of HTTP _upgrade_, in which a server makes a 288 similar decision based on seeing HTTPS on its end of the connection. 289 In cases where HTTP requests are upgraded to HTTPS, CDN or proxy 290 operators need to work with origin operators to control this 291 complexity and prevent the complementary attack, such as by only 292 performing upgrades for cache-able, static, and idempotent content. 294 7. Normative References 296 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 297 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 298 2014, . 300 Appendix A. Acknowledgements 302 Thank you to Suneeth Jayan and others at Akamai who have helped 303 develop best practices. Future versions of this draft hope to also 304 incorporate best practices developed elsewhere. 306 Authors' Addresses 308 Brian Sniffen 309 Akamai Technologies 310 145 Broadway 311 Cambridge 02139 312 US 314 Email: bsniffen@akamai.com 316 Mike Bishop 317 Akamai Technologies 318 145 Broadway 319 Cambridge 02139 320 US 322 Email: mbishop@akamai.com 324 Erik Nygren 325 Akamai Technologies 326 145 Broadway 327 Cambridge 02139 328 US 330 Email: nygren@akamai.com 331 Rich Salz 332 Akamai Technologies 333 145 Broadway 334 Cambridge 02139 335 US 337 Email: rsalz@akamai.com