The Move to a Faster, More Secure Web

James Bromberger Posted 28 June 2018

Cloud and IP networks are driving digital transformation, and Modis sits at the core of this for many of our largest Enterprise and Public Sector clients across Australia, and the world.

January 1, 1983 was the start of TCP/IP on what is now commonly known as the Internet, and some six years later TimBL (Sir Tim Berners-Lee, OMKBEFRSFREngFRSADFBCS and more) and Robert Cailliau (Belgian Order of the King and much more) produced a network protocol (HTTP), a mark-up language (HTML) and a client software for rendering this mark-up language (a Browser) while working at CERN.

This initial implementation was a vast improvement on the accessibility of the digital systems that pre-existed, such as Gopher, or Network News (not the TV Network News you may know, but a primitive distributed forum/bulletin board system).

Similar to those legacy systems, the early web had no real confidentiality when data was transmitted across the untrusted Internet. Any of the network providers that sat in the transmission path between the holder of information, and the requestor could inspect and possibly modify data in flight.

It wasn't until the release of Netscape Navigator in 1994 that a system of offering both negotiated encryption-in-flight, and separately a chain-of-trust identity system were made available. With confidentiality and server identification, vetted by a trusted organisation was the birth of the web as an e-commerce platform.

The choice of offering an encrypted transport protocol for responding to web requests was very much up to the content holder. The web server could listen on one port for unencrypted requests (80), and another service port for encrypted requests (443). Browsers would connect to the secure port and receive an x509 encoded signed Certificate — signed by the trusted Certificate Authority. The server administrator had to obtain this signed Certificate, and for many years this cost significant amounts of money, paid to the Certificate Authority for their role in asserting the identity of the web site operator.

Requiring this paid (at the time) assertion of identity was in effect an obstacle to ubiquitous adoption, a dis-incentive for validating identity; money would typiclaly be spent only on Production systems, and not for non-production, or non-customer-facing systems.

In moving to an encrypted web, historically the client browser would add additional decoration on the screen to show the user that the data being presented was fetched using an encrypted protocol — often using a green padlock – but even this is set to change in 2018.

The details of each of these are fascinating (avoiding the complex mathematics).

While we teach our staff the details, but its worth taking stock of some of the recent changes, as there's a fair number now. If you or your team who manage your Internet facing services are not fully aware of this, then you should urgently contact us to help you.

Certificate Authority Changes

  • Stronger chains of trust: SHA2-256, and ECDSA algorithms (replacing SHA1, MD5 based signature algorithms)
  • Forced removal of rogue CAs (distrust) that have been caught out not verifying identity correctly
  • The demise of the Extended Validation certificate
  • The rise of the free Domain Validated Certificate authority (eg, Let’s Encrypt)
  • Certificate Transparency: public logs of all issued certificates
  • Checking of DNS CAA records to confirm permission to issue for a domain name and DNS SEC
  • Stapling (attaching) of Online Certificate Status data, a CA-signed confirmations that the issued certificate has not been revoked, without alerting the CA as to whom the client is (replacing OSCP and the slower Certificate Revocation List check)

Encryption-in-Flight and Network Protocol changes

  • Deprecation of older Transport Layer Security (TLS) protocol versions (helped by auto-updated modern browsers, and the PCI Data Security Standard being prescriptive)
  • Deprecation of various older Bulk Ciphers such as DES a 3DES, now deemed insecure or weak
  • The move to Ephemeral key exchange mechanisms, providing Forward Secrecy (ECDHE)
  • Newer TLS 1.3 Protocol, having now been ratified by the IETF, and now pending final specification implementation and deployment
  • Deprecation of weaker MAC algorithms on blocks of encrypted data, replacing SHA (actually SHA1), with SHA256 (SHA2-256) and stronger options
  • Deprecation of Cipher Block Chaining (CBC), replaced by Galois Counter Mode (GCM)
  • HTTP/2, the binary version of HTTP that permits multiplexing and other goodness
  • IPv6… after 20 years of slow progress, this now (June 2018) represents around 5% of traffic in Australia, and 15% in the US, according to Vint CerfFather of the Internet

Browser Improvements

  • Frequent stable releases with constant security updates & mdash possibly aided by Software Engineering process improvements like Continuous Integration, automated testing, agile methodologies, and modern software source tree control systems such as Git, Mercurial and others
  • Content Security Policies: the ability to administratively limit where the browser will load content that JavaScript or HTML code will attempt to load data from
  • HTTP Strict Transport Security header (and pre-loading), to indicate a site should default to HTTPS instead of HTTP when entered without a protocol specification (scheme)
  • Sub Resource Integrity: permit the referring HTML page to indicate a checksum of items such as JavaScript or CSS being loaded, more importantly when loaded form 3rd party servers you don’t control (eg, CDNs and service providers)
  • Adding warnings to unencrypted pages as "NOT SECURE", re-adding the ‘http://’ scheme for unencrypted pages, yet at the same time removing the padlock icon and ‘https://’ scheme for secured communications: effectively turning the tables on ‘security as the exception’, to ‘insecurity as the exception, security as the default
  • Improved compression, such as Brotli

It is clear to see how the Web, the Internet, and our move to digitise the planet has changed society. Our reliance on security, integrity, and privacy over untrusted and sometimes hostile networks is what makes online banking, transactions, information sharing, personal interactions such as video conferencing possible. Many industries have been disrupted by this change; online maps now decimate the printed map market, streaming on-demand video and audio is overtaking broadcast television and radio for minutes watched/listened which, in turn impacts traditional advertising models on broadcast medium. Podcasts, vlogging have turned individuals into celebrities. However, this race to improve security will continue: new algorithms will come, Quantum Computing may upset some of these approaches, but innovation will continue.

For systems administrators and service operators: the biggest risks are to mis-configure the vast array of options before them. Most of the changes have been transitions over time between an older, once great solution, to a newer one that solves more problems, but too many organisations leave legacy options enabled. Freely available tools online help people configure these, such as Mozilla Observatory, and in-browser tooling and logging has also improved.

Outside of the risk of lack of awareness in organisations about actually encryption to meet current best practice, is the lack of real agility to apply critical security changes to production systems as urgently as possible. This is followed closely by the inability to quickly apply known updates — either at the application layer, operating system layers, or network device firmware(s) — despite those security vulnerabilites having been known about for extended periods, and patched versions of these components having been made available by vendors.


The trend is clear: secured web is becoming easier and cheaper, while unencrypted web is becoming less desireable. There are a lot of links to further information in this post; you'll see not one of them is to an unencrypted HTTP site!