HTTPS and delegation of encrypted traffic between interconnected CDNs

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 for some reasons, 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 that are presented in the requirements section. 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. and ). This document is intended as a starting point for discussion. It shall review redirection methods introduced in 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.

A trusted and secured delegation of the delivery of content hosted by an uCDN to a downstream CDN (dCDN) must be guaranteed in the CDN interconnection. Actually, this requirement must entail the following: Legitimacy of redirection: the uCDN must wilfully designate the dCDN to deliver the requested content to ensure the delegation is legitimate. End-users must be warned about any issues in the delegation process, e.g. bad certificate. This is typically ensured by the browser (or player). Revocation use case: A revocation might occur when a dCDN is not trusted anymore by the uCDN in case of policy or security concerns, i.e. the dCDN surrogates has unsolved security issues, or the delegation of HTTPS content delivery for a particular CP has been terminated. For instance, in case of revocation, a dCDN must not be able to present the CP or uCDN certificate to the user agent when UA has directly requested a content to the dCDN. CDN configuration/topology visibility: Reduce CDN configuration, topology and meta-data disclosure/visibility towards the end-users. This means to 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; this may imply for instance to remove data in the redirection messages.

In a secured CDN interconnection where uCDN 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 (please refer to ): using an HTTP-based mechanism, the UA is redirected by the uCDN to the dCDN. 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 the dCDN domain name. using DNS routing, the UA is redirected to the dCDN, e.g., with a CNAME sent by the uCDN's authoritative DNS server. Next the UA 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.

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: 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. 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, the TLS handshake 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. The 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 uCDN. The delegation is trusted and legitimate even if two independent TLS sessions will have to be set up in sequence by the UA. Indeed, when tying two sessions together, the authenticated origin uCDN communicates the target URI in the redirection message over an encrypted tunnel, which constitutes a trust delegation endorsement. However the issue here is when a uCDN invalidates the delegation to dCDN for some reasons. The dCDN will then still be able to stream the content with a valid certificate if an end-user directly requests content to it. 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 typically be 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 content is 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). In another more complex case, both the uCDN and the dCDN may deliver some of the video chunks.

In the API mode (e.g. via AJAX requests, JSONP, etc.), a web page requested by the browser contains a script that "transparently" - from the user's perspective - requests content on another web page. As far as CDNI is concerned, the initial web page and scripts would be located on domain A, whereas content 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 security issues likewise in other HTTP-based redirection cases.

