Internet Engineering Task Force F. Fieau Internet-Draft I. Oprescu Intended status: Standards Track Orange Expires: April 21, 2016 S. Slovetskiy October 19, 2015 HTTPS and delegation of encrypted traffic between interconnected CDNs draft-fieau-https-delivery-delegation-01 Abstract This document provides a basic non exhaustive background and discusses potential approaches to the issue of correct delegation of the encrypted TLS-based traffic requests between CDNs in inter CDN networks and during interactions between client User Agents (UA), and Content Delivery Networks (CDNs). 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 April 21, 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 Fieau, et al. Expires April 21, 2016 [Page 1] Internet-Draft HTTPS delivery delegation October 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Problem Scope . . . . . . . . . . . . . . . . . . . . . . . . 3 3. HTTP-based redirection methods . . . . . . . . . . . . . . . 4 3.1. 3xx directives . . . . . . . . . . . . . . . . . . . . . 4 3.2. URL Rewriting . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. URL Rewriting for Video Contents . . . . . . . . . . 5 3.3. API Mode, or scripted redirection (e.g. via AJAX requests, JSONP, etc.) . . . . . . . . . . . . . . . . . 6 4. DNS redirection . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. a DNSSEC-based approach . . . . . . . . . . . . . . . . . 7 5. Enforcing trust delegation: CDNI URI Signing . . . . . . . . 8 6. Topology hiding . . . . . . . . . . . . . . . . . . . . . . . 9 7. TLS API for third-party . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction In the interconnected CDNs context where CDNs are organized into a hierarchy, an upstream CDN (uCDN) that is not able to deliver the requested content, may need to delegate the delivery to a downstream CDN (dCDN). When end-users' connections are transported over TLS, this delivery delegation involves security requirements such as: o Ensuring the trusted delegation of the delivery of contents hosted by a uCDN to the downstream CDN (dCDN), i.e., that uCDN has wilfully designated the uCDN to deliver the content, thus ensuring the delegation is legitimate. o Ensuring a seamless security scheme when redirecting users' requests from a uCDN to a dCDN, i.e., the certificates received by the browser are valid and are tied to the domain for which the delegation occurs. For instance, an User Agent (UA) might request a piece of content from a upstream CDN (uCDN), and if the uCDN cannot serve the content, it may redirect the request to a downstream CDN (dCDN). Because the uCDN shall trust in that case the dCDN to deliver the content, this delegation should ideally not trigger a security warning in the user's browser. Fieau, et al. Expires April 21, 2016 [Page 2] Internet-Draft HTTPS delivery delegation October 2015 o Guaranteeing the confidentiality of CDNs configuration and topology information, i.e. keep this information hidden from each CDNs, and from the end-user browser. As an example, the end-user shall not be aware of the CDNI topology. A brief survey indicates that there is a multitude of ad hoc approaches for handling TLS-based traffic in CDN environment. However, many of the currently adopted practices seem to have problems of various nature, inhibiting and compromising security, scalability, and ease of operation and maintenance (see e.g. [HTTPS-CDN] and [SSL-Challenges]). This document is intended as a starting point for discussion. It shall review redirection methods introduced in [RFC3568] used in the Interconnected CDNs use case, their impacts on the security of delegation, and the implications of redirection in a secured web environment. It eventually identifies some workarounds, or solutions to the raised issues. o HTTP-based redirection methods: 3xx, URL rewriting, API based o DNS-layer redirection 2. Problem Scope In a secured CDN interconnection model where aCDN and a dCDN have two distinct domains, the User Agent (UA) tries first to resolve the uCDN domain when it contacts the uCDN for a piece of content. At this step, two types of redirection methods can be considered, both delegating the content delivery to the dCDN: o using DNS routing, the UA is redirected to the dCDN, e.g., with a CNAME sent by the uCDN authoritative DNS server. o the UA is redirected by the uCDN to the dCDN using a HTTP-based mechanism: Once the uCDN domain is resolved, the UA negotiates a secured connection to the uCDN for that content, and receives the uCDN certificate. Then the uCDN subsequently uses an HTTP redirection method to redirect the UA to a dCDN surrogate content server. Then, the UA resolves dCDN domain name, and then negotiates a new secured connection with the dCDN, retrieving the dCDN certificate. If the certificate is valid, then the UA will be able to connect to the dCDN surrogate, and the dCDN will deliver the requested piece of content to the UA. Both cases raises security issues in a CDNI environment: Fieau, et al. Expires April 21, 2016 [Page 3] Internet-Draft HTTPS delivery delegation October 2015 o How to ensuring that the delegation is legitimate? In DNS, this cannot be ensured without additional cryptographic measures (see DNS redirection related section) contrary to HTTPS, refer to HTTP- based redirection methods section for more details. o How to ensure that certificates received by the browser are valid and are tied to the domain for which the delegation occurs? This is may not be the case if uCDN and dCDN don't share the same domain name, see related [redirection methods] section and [TLS API] section for more details. o How to guarantee the confidentiality of CDNs configuration and topology information? The UA may be able to discover the CDNI topology which is not secure. Please refer to []Topology hiding] section for more details. 3. HTTP-based redirection methods This section deals with HTTP-based redirection methods for secured TLS connections in CDNI. 3.1. 3xx directives When dealing with redirection over HTTP/S, two sub-cases should be considered: o HTTP -> HTTPS: In this case, the CSP / uCDN from domain A redirects end-users' HTTP requests to the dCDN from domain B, and upgrades the security scheme to HTTPS. o HTTPS -> HTTPS: In this case, the CSP / uCDN domain A redirects the browsers' request to dCDN domain B. Regardless of DNS resolution aspects, in the first sub-case, the initial delegation will not be secured, or trusted: 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. 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 sub-case, TLS set-up happens before the first HTTP request is sent, therefore, the subsequent traffic including request URI and query parameters will be encrypted. First, the TLS session is established between the UA and the origin uCDN, authenticating the uCDN. Then, the uCDN uses HTTP mechanisms for redirection, using 3xx messages like 302 Found, embedding the new target URI aiming at the CDN surrogate in the Location header. UA then sets up a separate TLS Fieau, et al. Expires April 21, 2016 [Page 4] Internet-Draft HTTPS delivery delegation October 2015 session with the dCDN surrogate, validating the dCDN certificate. Trust relationship is implied since the redirection message has been received over the authenticated TLS tunnel with the origin uCN. The delegation is trusted and legitimate even if two independent TLS sessions will have to be set up in sequence by the UA. The trust delegation endorsement, tying two sessions together is realized by the fact that the target URI has been communicated in the redirection message by the authenticated origin uCDN over the encrypted tunnel. However the issue here is when both uCDN and dCDN domains are distinct. Indeed, the browser has received two certificates linked to two distinct domains. Therefore, the browser can't seamlessly assure the end-user that delegation has occurred on the same domain. While browser implementation determines how transparent the delegation may be to an end user, the browser may in most of the cases generate a warning message notifying the user of a secure domain change, which is not a seamless delegation. 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.2. URL Rewriting URL rewriting is a method to compute in a web page destination URLs to point at new web location while this page is rendered on the browser. This modification could be typically caused by a script embedded in the page. Alternatively, a server-side code could modify embedded URLs before the page is retrieved by a browser, including certain classes of web intermediaries. URL rewriting can therefore serves as a form of application-layer redirection. Regarding CDNI, a page served over TLS by an uCDN will prevent intermediaries from modifying URLs without the consent of the user or the uCDN. Client-side scripts pushed by the uCDN will still be secure, and then the redirection to any dCDNs via rewriting would be secure as well. 3.2.1. URL Rewriting for Video Contents In the case of HTTP Adaptive Streaming (HAS) techniques where contents are chunked in order to be played with multiple video qualities, a manifest file will describe the way the content was prepared/encoded, e.g. how many qualities, chunks size, and their Fieau, et al. Expires April 21, 2016 [Page 5] Internet-Draft HTTPS delivery delegation October 2015 network location. This manifest is requested by the player prior to any chunks. Regarding CDNI, if the manifest is available on the uCDN domain A, while video chunks are available on the dCDN domain B, the player requesting for chunks will be redirected by the uCDN to the dCDN using 3xx redirection methods (see the previous section), thus ensuring a trusted delegation but not seamless for the end-user. In another more complex case, both the uCDN and the dCDN may deliver some of the video chunks. 3.3. API Mode, or scripted redirection (e.g. via AJAX requests, JSONP, etc.) In the API mode, a web page requested by the browser contains a script that "transparently" - from the user's perspective - requests contents on another web page. As far as CDNI is concerned, the initial web page and scripts 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 fixed with an "Access-Control-Allow-Origin" header, this use case raises also the HTTPS certificate issues likewise in other HTTP-based redirection cases. 4. DNS redirection In the case of DNS-based redirection, prior to any HTTP delivery requests, the UA tries to resolve the uCDN domain, then uCDN DNS server answers with the dCDN domain name (e.g., using a CNAME) instead of the uCDN domain, thus realizing the DNS redirection to the dCDN. In that case, the actual redirect happens before the establishment of the TLS tunnel. The issue here is that the user UA expects the uCDN's certificate, but instead obtains the dCDN surrogate's certificate during the TLS handshake. Mismatch between the expected origin uCDN URI and the received dCDN URI designated in the obtained certificate causes certificate validation warnings at the UA. Eventually a client UA displays a warning to the end user requiring additional steps, which compromises the seamless delegation. 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, Fieau, et al. Expires April 21, 2016 [Page 6] Internet-Draft HTTPS delivery delegation October 2015 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 input by the end user. Consequently, this will 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. Another security issue wider than CDNI scope, related to the "HARD problem" draft [I-D.barnes-hard-problem] ("High Assurance Re- Direction") is where a malicious DNS resolver could return DNS responses (IP addresses/CNAMEs) that steer the User Agent to a malicious server. DNS response hijacking could be used to mount a DoS attack against the CDN/Content Provider as the User Agent won't be able to receive the content that it wants because it is being told to retrieve it from a server that it can't establish a TLS session to. DNSSEC would prevent that because responses would need to be signed and a malicious DNS resolver would therefore not be able to return malicious responses as it would not be able to generate properly signed DNS response. 4.1. a DNSSEC-based approach 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. Such an approach is proposed in [HTTPS-CDN] for the DANE-based [RFC6698] front-end authentication using the DNS-based redirection. We reproduce a brief overview of the proposal from [HTTPS-CDN] here as an example of a possible approach. Using DANE, an origin CSP binds target CDN's certificate with the CSP's own certificate and domain name (see section VI. B. of [HTTPS- CDN]) by adding both certificates to the CSP's TLSA record [RFC6698]. After initiating a TLS connection to target CDN surrogate, and having received CDN's certificate, the UA further issues a DNS query to request origin CSP's TLSA records. UA then is capable of validating both URIs and Certificates with those received in the TLSA record, explicitly ensuring the delegation of trust. Fieau, et al. Expires April 21, 2016 [Page 7] Internet-Draft HTTPS delivery delegation October 2015 +----+ +--+ +---+ +---+ |User| |UA| |CDN| |CSP| +----+ +--+ +---+ +---+ | 1. https://csp.com/. | | | |--------------------->| | | | | | | | | 2. csp.com A? (DNS) | | |- - - - - - - - - - - - - - - - - - - - ->| | | | | | | 3. CNAME csp.cdn.com (DNS redirect) | | |<- - - - - - - - - - - - - - - - - - - - -| | | | | | | 4. start TLS +-+ | | |- - - - - - - - >| | | | | | | | | +-+ 5. CDN's Cert | | | | | |<---------------| | | | | | | | | | | | 6. csp.com TLSA? | | | |---------------------------------------->| | | | | | | | | | 7. TLSA csp.com (CSP's and CDN's Certs) | | | |<----------------------------------------| | | | | | | | | | | | | | | |---+ | | | | | | | 8. | | | | | |<--+ Validation | | | | +-+ | | | | | 9. HTTP GET | | | | |---------------->| | | | | | | | | | 10. Content | | | | |<----------------| | | | | +-+ | | 11. Video | | | |<---------------------| | | | | | | Figure 1: DNS-based Request Routing Redirection using DANE 5. Enforcing trust delegation: CDNI URI Signing CDNI URI Signing [I-D.leung-cdni-uri-signing] draft specifies a detailed mechanism to ensure validation of parameters communicated in the redirection URI. Fieau, et al. Expires April 21, 2016 [Page 8] Internet-Draft HTTPS delivery delegation October 2015 Considering CDNI and HTTPS delegation, this URI signing mechanism could be used as means to enforce trust delegation. While this later draft focuses on the validation by the target CDN of the authenticity of the parameters communicated in the redirect URI generated by the origin CSP, CDNI URI Signing could be extended or used to include the certificate information or hashes either in the provided URI Signing Package Attribute, or in an additional Package Attribute (e.g. Redirect Authentication Attribute), reusing much of the mechanisms detailed in the draft. 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. 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. TLS API for third-party Delegating delivery of HTTPS traffic to a third party without triggering any warnings on the client's browser can be achieved if the dCDN surrogate is able to present the security credentials for the domain name in the user's initial request. One of the common practices so far has been for the content provider to directly delegate the storage of the private keys to the CDN that is delivering the content on its behalf. This solution could persist in the CDNI context, but in a scenario where delivery is done through multiple cascaded dCDN, it becomes unlikely that the content provider would be willing to share its private keys with all the parties involved. Another solution is the introduction of a Private Key Server in the TLS handshake. Such solutions are commercially deployed and several examples are made publicly available. Such a setup allows the private keys to remain under the authority of the content owner (or the uCDN) while the actual content can be served from a dCDN surrogate that is closer to the end user. Indeed, the architecture Fieau, et al. Expires April 21, 2016 [Page 9] Internet-Draft HTTPS delivery delegation October 2015 introduces a split in the setup of the secure tunnel between the client's browser and the surrogate delivering the content. Since the dCDN does not possess the private keys for the requested domain name, during the setup of the TLS tunnel between the client and the dCDN surrogate, the latter forwards the challenge to the Private Key Server which is under the control of the content owner (or the uCDN). With the response it receives, the surrogate is able to successfully establish a secure connection to the end user and serve the requested content without triggering any warnings in the client's browser. o The user agent connects to the CDN surrogate. The client sends a secret encrypted with the site's public key for the surrogate to decrypt. o The surrogate contacts the key server, authenticating itself with a certificate. The surrogate sends the encrypted secret to the key server to decrypt it. The key server returns the decrypted secret to the dCDN surrogate over a secure tunnel. o Both client and surrogate use the shared secret to establish a secure connection. The user agent issues its request for content over HTTPS. o The surrogate then processes the original request. Below is an example of the handshake establishment: Fieau, et al. Expires April 21, 2016 [Page 10] Internet-Draft HTTPS delivery delegation October 2015 +----+ +----+ +---+ +---+ | UA | | CDN| | KS| |CSP| +----+ +----+ +---+ +---+ | | | | |1. HELLO, client random #, cipher suites| | |------------------->| | | | | | | |2. public key certificate + session ID | | |<-------------------| | | | | | | | |3. Hash of client #, server #, DH param | | |------------------>| | | | | | | |4. signature of client #, server #, public key cert | |<------------------| | | | | | |5. server DH parameter, message signature | |<-------------------| | | | | | | |6. client DH parameter | | |------------------->| | | | | | | | | | | Figure 2: Overview of Keyless SSL DH handshake 8. IANA Considerations This document has no IANA considerations. 9. Security Considerations The entire document is about security. 10. Acknowledgments The authors would like to thank Jon Peterson, Jan Seedorf, and Ben Nivens-Jenkins for their help in putting this draft together. 11. References 11.1. Normative References [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms", RFC 3568, DOI 10.17487/RFC3568, July 2003, . Fieau, et al. Expires April 21, 2016 [Page 11] Internet-Draft HTTPS delivery delegation October 2015 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . 11.2. Informative References [HTTPS-CDN] J. Liang, J. Jiang, H. Duan, K. Li, T. Wan, and J. Wu, "When HTTPS Meets CDN: A Case of Authentication in Delegated Service", in 2014 IEEE Symposium on Security and Privacy (SP), 2014, pp. 67-82.. [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-13 (work in progress), October 2015. [I-D.leung-cdni-uri-signing] Leung, K., Faucheur, F., Downey, B., Brandenburg, R., and S. Leibrand, "URI Signing for CDN Interconnection (CDNI)", draft-leung-cdni-uri-signing-05 (work in progress), March 2014. [SSL-Challenges] J. Clark and P. C. van Oorschot, "SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements", in 2013 IEEE Symposium on Security and Privacy (SP), 2013, pp. 511-525. Authors' Addresses Frederic Fieau Orange 38-40 rue du General Leclerc Issy les Moulineaux 92130 FR Email: frederic.fieau@orange.com Fieau, et al. Expires April 21, 2016 [Page 12] Internet-Draft HTTPS delivery delegation October 2015 Iuniana Oprescu Orange 38-40 rue du General Leclerc Issy les Moulineaux 92130 FR Email: iuniana.oprescu@orange.com Sergey Slovetskiy Email: sergey.slovetskiy@fastmail.com Fieau, et al. Expires April 21, 2016 [Page 13]