How HTTPS-based CDN service works?

Please note that this article is my personal opinion only based on my recent study. I will verify it with more experienced CDN professionals. It is worthwhile to write it down because I hardly find any single web page with good coverage of the topic.

First of all I don’t think CDN is providing security service. That said, security is a must consideration for Internet service providers, including CDN. Core purpose of CDN is to speed up the delivery of content over Internet.

How to secure a web site? OWSAP TOP 10 Project is a great reference. (ISC)2 has recently teamed up with Security Compass to provide (ISC)2 members free CBT on each of OWASP’s Top 10 Web Application Security Risks. I highly recommend (ISC)2 members to spend 2hrs to watch them all and to get 2 CPEs:D

How to set up CDN works securely with a secure web site is the center of this article. If a web site is not secure, CDN does not help much besides availability improvement.

Some customers tell me they want to use CDN but cannot do so because their sites are (1)dynamically generated and/or (2)using HTTPS.

There are some misunderstandings about (1). NOT all components on a dynamically generated web page are generated dynamically on the fly. Most videos, graphics and scripts used in dynamically generated web pages in online banking and shopping sites etc. are static objects. These static objects are cacheable if their HTTP Cache-Control headers allow. Cacheable means CDN can be used to speed up their deliveries.

An example is the popular social networking site tumblr. The site is frequently updated with new photos & blogs posted by users. tumblr uses CDN to improve user experience. Scroll down you can see more photos displayed. Lighting fast, right?

Mark Nottingham’s Caching Tutorial is a good resource about Cache-Control header

About (2), how HTTPS works with CDN, let’s review how to use HTTPS. In essence, HTTPS is to run HTTP over SSL or TLS between endpoints (which usually are browser and web server). HTTPS mitigates man-in-the-middle attack by using SSL/TLS to encrypt data in-transit. Data at-rest is in originally format (likely unencrpted) at endpoints:

Diagram (a)

A single browser window can form multiple HTTPS connections concurrently to multiple servers and it is not necessary that all servers with the same Multi Domain/SAN or Wildcard certificate. Please also note that HTTPS does not imply authenticated access control! Let’s take my twitter page, which is open to public, as an example:
My twitter page URL:!/jiansuo
My twitter page photo URL:

For HTTPS-based CDN service, there are two common configurations:
Diagram (b)
browser——HTTPS’——CDN——HTTPS”——customer origin server(s)

Diagram (c)
browser*——HTTPS’——customer origin server(s)
browser*——HTTPS”——CDN——HTTPS”’——customer origin server(s)

*same browser window instant
HTTPS’, HTTPS” and HTTP”’ represent different independent HTTPS connections

CDN plays endpoint roles in HTTPS. In both configurations, objects in transit are encrypted. These objects can be cached/stored on CDN (as well as browser) with appropriate Cache-Control header settings. In general a CDN customer will set non-sensitive objects (likely static objects such as images and scripts) to be cacheable and sensitive objects (likely dynamic objects such html pages with user-specific information) to be non-cacheable. Customer can also choose to cache sensitive objects (e.g. confidential CAD/CAM design diagrams) on CDN and use other mechanism (e.g. token authentication, cookie, file encryption, etc.) to prevent unauthorized access.

In summary, HTTPS-based CDN service helps dynamic and SSL-protected web site by
– speeding up delivery of those cacheable objects
– preventing man-in-the-middle attack at the same security level offered by HTTPS

Comparing diagrams (a), (b) and (c), one may argue that we actually introduce a man-in-the-middle if using HTTPS-based CDN service. Yes, CDN always sits between users and web servers. How to mitigate potential risks introduced by CDN? Reputation, industry best practice and standard compliances help.

HTTPS protects data in-transit, not data at-rest.

The joy is in the journey. The Next Big Thing in our hands

People ask me why I am so passionate with my work. My answer is I am very happy and excited being part of The Next Big Thing – The Web in our hands.

Transportation was the big thing of the last century, as Horace said in the 5by5 Critical Path #40

I don’t have chance to join the development of rail and aviation industry. We have the Web now. I am glad I can participate in it! “The joy is in the journey” as Tim Cook shared in D10.

I believe the Web is The Next Big Thing and CDN will be a core component because
1.Business transactions, no matter B2B or B2C, are moving to the Web
2.Businesses will operate more regionally/globally to stay competitive and to extend market reaches
3.People expect Web will be beautiful, and available instantly anytime and anywhere. People become more and more impatient of slow Web

Twenty years ago in 1992 HTTP and Mosaic visualized the Internet. If we apply Diffusion of Innovations in the commercial application of the Web, I think we’re now in the Early Majority phase. Adoption grows much faster and creates huge demands and opportunities. Now is a great time for everyone to join the party!

In a 1996 interview, Steve Job told Wired that the Web is The Next Big Thing and there were three parts to the Web: the client, the pipes, and the servers. He envisioned that some people could come out with some very interesting Web terminals and sell some hardware.

After Steve returned to Apple, Richard Rumelt asked him “What are you trying to do? What is the long-term strategy?” “I’m going to wait for the next big thing” Steve answered with simile.

