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.

Andrew Cunningham

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.

Andrew Cunningham

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.

Andrew Cunningham

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).

Andrew Cunningham
Andrew has a B.A. in Classics from Kenyon College and has over five years of experience in IT. His work has appeared on Charge Shot!!! and AnandTech, and he records a weekly book podcast called Overdue. Twitter@AndrewWrites

69 Reader Comments

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.

I'm interested that if you're using https, you're using a "combination" of symmetric and asymmetric encryption. Is there some analogy that would help me understand what's happening?

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.

I'm interested that if you're using https, you're using a "combination" of symmetric and asymmetric encryption. Is there some analogy that would help me understand what's happening?

You start with asymmetric to set a common secret in a secure way and then go on using that in symmetric crypto. Asymmetric is too complex to be kept all the time.

This sort of stuff should be taught mandatorily in schools, together with basic primers on safely using FB, Twitter, YouTube, email, malware, etc etc, understanding how your information is collected and used, how others can access it, how easy it is to build a profile on someone. Internet Safety 101. It should be up there with Maths and English as a core subject in every school.

I like HTTPS everywhere from the Electronic Frontier Foundation. It is a browser extension for Firefox and Chrome that attempts to encrypt has much internet traffic as possible as well as helps to keep an eye on the integrity of digital certificates.

I like HTTPS everywhere from the Electronic Frontier Foundation. It is a browser extension for Firefox and Chrome that attempts to encrypt has much internet traffic as possible as well as helps to keep an eye on the integrity of digital certificates.

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.

I'm interested that if you're using https, you're using a "combination" of symmetric and asymmetric encryption. Is there some analogy that would help me understand what's happening?

You use symmetric encryption because it's both faster and in general is hardware accelerated. However in order to setup a symmetric encryption you need both parties to have a shared secret key. But how do you know when transferring that the key actually originated from Gmail.com servers? Or that the key isn't visible to anyone but you enroute? What you do is rely on third party like VeriSign to provide you with information in order to authenticate/verify the key yourself. Once you verify that key, you can then start using that key with the symmetric encryption and can be certain the only two people that know what the key is you and gmail.com.

I like HTTPS everywhere from the Electronic Frontier Foundation. It is a browser extension for Firefox and Chrome that attempts to encrypt has much internet traffic as possible as well as helps to keep an eye on the integrity of digital certificates.

I like it too, but I'm wondering if it's able to recognize fraudulent certificates. Never heard about warnings in real life from someone...

I am not sure if it lets you know personally or not (I have not had this happen). They may just forward problems to the certificate authority for resolution. I know all certificate data is sent to the SSL Observatory for analysis (if you opt in) which is used to detect problems.

Thanks for this information, but IMO, you've offered it in the wrong order, especially if this is a guide that is supposed to be consumed by people outside of the typical Ars audience, because we pointed them here.

Starting with https/encryption was ok (but may make some eyes glaze over unfortunately), but I'm very surprised there was no mention of password strength, or a link/mention of the subject. Especially since it doesn't seem like that's something that will be covered with the Malware discussion.

2: What to watch for -- suspicious e-mail/bank activity, links (and how to see where they really go), pop-ups, toolbars, malware/adware, browser certificate warnings

3: How to defend -- password practices (is there a way to make LastPass/1Password/etc. sound simple? Which is the easiest for non-techies?), 2part auth, anti-virus/malware (adblock, noscript?), update software, encryption/VPN

I probably left some stuff out, but if the first two "articles" were easy-reads, and the 3rd was basically a check-list that spells out almost exactly how to achieve a more secure digital presence I could see them being useful for years to come -- especially if they were updated when new threats/options arise.

Hear, hear, ClownRazer. (Upvoted.) But you know what? We have several sites that we *must* visit that don't offer "https". (Just as we have several sites that we *must* visit that enforce stoopid insecure password limitations, for example. And sites that require Java. I asked.) Important sites (for us, anyway). I've sent gripes. P1$$3$ me off little end.

I suspect that many Ars readers already understand that all a VPN does is help you create a trusted network environment when you're on an untrusted network (like a public wifi hotspot).

However, if I were to give this article to most of the people I know that aren't in the IT profession, I feel they would be left with the impression that a VPN connection would make non-secure websites (HTTP) act like secure websites.

Particularly since at the end of the first page, the article presents a VPN as a solution to unencrypted HTTP traffic:

Quote:

Many sites still communicate using plain-old unencrypted HTTP. If you want to protect all of your traffic at once...

