It’s actually surprising to me that so many people are shocked by what this demonstrates. Even those who claim to be technically literate seem taken back. Insecure sites by definition are insecure. Anyone can read what’s going across the wire (that includes WiFi) when it is sent unencrypted. If your browser can interpret and use the information to let you browse Facebook, Twitter, etc. so can any browser, on any computer. It’s that simple. Firesheep only supports a handful of sites, but adding support for more sites isn’t difficult. If your favorite website hasn’t been done yet, I expect it will be soon enough.

How Do You Protect Yourself?

The best way to protect yourself is to demand that websites that hold private information use HTTPS from the moment you log in until you log out. Short of that, the best you can do is use a Firefox extension like EFF’s HTTPS Everywhere to force your browser to use HTTPS. This won’t work everywhere as not every web server even has HTTPS working, but many secretly do. They sometimes use HTTPS for certain things like login, then use insecure HTTP for the rest of your visit. That’s so your password isn’t transmitted in plain text. Protecting a password is important, but if the session is insecure anyone can intercept what you do. HTTPS Everywhere works by rewriting all requests to many popular sites to use HTTPS ensuring your privacy and security through the length of your visit. Some websites will have minor issues. For example Facebook Chat is impossible to support right now due to it not working via HTTPS. The rest of Facebook however works.

For more advanced users, HTTPS Everywhere lets you write your own rulesets for sites it doesn’t support.

How Do Websites Protect Their Users?

It’s very simple. Use HTTPS for the period a user is logged in, not just when authenticating and submitting sensitive data. Sure it’s a little slower and requires more hardware, but scaling HTTPS these days isn’t nearly as difficult as it was just 5 years ago. In 2 years it will be even easier. Google went as far as forcing HTTPS upon all of Gmail users. Binding a session to an IP address is fussy and largely ineffective due to NAT, WiFi hotspots and mobile services that can cause an IP to just change with little/no notice. It’s not effective security. It’s better than nothing, but it’s not a fix.

Google could make a huge difference by supporting SSL in Google AdSense, something I’ve called for since 2008. Google has supported SSL with Google Analytics for some time, but they have lagged with rolling out support in other services. Lots of websites monetize with AdSense and this is just another reason websites put off supporting SSL. Other ad networks should do the same. Google AdSense has the least barrier to entry since they serve their text ads off of their own infrastructure, vs. creatives hosted by other parties like some smaller ad networks. One could argue having third-party code inserted on a page mitigates security but it would still be a major improvement over the current state of affairs and would prevent simple session jacking.

However Gmail using HTTPS is not the big story here.

The big story is that HTTPS is now being used in places where it before was considered excessive. Once upon only financial information was generally sent over HTTPS. As time went on, so did most website login pages, though the rest of the sites often were unencrypted. The reason for being so selective is that it’s more costly to scale HTTPS due to it’s CPU usage on the server-side, and it’s performance on the client side. These days CPU is becoming very cheap.

In the next few years I think we’ll see more and more of the web switch to using HTTPS. If things like network neutrality don’t work this trend could accelerate at an even quicker rate just like it did for P2P using MSE/PE to mask traffic.

Like I said, these days the CPU impact is pretty affordable, however the performance impact due to HTTP handshaking can be pretty substantial. Minimizing HTTP requests obviously helps. HTTP Keepalive is a good solution however that generally results in more child processes on the server as they aren’t freed as quickly (read: more memory needed).

Mobile is a whole different ballgame since CPU is still more limited. I’m not aware of any mobile devices that have hardware to specifically handle SSL, which does exist for servers. Add in the extra latency and mobile really suffers. Perhaps it’s time to re-examine how various Crypto libraries are optimized for running on ARM hardware? I think the day will come where performance over SSL will matter as it becomes more ubiquitous.

Since July 2007 Google AdSense has had the ability to crawl login protected pages so that it can scan (and therefore provide relevant ads) to pages behind logins. This is great since many pages on sites, in particular social networks where the the majority of page views are post-login can now be monetized.

Despite this progress, Google still doesn’t provide an SSL version of AdSense, so while the page itself can be served over SSL, the ad isn’t. This is problematic since the browser will alert the user that the page is not entirely secure. I really don’t understand why this can’t be done. Google does appear to scan these pages as the ads are relevant, so I don’t think the crawler is the issue. They just don’t want to serve ads over SSL.

Come on Google, the web would be a much more secure place if AdSense supported SSL. It would remove a big reason for sites to not use SSL in places that they should.

For those who would argue that putting third party ads on an SSL page defeats the purpose, that’s only partially true. Yes in an ideal world there’s no third party content on an SSL page. In the real world, Google already supports using SSL with Google Analytics (as do virtually all other analytics services), and you can bet almost any SSL page you access has some analytics on it already. This is no worse. If anything it’s better since unlike Analytics, the nature of the service involves much less recording of user behavior.