Computing power and connectivity are much more accessible now. People are ready. If someone thinks iPhone is a phone, then the iPad debuted in year 2010 was the first “very interesting Web terminal”. It took Apple twelve years to make it happens!

The Web – the client-pipe-server architecture – needs more than Apple. It involves a lot of parties to work together to make the Web delivered faster form the server thro the pipe to the client. End-to-end transmission is no longer good enough and more intelligent delivery mechanisms will evolve. Similar to the shift of computing power from mainframe to PC, Internet traffic is moving from backbone to the edge. Most of us shop at convinent stores like 7-Eleven. Most of us, if not all, will use the Web build on top of CDN.

To make the Web more user-friendly and secure are exciting opportunities too! A lot of interesting things happen!

The Web is an incredible democratizer. What are you waiting for?

In the first Men In Black, Tommy Lee Jones and Will Smith hold the “universe” in their hands to protect it. We have the Web in our hands to make it better.

My first HLS video stream delivered on CDN

Video Video Video!

I’ve been learning video stuff in the last two weeks. Video is now more accessible and people are talking about 3-Screen (TV, PC, mobile device) or TV Everywhere. Most of us watch video on our computing devices without any interest in understanding the underlying technology. Well, at least me in the past.

Where to start? is an excellent resource. First of all there are two major types of video content on Internet:
Video-on-demand (VOD) – pre-recorded video content
Live video streaming – video of live event. Because it is live so there is no “pre-recording”

In the past there were different technologies for VOD and streaming. Streaming technologies can carry VOD traffic but VOD technologies cannot be used for live. In a null shell, streaming technology enables
-the video server to send video content, live or pre-recorded, to video player (client). The player will play the video and then discard the video content.
-the video player to communicate with video server so that the video server can send different quality video to the player based on the performances of the player Internet connectivity and CPU loading of the device the player is running on. By doing so the player can provide the best viewing experience by minimizing video buffering and maximizing resources availability.
-the player to request server to send content at different portions of the video. So user can skip some parts of the video. Once the player stops playing video, server will not send video traffic to it and reduce unnecessary transmission and bandwidth usage.
-players are free in general but servers are expensive.
-beside cost, another major drawback is firewall blocking of streaming protocols

Leading vendors like Adobe and Microsoft develop different technologies and solutions:

Streaming Protocols Server Client
Adobe RTMP, RTMPE Adobe Flash Server Adobe Flash Player
Microsoft MMS Microsoft Media Server Microsoft Media Player

On the other hand, VOD technology lets player to download (e.g. via HTTP or FTP) the whole pre-recorded video file first and then play it. For long video the lengthy download time will frustrate user. Later on with HTTP Progressive Download, video file header notifies player to start playing the video if a specific amount of video content (buffer) is received by the player. HTTP Progressive Download improves user experience by reducing wait time. However, HTTP Progressive Download has two limitations:
-video content cannot be delivered dynamically to the player based on resource availability at client end. No adaption mechanism to reduce user frustration.
-waste of bandwidth since the whole video file will be downloaded to the player even the player stops playing the video.

The latest Cisco® Visual Networking Index (VNI) predicts Internet traffic will grow to 1.3 Zettabyte by 2016 and 54% will be video-on-demand or video streaming traffic. So what Internet protocols will carry most of video traffic? RTMP? MMS? HTTP?

The answer is HTTP.

A hybrid solution was evolved around year 2007 to mix the best of streaming and VOD technologies:
-use HTTP as the underlying transport layer
-divide the video content into small file segments/chunks and construct an index file to instruct the player to download different chunks based on a)different portion of the video is requested and b)resource availability

This solution is called HTTP Dynamic Streaming or Adaptive Bitrate Streaming. Benefits:
-firewall friendly
-more user-friendly. It is browser-based and therefore no need for another video player as long as browser supports it
-more economical because of using standard HTTP servers
-user can play different portions of video without much waiting and skip unnecessary file download, therefore better experience and bandwidth usage
-since it is HTTP content then CDN can be used to improve content delivery!

There are three leading vendors in HTTP Dynamic Streaming:
Apple: HTTP Live Streaming (HLS)
Adobe: HTTP Dynamic Streaming (HDS)
Microsoft: Smooth Streaming

There is a great article at about the HTTP Dynamic Streaming (in general, not just for Adobe HDS):

I would like to learn HLS first because I am an Apple user. Moreover
-both iOS and Android support HLS
Apple owns 74% of smartphone web traffic, 95% of tablet traffic
Mobile Safari is the fastest growing browser
-there is a very good article from Priya Rajagopal: Generating HTTP Live Streaming Content for iOS Devices
-EdgeCast supports HLS provides some free online encoding services (e.g. mp4 to HLS) provides some free ftp services. I can send output via ftp

I would like to end this long article by sharing my first HLS video stream delivered on CDN. Please use your iDevice to click this URL:
[update 20160309]

(The follow URL created on 20120603 is no longer functional

Sorry for the long URL because it is a CDN URL~ It is for testing purpose.

It is a 3min 16sec MTV. Count on me like one, two, three… there are twenty-one .ts segment files listed in the .m3u8 index file.