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

69 Reader Comments

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.

It's worse than that. A lot worse. The SSL system as a whole is only as trustworthy as every single CA in the world. Basically, we're trusting companies run by the American, Russian, and Chinese governments to be secure and not to issue fraudulent certificates for any host on the Internet, along with a herd of profit-minded companies.

So far, the government ones have been fine, as far as we know, but several of the commercial ones have been shown to be insecure, leading to massive scrambles by every OS and browser vendor to stop trusting those bad authorities.

I'm surprised Tor wasn't mentioned. I agree that a VPN is excellent but it's also costly. Tor is an excellent alternative, assuming there's no man in the middle or you haven't connected to a rouge node.

It would be helpful to define what kind of beginner this article is targeting. It's definitely not written for an audience that has little to no understanding of computers, never mind how network protocols and the internet work. The article is very technical, almost tiring in its detail and depth, and not something I would recommend for an actual beginner.

One problem us tech people have, is that many of us don't know how to speak in a way that a 'normal' user understands. I agree that this is the type of knowledge that needs to be put out there. But there must be a way to deliver it that's more concise and generally understandable.

The debate about "host-based security" - that is, having someone else run a component of your security architecture rather than trying to do it yourself - has a tendency to form into a caricature of itself if taken to the extreme. Starting from a fairly reasonable premise, it veers of into swampy terrain like recommending folks try to run their own VPN network (!!) rather than purchasing service from a proven, experienced, competent provider.

Yes, in theory, doing everything yourself means you don't have to trust anyone else - and thus won't be burned if someone else betrays you. That's all well and good. However, in practical terms ALL security implemented nowadays is based on trusting someone else - whether we admit it or not: we trust that someone wrote good code, or we trust that someone else audited that code, or we trust the fab that made the chips on which the code runs, or we trust the tech website that says a given security widget is not all hot air, or we trust the distribution path for the binaries we use (unless we compile ourselves... in which case we have to trust the compiler - or we can do hash checks, but then we have to trust the hash computation tool we're using, unless we write our own, in which case we still have to trust the hardware on which it runs... ad nauseum). Nobody writes their own crypto algorithms, not even the vast majority of professional cryptographers - they trust stuff written by someone else, or they trust the review process that has tested those algorithms, or they trust the academic journals that carry the papers that certify the testing process others have done. There's _always_ trust in the chain, somewhere.

So the real question is: what are the smart, and dumb, ways to go about making trust decisions? Trusting yourself to run your own VPN network, if you know it's beyond your technical chops, is dumb trust. Trusting experienced, competent, respected folks to do so might - and they key is _might_ - be a better idea for most folks. Smart. It's a balance. There's no black and white, despite what some zealots might claim (see: https://www.cryptocloud.org/viewtopic.php?f=17&t=149). (and yes, using Tor requires trust too - it's no panacea for trust-free security, despite the dreams of the most rigid of the Tor fundamentalists... see "evil exit node" issue for example)

Trust is complex. That's as true within the technology world as it is outside of it. Good trust decisions involving making wise trade-offs, getting lots of benefit for only a little extra risk as variables are shifted about on the possibility landscape. Such a process is actually surprisingly difficult to describe in the abstract: to boil it down to a series of rigid decision rules that can be applied in any context. In contrast, tactical trade-offs in the real world are often fairly straightforward: is it better to do this, or do that?

Remember that the default option of "do nothing" is rarely the best outcome... and that's what happens if people don't have the ability to make good choices based on their own trust-balance parameters. So it is that real-world security configurations for most folks using the internet becomes inherently difficult process - they don't have confidence in their own trust decisions, and thus are tempted to do nothing at all. The best way to help break this jogjam is to teach the skill of making good trust choices; in contrast, burying folks in technical mumbo-jumbo rarely helps all that much, and can actually result in non-techies simply giving up and running everything plaintext.

Which, incidentally, is the worst security outcome of all.

So we all need to do better in providing the kinds of educational resources that make a tangible difference. Rarely is it the case that actual human beings are better served trying to roll-their-own security solutions: not only are they likely to make serious errors in configuration, they're all but guaranteed to grow frustrated and, eventually, give up altogether.

One problem us tech people have, is that many of us don't know how to speak in a way that a 'normal' user understands. I agree that this is the type of knowledge that needs to be put out there. But there must be a way to deliver it that's more concise and generally understandable.

My assertion is that there is no way to deliver it in a way that's concise and generally understandable.

I was just rereading some Dijkstra, and found this fun document: On the cruelty of really teaching computing science. Basically, Dijkstra argues that computer science is so radically different than anything we've encountered before that we can't reason about it in the same way that we reason about objects from everyday experience. Consequently, when dealing with computers, it's natural that there's a new vocabulary that takes a lot of education to understand.