By not supporting SSL it’s just encouraging sites to not use it in places where a users privacy and security would be better off with it.

1. Use SSL When Available – Many sites offer SSL interfaces to make them more secure. Sometimes it’s used by default, sometimes it’s not. You can often test yourself by just changing the http:// in the url to https:. For example, you can do this for virtually all Google services including, Google Docs, Gmail, Google Calendar, etc. For Gmail there’s even an option to force SSL. If you still haven’t enabled this, do so now. Many non-Google products offer this too, for example Meebo.
2. Be Cautious Of Open Networks – Just because you see a WiFi hotspot doesn’t mean it’s safe. It’s trivial for someone to sit in a coffee shop with a laptop and pretend to be free internet access. Once someone connects they can essentially snoop on all that persons traffic. Connect only to networks you know and only use services over a VPN or HTTPS so that your traffic isn’t in plain text. To be extra cautious limit the amount of high risk activities you do on these networks (do your banking from home).
3. Don’t Connect To The Internet Directly – Even if you have only one computer, it’s still advisable to have an access point between you and your internet connection. Virtually all access points today provide decent firewall protection that will shield you from any of the horrors that exist on the internet. Any NAT device will provide a degree of protection (though NAT isn’t a firewall replacement). Access points can often be found for under $50 making this a very sound investment. Yes there are software firewalls, but they have downsides. The minimum is a hardware device between your computer and your broadband modem
4. Use Encryption For Your Home WiFi – If you have a home wireless network, make sure you have encryption enabled and use it. Ideally you should be using WPA2/AES since it’s the most secure at this point, though anything is better than nothing. While sites you browse over HTTPS are encrypted, you still want the entire tunnel encrypted. This does hurt performance slightly but most modern hardware (even the cheap stuff) is more than capable of handling this. Odds are you run an 802.11g network and your wireless is way faster than your broadband anyway. If you don’t have this enabled or don’t know how, check the manual, the manufacturer’s website or call tech support for help. You should be doing this.
5. Don’t Trust IM or Email For Confidential Information – IM and Email aren’t very secure mechanisms for sending information. They should never be trusted for things like sending credit cards, social security numbers, medical information, etc. If you ever see a merchant using IM to process a credit card (so they only need 1 terminal rather than one per location), pay cash or walk away. Sadly it happens. It’s perfectly fine for chatting with your friends, but not good for secure information. It’s possible to encrypt email with PGP or GPG, and IM’s with OTR or an encryption certificate but they require both parties to utilize them and are somewhat technical in nature and therefore few actually use them.
6. Only Download From Trusted Sources – Download only from trusted places. Download software only from the developer’s website, not just any place that has it. Look for software at places like Tucows, FileForum, download.com (operated by my employer) and other well trusted download locations. There’s a lot of hoax sites out there trying to distribute malware (malicious software). Also be suspicious of anyone offering commercial software for free.
7. Keep your AntiVirus Up To Date – Just installing AntiVirus software isn’t enough. The program is useless unless you keep the virus definitions (the files which tell the software what is a virus and what isn’t) up to date. All modern AntiVirus software does this automatically for the duration of the subscription. When your subscription expires either upgrade to a new version or renew the subscription. There are enough free AntiVirus solutions out there for Windows to make it inexcusable to not have protection. For paid AntiVirus, Norton AntiVirus 2009 is pretty good (I use it and reviewed it myself). So is Kaspersky. Avast and AVG would be my personal recommendations for free.
8. Use AntiSpyware – AntiVirus products go a long way, but you’re much better off if you use an AntiSpyware product as well. Many of them are free downloads, just make sure you get them from reputable places. I’d recommend Spybot S&D, AdAware and Windows Defender. Make sure to run the updater within the product at least once a week, and scan on occasion (weekly, biweekly, whatever). Mac users don’t really need to do anything here as Spyware isn’t much of an issue thus far.
9. Be Aware Of Phishing – Never open links in email unless you’re sure of its origin. If your bank wants you to login and do something, visit the banks website by going to the site yourself rather than clicking on a suspicious link. No business will ask you to verify your password. Microsoft has some more tips.
10. Use A Secure Browser – Firefox 3, IE 7+, Safari 3.2 all offer Phishing protection. This isn’t perfect (nothing really is), but it can greatly reduce your chances of being a victim of a phishing attack. Enough browsers support protection that you shouldn’t be browsing without it. Firefox 3 also includes malware protection. I have a Firefox bias though that doesn’t mean you can ignore this. Use a modern browser with phishing protection.
11. Secure Your Computer – If you have a laptop you should have a password when logging in. If you don’t, correct this. It’s easy to do on Windows or Mac OS X. This will at least stop dumb thieves, which are fairly numerous. Even if your laptop never leaves your home this is still a good idea. It’s not impossible for the cable guy, phone guy, refrigerator repair man, etc. to try and steal something like a laptop. This is such a small step that can save you some trouble later on.
12. Secure Your Cell Phone – It’s not going overboard to secure your cell phone. If you’re like a growing number of people, your cell phone is a much more complicated device than it was just a few years ago. It can contain a lot of data including phone numbers, your calendar, photos, browsing history, email, even financial data. Just this week someone sued because they lost their cell phone, which happened to contain nude pictures that they claim were leaked online. Most phones include the ability to add some form of a password or passcode. The iPhone even has an option to wipe data after a certain number of unsuccessful attempts. Securing this compact hard drive isn’t a bad idea.
13. Don’t Put Things Online You May Regret – People who do this admittedly deserve what they get. Posting information regarding your personal lows may work out to your advantage in the future. Already 1 in 10 college admissions officers check social networking profiles according to Kaplan. When I graduated college in 2006 I could tell who actually looked at my job application by looking at the log files for this blog. All but one or two potential employers went to Google to screen me. In more than one case I actually used tail -f and watched them (live!) browsing this blog from their corporate network while they screened me over the phone. Only one actually brought it up in an interview (and he said he was impressed by depth of my technical posts). That was way back in 2006. Employers and colleges are much more savvy now. I get emails from headhunters constantly because of this blog. Because of this I know it’s not scaremongering. People out there really do use the Internet to screen strangers. This is standard practice, especially if you’re under 30 (and more likely to have some digital trace online) or if you apply for a tech/internet job.
14. Backup – Backing up is important. Get an external hard drive and backup all data you care about on a routine basis. I’d suggest at least once a week. I’d also suggest having some sort of off-site backup for things you wouldn’t want to loose in the event of a fire or natural disaster (email, financial records, etc.). You could use online services like Amazon’s S3, though make sure to use encryption, or the offline method of saving them to a disk and putting that disk either at a parents home, safe deposit box, etc. Just make sure that disk is either encrypted or in a secure location where it won’t fall into the wrong hands. A fireproof safe is another way to go though you’ll want to make sure you use a UL Class 125 safe rated for at least 1hr. They can withstand fire and keep the internal climate at no more than 125°F and 80% humidity, suitable for magnetic media. If it’s not UL tested make sure it’s suitable for the media you are trying to store for at least 1hr, preferably more.

