Wednesday 30 January 2013

Keep it secret, keep it safe: A beginner's guide to Web safety

My family has been on the Internet since 1998 or so, but I didn't really think much about Internet security at first. Oh sure, I made sure our eMachines desktop (and its 433Mhz Celeron CPU) was always running the latest Internet Explorer version and I tried not to use the same password for everything. But I didn't give much thought to where my Web traffic was going or what path it took from our computer to the Web server and back. I was dimly aware that e-mail, as one of my teachers put it, was in those days "about as private as sticking your head out the window and yelling." And I didn't do much with that knowledge.

That sort of attitude was dangerous then, and the increasing sophistication of readily available hacking tools makes it even more dangerous now.  Luckily, the state of Internet security has also gotten better—in this article, the first in a five-part series covering online security, we're going to talk a bit about keeping yourself (and your business) safe on the Web. Even if you know what lurks in the dark corners of the Internet, chances are you someone you know doesn't. So consider this guide and its follow-ups as a handy crash course for those unschooled in the nuances of online security. Security aficionados should check out later entries in the series for more advanced information

We'll begin today with some basic information about encryption on the Internet and how to use it to safeguard your personal information as you use the Web, before moving on to malware, mobile app security, and other topics in future entries.
SSL and TLS, the invisible security blankets

The most common kind of Web encryption is one many users probably don't even notice. The Hypertext Transfer Protocol Secure protocol, or HTTPS, encrypts standard HTTP Web traffic using the Transport Layer Security (TLS) or Secure Sockets Layer (SSL) protocols. TLS is the newer of the two and is more frequently used by modern sites, but since they're functionally similar, they're often lumped together as "SSL/TLS" by security gurus. The newest version of the SSL protocol is 3.0, and TLS 1.0 can be thought of as SSL 3.1 if it helps you understand the relationship between the two. HTTPS is used most often in cases where sensitive or personal data is being transmitted—usernames and passwords, financial information, and webmail clients are all commonly encrypted. Regular webpages often aren't, though alternate, HTTPS-protected versions of sites like Wikipedia are slowly becoming more common.
HTTPS establishes an encrypted connection between the Web browser you're using and the server you're accessing. Data is encrypted before being sent to the server over the Internet, and the data is only decrypted once it has safely reached the server—the same is also true for information sent from the server back to your browser. In standard "symmetric" encryption, a key used to encrypt and decrypt data is the same. In asymmetric public key cryptography, by contrast, a public key that's available to anyone is used to encrypt data that can't be deciphered without a secret-but-mathematically-related private key. HTTPS uses a combination of the two to keep unauthorized parties from decrypting sensitive data.

Another vital part of the protocol involves verifying that the server and its public key belong to who they say they belong to. An encrypted connection isn't worth much if all of your data is being received and decrypted by someone running a bogus server (a phenomenon known as a "man in the middle" attack in security circles). To properly prove the identity of your Web server (and to verify that your public key belongs to who you say it does), you need a public key certificate signed by a recognized certificate authority (CA). CAs are trusted entities who, for a sometimes hefty fee, will give you a "signed" digital certificate that verifies your identity when browsers visit your site.
Server administrators can still encrypt traffic without coughing up for one of these signed certificates, but these "self-signed" certificates don't do any reliable identity verification and thus are more easily spoofed. Most browsers and other programs are also designed to distrust self-signed certificates specifically because they're easier to fake, and they will generally throw up scary error messages discouraging users from visiting any site that uses them. It's insecure, and it's a bad user experience.
The weakness of this system is that a CA is only as trustworthy as the CA's own security policies make it—if the CA is compromised, every certificate that it has ever issued should also be treated as compromised. That, however, is another article.

With this whole certification process mostly out of the user's hands, the best thing you can do to protect yourself when transmitting private information is to be aware of what sites use HTTPS and what sites don't, and to be on the lookout for properly signed certificates. Most browsers will display an image—generally a padlock icon—in the address bar to denote that you're looking at a secure site. These icons can sometimes be spoofed, so you should always look for the "HTTPS" in the address bar to be sure.

If you ask it to, your browser can also tell you just about everything about the certificate and the encryption algorithms that a given site is using—we'll be using Google Chrome in our screenshots, but this is stuff that just about any browser can do.



Clicking the browser's padlock icon while visiting Facebook, for example, gives us the most relevant information about the certificate and its encryption algorithms: the certificate has been signed by VeriSign and the connection uses TLS 1.1 with 128-bit RC4 encryption. Clicking the Certificate Information link will display even more information about the certificate itself, including its expiration date and more data about the entity the certificate belongs to.

