When HTTPS Meets CDN: A Case of Authentication in Delegated Service

Abstract

Content Delivery Network (CDN) and Hypertext Transfer Protocol Secure (HTTPS) are two popular but independent web technologies, each of which has been well studied individually and independently. This paper provides a systematic study on how these two work together. We examined 20 popular CDN providers and 10,721 of their customer web sites using HTTPS. Our study reveals various problems with the current HTTPS practice adopted by CDN providers, such as widespread use of invalid certificates, private key sharing, neglected revocation of stale certificates, and insecure back-end communication. While some of those problems are operational issues only, others are rooted in the fundamental semantic conflict between the end-to-end nature of HTTPS and the man-in-the-middle nature of CDN involving multiple parties in a delegated service. To address the delegation problem when HTTPS meets CDN, we proposed and implemented a lightweight solution based on DANE (DNSbased Authentication of Named Entities), an emerging IETF protocol complementing the current Web PKI model. Our implementation demonstrates that it is feasible for HTTPS to work with CDN securely and efficiently. This paper intends to provide a context for future discussion within security and CDN community on more preferable solutions.

CDN-on-Demand: An Affordable DDoS Defense via Untrusted Clouds

“…In Figure 1 we present the usage distribution of commercial CDN providers among the 32K most popular websites (according to Alexa website-popularity rank [5]). 1 Line 1 of Figure 1 confirms earlier studies [24], [27]: most websites do not use CDNs, and furthermore, use of CDN declines for less-popular sites (from the 2000 place onwards). Note that larger organizations often use their own infrastructure instead of an external CDN provider.…”

“…In particular, the CDN market is dominated by a few providers [24], [27], resulting in a less-competitive market and hence higher costs. To distribute content in face of strong DoS attacks, CDNon-Demand deploys proxy servers on multiple Infrastructureas-a-Service (IaaS) cloud providers, optimizing resource use to minimize expenses.…”

“…In order to securely use such less expensive -and less trusted -providers, CDN-on-Demand does not require entrusting providers with the website's private key or certificate. This also solves an important concern with CDNs [24]. We achieve this property by protecting the website content, delivered to clients from CDN-on-Demand, using a novel clientless secure-objects mechanism.…”

“…Currently, the only contentsecurity mechanism available using standard web clients is HTTPS (i.e., SSL/TLS), securing the communication channel between clients and proxies, but leaving the proxy with complete access to the content. Furthermore, Liang et al [24] show that there are currently two options to support HTTPS connections using CDNs, both problematic. In the first option, the website shares its private key with the CDN; this presents challenges, for example when the website decides to switch to another CDN provider.…”

Upgrading HTTPS in mid-air: An Empirical Study of Strict Transport Security and Key Pinning

“…Other empirical studies of the TLS ecosystem have focused on certificate validation libraries [66], non-browser TLS libraries [67], the interaction of HTTPS with content-delivery networks [68], and TLS implementations in Android apps [69], [70]. Again, these efforts all found widespread weaknesses.…”