In the case of DNS-based redirection, prior to any HTTP delivery requests, the UA has to first 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 redirection 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 domain 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 may compromise the delegation security. The CDNI Redirection draft () 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, upon querying the hostname associated with the uCDN URL, the DNS resolver will receive a DNS response (such as CNAME) that will direct the client to the dCDN. However, in an HTTPS environment, the client will end up with a domain different 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 related to the "HARD problem" draft ("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 explicitly designated the dCDN as its delegate. However, DNSSEC adoption remains limited, 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.

Delegating the delivery of HTTPS traffic to a third party without any certificate issues 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 and breaks the delegation revocation use cases. The proposed solution here relies on the introduction of a Private Key Server in the TLS handshake as described in the Lurk draft that suggests several use cases of private key server and protocols implementation. Some solutions implementing private Key Servers are being standardized. For instance, the Session Key interface - SKI - draft shows an example of Lurk interface implementation. Others are commercially deployed and are made publicly available. A Lurk interface implementation for CDNI would allow the private keys to remain under the authority of the content provider (or the uCDN) while the actual content would be served from a dCDN surrogate that is closer to the end user. Indeed, the architecture would introduce a split in the setup of the secure tunnel between the client's browser and the surrogate delivering the content. Since the dCDN would not possess the private keys for the requested certificate, during the setup of the TLS tunnel between the client and the dCDN surrogate. The dCDN would in turn forward a request to get the necessary credentials to establish the secure connection to the end-user and serve the content. Note that a Lurk interface would allow provisioning certificates to the dCDN and avoids any private keys exchanges between uCDN and the dCDN involved in the delegation. The implementation of Lurk need to be used jointly with DNS redirection.

Two main use cases shall be considered when implementing Lurk in the CDNI context: "Nominal" case for HTTPS delegation: a uCDN delegates the HTTPS content delivery to a dCDN without providing with its private keys for legal/trusting issues. In this case, only the uCDN would need a valid certificate, whereas the dCDN would rely on session key received from the uCDN Key Server (KS) for the TLS session establishment. Therefore the dCDN will deliver HTTPS content using the uCDN certificate. Cascaded HTTPS delivery delegation: This use case has a wider scope that the previous use case. In the context, the content provider delegates the HTTPS content delivery of his content to an uCDN, that in turn delegates the HTTPS delivery to a dCDN. For security reasons, the CP do not want to provide his private keys to all CDNs involved in the interconnection hierarchy. In that case, the uCDN and all dCDN will rely on the CP private keys received from a Key Server (KS) on CP side to deliver HTTPS content.

This section describes basic implementations of Lurk for CDNI secured traffic delegation (case a.). In the following example, the CP has provided his certificate to the uCDN. As seen on figure 2, once the DNS resolution is done (i.e., UA is able to resolve dCDN surrogate IP@ steps a to d), the user agent connects to the dCDN surrogate. Also please note that DNS cache is not shown on the figure. 1. The client sends a ClientHello, as defined in the TLS protocol . 2. The surrogate sends a ServerHello. 3. The surrogate sends the public certificate to the user agent. The user agent checks the certificate signature with the public key. In order to prepare the certificate delegation, it may be necessary to provision CP public certificates hosted on the Key Server, on uCDN or CP side, to the dCDN that will be requested the content. Please refer to fig. 3. A request is sent by the dCDN to uCDN KS to get the CP Public certificate. 4. The surrogate requests the key server to sign parameters with the private key. 5. The key server returns the signature to the dCDN surrogate over a secure tunnel. 6. and 7. the client and the surrogate exchange public DH parameters and compute session keys. 8. The end-user terminal and the surrogate establish a secure connection. The user agent issues its request for content over HTTPS. The surrogate then processes the original request. Below is an example of the handshake establishment:

| | | | | |b. DNS CNAME dCDN | | | |<----------------------------------------------------------------| | | | | |c. DNS A? dCDN | | | |------------------->| | | | | | | |d. DNS A IP Surrogate | | |<-------------------| | | | | | | |1. ClientHello (Client Random) | | |------------------->| | | | | | | |2. ServerHello (Server Random) | | |<-------------------| | | | | | | |3. Certificate (Server certificate) | | |<-------------------| | | | | | | | |4. API request for Signature (ECDHHParams) | | |------------------>| | | | | | | |5. API response: signature (ECDHHParams) | | |<------------------| | | | | | |6. ServerKeyExchange (ECDHParams, Signature) | |<-------------------| | | | | | | |7. ClientKeyExchange (clientDHpublic) | | |------------------->| | | |Finished | | | |<------------------>| | | | | | | |8. HTTPS request | | | |------------------->| | | ]]> Figure 2: Overview of Lurk interface with DH handshake in case of regional delivery delegation As shown on figure 4, a similar implementation can be considered for RSA keys handling. Note that next after step 1, the dCDN may have to retrieve [at least once] the CP public certificate related to the targeted FQDN. This could be done using specific API methods dedicated to certificate retrieval. The certificates may be cached on the dCDN for a given duration. See next figure. This Lurk API may have to support both RSA (cf. figure 4) and/or Diffie-Helman (cf. figure 2) connection setup.

| | | | | | | | |a. API: Request FQDN CP public certificate | | |------------------>| | | | | | | |b. API: CP Public certificate (cacheable) | | |<------------------| | | ... | | | ]]> Figure 3: Optional steps for a dCDN to get the uCDN public certificate (public certificates may be cached on the dCDN for a given duration)

HTTPS: currently, the contents are delivered with the credentials of uCDN or dCDN. The introduction of a key server in the CDNI architecture allows the HTTPS content to be delivered with the origin server certificate. It conforms to the end-to-end HTTPS framework . TLS: it does not significantly impact the TLS session establishment duration, while benefiting from TLS session resuming. Certificates: a certificate per CP would be stored and managed by the uCDN (or the CP) in a private KS is needed for the CDNI. Therefore it avoids the complexity of having multiple certificates and domain names, e.g. one domain name per CDN of the interconnection. As a side effect, it could also prevent certificates mismatches and help warning the user at user agent side, while ensuring the legitimacy of redirection. Security: the dCDN has never access to the uCDN (or CP) private keys, as it rely on the uCDN (or CP) certificate to setup the connection. Revocation: in the case of an HTTPS delegation revocation, a dCDN has no longer the delegation right to deliver a content for a given CP. The uCDN would then deny access to CP certificates, and therefore the dCDN would not be able to present the CP certificate to the UA. RSA: the use of RSA scheme is not recommended as the UA needs to share premaster secret key which can be a security flaw. Use cases: other use cases, e.g. the dCDN would manage its own keys/cert in a Key Server that would be requested by the uCDN, will be described in a further version of this draft.

Another means of enforcing trust delegation would be to use CDNI URI Signing mechanism. The CDNI URI Signing draft specifies a detailed mechanism to ensure the 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 mechanism 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 Section 5 considers the possibility of using "probes" of this form, and the potential topology leakage of any redirection interface.

This document has no IANA considerations.

The entire document is about security.

The authors would like to thank Iuniana Oprescu and Sergey Slovetskiy for the initial authoring of this draft. Many thanks also to Jon Peterson, Jan Seedorf, and Ben Nivens-Jenkins for their help in putting this draft together.