Privacy vs. Security

Privacy and security are two sides of the same coin. They are tightly linked concepts that together allow an individual or a group of individuals to share information in secret from others. As individuals it is necessary that we keep our passwords private in order to ensure the security of our data.

Privacy (from Latin: privatus "separated from the rest, deprived of something, esp. office, participation in the government", from privo "to deprive") is the ability of an individual or group to seclude themselves or information about themselves and thereby express themselves selectively.

Security is the degree of resistance to, or protection from, harm. It applies to any vulnerable and valuable asset, such as a person, dwelling, community, nation, or organization.

Over the past year it has been revealed that the NSA has a massive program to collect it all - meaning if something is digital or can be made digital, they want a copy in their databases.

There are a number of tactics that the NSA uses to get access to our data, one of which involves exploiting non-existant or weak encryption of web traffic. Fortunately, this is easy to address in the short term by protecting currently unprotected web traffic with strong encryption and strengthening the encryption of web traffic that is currently only protected by weak encryption.

Reset the Net

Reset the Net is an effort to raise awareness among users and technologists to do what we can to strengthen the encryption used on web traffic as a step towards stopping mass surveillance.

For users, this amounts to adding your signature to demand that companies do everything they can to protect your privacy. It's really only going to matter if the number of people putting their name down is enough to get the attention of business and government leaders.

As technologists, it's about committing to add new and stregthen existing encryption protocols such that the NSA will no longer be able to rely on their existing means for carrying out their mass surveillance. For those of us operating web sites, this requires doing three things.

HTTPS

Sites need to encrypt all their web traffic by using HTTPS everywhere. Anytime there is user data being sent or received — regardless of whether it is the result of a form being submitted or data stored in a cookie — the transfer needs to occur over HTTPS. The simplest way to achieve this is to make any sites 100% HTTPS and not to use unencrypted HTTP anywhere. This way any accidental data leakage is avoided and no one can spy on you.

HSTS

HTTP Strict Transport Security (HSTS) is a mechanism that a web server can use to instruct a web browser that it should only access the current site using HTTPS. While making a web site 100% HTTPS goes a long way in securing it, it is also important to make sure that a browser can not be tricked into accessing the site over HTTP. That is what HSTS does.

PFS

Perfect forward secrecy (PFS) is a property of some of the encryption algorighms available for use with HTTPS. Algorithms that do not implement perfect forward secrecy ultimately depend on the web server's private key not being compromised. Capturing the secret key in this case would enable one to decrypt all the data that was encrypted using it.

Encryption algorithms that implement perfect forward secrecy have both the browser and the server calculating the same key, which itself is not transmitted from the one to the other. This key is then used to encrypt the traffic for that HTTPS session. This is important in two ways. First, the web server's private key can not be used to decrypt HTTPS traffic. Second, each HTTPS session uses its own key - this means that even if one managed to decrypt a single session, the same amount of effort would be required to decrypt the second as a new key would have to be guessed.

ScreenLight security today

With ScreenLight we are proactive about security. In fact, we already meet the objectives outlined by the Reset the Net initiative to be targetted for the end of the year.

Qualys SSL report results

As you can see, we're doing pretty well with our SSL implementation. In fact, the one thing holding us back from doing even better is that we have some customers whose clients are stuck running Windows XP and Internet Explorer 8 - an unfortunate combination that is unable to use any encryption algorithms that provide PFS.

Don't take our word, verify for yourself

There is no need for you to take our word for it though. You can run the report we grabbed the summary above from for ScreenLight or any other web site by using the form below. While there is much more to securing a web site than implementing HTTPS, HSTS and PFS, it is also not that difficult to do.

The future of Screenlight security

The first thing we are planning on doing is to disable the remaining non-PFS algorithm. Fortunately Microsoft has finally ended suport for Windows XP. With that taken care of, data moving in and out of ScreenLight itself will all be protected from prying eyes. Another benefit of making this change is that we will then only be supporting 256-bit encryption algorithms.

Things get a little more complicated with our content delivery network - Amazon CloudFront. First of all, CloudFront only supports keys up to 2048-bits. We use a 4096-bit key for ScreenLight and would prefer to do so for data transfered from our CDN as well. The second thing is that Amazon CloudFront does not support encryption algorithms that provide perfect forward secrecy. Finally, Amazon CloudFront also enables older protocols (ie. SSL 3) and weaker encryption algorithms (ie. RC4) limiting the encryption strength to 128-bits.

Qualys SSL report results

The results from the Qualys SSL report for one of our production CloudFront edge locations are still pretty good. While I understand Amazon wanting to support older protocols and algorithms to maximize browser compatibility, there is really no reason for them not to add the newer algorithms that offer perfect forward secrecy and 256-bit encryption such that they are prioritized for those browsers that support them with a fallback to the older protocols and algorithms only where needed. Hopefully we will see some of this in the coming months.