| 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
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).
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 (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.
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:
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.
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:
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:
This section deals with HTTP-based redirection methods for secured TLS connections in CDNI.
When dealing with redirection over HTTP/S, two sub-cases should be considered:
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 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.
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.
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 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.
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.
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, 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.
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.
+----+ +--+ +---+ +---+ |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
CDNI URI Signing [I-D.leung-cdni-uri-signing] draft specifies a detailed mechanism to ensure validation of parameters communicated in the redirection URI.
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.
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.
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 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.
Below is an example of the handshake establishment:
+----+ +----+ +---+ +---+ | 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
This document has no IANA considerations.
The entire document is about security.
The authors would like to thank Jon Peterson, Jan Seedorf, and Ben Nivens-Jenkins for their help in putting this draft together.
| [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. |
| [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. |
| [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", Internet-Draft draft-barnes-hard-problem-00, July 2010. |
| [I-D.ietf-cdni-redirection] | Niven-Jenkins, B. and R. Brandenburg, "Request Routing Redirection Interface for CDN Interconnection", Internet-Draft draft-ietf-cdni-redirection-13, 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)", Internet-Draft draft-leung-cdni-uri-signing-05, 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. |