With all the revelations about out-of-control government spying on the Internet, a great deal of attention has been paid to:
- Political changes, such as new laws and legal interpretations. This, of course, is at the core of the problem – what they’re doing should not be legal, or if it’s already illegal, more effort should be made to notice when it’s happening and stop it, and somebody should be getting in trouble for doing it. However, there will be a lot of resistance to this, and change will take a lot of time and likely be incomplete.
- “NSA-proof” privacy solutions, such as end-to-end encrypted email or chat, or using TOR to browse the web. While no solution is really “NSA-proof” in the end (especially if they target your actual computer), a lot of solutions can come reasonably close. But end users often find such solutions inconvenient to use, or may not even be aware of them. Worse, they may not feel they have anything to hide from the government or are skeptical they’d be targeted for attention; indeed, we are aware that using such tools explicitly DOES single you out for attention from three-letter agencies.
These approaches are not only laudable, but critical – they are necessary to protect against determined, focused attacks by three-letter agencies. But there are many other things that can be done to protect against casual “hoovering” of information on the Internet. Part of the problem is simply this: it’s too convenient to access most information by casual listening, because there isn’t even a pretense of privacy or security when information is transmitted without any encryption at all. This leaves a very large amount of internet traffic unencrypted for them to sift through without needing to crack or otherwise bypass any form of encryption.
But what if we made encryption the default for more traffic? While it would still be feasible for the NSA to crack or bypass much of that encryption when they really wanted to (by hacking your computer to install a key logger, for instance, or requiring a service provider to hand over your data), merely enabling encryption where it is currently missing could vastly reduce the amount of unencrypted traffic flowing through the “pipes”, meaning it would cost a lot more to sift through, while also making it more difficult to target encrypted traffic for special treatment as “suspicious activity”.
Most encryption beyond whatever happens to be enabled by default turns out to be too difficult for most users to deal with. We also can’t control what access the government has to Google, Microsoft, Yahoo, and Facebook that bypasses the https connections to their servers. But as engineers working on all the other websites and servers out there, we do have control over a lot of other things.
There is much that can be improved: security and privacy on the Internet are shockingly bad, and not just because the NSA is really good at their job (though part of their job is supposed to be strengthening our cyber-security, a task I believe they are failing at). A lot of this is caused by laziness on the part of developers, sysadmins, and internet engineers, as well as a lack of understanding, priorities, or budget from managers.
But many of these changes don’t really take that much time, and aside from that, often the only cost is that of a signed SSL certificate, available for as low as $50 per year.
While there are many security tips for how to lock down your server and network, here I will only talk about simple steps you can take to increase the “background noise” level of security and privacy of communications over the Internet. Here are some suggestions:
- Enable HTTPS/SSL on your web server. I’ll talk about this more below.
- Enable TLS for SMTP on your mail server. While it is probably not feasible to force the use of TLS at all times (many mail servers may still not support it), at least enabling it on yours increases the odds of email transfers between servers being encrypted.
- Disable FTP and telnet in favor of SFTP and SSH. You don’t want to be talking to your server or transferring files over non-private connections when there are secure alternatives that are just as easy to use.
These three steps, taken by the administrators of many sites around the Internet, could end up encrypting a large amount of traffic that is currently sent as plaintext.
Enable HTTPS/SSL on your web server
This is perhaps the most obvious one, as the web is probably the biggest activity people use the Internet for and whether a site is secure or not is immediately visible to users.
What does it take?
- Install a certificate and encryption keys. In order to protect against man-in-the-middle attacks, this should be bought from a legitimate certificate authority, rather than using a self-signed certificate. However, aside from e-commerce sites, where there’s extra value in trusting who you’re about to give your credit card number to, there’s not much benefit to so-called “Extended Validation” certificates aside from more profit for the certificate vendor.
- Enable port 443 on your web server, referencing the keys that were installed in step one.
- Make sure your web pages work properly over SSL, most particularly that they don’t include any insecure content that would trigger “mixed content” warnings in the browser. This includes CSS and JS files, images, and background images referenced from the CSS.
- Make your SSL as secure as it can be. This includes:
- Using at least 2048-bit encryption keys.
- Enabling “perfect forward secrecy” by enabling the needed “ephemeral” cipher suites and making their use preferential, as well as making sure TLS Session Tickets are disabled.
- Disabling weak cipher suites, such as anonymous, null, or export ciphers, as well as avoiding Dual_EC_DRBG, which appears to have been “back-doored” by the NSA.
- Protect against BEAST and CRIME attacks by upgrading to TLS 1.2, de-prioritizing vulnerable cipher suites (unfortunately there is no clear approach that works in all situations), and disabling TLS compression.
- Make encryption mandatory by implementing a global 301 or 302 redirect from port 80 to the same URL on port 443, and updating all your internal links to reference https.