This may seem like an odd question, but what do fashion and DevOps have in common?
One of the most common challenges most software teams have is legacy patterns and practices. Often, they are retrofitting new terminology onto old patterns to make it easier to justify the approaches. Before anyone claims superiority in this space – it’s very easy to judge teams by the practices they implement. Sadly, it’s usually an inherited legacy. In most cases, their practices and conventions were common and recommended decades ago. Over the years, they have since fallen out of favor as we modernize our approach to software development. Simply put, these practices were completely in style for their time, but they now have people questioning the judgment of the team that endorses them. It’s like some of the 80’s fashion trends. They worked for their time, but they seem out of place now.
There is a difference, of course. Old software patterns take a substantial time to undo. There’s often lots of legacy code build on frameworks and approaches that are showing their age. While there are ways to work down that technical debt, it’s often a multi-year journey. It takes time to enable teams to modernize their practices, and it takes time to implement implement new coding paradigms. Like most journeys, the first step is deciding to eliminate bad practices.
So does any of this have to do with certificates?
Last month, Google announced a new proposal, Moving Forward, Together. As part of this, they announced a recommendation to restrict TLS server certificates from a maximum validity of 398 days to just 90 days. One of their goals is to minimize a leaked certificate remains vulnerable. This also has the benefit of eliminating some of the challenges with validating certificates and identifying those that are rejected. A shorter validity time means a shorter time to exploit compromised certificates. It’s currently under review and consideration buthe CA/Browser Forum Server Certificate Working Group. In short – change is coming.
Naturally, any time they reduce the amount of time a certificate is valid, teams become concerned with the extra work. This is even more chaleenging if they’re using self-signed certificates. Instead of struggling to update and replace certificates on time each year, teams will need to do it nearly 4 times a year. I don’t expect a substantial price change with certificates. Companies that choose to manage these manually usually choose to pay a premium for the services of reputable CAs.
In other words, if you’re maintaining legacy approaches to infrastructure deployment and PKI, your job is about to get significantly harder.
Google makes some excellent points about the need for this transformation. One of those is that this should encourage automation. A common saying in DevOps is “if it hurts, do it more.” If something is painful, you need to look at the problem and understand why. From there, you are in a better position to eliminate the issues. By continuously refining the practices, teams continuously improve.
In 2012. a project was started to make TLS certificates more accessible. This project was publicly announced in 2014 and launched in 2016 as Let’s Encrypt. One of their first contributions to public key infrastructure (besides free certificates) was Automatic Certificate Management Environment (ACME). ACME automates the interactions between certificate authorities (CAs) and servers, making it easy to automate the process of requesting and issuing certificates. Since it’s launch, ACME has been codified as RFC 8555. To help with adoption, Let’s Encrypt publishes a list of clients and compatible projects. It wasn’t the first protocol for automating ceritifcate issuance and deployment, but it has proven to be the most successful. Google notes that over 50% of the certificates issued by the Web PKI use ACME, and 95% of the issuing CAs have ACME implementations.
That means that the technologies for automating this process – and even taking advantage of free TSL certificates for your servers – is mature and globally tested, with more than a decade of research under its belt. There’s no good reason to not adopt these technologies. If you’re not using HTTPS for your services, then you’re only getting a fraction of your available performance (and you’re less secure). HTTP/2 and HTTP/3 perform substantially better than the older technologies. While the HTTP/2 specification does not require TLS, every major browser vendor continues to only support HTTP/2 over TLS (making it required in practice). The HTTP/3 specification requires TLS, requring all messages to be encrypted.
Many companies have been able to hold on to out-of-date development practices for many years. In doing so, they’ve allowed their technical debt to grow. This impacts their ability to remain competitive and respond to a changing market. In many cases, it even restricts their ability to get the most out of modern cloud systems (or development platforms like GitHub). To be the most successful at developing secure software quickly, teams must be continuously improving and modernizing. No piece of code will last forever, so think modularly. Time is a precious resource, so automate away anything that doesn’t offer value. Ask yourself, “is this delivering a value to my customers?” If not, then question why you are still doing it. Finally, if you’re afraid to give up manual processes and on-premises systems in the name of security, consider the DoD’s 2018 Cloud Strategy Memorandum:
Moving infrastructure from DoD-managed, on-premises facilities to the cloud will take advantage ofthe rapid roll out of software and hardware updates…Hardware with defects or vulnerabilities is constantly swapped out and software patches are applied with vigor in a secure and fault tolerant manner…The transition from traditional IT management to the managed cloud service model alters the balance of visibility and control with ease of use, automation, leading edge technology adoption, and optimization of its information domain.
The speed of development is only continuing to increase. The window for adopting agile processes and practices (rather than just the terminology) is closing. If you hope to keep up and innovate, make time and look for opportunities to improve.