Protip: If you're using Chrome or Chromium, it's very easy to turn off Javascript and all plugins for all but a small number of whitelisted sites. To turn it on for any given site, you can click that little page icon in the location bar (or the padlock icon, if you're using HTTPS). I imagine this will be covered in the next article, though.

I agree with a few of the commenters here that the first part was pretty good, but the jump to VPN felt like going from training wheels to warp-speed.

Pretty much everyone needs to know about HTTPS and things like safe passwords, phishing, malware, etc. VPN's are really more of a niche that aren't really for the average user that does their 'important' work from home or office.

I'm a bit confused. I don't really know anything about VPN: how does having a VPN set up in your home protect you? Say I use OSX server, I connect to that server, but what does that server connect to? Could someone explain this too me a bit more?

The article seems to imply that corporate VPNs will encrypt and tunnel all of your traffic. In my experience this is not always the case. If you check the routing table on your corporate VPN client, you'll often find that the client is only tunnelling traffic to your corporate sites, but other traffic to other public IPs routes normally.

I'm a bit confused. I don't really know anything about VPN: how does having a VPN set up in your home protect you? Say I use OSX server, I connect to that server, but what does that server connect to? Could someone explain this too me a bit more?

I doesn't really. It relays your traffic securely between you and your home, so it's safer if you're on a sketchy public wifi network. You're no safer than you are on your home desktop though. See Cameroon's comment above.

When I read the title to this article, I thought, great, something I can send to my parents. But it got into details very quickly that only a higher level user would appreciate (and it was appreciated). It's just the headline was a a little misleading.

An article series like ClownRazer suggests would be super popular and I would definitely forward that on to many, many people. Make it happen!

1) What about sites that require membership login to see any content and forbid Google from scanning the site? As a member, once you're logged in, can your correspondence on the site be seen?

2) Does cellular security fall under the same general considerations in this article or is it more secure by default?

1) All that site did was prevent their data from being posted on a search engine. It does not stop man in the middle attacks. So, I once saw a cisco router sitting in front of a data center (hosting company) that had left the root account open. Anyone could have logged in and started copying off the traffic. Now, if that website you mentioned was in that data center, then you have a problem. Someone on that router could be watching all your traffic - unless it was encrypted - and they hadn't watched the encryption handshakes.

2) Cellular networks operate on very similar protocols. They just have a higher barrier to entry as you need cellphone modems to intercept things. If you use your smartphone to browse the web, you are vulnerable (see answer 1). The problem is that your web traffic has to jump from the cell network to the normal internet. Once on the internet, all the normal problems apply. To make matters worse, many cell phone apps ignore encryption entirely....

3) I have a friend who used to run security for a regional ISP. He observed that you should never trust an ISP. They leave routers open; they run wireshark; they are no different then your normal IT. From their perspective, your network is just a computer node. Just like a local IT sees all the computers under its care - or should - they viewed customers as a computer node. They fired an employee for running cain and abel on the network between customer nodes.

I suspect that many Ars readers already understand that all a VPN does is help you create a trusted network environment when you're on an untrusted network (like a public wifi hotspot).

However, if I were to give this article to most of the people I know that aren't in the IT profession, I feel they would be left with the impression that a VPN connection would make non-secure websites (HTTP) act like secure websites.

Particularly since at the end of the first page, the article presents a VPN as a solution to unencrypted HTTP traffic:

Quote:

Many sites still communicate using plain-old unencrypted HTTP. If you want to protect all of your traffic at once...

edit: Well, maybe I do understand. What I thought was that it secured your communication from your device to the VPN server and that's it (not from the VPN server to the website). So this is useful when on a public WiFi, but it doesn't secure the traffic from the website to the VPN which is still susceptible to intercept.

edit: Well, maybe I do understand. What I thought was that it secured your communication from your device to the VPN server and that's it (not from the VPN server to the website). So this is useful when on a public WiFi, but it doesn't secure the traffic from the website to the VPN which is still susceptible to intercept.

You're correct, but as "A beginner's guide" the article seems (to me anyway) to be poorly worded with respect to what a VPN does. Or at least what it encrypts/protects.

Obviously they shouldn't be using their real ones, just to get a idea how to create a hard one to crack.

Also keep in mind the cracking rate is based upon one PC, when botnets of hundreds of thousands or even millions of PC's could be deployed against a router, so it should be even longer and more randomized.

If possible, turn off PING on one's home router. Unfortunately Apple's routers don't offer this ability.

SSL connections begin with security and proceed directly to secured communications, TLS connections first begin with an insecure “hello” to the server and only switch to secured communications after the handshake between the client and the server is successful.

TLS allows both secure and insecure connections over the same port, whereas SSL requires a designated secure-only port. For users connecting to an email server via POP or IMAP, this means that using TLS will allow you to opt for secure connections but easily switch to insecure connections if necessary without needing to change ports. This is not possible with SSL.

If neither SSL nor TLS is used, then the communications between you and the server can easily become a party line for eavesdroppers. Your email data and your login information are sent in plaintext for all to see, and there is no guarantee that the server you connect to is not some middle man or interloper.