I think, ultimately, the best you can do for ordinary people is to turn portions of security into a product. Like those ridiculous "secure lines" in movies, people want to be able to click a button and have a safe experience. But that's ultimately futile, because most people have lives that don't center on using secure products in secure ways, and the progress of technology makes secure products obsolete.

One thing I find everywhere (including in this article) is that no one bothers to mention client certificates. Whenever you see someone talk about running a home server, they will always say VPN. Good luck connecting your VPN on a phone or tablet, video game console, or even many flavors of linux...

The certificate system can also be used backwards, with the server requesting a certificate from the client. Both server and client trust a root certificate authority which issues a certificate to each party. Then neither side will allow communications unless the other side proves who they are. This way you can easily setup a home web server that only someone with the client certificate can access. You can even make individual client crets for each person who you want to give access to.

Futhermore the client cert can be deployed using a pfx file which is encrypted with a password. Meaning that even if someone steals or gets hold of the pfx file, they can't use it to get the client certificate and so can't connect to your server.

It's worse than that. A lot worse. The SSL system as a whole is only as trustworthy as every single CA in the world. Basically, we're trusting companies run by the American, Russian, and Chinese governments to be secure and not to issue fraudulent certificates for any host on the Internet, along with a herd of profit-minded companies.

So far, the government ones have been fine, as far as we know, but several of the commercial ones have been shown to be insecure, leading to massive scrambles by every OS and browser vendor to stop trusting those bad authorities.

You don't 'automatically' trust every CA in the world... anyone can be a CA. Your browser comes with a bunch of CAs that are automatically added to its trusted list. You can delete them all if you want - and you probably should. In-fact the best way is to delete them all and trust them one by one as you visit sites. You will probably find that you only end up trusting about 8 to 12 CA's instead of the hundreds that come reprogrammed, and the potentially millions that are trusted as sub CA's.

Secondly, you can always view the certificate. If the certificate has suddenly changed and a site is now verified by another certificate, its a pretty good hint that something is wrong. There is even a firefox plugin that allows you to crowd share certificates, so you will know if someone is doing a man in the middle attack with a certificate that you trust, as everyone else will be reporting a different certificate for that site.

An even better way is to physically contact each company you are trusting with important data and add their individual certificate as a trusted certificated, and don't use CA's at all. This is the best way to do banking. That way you are trusting no one except the bank.

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?

Generally this is controlled by using a robots.txt file in the webroot folder. Google/Bing/Yahoo play nice out of courtesy crawling-wise, it provides no actual security. (edit: visibility requiring authentication is not fool-proof either, as a 'member' other have access to your data as well (publicly posted, low-hanging fruit), and maybe they (online content keepers) are too concerning with mining for $ to 'waste' cpu on securing against rouge access)

deckeda wrote:

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

The IP packet is encrypted before hitting whatever type of cable/dsl/fiber/cellular/satellite network is in place. Doing a 'traceroute' in a terminal will show that the packets bounce around more than you might thing regardless of transmission medium.

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.

One problem us tech people have, is that many of us don't know how to speak in a way that a 'normal' user understands. I agree that this is the type of knowledge that needs to be put out there. But there must be a way to deliver it that's more concise and generally understandable.

My assertion is that there is no way to deliver it in a way that's concise and generally understandable.

As a long-time tech writer who's written many a tutorial for your typical high school tech student, I'll agree that it's not easy.

The trick is implementing Bloom's Taxonomyin a strict fashion. If the writer does that, virtually any subject can be explained, but staying concise is just a matter of discipline. I used to work with a guy who was a genius at this, he wrote many of the original Heathkit electronics training books. I bet some of you old farts read those books. :-) (They were still being published until a year ago....still probably the best available on the subject.)

Unfortunately Andrew didn't define his "beginner" level and then didn't stick to whatever level of the taxonomy was relevant to that level. For example, the diversion into private/public key crypto is, IMHO, a mistake...that's a weird subject that requires an entirely separate discussion. My eyes started glazing right there...too many unexplained topics.

I'm currently working on a seminar for internet safety in the office for true beginners and I have to define a browser, explain URLs, domain names, address bars, home pages, default browsers, hyperlinks, and toolbars. After all that....establishing a common language, then I can talk about what to do and what to watch for. If I leave any technical term undefined...I risk losing the learner at that point.

Yeah, it gets asked every time there is an article discussing https, but is there a reason why Ars doesn't have an SSL/TLS alternative?

