Traffic, Bridge Tolls, and Secure Browsing - How Automation Secures The Internet

Mike Maxey

Follow Smallstep

When I first moved to the San Francisco Bay area, I spent a ton of time in Marin. For those unfamiliar, Marin is the area north of San Francisco, just across the Golden Gate Bridge. This was 15+ years ago and the trick to an enjoyable day in Marin was navigating the bridge. Traffic getting back into the city was always ridiculous. It would back up for miles over the top of the hill and through the Robin Williams Tunnel. Through much trial and error, I learned you couldn’t beat the traffic. It was always a factor and I accepted this reality by planning an extra 45 minutes into my return trips.

Today that traffic problem is gone. No, they didn’t add lanes to the iconic bridge. Nor did population density go down in Marin. Instead, the bridge authority implemented automation around toll collecting. The system scans your license plate and you pay the toll later. No longer do I need to stop at the booth while hunting for exact change while I hold up a couple 1000 cars behind me. Automation removed that burden and now I don’t even think about it as I zip across the bridge with minimal delays.

A similar experience has unfolded over the past few years across the public internet with the use of HTTPS. Driven by automation, the vast majority of public websites use HTTPS to provide secure browsing. In this post, we will explore how successful public internet practices provide a set of instructions for how the industry should be thinking about securing internal systems.

Secure browsing is based on trust

Trust on the internet is presented and verified using certificates. Ultimately there is a set of trustworthy organizations that the community has empowered to issue certificates. These organizations are called certificate authorities and the issuance practices have been around almost as long as the internet itself.

Much like sitting in miles of traffic to pay a bridge toll, getting a certificate was a painful process until the invention of Let’s Encrypt. You had to complete a web form, then prove your identity via a very manual process. One that often included requiring you to send bank statements, articles of incorporation, or a copy of your passport. As a second factor authentication, you then were required to answer a telephone call to a phone number that is registered in a third party database (whatever that means). Yeah, it sucked, and as you can expect, not everyone made the effort. And those that did, made sure they didn’t have to do it again by asking for a very long certificate life (not a great idea when it comes to Identity and Access Management).

Automating trust is a good thing for user privacy

Let’s Encrypt has profoundly changed how the world accesses information on the internet. Formed as a Linux Foundation project in 2016, Let’s Encrypt is a non-profit organization with a clear objective: ‘The objective of Let’s Encrypt and the ACME protocol is to make it possible to set up an HTTPS server and have it automatically obtain a browser-trusted certificate, without any human intervention.’ That’s right, no phone calls, no legal documents, and best of all, it’s free.

Let’s Encrypt has automated certificate management for the public internet. And while that’s all well and good for websites, the extended impacts of this change are profound. In the year prior to the creation of Let’s Encrypt, ~35% of web traffic was using HTTPS.

In 2016, the founding year, that number jumped to 50% and continues to increase to today’s number of >78%, more than double. Remarkable progress in a few years.

Applying successful public internet practices to securing internal systems

If we can wrangle the internet, surely our internal networks are much safer, right? Sadly, this is not the state of most internal networks. Where 78% of the public internet relies on both networking and identity-based encryption to secure interactions, most internal systems have only implemented network-based solutions. The barrier to adoption of identity-based encryption has largely been challenges associated with managing certificates.

At the same time, we see an identity-based encryption adoption trend within enterprises who are embracing DevOps and modern cloud platforms. Along with new developer practices, many organizations are implementing identity-based security to enhance existing network security strategies. The combination delivers accelerated developer productivity and defence in depth.

At smallstep, we like to say we are the Let’s Encrypt for internal networks [1]. We’ve built an open-source PKI framework that provides automated certificate management for DevOps environments. Using certificates as the foundation of production identity, smallstep users are automating encrypted communications between microservices, humans, functions, applications, and devices. I encourage you to visit our repos on githubwhere you will find the smallstep framework. Try it for yourself to automate your bridge traffic problems, and let us know what you think.