SSL and TLS encryption is all well and good—and use of the protocols is becoming increasingly common—but the fact remains that they can only protect the connection between your computer and one site. Many sites still communicate using plain-old unencrypted HTTP. If you want to protect all of your traffic at once—especially if you're on a public Wi-Fi network where anyone could be trying to intercept your encrypted and unencrypted communications—you might want to protect yourself using a virtual private network (VPN).

Using a VPN for comprehensive protection

There are a few different types of VPN servers, but most of them work the same basic way: your computer authenticates to a VPN server, and then all traffic between your computer and the server is encrypted. Think of a VPN as a secure "tunnel" that separates your data from the rest of the data on the network, and it is used to encrypt all of your traffic instead of just part of it. All of your communications are decrypted by the server and then set out over its (presumably) secure network before being re-encrypted and sent back to your computer through the tunnel.

The downside of a VPN service is that it's generally incumbent on the user to initiate the connection, where SSL or TLS connections can be more-or-less transparent (some more automated VPN alternatives (like Microsoft's DirectAccess) exist but are less widely used). You also have to either build or gain access to a VPN server—your employer may offer one that you can use, but if you have non-work-related things you need to do (or just don't want your employer to see everything you do on the Internet) you may need to work something else out.
If you want to roll your own server, you can use free software like OpenVPN (or, for Mac users, the VPN server included in the $20 OS X Server package). Some higher-end routers and third-party router firmwares also include basic VPN server functionality without requiring dedicated hardware. OpenVPN also serves as the backbone for many third-party VPN services, which we'll talk about in a bit more detail later on.

This route is probably the most secure, if you don't mind purchasing and maintaining the hardware required—your VPN connection is going to be just as private as using your network in the comfort of your own home, since you're in control of everything on it. But this approach won't work for everyone. You'll also need to configure the proper port forwarding settings on your router to allow communication between your VPN server and your clients, a process that can vary widely from router to router. For those using consumer-level Internet, you'll usually need to deal with an external IP address that changes occasionally as well. This requires tweaks to your VPN server's settings or the use of a dynamic DNS service like DynDNS—that is, if your ISP allows VPN communication at all. Both of these issues can usually be circumvented by purchasing a business-class connection from your ISP, but this is generally quite a bit pricier than a consumer-level connection.

Like most technology services, though, VPN servers can be outsourced. A large number of for-pay third-party VPN services are available, most of which offer one or all of the different VPN protocols we've discussed above. The benefits to using a third-party service should be obvious: you don't have to run your own server, and there's less likely to be downtime caused by network outages, power outages, system updates, or the other small, inexplicable problems that crop up when you're taking care of your own hardware. Most of these VPN services also promote privacy as well as security, playing up the fact that they can mask your traffic from your ISP or even make you appear as though you're connected from another country.

The main drawback, paradoxically, might be security; these VPN services are only as trustworthy as the people running them since you're going to be sending all of your traffic to their servers.

"This is the inherent difficulty with VPN services: they require the user to place a huge amount of trust in the company that's running the VPN," said Peter Eckersley, Technology Projects Director for the Electronic Frontier Foundation. "Even if you use HTTPS/TLS for everything, your VPN is always in a position to have logged your IP, your DNS queries, and which servers you connected to. If you don't or can't use HTTPS/TLS, you have to trust the VPN with the content of your traffic too."

"There's also a question about whether VPN providers are guaranteed to follow their own stated privacy policies," Eckersley continued. "That's a complicated question, and evaluating it for a particular VPN would require not only knowing about the VPN company and how trustworthy its staff is, but in many cases knowing about law for all of the (often international) jurisdictions involved."

For a comprehensive look at the various VPN providers' respective privacy policies, Eckersley recommended this list from TorrentFreak. (The site polled a number of third-party VPN services regarding their data logging and privacy policies.) Granted, it's not generally within these services' best interest to access your information or sell it to others—any company that was discovered doing any of these activities would almost surely be abandoned by its security- and privacy-minded users—but it's still something outside your control. Even the best provider won't be quite as private as a server you're running yourself, but it's also better than staying unprotected on a public Wi-Fi network. Regardless of the services' intentions, it could still be breached or compromised in some way, leaving your information at risk.
First step, not the only step

Technologies like TLS and VPNs are fundamental to keeping you safe on the Web. The best first step you can take to protect yourself is to know what this stuff is. Make sure sites you put your personal information into—credit card numbers, addresses, passwords—all use signed digital certificates and some form of SSL or TLS encryption. If you regularly work with confidential information while using public networks, consider using a VPN to keep your data protected from other, potentially malicious users on that network. Even if that's all you do, you'll be in much better shape than I was when I started using the Internet.

No comments:

Post a Comment