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.
It's the S: an HTTPS connection protects communication between your browser and the site's server.
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.
Most Web browsers can tell you everything you need to know about a given site's digital certificate.
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.
Enlarge / Self-signed digital certificates are significantly more susceptible to being spoofed.
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.
Chrome makes it pretty easy to get a high-level overview of the encryption being used to safeguard your data.
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).
http://arstechnica.com/security/2013/01/keep-it-secret-keep-it-safe-a-beginners-guide-to-web-safety/
No comments:
Post a Comment