If you’ve been following the drafts of this RFC, then nothing here will surprise you. The first draft was published on July 21, 2014, and, a short seven months later, RFC 7465 has been published. It’s a great idea for an RFC that I’d like to see used more frequently, but more on that in a moment.
If you’re unfamiliar the term RFC, it stands for Request for Comments and the RFC collection (published by the IETF) describes specifications and protocols related to networking and the Internet. HTTP and SMTP, for example, both have RFCs that describe how they work.
Think of RFCs as a blueprint for implementation that anyone can follow. I’ve long had a fascination with RFCs and as long as I’ve had an iPad, I’ve carried a full set of RFCs for casual reading; I’d love to rebrand RFC to ‘Really Freaking Cool.’
Now that we’ve covered the background, let’s focus on
RFC 7465, entitled 'Prohibiting RC4 Cipher Suites.' The document’s abstract very clearly spells out its intention:
This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections.
The emphasis is mine, but it’s important to note the use of the word ‘never’. In the official body of the RFC, this language becomes ‘MUST NOT.’
The short version of the document is that to be RFC7465 compliant, you cannot use RC4 in both clients and servers. I’ve long believed that RC4 was dead based on past research and multiple vendors have already declared it dead. Seeing a standards body willing to issue a document that reflects this opinion is awesome.
So, if you haven’t yet, why not sit down and disable RC4 today?
Resources:
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].Title image courtesy of ShutterStock
