You might have noticed that our web front-end is now fully SSL encrypted, without you having to go to secure.travis-ci.org. This is thanks to our new and shiny wildcard SSL certificate, which we are now using for all our apps running at Heroku.
Note that we are now using the same certificate for secure.travis-ci.org, so your HTTP client might warn you about a certificate change.
Why didn’t we have that before?
Most of the content we serve is publicly available, the GitHub scope we use does not even allow us to access private data. This is of course different for Travis Pro, which is why we have been using full SSL encryption there from day one.
Why did we turn it on?
We still want to make sure we don’t leak any data accidentally to anyone watching the stream, like what public repositories you have push access to. And we also want you to be sure it’s us you’re talking to.
Even though we are not aware of any such incidents, this will protect you against replay attacks, which might have led to an attacker enabling or disabling one of your projects without your consent.
OK, and how?
If you run your website on Heroku, you might know that it’s not that simple to add an SSL certificate to a naked domain (one without a subdomain, like travis-ci.org).
The reason for this: When you add a certificate on Heroku, it gives you a link to a custom SSL endpoint. You are supposed to use this endpoint as a CNAME entry for your DNS record. However, naked domains can not have a CNAME entry, but instead must have an A record entry, which points directly to an IP address. Now what we could have done is lookup the IP address the SSL endpoint is pointing to and use that as the A record. But if that should ever change, our website would instantly stop working.
Luckily, the amazing team at DNSimple already solved this problem for us: They have a feature called ALIAS records. From our end, it behaves exactly like a CNAME: We just give it another host. However, whenever someone is resolving travis-ci.org, DNSimple will actually look up the IP for the SSL endpoint and return that as an A record.
Saving money with Heroku
If you use a wildcard certificate for more than one application on Heroku, you have probably already been annoyed by the fact that you have to pay for the SSL endpoints for all of these apps separately.
If that’s the situation you’re in, here’s a Pro Tip™ to save you some money: Heroku dispatches to the correct Dyno based on the domain name, not the SSL endpoint. This means you can reuse the same endpoint for as many applications as you want, only paying for it once.
We, for instance, currently have 30 apps on Heroku and instead of having 30 SSL endpoints, we only need two (one for travis-ci.org and one for travis-ci.com).
The future is secure
We will continue to improve security here at Travis CI. In fact, we are currently working on new architecture for our web front-end, featuring a new JavaScript client and a new JSON API.
Instead of just trying to detect opportunistic attacks, it will also features a stateless, session-free architecture. This instantly renders it invulnerable against a whole range of attacks all based on session capturing, like normal CSRF attacks or even CRIME.
We will report more on this once we release the new client.