Solving the SSL Conundrum

Now that we’ve launched WordPress on Akash, a decentralized platform-as-a-service (PAAS) service based on Docker and Kubernetes, we’ve got to figure out a way to secure it.

In today’s Internet, the standard is known as SSL. It’s really TLS 1.2-1.3, which is a technical difference I won’t get into, but either way we want our communications encrypted between the browser and the server, so that someone snooping on our Starbucks wifi login can’t capture our password and hijack the site.

Another consideration is that even for people just browsing the site, modern browser applications like Chrome and Firefox are starting to provide visual warnings when a site is not being accessed through a validated https (encrypted) connection.

All this is basic Internet engineer stuff: so where’s the conundrum?

Docker limitations

By design, Docker is jailed. What this means is that the containerized software is purposely limited to its own container. For security reasons, the private key of the SSL certificate must be stored outside the root directory of the website–otherwise a hacker may be able to obtain the certificate key through the browser and be able to provide a fully-validated but fraudulent version of your site.

Most traditional hosting solutions get around this by either providing SSL services as part of the paid subscription, or by giving the user privileged access to a larger portion of the hosting server, for uploading certificates and other files.

Being designed in an automated fashion, Akash-on-Docker doesn’t give us those options yet, although it’s entirely possible for some enterprising programmers to launch a concierge PAAS service that would offer SSL, deployment tools and other a-la-carte options using the Akash protocol on the back-end for the actual hosting. I hear those projects are in the works.

Stopgap: Cloudflare

For now, I’ve opted to use a centralized service to host my SSL, one that almost all Crypto projects seem to be using at the moment for their primary sites: Cloudflare.

Cloudflare provides a freemium (free options limited) service that includes SSL certificate provision, content caching, DDoS (distributed denial of service) protection and basic reporting. It also obscures the IP address of my back-end source system from prying eyes who may try to attack the node directly. Things I don’t like about it:

  • It’s a centralized service (I swear I’ll write up the reasons that’s bad if you’re wondering)
  • They require the full delegation of your root domain DNS, not just delegation of your site’s DNS. This takes 24-48 hours to fully implement, with the same timeframe for getting out of it. I don’t like the loss of control, considering that it’s a centralized service.
  • It still doesn’t provide end-to-end encryption, as given the issues with installing SSL in Docker, the traffic between Cloudflare and my source site is still not encrypted. This is a low risk, however, as a MITM (man-in-the-middle) attack is very difficult at the infrastructure level; it’s much easier (thus more profitable) to target the client side as in the Starbucks wifi scenario.
  • Some weird caching issues sometimes
    • As I’m using Amazon Cloudfront as a CDN for my images as detailed here, the double-caching of Cloudfront and Cloudflare made my images disappear until I put in a specific rule to bypass Cloudflare caching for Cloudfront-hosted elements (see Page Rules below).
    • I’m having trouble with editing posts or pages when proxied through Cloudflare. I have not solved this issue, but am working around it by directing my laptop to bypass Cloudfront using my technical wizardry (host file edit), and risking the unencrypted connection for the purpose of writing posts.

Build a Better Cloudflare

Here’s a challenge to the Crypto community: build a better Cloudflare. While I may end up resolving the SSL-on-Docker problem (I’m thinking of bootstrapping Traefik into a future deployment of the site), the DDoS protection and caching capability of Cloudflare also provide security to the site–and these are things that absolutely can be done using blockchain and decentralized solutions. Here’s a use case spec based on my ideas of what this service should look like:

  • An encrypted network of router nodes that participate in the blockchain consensus and provide high-speed routing services for the consumer apps
  • Multi-path redundancy so congestion, blocking or regional outages can be bypassed
  • Network-wide knowledge and recognition of DDoS patterns and detection, with auto-blocking of detected sources
  • Distributed edge services where site URL’s can be delegated, content cached and payment exchanged with consumer app managers for bandwidth usage; this may require some sort of BGP cloud or IPAnycast implementation to keep front-side configuration to a minimum
  • Load-balancing among multiple back-end source sites as an option so enterprise-level solutions can guarantee their customers globally-distributed redundancy
  • Web Application Firewall and caching options would be handy but not required

One project I’ve become aware of that has the potential to provide this type of routing is NKN, which advertises itself as a peer-to-peer network connectivity protocol providing end-to-end encryption. I haven’t done a ton of homework on them yet, but they are getting listed by Coinbase, so they seem to be legit. So far as I know, a Cloudflare replacement service isn’t in their roadmap, but it appears that someone building the edge service described above could use the NKN network in the routing capacity for the role.

Share

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.