1. 5
  1.  

  2. 4

    Agreed that TLS is bloated, and super complicated, but:

    It takes a lot of network traffic to negotiate an SSL connection, and on a slow internet connection like I often have on my phone, this can be the difference between a page loading or not loading.

    Well, the amount of traffic this takes is negligible compared to that of the resources most sites wil make your browser load. Try loading a site on your browser with JS, external fonts, and CSS disabled. Even with TLS it will be much faster than with all the cruft enabled.

    It raises the entry bar for making a website.

    It is not necessarily easy to setup TLS correctly, although Let’s Encrypt will hopefully help here in the future, but nothing prevents you from setting up a website without TLS. It will work for a long time to come! Using TLS is important when you are actually deploying a site. Hosters can (and do) help with this.

    1. 7

      Most importantly, TLS enables you to use SPDY or HTTP2 which comes with compression and all other sorts of bandwidth saving stuff, so the extra effort required by the handshake is probably worthwhile.

      The article mentions TLS as a problem for proxies. I like to use TLS because it works against them. ISPs have and are currently using proxies to save bandwidth themselves without being transparent to the user about them. I’ve heard some even cache POST requests.

      1. 2

        It is not necessarily easy to setup TLS correctly, although Let’s Encrypt will hopefully help here in the future, but nothing prevents you from setting up a website without TLS. It will work for a long time to come! Using TLS is important when you are actually deploying a site. Hosters can (and do) help with this.

        Mozilla has a nice config generator for popular web servers.

        https://mozilla.github.io/server-side-tls/ssl-config-generator/

      2. 4

        I can dismiss all of his arguments in the name of security, except the last:

        It raises the entry bar for making a website. I think it’s really great that kids can learn about HTTP and HTML just by spawning Apache and modifying the index.html. I also think it’s great that you can write a working HTTP server in one line of code. It’s not that simple once you add SSL.

        I think this is a really legitimate complaint. Tools like Caddy and other ACME-enabled servers help here, but even they require you have properly set up DNS to begin the process—and since understanding not just mechanically what ACME does, but why it’s acceptable from a security standpoint, is quite complicated, that also raises the barrier to entry a ton.

        This actually gets at something I’ve been struggling with a lot recently: I think the complexity of modern computers has gotten away from us a bit. When I was a kid, a computer was something you could have a lot of fun with, but that was ultimately a tool to get things done. The amount of complexity that has been (necessarily!) introduced to handle their ubiquity has also taken a lot of the fun away, at least for me. I’m hopeful that we’ll figure out a way to do a bit of both over the next decade, but I can’t honestly say I’m optimistic.

        1. 3

          I though this piece would be about DER encoded data that make up the SSL. Since I’ve spent some time around that recently, the title would be quite euphemistic, but still applicable, in my humble opinion.

          No, seriously. Can we ditch DER, adopt JOSE and invent CBOR-encoded JOSE for TLS 4.0? That way the noobs can dump the whole crypto exchange as a JSON and gain some insight. Try dumping DER with openssl asn1parse.