As part of my job working on SSL Labs, I spend a lot of time helping others improve their TLS security, both directly and by developing tools and writing documentation. Over time, I've noticed that deploying TLS securely is getting more complicated, rather than less. One possibility is that, with so much attention on TLS and many potential issues to consider, we're losing sight of what's really important.
That's why I would like to introduce a TLS Maturity Model, a conceptual deployment model that describes a journey toward robust TLS security. The model has five maturity levels.
> See also: Five tips for keeping corporate email secure
At level 1, there is chaos. Because you don't have any policies or rules related to TLS, you're leaving your security to chance (e.g., vendor defaults), individuals, and ad–hoc efforts generally. As a result, you don't know what you have or what your security will be. Even if your existing sites have good security, you can't 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 it's usually the easiest one to achieve. With modern systems, it's 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 we're talking about web sites, 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). HTTP Strict Transport Security enforces a stricter TLS security model and, as a result, defeats SSL stripping attacks and attacks that rely on users clicking–through certificate warnings.
> See also: One year on from Heartbleed, what has changed?
Finally, at level 5, robust security, you're carving out your own private sliver of the PKI cloud to insulate yourself from the PKI's biggest weakness, which is the fact that any CA can issue a certificate for any web site without the owner's 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.
The conceptual simplicity of the TLS Maturity Model enables us to easily understand where we are and what we need to do to improve. As a result, we can focus our attention on what really matters. Although level 5 provides best security, it involves most work and addresses risks that don't exist for most sites. Level 4 is arguably the minimum level that can be called secure, and the level that most organisations should be aiming for.
