Tom McAdam

ssl and cdns: deep pockets required

There are many reasons why supporting HTTPS is a Good Thing. A couple to get started: it protects the data from prying eyes during transmission, and gives a level of assurance of the provenance of data. For the purpose of this post, I’ll not be covering the trust issues with SSL CAs which bring that second reason into question…

mixing and matching

Browsers have recently started tightening up how they deal with content from HTTP and HTTPS on the same page, known as “mixed-mode”. Firefox, for example, now blocks some types of HTTP content on a page served over HTTPS. Other browsers will surely follow in due course, as allowing mixed content is at worst dangerous and at best very confusing from a UI perspective: do you show a padlock, or don’t you, and if you don’t, what do you say about the security of the page? The majority of users won’t know what it means, and certainly shouldn’t have to.

Our personalisation and recommendations API, Voila, already uses HTTPS, as we’re providing sensitive user information in the form of users’ TV-watching preferences to clients but, until recently, we had no need to support it on our video and audio index, Atlas.

However, with Atlas being more and more widely used, either directly through its API or indirectly with our listings widget, and some of those places serving content over HTTPS, the change in behaviour of browsers means that we needed to add HTTPS support. You’ll not hear us complaining, mind; supporting it is the right thing to do.

https://atlas.metabroadcast.com/

Since we use AWS‘s load balancers (ELBs) to provide a fault-tolerant, automatically scaling API, supporting SSL on the API itself was as easy as configuring the ELB through the AWS API.

The pain started, however, when we wanted to add HTTPS support for cached content and API calls, for which we currently use a third-party CDN provider. Their pricing isn’t publicly available, but we’ll use Amazon’s CloudFront as a guide. There’s a $600 a month fee for using your own SSL certificate. That’s not cheap.

I understand why, though; HTTPS doesn’t play nicely with your typical CDN IaaS. With HTTP, you can simply configure another virtual HTTP hostname on your edge servers, and you’re done. HTTPS doesn’t work with virtual hosts, so you need to configure a separate IP address on each of your edge servers for each customer’s SSL certificate. You also need to deal with that secret SSL private key, and associated infrastructure. That’s a fair amount of work.

We could just use Amazon’s own HTTPS hostnames, but then we’d not be able to provide people a level of confidence that the data is coming from us since content would be served from an anonymous Amazon hostname.

rolling our own

So we’ve gone down the route of providing the cached data through our own caching services, using ELBs to terminate the SSL. It’s not quite what we were expecting when we embarked on this, but the cost of others doing HTTPS for us forced our hand.

It’s a shame that serving content over HTTPS from a CDN with your own certificate is considered a premium service and is priced such that it’s out of many people’s reach. It either encourages bad behaviour of serving secure content from seemingly-random hostnames — increasing the scope for man-in-the-middle or impersonation attacks — or, more likely, people just continue to not support SSL at all. We can but hope the situation improves when Server Name Indication, name-based virtual hosts for HTTPS, gets wider adoption as it should lower the cost to providers.

blog comments powered by Disqus