There are several reasons, yes. The biggest is that our ads are served from different networks than the rest of the site. TLS'ing the ad servers is out of our control, obviously, and implementing SSL/TLS on the main Ars site would result in mixed content warnings in everyone's browser. It would also be complex (not impossible, just more complex than it's worth) to implement HTTPS with our CDN.

There are workarounds to the ad network issue, but addressing the problem becomes a question of benefit versus cost. Right now, there are more important things we'd rather have our tech team working on that will yield a greater return on their time.

MisterAV wrote:

TimtheTaxMan wrote:

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

It's not the job of the HTTPS-Everywhere plug-in to recognize fraudulent certificates--that's a function of your web browser's HTTPS implementation, though it comes back to SSL/TLS itself.

It also depends on what exactly you mean by "fraudulent." A "fraudulent" certificate that appears to be issued by a trusted CA--like DigiNotar--is unrecognizable as fraudulent unless it is specifically revoked or unless the CA itself is no longer trusted, so that becomes a question of when and how often your browser checks certificate revocation status or updates its trusted roots list. A "fraudulent" certificate that isn't signed by a trusted CA or that is being used for a different domain or host than the one for which it has been issued should be flagged already with a big browser warning.

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.

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.

It's a noble notion but you should keep modest expectations. You're only going to get through to a few and the people being taken advantage of now will still be in the same boat.

"Even if you know what lurks in the dark corners of the Internet, chances are you someone you know doesn't."

(Emphasis added.)

I get what you are trying to convey here, but this sentence doesn't make sense as-written.

Thank you for writing this article series. My difficulty explaining technology to my parents and grandparents dropped by an order of magnitude when I started reading Ars articles more regularly. Keep up the great work!

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

It's not the job of the HTTPS-Everywhere plug-in to recognize fraudulent certificates--that's a function of your web browser's HTTPS implementation, though it comes back to SSL/TLS itself.

It also depends on what exactly you mean by "fraudulent." A "fraudulent" certificate that appears to be issued by a trusted CA--like DigiNotar--is unrecognizable as fraudulent unless it is specifically revoked or unless the CA itself is no longer trusted, so that becomes a question of when and how often your browser checks certificate revocation status or updates its trusted roots list. A "fraudulent" certificate that isn't signed by a trusted CA or that is being used for a different domain or host than the one for which it has been issued should be flagged already with a big browser warning.

By fraudolent I meant something that should not be issued. Like a CA forced to sign something or a strange change in the CA of a website. Only someone like EFF that checks certificates from around the world can do something like that. So if I go to a website and I find a certificate totally different from any other that go to the same website, I'm 99% sure someone is wiretapping me, and storing the certificate I also have the proof!

You should remove the reference to DynDNS. They've killed the free tier which makes them irrelevant for personal use. No-IP is the answer.

Existing free DynDNS accounts continue to work, and the paid product that provides the same services as the old free account is (only) $20/year. A similar service from No-IP is $15/year, and No-IP offers a free service that will do everything most people need.

I don't work for either DynDNS or No-IP, but I'm a happy user of a DynDNS free account.

You should remove the reference to DynDNS. They've killed the free tier which makes them irrelevant for personal use. No-IP is the answer.

Not true, they're still completely free. You now have to sign up for the paid account, and then cancel the service within 30 days to be moved to the free tier - there's no charge for this, and the process is listed on their site. There are many routers that only support DynDNS, and if you've got one then they're still the way to go.

Agreed. Once TLS was mentioned, I decided it wasn't for the folks that I was initially thinking of. That sort of thing is way more involved than any standard user will need to get, at least initially. I was expecting best practices for password management and use, how to tell a bogus website/email from the real thing, how to know what not to click on, how to avoid being phished; that sort of thing. SSL/TLS, VPN and encryption are more advanced topics and should be treated as such.

Great, basic form of security 101. But I personally want to revamp this up to a level where one must be knowledgeable of criminal like security but not in a sense of being one much less executing criminal acts. I also would like to know how to spoof SSL certs so one can... say... bring back classic shut down game servers Since I'm in the middle of reviving such game they decided to shutdown.

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.

I just got sa VPN from a review website ( http://www.starvpnreviews.com ) and I'm using every time I connect to a wifi network. I/m not an IT advocate but I know that SSTP and Open VPN protocols are the most secured and these are what I'm using while connecting to a server. Hope this is enough for my safeness.

I think the bigger challenge would be ensuring your kids' web safety. Having a VPN and all this web security is pointless if your loved one is going to type in all your sensitive information to a stranger, even on the safest networking site. Having a extra tracking device would be great such as this: http://www.youtube.com/watch?v=eGu43QEe1XQ

Of course having your browser to block you off from unknowingly malicious sites is still a great defence.

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.

They should still teach them about credit cards, credit reports, and savings, which I bring up because I'm told some schools STILL don't cover this, but point taken.