SSL for your domain on Google App Engine

March 30, 2012

As Jon and I prepared to launch Voost, we knew we needed an always-on SSL solution. In the age of Firesheep, it is simply no longer reasonable to provide any kind of authenticated service, no matter how trivial, over unencrypted channels. Even though our website hands off authentication (Facebook and BrowserID) and purchasing (WePay) to third parties, there are two good reasons why our online athletic registration system needs always-on SSL:

• Even if the authentication and purchase processes are securely encrypted, it's not always clear to the user. This is especially true for purchase flows that run embedded in a "normal" page like WePay and Stripe - the URL bar shows no padlock.
• Every time you think to yourself "who would bother exploiting this loophole to annoy other users?", the answer is probably sitting in the cafe next to you. One thing I learned at EA is that in any community of appreciable size, there are always a handful of sociopaths that delight in causing trouble for their fellow humans. As unlikely as it is, the chance that someone could steal an auth token and use it to change somebody's race entry is simply not acceptable - it could ruin the day that an athlete has spent months training for.

Unfortunately, lack of support for SSL has been a consistent complaint of serious Google App Engine developers since the beginning. You can publish your app to the world as https://yourobscureappid.appspot.com/, but not https://www.yourdomain.com/ - and appspot.com in the URL bar looks like amateur hour to all of your users who actually care about security and encryption.

Google has had SSL on the roadmap since I first started using App Engine three years ago. The feature is actually in the "trusted tester" phase - but unfortunately this particular test group is nearly impossible to get into. My repeated enquiries through various channels both official and personal have failed - and due to open source work I'm about as well-connected as anyone gets outside the G-plex. Good luck.

Fortunately, you don't actually need Google's help to have SSL on your custom domain.

We discovered CloudFlare because their Platform Lead is one of Jon's cycling teammates (John Roberts has since become a valuable advisor to us, although we're still paying list price!). Their business is normally about providing worldwide CDN services and DOS attack protection, but they will proxy SSL for paying customers.

The basic information you should know:

• SSL services are offered as part of the "Pro" plan, not the free plan. It costs $20/mo for the first domain, $5/mo for each additional.
• CloudFlare generates the SSL certificate for you. They actually generate a cert that includes 20+ domains together (check the cert details at https://www.voo.st/ for an example), which makes a fair bit of sense. Otherwise they would need a separate IP address per customer. End-users don't see this unless they closely examine the certificate.
• With GAE, you use the "Flexible SSL" option instead of the "Full SSL" option. This provides encryption between the browser and CloudFlare, but plain HTTP between CloudFlare and Google. Voost sends passwords and credit card numbers directly from the browser to the respective service providers (encrypted), so this half-SSL approach effectively solves our realistic threat models. If Echelon really wants to know what marathons you're signed up for, they can just crawl the public registration records.
• In theory, you can use CloudFlare to serve naked domains on GAE. We're cautious so we didn't choose to try this, despite the fact that adding "www." practically doubles the length of our domain name (sigh).
• You use CloudFlare's DNS servers for your domain rather than pointing individual DNS records at CloudFlare. This is actually a bonus - CloudFlare's management interface is rather nice, in sharp contrast to other hosted DNS systems I have used (I'm looking at you, Rackspace). It also makes setup quite a lot easier than it is with other CDN systems.

Here's the HOWTO:

1. # for the "Pro" plan at CloudFlare ($20/mo). Add your website domain. You should have a panel that looks like this: Note the DNS settings, CloudFlare settings, and Page rules menu items on the dropdown - you will need those in a moment.
2. Go to your domain registrar and point your domain's nameserver entries at CloudFlare's DNS servers. You will manage DNS for your domain entirely at CF.
3. In the CloudFlare DNS settings for your domain, add the usual entries for Google App Engine. For example, a CNAME for www -> ghs.google.com.
4. In the CloudFlare settings for your domain, set SSL to "Flexible SSL".
5. After a few minutes you should successfully be able to visit https://www.yourdomain.com/. However, you aren't done.
6. You still need to redirect http:// requests to https:// requests. This will require a Page Rule. There's a special Page Rule for doing exactly this:
7. Last but not least, you must do something about the naked domain. Google Apps has a built in redirector for naked domains to www (or whatever), but it does not work with SSL - it just hangs. Instead we will add a CloudFlare PageRule which takes care of naked domain redirection for us - both SSL and non-SSL. As a bonus, it will preserve the remainder of the URL.
   
   Map yourdomain.com/* to https://www.yourdomain.com/$1 like this:

At this point you should be up and running. You can turn on and off CloudFlare per-domain by clicking on the little cloud in DNS settings (see the right side of the picture in #3). Note that it may take a few minutes for DNS entries to propagate when you make changes.

Since CloudFlare IP addresses will show up as the request origin in your GAE logs, CloudFlare adds special headers to each request. Here is an example:

CF-Connecting-IP: 173.190.104.220
CF-IPCountry:     US
CF-Visitor:       {"scheme":"https"}
X-Forwarded-For:  173.190.104.220

Will we continue to use CloudFlare when Google rolls out SSL for App Engine? Without any visibility into what Google plans to offer, that's a difficult question to answer. However, it's hard to imagine switching:

• The SSL prices Google floated as a trial-balloon in a user survey were several times higher than what CloudFlare charges.
• CloudFlare offers compelling features in its own right beyond SSL:
  • CF has a global edge cache with documented behavior. GAE has some sort of built-in edge cache, however, its behavior is undocumented and has been experimentally discovered to be rather quirky.
  • CF offers a lot of nifty little performance-enhancing tricks like rewriting our pages to eliminate extra whitespace, minifying css, etc. We compile and minify our own JS but it's nice not to have to worry about the rest.
  • CF has analytic tools that are significantly more sophisticated than the GAE dashboard. It's like Google Analytics-lite but based on actual traffic served rather than cookies and javascript.
  • CF's threat-protection could become incredibly valuable if we ever needed it. GAE's builtin make-your-own-IP-blacklist is not especially reassuring.
• CloudFlare answers their support email in minutes (as in, less than 5). It's shocking.

Our experience is still young, but so far all lights are green.

Discuss this at Hacker News

original