I must admit I didn’t know that the database is funded by the National Cyber Security Division of the United States Department of Homeland Security. I did know US-CERT was.

1. Invalid certificates, while providing a secure mechanism between the client/server are extremely annoying to use in Firefox 3 for many people because of the multi-step process. Previously it was just a warning dialog.
2. There are no free SSL certificates that are really “usable” (not throwing up warnings in a many browsers). CAcert.org has likely gotten the most inclusion, but it’s barely anywhere.

Certificates not signed by a trusted certificate authority (CA) give up a warning because of the idea that a certificate authority verifies the certificate belongs to the person whose name is on the certificate. This concept was busted a while back as CA’s started doing “domain validation” to offer lower prices. To “remedy” this, they created EV SSL. EV SSL requires more background checking, but at a higher cost. This means there are three tiers of SSL:

1. Untrusted/Self Signed – Free – The user is strongly discouraged from visiting a site with one of these. Indicates the technologically the channel is secure only.
2. Signed By CA – Variable Pricing – The user is told this is secure.
3. EV SSL – Expensive – The user is told these sites are super awesomely amazing and can cure cancer.

Essentially EV SSL is nothing more than a scheme to charge more. EV SSL is supposed to do what a signed certificate should have been doing all along. By 2012 I’d bet there will be a SEV SSL(Super Extended Validation Certificate). Maybe that would require a DNA and fingerprints to prove identity.

The Problem

It’s 2008 (actually more than half way through it). I still can’t use a secure https connection without either throwing up an error to users (who are always confused by it), or paying a fee? It seems right to me it should be free to use https without any barrier for a technical level of security.

Why is “trust” bound so tightly to encryption? Why can’t a medium be encrypted without being trusted? The technology shouldn’t be tied the way it is to the business side of things.

Trust should be bound to encryption, but encryption should not be bound to trust. Trust is the “needy” individual in this relationship. Encryption is strong and confident. At least it should be…

A modest proposal

