The Philosophy of TLS

TLS Philosophy

Philosophical thoughts

by Craig Miller

I have been creating websites (and web pages) for over thirty (30) years. I remember the days when HTML and HTTP were the new kids on the block. Not only could you create text, but add graphics on the page.

But security was lacking, and online services could not flourish. Fast forward to today, and most web pages have Transport Layer Security (TLS) enabled and Online Shopping is rampant.

The Electronic Frontier Foundation (EFF) started a campaign called "TLS Everwhere" in 2014, as a result of the revelation of NSA Spying by Edward Snowden in 2013.

While laudable, I have resisted making my web pages TLS enabled, as the pages only provide information. There is no log-in, or credit card information on my website. The website is managed by Secure Shell (SSH). For this reason, I have had a philosophical difference with the EFF's campaign.

History of the Web and Security

Back in the 1990s, the web was cool, but everything was in the open, security was (not surprisingly) an after thought. Security came in the form of Secure Sockets Layer (SSL). SSL provided the needed security to implement basic commerce over the web. We wouldn't have Online Shopping/Banking/Medical today, if it weren't for the efforts of Netscape and SSL.

In 1999 SSL was standardized as Transport Layer Security (TLS) in RFC 2246. TLS is standard in every modern browser today.

The Overhead of TLS

There are many reasons to resist implementing TLS:

Providing information (via the web) should not be more expensive (in time, traffic, and complexity) for the end user. My philosophy has always been: Keep it Simple, provide Information.

Looking for the Lock

Of course, there was a time when people were trained to look for the lock in the URL which shows the traffic has been encrypted (using TLS). But the lock has fallen by the wayside and replaced with a shield (or in Chrome, a mystery icon to the left of the URL).

Resistance is Futile

Sadly my philosophy of "Just the Facts" and avoiding TLS are about to become obsolete. Browsers (e.g. Chrome, Firefox, LibreWolf, etc) are much more than HTML display programs these days. The powers in charge of creating these Browsers have decided that looking at non-TLS web pages is a hazard and not safe. And the user must dig into the configuration of the browser to allow non-TLS web pages to be displayed.

Of course, with this latest browser development, my non-TLS-enabled information will be blocked for the average reader. As an Open Source advocate, I find this challenging. Information should be free.

Setting up TLS with Nginx

I have been running nginx as my webserver for several years now. I run it on a IPv6-only webserver, and use the IPv6 Advantage rather than the old IPv4 method of virtual servers.

Using the IPv6 Advantage, I can add additional IPv6 addresses to the host, and have each server listen to an individual IPv6 address.

In nginx, I add an additional configuration file, which listens to the specific IPv6 address. The server section of the configuration file has the following:

server {

    listen [3fff:0098:8:54::e02]:443 ssl;


    # TLS stuff
    server_name         tls.makikiweb.com.com;
    ssl_certificate     /etc/letsencrypt/live/tls.makikiweb.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tls.makikiweb.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;
    ...

What about those legacy clients stuck on IPv4

My hosting service has a reverse proxy for IPv4 clients, which redirects inbound requests over IPv4 to a specific IPv6 address on my server. I just setup another server (using a separate configuration file) and another IPv6 address to receive the proxied requests.

The proxy enabled configuration file looks like:

server {
    #listen 80 default_server;
    listen [3fff:0098:8:54::202]:443 ssl proxy_protocol;

    # TLS stuff
    server_name         tls.makikiweb.com.com;
    ssl_certificate     /etc/letsencrypt/live/tls.makikiweb.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tls.makikiweb.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         HIGH:!aNULL:!MD5;

    # setup to log original client IP address   
    set_real_ip_from  2001:db8:0:80:1000:3b:1:1;
    set_real_ip_from  2001:db8:0:82:1000:3b:1:1;
    real_ip_header    proxy_protocol;
    real_ip_recursive on;
    ...

The proxy_protocol stuff allows nginx to log the IPv4 addresses of the clients making requests, rather than only showing the reverse proxy's address.

Running IPv6-Only Servers

As you can see from the configuration (above), setting up the IPv6 server was much easier than the proxied IPv4 server. My IPv6-only server has a full /64 routed to it, and I can put as many IPv6 addresses on the interface as I choose. At the moment, I have eight (8) IPv6 addresses on my server.

Going Forward

The days of http-only are going the way of the Dodo. With the change in Browsers, those of us who are philosophical hold-outs, will have to implement TLS on our servers, or become unreachable.

I have implemented TLS on a test server, for now. And will reluctantly, against my philosophy, add TLS to my servers in the future (if I have to... I guess).

Notes:


28 July 2026