Secure github-pages

This morning I learned about Kloudsec, a service that offers a CDN, HTTPS encryption and shadowing in case Github pages are unavailable1 :stuck_out_tongue:.

UPDATE (September 22, 2016): Kloudsec is down :sob:, but Steve left a few notes for his follower and clients. Do yourself a favor and ignore this post from now up.

Update DNS

In order to setup Kloudsec the user is required to update A and TXT DNS records for the domain of interest. The A record in my case points the domain to a Kloudsec proxy. Quang Huynh discusses in this post how one may configure a Nginx proxy server with a certificate obtained from Let’s Encrypt CA to provide a similar self-managed solution.

The TXT records is there for Kloudsec to verify control of the domain. It is quite common for service providers to request the addition of TXT records from their clients in order to allow the client to demonstrate some control over the domain in question.

Update CORS Policies

I serve some assets through S3 buckets. In order to ensure that my assets are retrievable by the browser, it is important to properly configure CORS on the buckets of interest. In my case, I rather explicitly state the domain which is allowed to access the bucket cross domain which. Since is different to I will need to reflect that in my CORS policy.

CORS needs to be setup on S3 in order to access resources from the web page
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="">

If you choose a wildcard * as the allowed origin, be aware that anyone out there will be allowed to embed resources from your bucket into their pages. If you want to keep your S3 bills to a minimum, perhaps anyone who needs some resources that you serve should consider mirroring them instead of serving them directly from your bucket :wink:.

Update URL’s

Another point of interest is rewriting all URL’s to secured endpoints which could be as easy as replacing every occurrence of http:// with https://, provided that the host in question offers supports HTTPS.

Retrieving unsecured resources from a secured site defeats the purpose of going secure. Man in the middle attacks are still easily possible if anyone can present itself as a mirror of some resource (.e.g: stylesheets, scripts, images, etc). Every non-HTTPS resource requested travels over the wire unencrypted and is sourced by a host who’s identity we can not properly verify.

Secure connections, besides simply providing encryption, therefore also provide some assurance regarding the authenticity of the endpoints in the conversation. With TSL encryption between the endpoints, one could at least be justified in assuming that the content is from an authentic source and no impostor.

Rewriting all links is quite a chore, I’m in the middle of grepping through my corpus to rewrite links. Some hosts do not serve their resources over HTTPS which means that I will have to serve those resources from my S3 bucket, for example, or find some other alternative. Be mindful of licenses and copyrights whenever you consider mirroring resources.

Point is… if you serve a HTTPS page which embeds content from non-HTTPS sources, you might as well not even have bothered serving the thing over HTTPS. In my book, even if it is HTTPS served. It’s unsecure! :unlock:


Kloudsec offers a few tricks for optimizing page load. At the mere click of a button any github page can be served through their CDN which leverages smart routing schemes (instead of just relying on DNS) to provide a more reliable means of finding the closest mirror for content. The tools of use at Kloudsec include BIRD (recursive acronym for Bird Internet Routing Daemon) which as the name implies deals with routing, while pf is used for packet filtering in combination with relayd which aids in dynamically changing the pf configuration, but don’t take it from me, read the inside scoop from Bach Le at Kloudsec.

Friendly Defacing

Another thing to consider is that Kloudsec mutates the page with some additional logic. The goodfellas and gals at Kloudsec need to record some performance metrics for the dashboard, and just to get an impression of whatever they add take a look at the source for a simple HTML page that originally just contained the following code:

<!DOCTYPE html>
<html lang="en">
    <meta charset="utf-8">
    <script>console.log("here we go");</script>
    Move along. Nothing to see here!

Essentially whatever happens here is that Kloudsec simply adds script tags to your pages. Some service providers require you to do it yourself, but the Kloudsec team just wanted to be helpful and take another worry off your shoulders. Somewhere it kind of creeps me out that they do it for me, but I get why they did it.

CA Housekeeping

Another thing to consider is that using the Kloudsec service requires you to trust Kloudsec. Kloudsec holds the certificates and they provide the first front for your page on the web. They could provide resources that aren’t yours but are hardly indistinguishable from the resources you intended to provide.

In short, if there would be anything somewhere in the middle, it could be them. To be fair, if Github were to offer HTTPS pages for custom domains, they would have that power too, so what am I really bitching about here?!? :stuck_out_tongue_closed_eyes: It’s just a trust issue, but I felt I needed to point it out clearly.


In conclusion: The TLS, CDN and mirroring features that are offered are pretty cool, a few topics raise minor concerns but I needed to invest less than 5 minutes of my live to see it work – that is, if I ignore all the work I still have left to do in removing all non-HTTPS links throughout my repository :stuck_out_tongue:. It’s pretty dope :metal:.

For now I’ve got some work to do :sweat:

UPDATE (September 22, 2016): You could setup Cloudflare if you still want serve secured github pages.

  1. Hell does freeze over occasionally, so don’t think you would never need it :wink: