SSL: Trust the math. Choose your friends wisely

Just like you, over the past months, we have been watching the coverage on the Edward Snowden leaks.

Each leak has provided unprecedented insights into both the capabilities and practices used by the intelligence community today.

While I personally find some of the details in these leaks both surprising and disappointing, the fact that the intelligence community has continued to develop its abilities around cryptanalysis and cyber defense is not surprising at all.

This is a problem that is literally thousands of years old: as long as cryptography has been applied, there have been people developing techniques to break that cryptography or work around it.

I won’t go into the details of these leaks in this post as I believe they have been well covered by others like The Guardian, ProPublica, The New York Times, Mathew Green (a research professor in Cryptography at John Hopkins), and Bruce Schneier.

But I do want to talk about our commitment to you and the rest of the Internet, provide some insights to our perspective on this problem, and provide you guidance on what we feel you should be doing to protect your privacy and the privacy of your customers when on the Internet.

First, I want to assure you that we have never received a request from any government to forward any key material or to certify any keys with any identity, domain name or organization information that was not legitimate, and if we did we would fight that request to our fullest ability.

Furthermore, we are the only certificate authority that I am aware of who has committed to provide notice to customers when we receive any requests for their data and it is (and always has been) expressly against our policy to use the fact we are a publicly trusted CA to facilitate a MiTM (man-in-the-middle).

Simply put, we believe we have a responsibility to represent your interests to the best of our ability, and we believe that responsibility requires us to act honorably and transparently – even when that is not the easy path.

In the name of transparency we also will be adopting a proposal from Google called Certificate Transparency in our platform update next year. This will make it possible for the public at large to monitor all the certificates that we issue.

One part of how we believe this responsibility manifests itself is how we design, build and operate our services. When building our services we proactively consider state-sponsored attacks as part of our threat models. This means that sometimes we have to do things that are less efficient and more time consuming, but it also helps us protect against compromises from a well-funded and highly skilled adversary. This extends itself beyond our own engineering and operations practices to the service, hardware and software providers we choose to work with.

As history has proven, we cannot be perfectly immune from attack or suggest that there are not vulnerabilities in cryptographic algorithms, hardware or software we leverage in our operations.

However, it does mean that we do our best to design our systems so that no single failure can bring down our services or compromise them. In fact we are in the process of making what is likely one of the largest investments made by our industry in the last decade to better scale and secure our services.

This takes us to the math, like Bruce Schneier said after reviewing the leaked papers. I trust the math. Our understanding of cryptography is constantly evolving, as is the definition of what is “secure enough”. With that said, the cryptographic algorithms used in digital certificates have undergone and continue to undergo extensive cryptanalysis review the world over. However, due to improvements in cryptanalysis as well as faster hardware, they are considered weaker today than they were just a few years ago. With that said the consensus is that they are still fundamentally sound.

We are actively working with industry partners to accelerate the adoption of more modern cryptographic algorithms that have the potential to be strong enough for the future and will continue to push for the migration to these algorithms as quickly as possible.

It is important to understand the problem does not stop with the cryptography that is used within certificates; the cipher suites that are used with those certificates represent a large attack vector as well. Today, according to the Trustworthy Internet Movement’s data, nearly 33% of the top 200,000 sites are using weak cipher suites and very few have deployed suites that offer Perfect Forward Secrecy (PFS), a mechanism that protects sessions from later key compromise.

To help address these issues we have worked with Qualys to provide the internet a free tool to help server administrators address these issues in their configuration and are working with theopen source community to provide examples of proper server configurations.

For me, though, one of the larger issues where we see too little progress is that of key management. We now know definitively from these leaks that adversaries maintain databases of compromised keys. This too isn’t exactly a surprise as security researchers maintain similar public repositories.

The deficiencies in key management practices that exist today are valuable to attackers for a few reasons; one of the largest is that sites maintain the same keys for far too long making them a valuable asset. For this reason we explicitly allow unlimited re-issuances and do not allow the same key to be used request to request. We also provide APIs and plug-ins to help customers automate these changes.

There is still a lot of work for us to do as an industry, and you have my word this is an area that you will see us invest more.

As for my recommendations to you as you look at your own infrastructure relative to the news:

1. When you are buying a certificate you are picking a partner, understand their motivations and what their commitments are to you. 

2. Maintain a policy for what cryptographic algorithms can be used in your environment, how often keys must be changed, how strong they are, and how they should be generated and secured. 

3. Maintain an inventory of your cryptographic keys, their age, strength and ensure each one of them is managed in accordance to your policies. 

4. Be mindful of the fact that deploying SSL/TLS securely requires more than just a certificate with a sufficiently large key. Be sure to: 

1. Run the most recent stable version of web server and SSL/TLS libraries available. 
2. Deploy ciphers that offer Perfect Forward Secrecy when possible. 
3. Ensure that all SSL configurations in your environment follow current industry best practices. 

5. Review the security of any and all machines that have access to key material used, ensure they are fully patched, hardened and only those necessary personnel have access to them.

Fonte: Globalsign