Implementing the TLS Maturity Model

For more than two decades SSL has ruled the roost as the predominant encryption protocol on the Web. This is unfortunate, at least because in recent years many vulnerabilities have surfaced in SSL. Its had its day, done its job, and is now battle weary. Today, to say the least, early versions of SSL and TLS dont get the job done when it comes to securing website traffic.

In fact, earlier this year, the PCI Security Standards Council removed SSL from its list of strong crypto protocols in the PCI Data Security Standard, and as of June 30, 2016 it will no longer be permitted as a security control. "That isnt much time for everyone who needs to become compliant to become compliant," said Ivan Ristic, director of application security at Qualys during his presentation The TLS Maturity Model here at Qualys Security Conference 2015 in Las Vegas.

"Life was much simpler back when we thought that encrypted communication via TLS was just secure. Not so any longer," Ristic said.

Why does it matter? SSL and TLS, simply put, encrypt traffic between two endpoints, such as the web browser of a shopper and the server of an eCommerce provider. SSL has shown that it remains vulnerable to all sorts of attacks, such as the ability to grab data during communications, man in the middle attacks, among others.

"The SSL protocol (all versions) cannot be fixed; there are no known methods to remediate vulnerabilities such as POODLE. SSL and early TLS no longer meet the security needs of entities implementing strong cryptography to protect payment data over public or untrusted communications channels. Additionally, modern web browsers will begin prohibiting SSL connections in the very near future, preventing users of these browsers from accessing web servers that have not migrated to a more modern protocol," the PCI Security Standards organization wrote in its report Migrating from SSL and Early TLS.

What should organizations do? One would think that it would be very straightforward, but its not, Ristic explained in his keynote. He developed a TLS Maturity Model that is designed to help enterprises get to where they need to be, not only to be compliant, but to be secure.

The model has five levels, which range from utter chaos in Level 1 to a Level 5 which is probably more security than is necessary for most mere mortals. Level 4 is were most organizations will want to be, Ristic said.

Here is the model as he described in this post:

At level 1, there is chaos. Because you dont have any policies or rules related to TLS, youre leaving your security to chance (e.g., vendor defaults), individuals, and ad-hoc efforts generally. As a result, you dont know what you have or what your security will be. Even if your existing sites have good security, you cant guarantee that your new projects will do equally well. Everyone starts at this level.

Level 2, configuration, concerns itself only with the security of the TLS protocol, ignoring higher protocols. This is the level that we spend most time talking about, but its usually the easiest one to achieve. With modern systems, its largely a matter of server reconfiguration. Older systems might require an upgrade, or, as a last resort, a more secure proxy installed in front of them.

Level 3, application security, is about securing those higher application protocols, avoiding issues that might otherwise compromise the encryption. If were talking about websites, this level requires avoiding mixing plaintext and encrypted areas in the same application, or within the same page. In other words, the entire application surface must be encrypted. Also, all application cookies must be secure and checked for integrity as they arrive in order to defend against cookie injection attacks.

Level 4, commitment, is about long-term commitment to encryption. For web sites, you achieve this level by activating HTTP Strict Transport Security (HSTS), which is a relatively new standard supported by modern browsers (IE support coming in Windows 10). HSTS enforces a stricter TLS security model and, as a result, defeats SSL stripping attacks and attacks that rely on users clicking-through certificate warnings.

Finally, at level 5, robust security, youre carving out your own private sliver of the PKI cloud to insulate yourself from the PKIs biggest weakness, which is the fact that any CA can issue a certificate for any website without the owners permission. You do this by deploying public key pinning. In one approach, you restrict which CAs can issue certificates for your web sites. Or, in a more secure case, you effectively approve each certificate individually.