I propose that browsers should allow for self signed certificates to be used without any dialog, interstitial or other obstruction provided they are properly formed and not expired. The user interface should indicate that the channel is encrypted and communication is unlikely to be intercepted between the user and the server. It should note if there is any change (just like SSH notifies the user if the signature is changed between sessions). Other than that it should be transparent.

SSL certificates and EV SSL certificates should indicate in the user interface the the site being browsed is not only encrypted, but trusted by a third party the browser trusts. These are suitable for ecommerce, banking etc.

This would allow for things like intranets and other places where encryption is desired, paying for a CA to verify identity is overkill, and “domain verification” is just pointless.

Trust should be bound to encryption. Encryption shouldn’t be bound to trust. Encryption shouldn’t require verification. Encryption should be self-serve.

I’d be curious to know what others thought of the issue.

For some reason Firefox 3 can’t access Webmin on port 10000, which is how it’s setup on a box I have. It worked in Firefox 2.0, but not 3.0. I’m not sure if it’s something to do with Perl’s Net::SSLeay, which Webmin uses for SSL support, or the port number being 10000. I’ve tinkered a little bit with SSL settings, but so far haven’t been able to figure out exactly what’s going on. It seems to be a regression in NSS.

Anyone notice a regression like this using nightly builds somewhere else? This is the only case I’ve personally experienced it. If you have, then visit bug 423499 and let us know.

Edit [5/4/08 @ 11:30 PM EST]: No idea what’s going on here, but apparently nobody else can reproduce, so calling it quits for now.

In other news, there is now a SafePasswd.com blog. The focus is quite simple. Bring better security to the masses.

Check it out, add the feed to your favorite rss reader, bookmark it.

Please note these directions, and intended to be a casual guide for experienced individuals. I’m not providing assistance or support.

1. Download stunnel and install it.
2. Open up the stunnel.conf file (either through the Start Menu —> Stunnel —> Edit stunnel.conf, or navigate to the file yourself.
3. For each mail server you use, create an entry as follows. Replace mail.myisp.com with your mail server. Also make sure you set the appropriate port (995 is typically fine). Make sure the accept port is different for each one.

   client=yes
   accept=127.0.0.1:110
   connect=mail.myisp.com:995
   

4. Start Menu —> Stunnel —> Service install
5. Start Menu —> Stunnel —> Service start
6. Now configure your email client to use the following information:

   Server: localhost
   Port: 110 (or whatever port that account was set to use up above)
   

   SSL should be off (the SSL connection is now terminated at stunnel, which uses the local loopback interface to send mail to your mail client on port 110. So mail is sent over the web in SSL, but locally in plain text (where an AV can sniff it).

7. Test it out.

Important Last step

Up to now it should be working, but it’s using a generic key. This means everyone who downloads stunnel has the key. You need your own. There are good directions for that from available here. You can create one with a copy of OpenSSL (it’s up to you to get it for Windows, or hop on a Unix box for this step). I should note that the stunnel.cnf file is missing in the Windows binaries as of Stunnel 4.20 (don’t ask me why). If your going to gen a key on windows use the following in a text file named stunnel.cnf:

# create RSA certs - Server

RANDFILE = stunnel.rnd

[ req ]
default_bits = 1024
encrypt_key = yes
distinguished_name = req_dn
x509_extensions = cert_type

[ req_dn ]
countryName = Country Name (2 letter code)
countryName_default             = PL
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = State or Province Name (full name)
stateOrProvinceName_default     = Some-State

localityName                    = Locality Name (eg, city)

0.organizationName              = Organization Name (eg, company)
0.organizationName_default      = Stunnel Developers Ltd

organizationalUnitName          = Organizational Unit Name (eg, section)
#organizationalUnitName_default =

0.commonName                    = Common Name (FQDN of your server)
0.commonName_default            = localhost

# To create a certificate for more than one name uncomment:
# 1.commonName                  = DNS alias of your server
# 2.commonName                  = DNS alias of your server
# ...
# See http://home.netscape.com/eng/security/ssl_2.0_certificate.html
# to see how Netscape understands commonName.

[ cert_type ]
nsCertType = server

This is from the source code of version 4.20.

From there you can effectively use the following commands (from the above linkage):

openssl req -new -x509 -days 365 -nodes -config stunnel.cnf -out stunnel.pem -keyout stunnel.pem

Change 365 to something higher if you don’t want to do this on a yearly basis. Though may not be a bad idea to do annually. Answer the prompts as required. Make sure the Common Name is set to “localhost”.

Followed by:

openssl gendh 512 >> stunnel.pem

Make sure your cert.pem is in your stunnel directory, stop the service and start it again. From now on you should be good to go.

So that’s it. Now you have SSL encrypted mail connections, with support for AntiVirus scanning. This will work for any mail host that uses POP3 over SSL including Gmail.