[StuCo 98008]
GNU/Linux for Beginners

Session 11

Privacy

By the end of this lecture you will know

The ways by which commercial organizations and spammers collect your personal information

How to defend your private information

Settings/plugins of common GNU/Linux applications that help you strike a balance between usability and privacy

Privacy Violations

Spam email

Spammers trying to sell you Viagra, “more confidence”, dates with Britney Spears, etc.

M$-assisted worms that bombard your mailbox and attempt to infect your computer

Scam email that costs lots of money (Nigerian spam)

Targeted advertising

Implies that your online behavior is tracked

Consumer behavior patterns

“Minority Report”-like “Hi Alex, welcome back!”

Why Do I Get Spam?

You have posted to public mailing lists/newsgroups

Such lists/newsgroups are archived, and spammer bots (scripts) read through them to harvest legitimate email addresses.

You have used online services that required an email

Service providers regularly sell the personal information of their subscribers

You have received email from a friend with a free web mail address

Outgoing email addresses are harvested and sold to spammers

Defenses Against Spam

Proactive

Don't give out your real information unless you must

Use a “junk” account for online registrations

Don't accept HTML email

Use timestamped addresses (apapadop+rh7Jul02@cmu.edu)

Reactive

Use spam filtering software like SpamAssassin

Never click on “click here to unregister” links

The Joys of HTML email

Web browser is typically invoked

All web browser vulnerabilities applicable

Web bugs (remote transparent 1x1 images)

You're in spammer's HTTP server logs

Good email address, keep for future spamming

All your IPs/timestamps are belong to us

JavaScript and friends

No legitimate use

Malicious code execution (worms, trojans)

What Happens When You Get An HTML email?

Client tries to render the HTML

Remote elements are loaded from the network

Busted – you're in spammer's logs

Turning Off HTML email

Mozilla

KMail

Getting Rid of Web Bugs

Mozilla

KMail

Tracking People on the Web

The “referer” field

Where did this visitor come from?

Cookies

Uniquely identifiable consumers

Banner ads

Profiling

The Good Cookies

Small text files stored on your local machine

They usually keep useful information for a specific site – e.g. lang=el for a multi-language site

Necessary for web authentication, since HTTP is stateless

Theoretically not accessed by anyone else but the site that put them there.

Misuse of Cookies

Consumer profiling networks like DoubleClick

Cookies combined with banner ads

Why do banners always point to so long URLs?

Accessing cookies of other domains

Everyone gives you a cookies nowadays. Do you need them?

Cookies are only necessary for authentication

Defenses Against Cookie Misuse

User decides to accept/reject cookies per domain

Actually works after a while

Always use the “remember my choice” feature

Expire all cookies when I exit my browser

Hassle-free web browsing

Keeps all sites happy

Acceptable, as long as you quit your browser often

Privoxy – Anonymizing HTTP Proxy

All HTTP requests + replies go through Privoxy

It strips all cookies / banner ads / popups

Breaks some sites

Email Encryption

How?

Public Key Infrastructure

OpenPGP standard (RFC2440)

Why?

Confidentiality (third parties cannot read your email)

Integrity (message is not altered while in transit)

Authentication (I know who sent the message)

Public Key Crypto

Alice has a private and a public key. So does Bob.

They both post their public keys on a key server.

Alice gets Bob's public key from the server.

Alice uses Bob's public key to encrypt a message to him.

Alice signs the message with her private key.

Bob gets the message. He uses his private key to decrypt the message, and reads it. No one else could have read it.

Bob uses Alice's public key to verify her signature. No one else could have signed it, so the message is from Alice.

An Encrypted Message

PKI Pitfalls

Getting a corrupt public key

Always check the fingerprint, e.g.
3DAD 8435 DB52 F17B 640F D78C 8260 0CC1 0B75 8265

By phone call, or face-to-face verification

Not keeping your private key secure

Secure your machine

Use a strong passphrase (not just a password)

Key mismanagement

Always issue revocation certificate

Set expiry date before the next Ice Age

Creating Your Own Keys - GnuPG

$ gpg --gen-key

