Internet Engineering Task Force F. Fieau, Ed. Internet-Draft I. Oprescu Intended status: Standards Track Orange Expires: January 7, 2016 July 6, 2015 HTTPS and delegation of encrypted traffic between interconnected CDNs draft-fieau-https-delivery-delegation-00 Abstract This document illustrates some use cases and associated problems related to delivery of HTTPS secured traffic in the context of interconnected CDNs. A common scenario is when a uCDN is delegating the delivery of encrypted traffic to a dCDN using HTTP or DNS redirection. Some potential solutions are considered. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 7, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Fieau & Oprescu Expires January 7, 2016 [Page 1] Internet-Draft HTTPS delivery delegation July 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. HTTP Request Redirection . . . . . . . . . . . . . . . . . . 2 3. URL Rewriting . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. URL Rewriting for Video Contents . . . . . . . . . . . . 4 4. API Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. DNS Request Redirection . . . . . . . . . . . . . . . . . . . 4 6. Topology hiding . . . . . . . . . . . . . . . . . . . . . . . 5 7. Existing solutions . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction CDNI deals with contents stored on hierarchical CDNs. An end user browser might request a particular piece of content from a uCDN, and if the uCDN cannot serve the content, it may redirect the request to a dCDN. Because the uCDN trusts the dCDN to deliver the content, this delegation should ideally not trigger a security warning in the user's browser. This draft shall review some methods of redirection used in the field today, their impacts on the security of delegation, in the Interconnected CDNs use case, and the implications of redirection in a web environment that has transitioned entirely to HTTPS. This document currently addresses three HTTP redirection techniques as well as one DNS redirection method employed in CDNs today: HTTP 3xx redirect URL rewriting API mode, or scripted redirection (e.g. via AJAX requests, JSONP, etc.) DNS-layer redirection 2. HTTP Request Redirection In this use case, the browser asks for a piece of ontent on a server, and the HTTP server replies with a "302 temporarily moved" message with a Location header field value containing the chosen content URL. Fieau & Oprescu Expires January 7, 2016 [Page 2] Internet-Draft HTTPS delivery delegation July 2015 In the CDNI case, we have to distinguish two sub-cases when dealing with redirections and HTTPS: o HTTP -> HTTPS: In this case, the uCDN domain A redirects end- users' HTTP requests to the dCDN domain B, and upgrades the security scheme to HTTPS. In this case, the initial delegation will not be secured; the end user will have no cryptographic assurance that the uCDN is delegating to that dCDN, even though the user may subsequently form a secure connection to the dCDN. o HTTPS -> HTTPS: In this case, the uCDN domain A redirects the browsers' request to dCDN domain B. The browser forms an initial TLS connection to domain A, receives a secure delegation, and then forms a new security association with domain B. In the first case above, the HTTPS upgrade should always be accepted automatically by the browser, on the condition that the certificate is valid and trusted (e.g., not self-signed). In the second case, the delegation is secure. Browser implementation determines how transparent the delegation may be to an end user. If a browser generates a warning message notifying a of secure domain change, that would be problematic. However, mainstream browser implementations support seamless secure redirection via HTTP 3xx responses. Ultimately, the secure delegation from a uCDN to a dCDN is entirely tractable in the HTTPS environment provided that application layer redirection such as HTTP 3xx responses is used. 3. URL Rewriting In some cases, when a web page is rendered on the browser side, embedded URLs in the page are modified in order to point at new web locations. This modification is typically caused by a script embedded in the page. Alternatively, a server-side script of some kind could modify embedded URLs before the page is retrieved by a browser, including certain classes of web intermediaries. URL rewriting can therefore serve as a form of application-layer redirection, effectively. As far as CDNI is concerned, provided that the page and the script are served over TLS, then this will prevent intermediaries from modifying URLs without the consent of the user or the uCDN, but client-side scripts pushed by the uCDN will still be secure, and then the redirection to any dCDNs via rewriting this case would be secure as well. Fieau & Oprescu Expires January 7, 2016 [Page 3] Internet-Draft HTTPS delivery delegation July 2015 3.1. URL Rewriting for Video Contents A specific case concerns the HTTP Adaptive Streaming (HAS) video contents. In this case, contents are chunked in order to be played with multiple available video qualities. To do that, a manifest file is required to describe the way the contents was prepared/encoded, e.g. how many qualities, chunks size, and their network location. The manifest file shall requested by the player prior to any chunks. Regarding CDNI, in one case the manifest could be available on the uCDN domain A, while video chunks are available on the dCDN domain B, thus making a transparent redirection. In a second, more complex case, both the uCDN and the dCDN may deliver some of the video chunks. When using HTTPS, concerns arise in both cases: if the manifest is rewritten insecurely, then 4. API Mode In the API redirection mode, the web page requested by the browser contains a script that "transparently" (not strictly from the browser's perspective) requests contents on another Web page. As far as CDNI is concerned, the initial web page would be located on domain A, whereas contents requested by the script would be located on a secondary domain B. Apart from "cross-domain" (CORS) issues that can be easily fixed with an "Access-Control-Allow-Origin" header, this use case raises also the HTTPS certificate issues likewise the first two use cases. 5. DNS Request Redirection The CDNI Redirection draft ([I-D.ietf-cdni-redirection]) specifies that in addition to HTTP, DNS redirection can be used as a means of delegation from a uCDN to a dCDN. In this case, the DNS resolver, when it queries for the hostname associated with the uCDN URL, will be served a DNS response (such as CNAME) that will direct the client to the dCDN. However, in an HTTPS environment, this will result in the client containing a domain other than the one originally specified by the URL inputted by the end user. Consequently, this will almost certainly result in a security failure when the browser attempts to negotiate TLS with the web server it contacts, as the change in domain name will be indistinguishable from a malicious attacker. Fieau & Oprescu Expires January 7, 2016 [Page 4] Internet-Draft HTTPS delivery delegation July 2015 This poses serious concerns about the use of DNS as a redirection method when HTTPS is expected for CDNI use cases. 6. Topology hiding A further security concern associated with redirection is the question of how much information a uCDN imparts to the browser, and consequently to the end user, about its policy decisions in delegating to a dCDN. This may tempt us to develop solutions that do not rely on a uCDN delegating via a redirection mechanism, either at the HTTP or the DNS layer. However, in order to preserve crucial security properties, it is likely unavoidable that a certain amount of information will be divulged to any browser or client of a CDN system. For example, consider that eventually, content will be downloaded from a dCDN cache at a particular IP address, and that consequently, information about a responsible network will always be revealed to an end user. The guidance in [I-D.ietf-cdni-redirection] Section 5 considers the possibility of using "probes" of this form, and the potential topology leakage of any redirection interface. 7. Existing solutions The problem CDNI faces with secure redirection in a pure HTTPS world is very similar to a set of known problem with secure redirection in the application layer. For example, [I-D.barnes-hard-problem] covers this question based on the experience of implementing comparable secure redirection systems in personal messaging. Any case where the client specifies an original domain name, and excepts to forge a security association a server holding a credential corresponding to that original domain name, will face certain difficulties when redirection is performed outside of the application layer, for example, in the DNS. There are several known ways to address this problem, though none is perfect. DNSSEC makes it possible to secure DNS redirections. Were CDNI to use DNSSEC for DNS based redirection, the client's resolver would have a strong assurance that the uCDN had in fact designated the dCDN as its delegate. However, DNSSEC adoption remains patchy, and consequently this may not be a practicable solution in the immediate future. While technologies like DANE which build on DNSSEC could help, they remain dependent on DNSSEC adoption. Attribute certificates are another potential solution, as a dCDN might be able to present a certificate containing a cryptographic assertion that it is an authorized delegate of the uCDN. However, attribute certificate adoption among browser vendors does not make this a viable market adoption today. Fieau & Oprescu Expires January 7, 2016 [Page 5] Internet-Draft HTTPS delivery delegation July 2015 It is also possible that a uCDN could give its private credentials to one or more dCDNs. Some virtual hosting providers in the application space have previously required this sort of credential sharing. However, this is usually very undesirable for the assignee of the credentials, and especially if they must share them with multiple parties, it significantly degrades the security of the entire architecture. Consequently, DNS redirection introduces a serious of difficulties that are more tractable at the application layer. Barring any progress in the market adoption of other solutions described above, HTTPS redirection should be preferred to DNS redirection. 8. Acknowledgments The authors would like to thank Jon Peterson and Jan Seedorf for their help in putting this draft together. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.barnes-hard-problem] Barnes, R. and P. Saint-Andre, "High Assurance Re- Direction (HARD) Problem Statement", draft-barnes-hard- problem-00 (work in progress), July 2010. [I-D.ietf-cdni-redirection] Niven-Jenkins, B. and R. Brandenburg, "Request Routing Redirection Interface for CDN Interconnection", draft- ietf-cdni-redirection-10 (work in progress), July 2015. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Authors' Addresses Fieau & Oprescu Expires January 7, 2016 [Page 6] Internet-Draft HTTPS delivery delegation July 2015 Frederic Fieau (editor) Orange 38-40 rue du General Leclerc Issy les Moulineaux 92130 FR Email: frederic.fieau@orange.com Iuniana Oprescu Orange 38-40 rue du General Leclerc Issy les Moulineaux 92130 FR Email: iuniana.oprescu@orange.com Fieau & Oprescu Expires January 7, 2016 [Page 7]