Content Delivery Network (CDN):
When you try to reach www.apple.com, you are making use of Content Delivery Network. In fact, there are chances your request would not have to reach origin at all. Instead a cached host on CDN serves your request. To know if a domain is making use of CDN, you can type host $domain_name on terminal.
To explain briefly, CDN is a distributed network of hosts that acts as proxy for the origin servers. For example, we now know www.apple.com is hosted on Akamai’s CDN. The intension of using CDN is to reduce latency, increase efficiency in uploads and downloads, decrease load on origin, quicker and secure transactions and so on. Akamai achieves this by maintaining highly-distributed network all over the globe.
In Figure 1, you will see the domain www.apple.com has a canonical name (CNAME) record to it- www.apple.com.edgekey.net. DNS does its thing, when the request comes to third-level domain while resolving, the nameserver will present this canonical name, the resolver then restarts the process with this cname all over again. Akamai is authoritative of the cname, its nameservers, now with the cname follow the mapping protocols/alogorithms that will point your resolver to the nearest host. If you are in San Jose, California, you’d be served by a host in San Jose. If you are in Bangalore, India, you’d be served by a host in Bangalore. CDNs can be so vast.
CDNs provide various services to customers. CDNs host e-commerce, health-care and government websites along with less secure domains. Secure transactions between clients and origins happen via CDNs. This brings us to a few questions- how CDNs manage customers’ digital certificates or how TLS handshake is completed between clients and the edge hosts (belonging to CDN) or when you say the request doesn’t reach the origin, how does client know what domain is the request for (because some CDNs like Akamai host thousands of domains on a single machine and the ClientHello does not have domain name information).
In this article, I will try to write down two important types of TLS technologies used by Cloudflare and Akamai Technologies (Two of major CDNs in the industry today).
Internet traffic is moving faster towards HTTPS. According to Google’s report, 73% of pages loaded in US use HTTPS up from 59% last year. Cloudflare introduced Keyless SSL to the world. CDNs or cloud vendors should posses customer’s private key in order to accomplish SSL/TLS encryption. This also means that the vendor can read the content in transit raising security concerns.
Keyless SSL:
Keyless SSL technology used by Cloudflare is a workaround to storing private keys on vendor’s platform. Cloudflare does this by transferring the steps in the handshake that require private key over to customer’s key server. Compare client-server TLS handshake and Figure 2.
As you can see in Figure 2, decryption of pre-master key is the step where origin’s private key is required. Cloudflare makes a roundtrip to origin to get this done. Even though private key is used, vendor is not in possession of the private key. Hence the word “keyless”.
TLS SNI:
Akamai achieves this by taking advantage of combination of Domain Validated (DV) and Organization Validated (OV) certificates and Server Name Identification (SNI).
Akamai uses two certificates – Origin server certificate and Akamai network server certificate. Origin server cert secures content in transit from origin to Akamai machines (This is used when edge machines are not cached, as a result request hits the origin). Akamai network server certs secure content in transit from Akamai machines to clients.
Onboarding and Configuration Assistant (OCA) process on Akamai’s web portal enables customers to create two certificate for their origin domain. DV certificate is just like you get digital certificate for domains owned by you (Eg. from Let’s Encrypt) but an additional step is to add DNS redirects pointing to Akamai CNAMEs. OV certificate involves CA calling up origin domain owner to verify if the request is legitimate once Akamai sends certificate signing request form to CA. Both these certificates form Akamai network server certificate.
Now we have certificates ready. Akamai has huge number of customers and with IPv4 being scarce, it is difficult to assign one IP to each hostname. With IPv6 scalability will not be a problem but not all websites support IPv6 yet. SNI lets CDNs use IPv4 IPs/VIPs very efficiently. It lets a single host shelter thousands of certificates and be successful in responding the clienthello packet with valid certificate. Without SNI, ClientHello packet in TLS handshake does not have hostname. Edge will not be able to identify customer with IP address as there is no 1-1 mapping. But clients with SNI enabled, send hostname in the ClientHello packet allowing the edge server to reply with valid certificate back in ServerHello packet enabling virtual hosting.
What are your views on security issues involving these two technologies?