$ gpg --list-keys

$ gpg -o revcert.asc --gen-revoke <myID>

$ gpg --send-keys --keyserver pgp.mit.edu

Go to http://pgp.mit.edu to verify your key

$ gpg --fingerprint <myID>

$ gpg --import revcert.asc

$ gpg --send-keys --keyserver pgp.mit.edu

Go to http://pgp.mit.edu to check proper revocation

Crypto – Email Client Integration

KMail: Native GnuPG support

Mozilla: EnigMail plugin

Other mail clients that support OpenPGP

Mutt

Pine

Sylpheed

Mozilla ThunderBird

Encrypting Local Files With GnuPG

$ gpg --encrypt --recipient <myID> <filename>

Encrypts and compresses the file

Creates <filename>.gpg

$ gpg --decrypt --output <filename> <filename>.gpg

Decrypts the contents of <filename>.gpg into the file <filename>

Nigerian scam spam: What a classic! A Dr. Somethingorother contacts YOU for a unique deal: He needs to take money out of the country, but they won't let him do it with his account, so you are to provide your account details. You'll get 5% of the 57 gazillion dollars he wants to transfer.

Well, guess what. It's a scam. And this is what happens to people stupid enough to believe it:

http://www.theregister.co.uk/content/archive/27243.html

It's quite impossible to protect your email address against harvesting from online sites.

Just focus on staying off the really nasty databases that spam you mercylessly.

A good idea is creating a free web based email account with no real personal information.

Then you can give out that email address when some site really pushes you for personal information. You retrieve the information/links that they send you on that email address, and then never use it again – or use it only for similar purposes, so that your real personal email account is not polluted with junk.

There is a nice tutorial on how to use KMail with antispam software, at http://kmail.kde.org/tools.html#antispam

By using an address of the form realID+string@realdomain.tld, you can create unique email addresses. Mail servers discard anything that is after a “+” sign, therefore you can enter the domain and date information there.

So, if I register with RedHat, and it's 15th of November 2003, and my real email address is apapad@cmu.edu, I will give them the address apapad+redhat15nov03@cmu.edu, which is simply an alias to my real email address. I will still get the emails from Red Hat, but if they sell my information to a spammer, and I get a “Meet Britney Spears” message on that particular address, I'll know that it was them who sold me out.

Although the attacker grabs the email by sniffing the network or compromising a mail server that handles this message, he/she cannot read the text of the email, since he/she does not possess the private key of the recipient.

This message has been encrypted “for Devin's eyes only”, and only someone holding his private key and his passphrase cam decrypt it.

If someone manages to grab your private key (e.g. By getting access to your hard drive), they still have to guess / brute force the passphrase. So it better be good!

Key litter is very common, because people don't know what they're doing when they start using PKI. Always create a revocation certificate, otherwise you are bound to find yourself in the unpleasant situation of being unable to de-activate a key you no longer wish to use!

1. Generate a new key

2. List your keyrings, to see the new key

3. Generate a revocation certificate, that will allow you to disable the key, in case something goes wrong.

4. Publish your public key on a key server

5. Verify that publication was successful

6. This is the fingerprint of the key – it can be used to verify that a remote recipient got your public key intact: just ask him/her to tell you the fingerprint!

7. We're done with this test run, we're revoking our keys.

8. Publish the revoked key, so that noone uses the old one.

9. Verify that key has been revoked.

Enigmail can be found at http://enigmail.mozdev.org/

The KMail product pages at http://kmail.kde.org have information about encryption with KMail.

Session 11 - Privacy

[StuCo 98008] Introduction to GNU/Linux

gnu linux privacy cookies web bugs encryption email tracking transparent GIF spam RFC822 privoxy proxy HTML email banner ads session

In this session we extend the discussion of the loose information that exists on any network (the Internet is a prime example), and look into ways of protecting our privacy. Topics discussed:
+ Cookies
+ Web Bugs
+ Spam
+ Online Forms
+ Personal Information in Applications (OpenOffice, UNIX user info etc)
+ Email encryption
+ Sensitive Information Encryption

2003-11-01T22:12:42