Nice article but you have only scratched the surface. https almost takes care of itself these days, without much effort. (Google redirects http to https, for example) You may have confused people with the VPN part as you discussed two very different applications of VPN, VPN for private network access and VPN services for anonymous web surfing. I could see how some people might get the idea that they could build their own VPN server for anonymous web surfing which would be the wrong conclusion.

If you plan on more articles in this area may I suggest one (or some) on encrypting one's personal emails with PGP or it's various incarnations and equivalents. This is where mainstream services are really failing us.

Considering that the NSA and other security agencies appear to be hoovering up all of our personal communications, I think we need to start pressing the public email services to include an easy to use encryption option. Until then we are on our own and PKI can be daunting. A good tutorial series would be useful.

Why hasn't some enterprising country stepped up to lead the way with VPN, sort of how the Swiss used to do banking? In 5-10 years it will be the only way to securely interact over the Tubes.

The USA had poorly considered "ammunition laws" around encryption tech for many years. To this day, if you are inside the USA and export strong encryption, you are supposed to request and get an export license from the Fed Government.

* IPSec was created 15+ yrs ago. It is part of the IPv6 standards, but IPv4 versions have existed all this time too. Secure.

* L2TP was pushed by network companies like Cisco and others. Secure.

* OpenVPN is not pushed by anyone. It is 100% F/LOSS, zero advertising, but free to use and deploy. Secure.

* PPTP was pushed by Microsoft. It has been hacked at least 2 times, once again in 2012. Security pros do not trust it. All Microsoft OSes support this.

VPNs have been around for a long time, but it is hard to explain to non-technical users how and why a VPN is important AND when a VPN is not important.

Sadly, there is no silver bullet for computer security. There is not even a silver bullet for network security or browser security.

have to agree - the VPN discussion in the article is lacking... it doesn't address even the basic real-world implementation concerns.

setting up any VPN is opening a hole in your defenses. newbies setting up their own VPN is asking for trouble. newbies accessing their VPN (which, typically has minimal internal security) from an internet cafe (keyloggers, shoulder-huggers, etc etc) is also asking for trouble.

as noted above, a VPN is useful (to most people) in very limited circumstances - (1) you want to anonymize your traffic by encrypting traffic to an anonymizer service (so, VPN is to a network owned by someone else) that forwards the traffic from a source IP that doesn't register to you (minimally anonymous, really); or (2) you want to send encrypted data to a secure node within a secure network without having to worry about packet sniffing along the way, AND you can't rely on and/or don't want to tip your hand to using https, ftps, ssh, etc etc, ALL of which are easier to maintain, securely, than a VPN. i'm sure there are corner cases I'm not considering, but (2) is pretty much limited to (a) enabling domain and/or peer networking services (multiple services) without having to set up multiple individual secured services, or (b) sharing files you want the contents/size of which kept secret.

in truth, (2) is consistently losing out to secure remote desktop services across the board, and much of those piggyback on https and/or ssh. too slow for comfortable remote desktop is typically too slow for whatever services you're trying to tunnel through the VPN (give or take some smart config strategies).

for a newbie, all they should know is a much shorter version of the above, and that (in bold letters) a VPN configured incorrectly is often orders of magnitude worse than typing your gmail password into an http (vs. an https) page, if that's even possible now.

aside from all that, i still don't know if i'd promote VPN as a way to access anonymous services that you can rely on. i keep fearing that someone will risk their life on such incomplete info (politics in the middle east) and the worst will happen.

Thanks for this information, but IMO, you've offered it in the wrong order, especially if this is a guide that is supposed to be consumed by people outside of the typical Ars audience, because we pointed them here.

Starting with https/encryption was ok (but may make some eyes glaze over unfortunately), but I'm very surprised there was no mention of password strength, or a link/mention of the subject. Especially since it doesn't seem like that's something that will be covered with the Malware discussion.

2: What to watch for -- suspicious e-mail/bank activity, links (and how to see where they really go), pop-ups, toolbars, malware/adware, browser certificate warnings

3: How to defend -- password practices (is there a way to make LastPass/1Password/etc. sound simple? Which is the easiest for non-techies?), 2part auth, anti-virus/malware (adblock, noscript?), update software, encryption/VPN

I probably left some stuff out, but if the first two "articles" were easy-reads, and the 3rd was basically a check-list that spells out almost exactly how to achieve a more secure digital presence I could see them being useful for years to come -- especially if they were updated when new threats/options arise.

I agree. I saw this article and immediately thought to forward it to my gf. But then I read it and realized it would have been useless. She would have glazed over 2 paragraphs in.

That said, I do tell plenty of people to consider VPN if using any sort of unsecured/untrusted/public network. Which everyone loves to do out of convenience.