HTTPS and delegation of encrypted traffic between interconnected CDNs
draft-fieau-https-delivery-delegation-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Frédéric Fieau , Iuniana Oprescu , Sergey Slovetskiy | ||
| Last updated | 2015-10-19 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fieau-https-delivery-delegation-01
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,
<http://www.rfc-editor.org/info/rfc3568>.
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, <http://www.rfc-editor.org/info/rfc6698>.
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]