Firesheep and BlackSheep on Firefox 4.0+

Firesheep

You may have noticed that the downloadable binary of the Firesheep add-on works only with version 3.6 of Firefox. The main branch is still incompatible with Firefox 6, but the latest Firesheep branch, (firefox5) remains very active and contributors are working toward making Firesheep compatible with newer versions of Firefox. I was able to compile this branch on Linux, but not on on Windows 7. Unfortunately, there were actually several changes in Firefox 4 that are incompatible with the original architecture and implementation of Firesheep.

New Add-on Manager

Firesheep calls the executable component firesheep-backend.exe (or firesheep-backend depending on the platform) which is packed with the add-on. To find the path of the executable, Firesheep needs to get information about the add-on through the add-on manager.

Firefox 4 introduced a new way to interact with the add-on manager and deprecated the previous one. The change is deeper than just calling a different function. Getting the path of the add-on now requires an asynchronous call instead of a synchronous function call. This can be a big change for most plugin architectures. Fortunately, Firesheep is very well structured and uses an event-driven architecture. This means that it can easily deal with asynchronous calls.

The Firesheep branch firefox4 fixes this issue (mostly in modules/Firesheep.js) in a way that is backward compatible with Firefox 3.6.

C++ XPCOM

While running firesheep-backend.exe, Firesheep needs to capture the output of the program. Natively, Firefox allows add-ons to run executables, but not to capture the output. Firesheep worked around this limitation by creating a custom XPCOM element in C++ that allows it to run executables and capture their output. In brief, XPCOM elements are cross-platform components that can be written in C++ and other languages. These components can interact with the platform (Windows, Linux, Mac OS X) and can be called through JavaScript inside the add-on.

There are several radical changes in Firefox 4.0 regarding XPCOM. First of all, you can see in the Firesheep compilation instructions, that the add-on must be compiled against Gecko 1.9.2. But Firefox 4 uses Gecko 2. This is a major version change which is not compatible with Gecko 1.9.2.

Among the changes required with Gecko 2 regarding custom XPCOM elements, the following are a problem for Firesheep:

• XPCOM elements must expose a new interface, so older XPCOM elements for Gecko 1.9.2 no longer work
• XPCOM elements must be recompiled for every new major release of Firefox. This is a maintenance headache with the new Firefox release scheme, where major versions are released every few months

This led Firesheep to change its back-end considerably. You can see these changes in the firefox5 branch. Firesheep dropped the custom XPCOM. It now uses the native Firefox objects to run the executable. The back-end writes its output directly to a temporary file and Firesheep tails the output.

As a result, the implementation of Firesheep is a bit more complex, but getting it to run on different platforms is easier. The new version of Firefox is compatible with OS X 64bit, which was not previously the case. It should also make it easier for Firesheep to work with newer versions of Firefox, because there is no longer a dependency on a custom XPCOM.

No binary release yet

Unfortunately, there is no binary release (the final XPI add-on) of the firefox5 branch available for users to download and install on Firefox. While I was able to compile it on Linux (32bit and 64bit) easily, I could not compile it on Windows (missing pcap-config, could not find my BOOST libraries, etc.). I've spent several days trying to compile the different branches on Windows without any success.

BlackSheep

Because BlackSheep is largely based on the Firesheep source code, it suffers the exact same problem. I did not test BlackSheep thoroughly enough after Firefox 4 was released, so I did not realize BlackSheep no longer worked. I apologize to the users of BlackSheep.

I want to make BlackSheep available for Firefox 4 to 6. This should be possible by using the firefox5 branch of Firesheep, but I need to successfully compile this branch on Windows 7 first, which I have not been able to do despite my best efforts. I would be very grateful if a reader has a working Firesheep firefox5 version for Windows and could send it to me. I'll then be able to update BlackSheep and release it to the public.

-- Julien

The Web has still not switched to SSL-only

In November 2010, the release of Firesheep highlighted the dangerous consequences of not using secure HTTPS transactions. Following this, I provided some of the reasons why the web has not switched to SSL-only yet. There have been some improvements since, notably Google+, which works only over HTTPS, and from Twitter.

But those are very small steps. A lot more needs to be done.

SSL by default

One trend involves offering HTTPS as a new option. Facebook and Twitter took this path. Unfortunately, the option is usually disabled by default. Half of the users do not understand what this option does and the other half is not aware of the new feature well hidden in their profile!

HTTPS option under Security settings in Facebook

HTTPS should be enabled by default, perhaps with the option of disabling it for the very few users having problems with it.

Facebook

While Facebook has fixed the 2 bugs I mentioned in the earlier post - SSL: the sites which don't want to protect their users, it is practically impossible to use HTTPS on Facebook. The problem arises from the fact that the use of SSL breaks most of the applications I've tried on the platform. I used to get error messages, now users are warned that they need to switch to HTTP. They have to logout, and login again, to get HTTPS back.

Most Facebook Apps cannot be used with HTTPS

HTTPS cannot be used for popular applications like CityVille from Zynga. I doubt many users will take the hassle to logout/login constantly to switch back to SSL.


Insecure cookies

I've seen HTTPS implemented incorrectly on many sites, including Facebook. The main purpose of HTTPS is to hide the user cookies, so that tools like Firesheep cannot be used to hijack a user session. That means the HTTPS cookie should never be sent over HTTP. There are two ways to achieve this:

1. Use the secure keyword when sending a cookie with Set-Cookie. This mean the cookie can be sent by the client only over HTTPS
2. Use a different sub-domain that support HTTPS only (like encrypted.google.com) and restrict the cookie to this sub-domain

Otherwise, when the user connects to the website over HTTP the user session is vulnerable. Unfortunately, Facebook uses the exact same cookie over HTTP and HTTPS, without securing it. If you type "facebook.com" in your address bar, you will send your cookie in clear text, even if you are then redirected to https://www.facebook.com/ and simply visiting a site that uses a Facebook widget, a Like button for example, leaks your user session in plain-text, even if you check the "Secure (HTTPS)" option in your profile. Nowadays, it is a challenge to not visit a website that does not contain any element from Facebook...

My Facebook cookie leaked on a random web site (Like widget)

In the end, it does not really matter whether you use HTTPS or not for Facebook. Your Facebook cookie will be leaked when visiting other websites anyway.

Google

Google did the right thing with Google+. The website works with HTTPS only and there is no way to use HTTP. User cookies cannot be sent in clear text.

You can also use their search engine over HTTPS, unlike Bing, which does not offer a secure alternative.

But Google still has some work to do on the rest of their current web applications. For example, the Google Personal Home Page cannot be accessed over HTTPS (users get redirected to HTTP) and Adsense, the major adverting network, does not support HTTPS, which leads to a Mixed HTTP/HTTPS warning for sites would would like to use SSL.

Mobile

The situation is even worse in the mobile space. Most of the applications used on smartphones and tablets need to contact a web server to function: to retrieve advertising (Admob/Adsense Mobile), to get data from a web service, etc. But there is no way for the user to know whether sensitive information is sent over HTTP or HTTPS. There is no UI element equivalent to the lock shown in browsers and no visibility into the URLs. Researchers have illustrated that mobile developers cannot be trusted to secure communications, as all too often, they send user credentials in plain text.

While some websites have taken a few steps to protect the users, there is still a great deal to do. HTTPS should be enabled by default on all new web sites requiring user authentication. HTTPS should not just be required for login, it should also be required for all requests sent with a cookie.

-- Julien

SSL: the sites which don't want to protect their users

Last week I explained some of the challenges that websites face to switch to SSL to protect their users. The main challenge is to send the correct SSL certificate in all cases.

Some websites make it very hard, or even impossible, to use secure connections to protect their sessions. It has been exactly a month since Firesheep was released to demonstrate the problem of session side-jacking, but these websites are still not willing to do anything about this problem.

Here are some of these sites, all part of the list of domains monitored by Firesheep.

Amazon: no HTTPS for you!

It is just not possible to use https://www.amazon.com/! This address redirect users to http://www.amazon.com/.

Permanent redirection from HTTPS to HTTP

To their credit, users must login again over HTTPS to make an order, but Amazon still provides plenty of information about their users: first name, last name, what they're interested in, full access to their shopping cart, etc.


Basecamphq.com: 37signals.com certificate

If you go to https://www.basecamphq.com/, you get a certificate for 37signals.com.  This isnt very helpful for users not aware that BaseCamp is a product from the company 37Signals.

SSL certificate valid for a very different domain name

Facebook: hidden HTTP connection, HTTPS login fails

I logged into my Facebook account using https://www.facebook.com/. Out of the 10+ requests required to display my home page, one of them is done to http://www.facebook.com/ap.php. This request does carry all the cookie values needed to hijack my account. There is currently no way to surf Facebook safely.

Unsecure HTTP connection

There is a worse scenario. I logged out of my account, and went to the secure login page https://www.facebook.com/. I entered the wrong password by accident. I was then redirected to the secure page https://login.facebook.com/login.php. There, I entered my password correctly. But I was redirected to the unsecured http://www.facebook.com/home.php (no HTTPS)!

Redirection from secure login page to unsecured home page

Although Firesheep has made a lot of noise, and the issue of session side-jacking has now been widely reported on, even the major sites have not taken the necessary actions to protect their users. It is very sad to see sites such as Facebook, widely used and by a large and diverse audience, are still very insecure.

This was just a quick review of a few sites, I'm sure plenty of other sites have the same weaknesses.

Happy Thanksgiving!

-- Julien

Which networks are more susceptible to Firesheep (aka session sniffing)?

Firesheep highlighted once more, the problem of session sniffing. Users on open wireless networks are especially at risk when they login to websites without SSL encryption. But not all wireless networks are the same when it comes to sniffing traffic...and wired LAN networks are not 100% safe either.

Firesheep found user sessions

Wireless networks

Firesheep was released to demonstrate the inherent weakness that session hijacking can present on wireless networks. They are several types of wireless networks, some are safe, but most are susceptible to session theft.

Open networks

Open wireless networks are becoming more and more popular. They can be found in public libraries, coffee shops, book stores, etc. Anybody can connect to these networks and no password is required. An attacker simply needs to be physically close enough to the wireless signal to steal unencrypted sessions.

WEP

WEP networks are protected by a password. These networks are often used in hotels to restrict Internet access to paying customers, but the password is the same for everybody. If the attacker knows the password, the network is as unsafe as an open wireless network.

It's generally very easy for an attacker to get the password without being a real customer (just ask another user for the password and you will likely get it). However, knowledge of the password is not necessarily required, as WEP encryption has been broken. There are tools freely available to crack the password.

WPA-PSK/WPA2-PSK

Unlike WEP, WPA negotiates a different key with each client to encrypt the traffic, but like WEP, WPA/WPA2 PreShared Key (PSK) encryption has been cracked as well. Somebody with enough security knowledge can determine the shared key, and sniff the HTTP sessions.

WPA-Enterprise/WPA2-Enterprise

These extensions built on the WPA/WPA2 protocols have not been cracked. Unfortunately, those are not often found or personal wireless equipments.

Wired networks

Wired networks are not necessarily safe. As with a wireless network, the type of technology used has an impact on the likelihood that traffic can be intercepted.

Hubs

If hubs rather than switch are used to connect computers, session sniffing is easy. Hubs send network traffic received on one interface to all other interfaces. This means that anybody connected to the same hub receives everyone else's traffic. Hubs are not used in many enterprises because of the security issues they represent, as well as their performance issues. However, they are cheaper that switches, and thus, can still be found in home or SMB networks.

Hub: traffic is replicated to all ports

Switch

Switches are more efficient than hubs: the network traffic is forwarded to one interface only. In theory, session sniffing is not possible on these devices. However, it is quite trivial flood a switch in order to make it behave like a hub. This flooding would probably be noticed in a company with a good IT department monitoring the internal network, but not necessarily in smaller companies.

Switch: traffic is forwarded to one interface

Monitor port

Most enterprise-grade network equipment (switches, routers, firewalls) has a monitor or mirror port: all traffic seen by the switch is mirrored to this interface. Anybody with physical access to this port can sniff traffic from the entire network. Unlike the case of flooding a switch to make it behave as a hub, this would not create any unusual network activity, and could not be detected.

Don't trust your network! Wired LANs are safer than wireless networks in general because they require physical access, but they are not 100% safe. To be sure that you're the only one accessing your accounts on the web, make sure you use SSL: use HTTPS only, or use an SSL VPN.

-- Julien

Why the web has not switched to SSL-only yet?

With the session-sidejacking issue highlighted once more by Firesheep, a many people have asked me why more websites, or at least the major players (Google, Facebook, Amazon, etc.) have not enabled SSL by default for all communication. Indeed, encryption is the only way to ensure that user sessions cannot be easily sniffed on a open wireless network.

This sounds easy - just add an s after http in the URL! It's not actually that easy. Here are some of the challenges.

Server overhead

The obvious issue is that encrypting all HTTP sessions requires additional resources on the sever-side. I've seen numbers showing 10% to 20% CPU overhead for SSL. Having to add 10% more servers is a big deal when you're dealing with thousands of them like Facebook and Google. However, the overhead can actually be much higher on specialized severs, which efficiently serve static content (such as images) directly from memory (think memcached). In this case, the processing power required is easily multiplied by a factor of 10. Of course the SSL encryption can be offloaded to a proxy or other external hardware, but you have to add the cost of managing a more complex topology as well as buying the new hardware.

Increased latency

SSL also has a perceived performance issue for the client (i.e. the browser). For  each new session,  SSL encryption must be set up between the client and server. This means a few more packets must be sent back and force before the actual HTTP data is received. This happens for each page load, and also for each domain.

1 HTTPS transaction: 4 SSL handshake packets, 6 data apckets

A typical  Facebook page (like the News Feed) contains HTML elements (images, CSS, JavaScript) from more than 10 domains.  This means the full SSL handshake is done over 10 times on each page. This in turn makes pages load more slowly. The problem is amplified if the user's connection has high latency, as it would on a cell phone.

4 of the 10+ domains used on a Facebook page

Challenge for CDNs

All the major websites use a Content Delivery Network (CDN) to deliver static content quickly to their users. Some have their own (Facebook, Google), but others use third parties such as Akamai.

The same website can be served from hundreds of CDN servers based on their geographical location, and each CDN server can handle several hundred websites. Most website owners don't want users to see content being downloaded from akamai.com, so they use an alias. For example, static.amd.com could point to a248.e.akamai.net.

Each CDN therefore serves different content based on the Host header received (static.amd.com for example). This creates a problem. The SSL handshake is done first,  then the HTTP data is sent. That means the SSL server must send an SSL certificate to each client without first seeing the host. In brief, the SSL server sends a certificate based on the destination IP address, not based on the HTTP hostname.

The second fact to keep in mind is that an SSL certificate is valid for one domain only.  If a user goes to www.example.com, the certificate has to be signed for www.example.com, not example.com or example.net.

SSL certificate for www.facebook.com

For example, http://www.amd.com/ is served entirely through Akamai. So what happens when you use https://www.amd.com/ ? You get a warning, because the Akamai CDN server sends a certificate valid for itself (a248.e.akamai.net), not for www.amd.com.

Wrong SSL certificate issued for akamai.net instead of amd.com

Wildcard certificates are not enough 

You don't need to use a CDN to have troubles serving the right certificate for a given hostname. Most sites can be reached with and without www: http://amazon.com/ and http://www.amazon.com/ brings you to the same site. When a site wants to handle several sub-domains (www.site.com, mail.site.com, static.site.com, etc.) easily, it can buy a wildcard certificate. This certificate is valid not just for one domain, but for all sub-domains: *.site.com. Unfortunately, this wildcard certificate is not valid for site.com (no sub-domain). For that, a separate certificate is required. This is again a challenge if the same IP address servers both site.com and www.site.com.

Dropbox has this exact issue. Access to https://dropbox.com/ delivers a warning to he user:

Dropbox's wildcard SSL certificate is not valid for dropbox.com

Mixed HTTP/HTTPS: the chicken & the egg problem

Yet another issue - HTTPS pages must contain external object from HTTPS URLs only. You cannot match HTTP and HTTPS on a secure page, otherwise users receive a warning message. Websites however rely on a significant amount of content from external sites: Googole/Comscore Analytics, Google/Twitter/Facebook connect, ads, etc.

Google Adsense, for example, cannot be used on a secure site. All sites which rely on this advertising network to make some money need to forget about HTTPS and about protecting their users!

Each website needs to make sure that all their partners, sometimes much bigger than they are, fully support HTTPS before they switch to it.

Warning about external HTTP objects on a secure page

Warning are scary!

It is not easy for a site to switch to SSL for all content. One mistake, and users will receive a warning. And they're scary! Internet Explorer 8 explicitly suggests that the user not to enter a site with an SSL certificate error.

Scary warning on Internet Explorer

Websites really don't want to scare away potential visitors!

But it is possible

Moving from HTTP to HTTPS is easier said than done. This must be carefully planned. All cases have to be thought through to avoid warning messages. Despite that fact, all of the challenges discussed in this post do have technical sotuions.

This can be done. Google has already moved Gmail to HTTPS by default, but they have not done the same for their other services...

-- Julien

BlackSheep for Linux

BlackSheep uses compiled code to listen to HTTP traffic. These executables come straight from Firesheep. Firesheep ships with executables for Windows And MacOSX 10.5 (Intel) only, this is why the first release of BlackSheep supports these 2 platforms only.

The number one request I got was to support Linux. The good news is that it is now possible to run BlackSheep on Linux - though it does requires some work to setup.


Too Many Linux environments

The main challenge is that the back-end must be compiled on each possible environment: CPU (x86, x86_64), compiler (gcc 3, gcc 4), and also different versions of libpcap, etc. In the case of Firesheep and BlackSheep, it is not possible to deliver one add-on that would work on all Linux environment.

This means that each Linux user must compile their own version.


Requirements

To make your own Linux version of BlackSheep, you need:

• autoconf 2.61 or higher (autoconf -V)
• libpcap-devel with pcap-config
• xulrunner-sdk (or xulrunner-devel depending on the distribution)
• boost-devel

Here is how to proceed on CentOS.

autoconf 2.61

CentOS provides autoconf 2.59, so a new version must be compiled from source:

wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.65.tar.gz
tar xf autoconf-2.65.tar.gz
cd autoconf-2.65
./configure
make
sudo make install
autoconf -V

If autoconf -V still shows the old version, modify your PATH:

export PATH=/usr/local/bin:$PATH

libpcap-devel

The version of libpcap-devel in CentOS is too old. A new one must be installed from source:

sudo yum install flex
sudo yum install byacc
wget http://www.tcpdump.org/release/libpcap-1.1.1.tar.gz
tar -zxvf libpcap-1.1.1.tar.gz
cd libpcap-1.1.1/
./configure
make
sudo make install

boost-devel

sudo yum install boost-devel

Back-end from Firesheep

Then, you need to compile the Firesheep-backend. Get the source code for Firesheep for Linux:

sudo yum install git
sudo yum install xulrunner-devel
git clone git://github.com/mickflemm/firesheep.git
cd firesheep
git submodule update --init
./autogen.sh --with-xulrunner-sdk=/usr/lib/xulrunner-sdk-1.9.2/
make

Note than xurlrunner could install in a different folder on your Linux box, for example in /usr/lib/xulrunner-devel-1.9.2.12

Check if the back-end works correctly. The directory might be slightly different

cd xpi/platform/Linux_x86-gcc3/
sudo ./firesheep-backend --fix-permissions
./firesheep-backend --list-interfaces

The last command might generate an error. However, this may not be an issue. To check if the packet capture works, try this (you may want to change eth0 to wlan0):

./firesheep-backend eth0 "tcp port 80"

In a different console, try this:

wget http://www.zscaler.com/

You should now this this in the first console:

./firesheep-backend eth0 "tcp port 80"
{"from":"10.10.100.109:37753","to":"72.249.144.174:80","method":"GET",
"path":"/","query":"","host":"www.zscaler.com","cookies":"",
"userAgent":"Wget/1.11.4 Red Hat modified"}

Congratulations, you'll be able to run BlackSheep on your box.

Next, you need to include the new back-end in the BlackSheep plugin (1.3 or higher):

cd ~
wget http://www.zscaler.com/research/plugins/firefox/\
    blacksheep/blacksheep-latest.xpi
mkdir blacksheep
unzip blacksheep-latest.xpi -d blacksheep/
cd blacksheep
cp -r ../firesheep/xpi/platform/* platform/

Edit the file install.rdf Remove the following lines:

[em:targetPlatform];Darwin_x86-gcc3[/em:targetPlatform][em:targetPlatform]WINNT_x86-msvc[/em:targetPlatform]

or add your new platform:

[em:targetPlatform>Linux_x86-gcc3</em:targetPlatform]
[em:targetPlatform]Linux_x86_64-gcc3[/em:targetPlatform]

You may also want to disable the updates to keep your custom, stable version. Remove this line, or modify the URL:

[em:updateURL]http://codebutler.github.com/firesheep/update.rdf[/em:updateURL]

You can now create the XPI file:

zip blacksheep-latest-linux.xpi -r *

Now, install BlackSheep. Restart your browser and open blacksheep/blacksheep-latest-linux.xpi.

There is one last step: the permissions must be fixed on firesheep-backend.

cd .mozilla/firefox/ygqde9s7.default/extensions/\
    jsobrier\@zscaler.com/platform/Linux_x86-gcc3/
sudo ./firesheep-backend --fix-permissions

The new version of BlackSheep contains Linux versions built on CentOS5 x86 and x86_64. If this does not work in your environment, follow the procedure above.

-- Julien

Detecting Firesheep

Firesheep, a Firefox plugin to do session hijacking ("sidejacking") by snooping on a LAN/WLAN and identifying session cookies passed in the clear over HTTP was released last week at Toorcon. To my surprise, this tool received a large amount of media attention. As the authors point out in their presentation, session hijacking is nothing new ... they actually describe it as the known "elephant in the room." In fact a few years ago (2008), sidejacking was presented at DefCon and a tool was written to take advantage of Gmail cookies being passed over HTTP to hijack Gmail sessions (see preso here). This presentation and tool also received a fair bit of media attention. Unfortunately not a whole lot was done about this problem. Google did eventually provided persistent SSL/TLS sessions for Gmail users, however as the Google Handler in Firesheep shows, user's Google session cookies can be captured when navigating from Gmail (HTTPS) to the Google search page (HTTP) or other HTTP Google pages that continue to track your Google profile (session). As the list of Firesheep handlers shows, the problem of passing session cookies in the clear is persistent across most all mainstream web services:


So how do you the user deal with this problem of websites passing session cookies in the clear for all to snoop off the Starbucks or Panera wifi you're using. The proper way of dealing with this problem is to browse to these sites through a trusted network connection. If not available, an encrypted tunnel (VPN, SSH, SSL, etc.) may be established through a trusted host to secure your web transactions. In addition to these known good security practices, I also took a look at detecting if someone is running Firesheep on the LAN/WLAN that you are connected to. The first thing that Firesheep does after it detects the session cookies for a site of interest is to automatically attempt to connect and scrape the user's account name and avatar to then display in the Firesheep/Firefox side panel. Because Firesheep is running on the same LAN/WLAN you are able to see Firesheep's network transactions the same way it saw yours :)

I just used Scapy (a python packet manipulation program) and generated one packet with the Facebook details that Firesheep is looking for. Here is the Facebook Firesheep handler:

Firesheep is looking for 3 cookies (xs, c_user, and sid) being passed to Facebook. So that's what I generate, with a few modifications - I make my packet IP address destination just for the gateway IP (versus sending garbage to Facebook) and send bogus "66666" values for the three cookies. In the Scapy interactive session this was done in these three lines (for readability):

>>> get = "GET /home.php HTTP/1.1\r\nHost: www.facebook.com\r\nUser-Agent:
Mozilla/5.0\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*
/*;q=0.8\r\nAccept-Language: en-us,en;q=0.5\r\nAccept-Encoding: gzip,deflate\r\nAccept-
Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\nKeep-Alive: 115\r\nConnection: keep-alive\r
\nCookie: c_user=66666; sid=66; xs=6666666\r\n\r\n"
>>> pkt = IP(dst="192.168.1.1")/TCP(flags="SPA",sport=12345,dport=80)/get
>>> send(pkt)

Here is the output of the packet that was generated:


Immediately after putting this packet onto the wire (well actually, it was wifi), I was able to see in Wireshark an attempted network session to Facebook with the fake session cookies that I populated.
The first packet highlighted in blue is the generated / fake Facebook session cookie packet to 192.168.1.1. Immediately following this packet being sent, we see packets being generated from my open Firefox running a Firesheep capture on the network. Firesheep immediately attempts to access www.facebook.com/home.php with the captured (fake) session cookies, only to be 302 redirected to the login.php page since the session is invalid. Any users running Firesheep on this LAN/WLAN would have also attempted this invalid session information and we would have seen it in our packet capture. From the Firesheep user's perspective, an error is displayed for the fake session information that I provided. Whereas, valid sessions display the account name and avatar that was scraped from accessing Facebook with the captured session cookies:

This technique could be put in a loop to generate and flood random fake session packets to provide an annoyance to the Firesheep user. Though they would just have to scroll through and ignore all of the error profiles. Also the flood of fake session packets and corresponding flood of traffic from Firesheep attempting to connect with the session cookies would likely result in a fairly unusable wifi network - and possible blacklisting from Facebook or other sites being repeatedly accessed by Firesheep with false session cookies.

The above described technique provides a 1 packet means of detecting Firesheep. Regardless of detection, users should (1) be wary of authenticating to sites on public/untrusted networks, (2) be disappointed with and encourage security changes among the web services they use, and (3) utilize encrypted tunnels (VPN, SSH, SSL proxy, etc.) to protect their session information when on public networks.

Who knows, maybe this round of attention on sidejacking will result in some real change..?

EV-SSL, SSL, and who’s not using it

It seems I've been picking on EV-SSL lately. It's not intentional; I just have encountered a lot of questionable marketing fluff lately and wanted to talk about it. Today is no different. Tim Callan's recent blog post got me thinking. Basically he referenced some SSL attacks that were disclosed at BlackHat, and suggested EV-SSL certificates as the cure to SSL MitM attacks and phishing in general. On the one hand, I believe his conclusion is conveniently aligned with his employer's sales agenda. On the other hand, I acknowledge that EV-SSL could raise the bar...if it's adopted and deployed in widespread fashion. And therein is the crux.

I've previously talked about the EV-SSL adoption rate (or lack thereof) in this blog. NetCraft has reported its findings of one million valid SSL-capable sites are in use (note: sites with invalid, self-signed, or expired SSL certs are not included in that count). And while I don't have access to their commercial SSL Survey report for January 2009, we infer from some third party mentions that the report states around 10,000 EV-SSL sites were found. That's 3,000 more than Verisign mentioned last month, but perhaps Verisign was only reporting what they alone issued. Given their marketshare (~75%, albeit that number is a year old) against total EV-SSL cert vendors, that seems to make sense.

Only 10,000 EV-SSL sites within two years seems very low to me, especially for something which is essentially an enhanced derivative of an already understood and accepted technology. People already know what SSL is and what function SSL certs perform, so that definitely is not the hold up. There just doesn't seem to be much of an adoption momentum, and maybe that's because the additional value these premium EV-SSL certs provide is questionable in the eyes of site owners.

But maybe I'm looking at this wrong. Only 10,000 EV-SSL sites seems a bit low, but what if they were 10,000 sites that matter? I suppose that would paint a different picture. If 10,000 big sites that account for a notable portion of the web's traffic used EV-SSL, I suppose that actually might not be so bad. So I entertained that theory. I manually surfed to each of the upper 50 of Alexa's Global Top 500 Sites list, and recorded who was using EV-SSL vs. normal SSL vs. no SSL. The idea is that these sites represent the most visited sites in all of the world (according to Alexa), and as such, assumingly have a vested interest in assuring their voluminous user population that the users' accounts and transactions are secure. If most of these sites were using EV-SSL, then that would actually provide notable EV-SSL permeation into overall web traffic.

The process I used was simple: visit each of the Alexa-listed sites (the top 50), surf around to find a 'signin' or 'signup' form or other equally-sensitive use of HTTPS, and then watch if the URL address bar in my Internet Explorer 7 browser turned green when SSL was utilized. A green bar meant EV-SSL; no green bar but still having a valid lock icon is standard SSL. I found that only two sites (ebay.com and login.live.com) were using EV-SSL. That's it. Just two. All of the other sites were using standard SSL, with the exception of ten sites that don't use SSL at all with their login forms (youtube.com, hi5.com, mail.ru, photobucket.com, vkontakte.ru, imageshack.us, friendster.com, skyrock.com, odnoklassniki.ru, and dailymotion.com) and two more that don't really receive sensitive info from the user and thus don't necessitate SSL (bbc.co.uk and cnn.com).

We might label that a bleak picture. Ten of the fifty top sites (20%) don't even use SSL for their logins. Only two use EV-SSL. I was a bit surprised to see the online retail giant, Amazon.com, didn't use EV-SSL. If EV-SSL was a sure-thing to lead to better customer confidence and more online retail conversions, I would have figured they would have been all over it. They would not be one to overlook a technological advantage if the ROI helped their bottom line...that is, after all, how they got started. And given that they store credit card data for quick purchasing convenience, there is a certain financial value to compromising someone's Amazon account; I’m surprised it hasn't been the target of more phishing attacks to date.

Also surprising was Yahoo (login.yahoo.com), AOL (my.screenname.aol.com), and Google (www.google.com) all use standard SSL for their common backend authentication sites. These vendors offer multiple different web services, but tie it all back to a single authentication mechanism, much like a Single Sign-On (SSO) platform. And aren't some of these vendors OpenID providers? That means a successful phish of a single account could be leveraged across many sites/services, even outside the realm of just these vendors. On Microsoft's live.com site, I found that the login form (from login.live.com, which was presented over HTTP by default but did include a link to switch to HTTPS) did go to an EV-SSL site once submitted, but the signup page (signup.live.com) was handled with a standard SSL cert. Maybe they just want to discourage new signups while assuring existing accounts it's safe to login.

But here's another thought: maybe these sites have invested in standard SSL certificates before EV-SSL was popular, and just are waiting for their current certs to expire before renewing with EV-SSL variants. That seems plausible, but the results are a bit mixed. Google renewed their current standard SSL cert in May 2008 and signup.live.com was renewed in November 2008. That was fairly recent, and definitely after EV-SSL was well established. Opposite that, AOL's my.screenname.aol.com certificate was issued in March 2007 and Yahoo's is from January 2006; it's arguable they were issued before EV-SSL really caught on. So it's hard to say, but the thought might hold true for some cases. Certainly not others.

But again, maybe I'm still looking at it all wrong. EV-SSL might only make the most sense to certain verticals, like online banking sites. The Alexa list doesn't really have any bank sites in their top 50. So I did a spot-check of some big bank site URLs pulled from the top of my head. Of all the ones I tried, only BankOfAmerica's login site (which is separate from their normal site) used EV-SSL:

• www.bankofamerica.com: standard SSL (renewed December 2008)
• sitekey.bankofamerica.com: EV-SSL
• www.wellsfargo.com: standard SSL (renewed June 2008)
• online.wellsfargo.com: standard SSL (renewed July 2008)
• www.chase.com: standard SSL (renewed August 2008)
• chaseonline.chase.com: standard SSL (renewed April 2008)
• online.citibank.com: standard SSL (renewed December 2007)
• www.us.hsbc.com: standard SSL (renewed July 2008)
• myonlineaccounts2.abbeynational.co.uk: standard SSL (renewed February 2009**)

That last one is very interesting. Abbey National Bank has been a notable target of phishing attempts going back a year. And yet, when they renewed their SSL certificate last week (February 12, 2009), they went with a standard certificate instead of EV-SSL. Whether they didn't know or didn't care that EV-SSL could help assure users against phishing, I don't know. But if a bank that's been phished for over a year doesn't decide to buy into EV-SSL when it has the convenient opportunity...who will? Marketing fluff aside, that is probably the absolute best-case realized application for EV-SSL ever. User accounts have access to monetary instruments. The site has been an active target of phishing attempts for over a year. They needed new SSL certs anyway. Any one of those reasons by itself is (supposed) ground for EV-SSL, and they had all three reasons. Oh well, maybe they're reconsider EV-SSL in 2010 when their new cert expires.

Until then,
- Jeff

**Postscript: it seems Abbey National Bank's site uses a cluster of SSL web servers that have different SSL certs installed. In some cases, I connect to a server that gives me an SSL cert that was issued on Feb 12 2009. On other occasions, I get connected to a server that gives me an SSL cert that expires on Feb 24 2009 (i.e. next week). So apparently they have currently upgraded the SSL certs on some of their servers, but not all. I just wanted to mention this in case you were poking around yourself and noticed the discrepancy. Here is a screenshot of the newer SSL cert, to prove I'm not making stuff up:

EV-SSL's reported successes, maybe

In a previous post I included a blurb mentioning that Verisign reported 7000 EV-SSL certificates were issued in the past two years, which seems fairly low. Recently I was referred to a spot on Verisign’s website where they keep their SSL case studies. Many of their more recently posted studies indicate the positive benefit/increased conversions brought about by using EV-SSL certificates. In other words, switching from standard SSL to EV-SSL certs lead to more sales, all because of customer confidence in seeing the 'green bar'.

For some reason, a mental warning alarm was going off in the back of my head. So I decided to dig deeper into the case studies to see how they actually tested things. After all, a flawed test methodology results in questionable results. I'm a bit of a stickler when it comes to having a solid, repeatable methodology for testing stuff.

In an ideal world, these case studies would have been conducted by subjecting half of their web clients to a standard SSL certificate, and the other half to an EV-SSL certificate. Easier said than done, but I suppose it's possible if you had a web server farm where half of the servers had the EV-SSL cert loaded and the other half didn't, and you used a network load balancer in front of everything to persistently keep the same client/source IP address connection mapped to the same server in the farm. You couldn't use an application level load balancer because that would require terminating the SSL to see the application-layer data, and you wouldn't know to terminate with EV-SSL vs. standard SSL. A completely wrong methodology would be see how many sales you got using the standard SSL certificate, then see how many you got after you upgraded to EV-SSL, and attribute the change to just the EV-SSL certificate. There are too many other factors that could affect a change in sales, such as a slow-down in the economy, a wave of released stimulus checks, a newly-launched advertising campaign, etc.

So how did they test? In the few case studies I read, they simply separated traffic into EV-SSL capable browsers (Internet Explorer 7, Firefox 3) vs. non-EV-SSL capable browsers (Internet Explorer 6, Firefox 2). The idea is that the non-EV-SSL browsers were not showing the green bar, while the EV-SSL browsers were. Then they measured the conversion rate of these two groups, and of course, the EV-SSL browser group had higher conversions. So it must have been the green bar. Or was it?

The core problem with this approach is that the population representation is skewed. The methodology assumes that users of IE7 are no different than users of IE6, which is not the case. The web development community is already largely aware that a significant portion of the remaining IE6 hold-outs (i.e. those who have not upgraded to IE7) are actually corporate users that are running on systems that are not allowed to be upgraded. Think about it: a notable number of home users will leverage Window's standard automatic update feature, and that would have updated them to IE7 long ago. Corporate environments, on the other hand, control the updates and look to have consistent version deployments across desktops. Further, they have a significant investment in web applications tailored to work with IE6 (which has been out for 7 years now...so that's 7 years of web apps that were made just for it); if the choice is to update all internal web apps to work with IE7, or just keep the corporate desktops at IE6, well, the fiscal choice is obvious.

Thus let's frame this scenario a bit differently: given visitors to a non-business-centric retail shopping web site, who is more likely to buy something...people shopping from their home computer, or people shopping from their work computer? Would you normally be tempted to buy a new pair of shoes online using your corporate workstation on your lunch break? Would you perhaps search a little to figure out what you wanted (which seems like an innocent-enough use of the corporate network), and then finish the transaction (i.e. officially make the purchase) later that evening when you got home?

Therefore my biggest complaint about the EV-SSL testing methodology that these case studies use is that the non-EV-SSL browser group (particularly IE6 users) will statistically have more coming-from-their-corporate-workstation users in it, and I'm not convinced that such users are identical to other users in regards to their immediate willingness to make personal retail or pharmaceutical purchases. Personally, I would expect those corporate users to be less-likely to lead to an immediate retail conversion. And that's what the EV-SSL case studies all seem to say/support...but they attribute that phenomenon to the presence or absence of the EV-SSL certificate.

So does that mean EV-SSL is responsible for the higher conversion rate? Not necessarily. Does it mean it's not responsible? Well, not necessarily. To know for sure, all other variables must be approximately equal...and in these situations, there are too many differing factors between the two groups to know in particular which factor is having the most impact. To help put things in perspective, it would be nice to see the same metrics (i.e. conversion rates for IE7 vs IE6 users) reported for sizable retail sites that are not using EV-SSL certificates. I have a hunch that, even without EV-SSL, those sites will still see slightly higher conversion rates for IE7 users compared to IE6 users.

Until next time,
- Jeff

The Obfuscated TCP project

Hello, Jeff Forristal here. In my last post I talked about the desire of some folks to use SSL for encryption purposes but forego the authentication components (via the use of self-signed SSL certificates). Overall it’s not a very good idea, since removing authentication from the process renders the benefit of the encryption moot for all but the most trivial (and lazy) threat vectors (passive eavesdropping).
So earlier this week I ran across a mention of the Obfuscated TCP project (a.k.a. ObsTCP), developed by Adam Langley of Google. The project is self-described as:
Obfuscated TCP is a transport layer protocol that adds opportunistic encryption. It's designed to hamper and detect large-scale wiretapping and corruption of TCP traffic on the Internet.
This sounds like an ideal potential alternate for all of those who wish for an 'encryption without (expensive public CA certificate-based) authentication' solution. The ObsTCP idea is simple: use light-weight and fast encryption functions to obfuscate all TCP data streams, in an effort to thwart passive eavesdropping. Processors are fast enough these days that the additional overhead to perform the data obfuscation is negligible. And (from my interpretation of the project’s documentation), the idea isn’t to be cryptographically secure transport and/or replace SSL…it’s just to obfuscate TCP data enough to make passive eavesdropping difficult to do. We are already seeing similar approaches deployed via P2P clients to bypass ISP-based throttling based on packet/protocol inspection; the obfuscation employed isn’t robust to survive a targeted cryptographic attack, but it is enough to make high-speed protocol detection and classification difficult. The project has produced a video (hosted on Youtube) that goes over the basic goals and reasoning behind them.
Looking at the project's history, the original intent seems to be for ObsTCP to be added into the TCP/IP protocol stack (ISO layer 4) for transparency. However, apparently the ObsTCP project approached the IETF with a draft, and, ... well ..., it got a chilly reception. So ObsTCP changed gears and instead moved up the stack to the application layer (ISO layer 7), and is now focusing on HTTP as their first high-value protocol target. So the original project description of ObsTCP being a "transport layer protocol" is a bit misleading when considered in the context of the project's new implementation direction.
So how does ObsTCP work? Well, it requires an ObsTCP-capable client and server. The server admin essentially embeds the server's public key (and some meta information) in a DNS entry related to the server. The client retrieves the server's public key, opens a connection to the ObsTCP port of the server, and then uses a Diffie-Helman authentication exchange to negotiate a key to use for subsequent encryption. Right now the project is offering proof-of-concept patches for Firefox browser, and Apache and lighttpd web servers to make them ObsTCP-capable. They also offer an ObsTCP-to-normal-TCP proxy which can be placed in front of TCP services to make them ObsTCP-capable.
Overall, how does ObsTCP compare against the threat vectors previously listed in my "SSL encryption without authentication debate" post? We already mentioned that passive eavesdropping would be thwarted, as that's the purpose of ObsTCP to begin with. But what about a more active man-in-the-middle (MitM) attack? My cursory review of the ObsTCP documentation and design indicates that it does not directly mitigate that specific threat vector—however, it does make it harder for an attacker to pull off. This is because the server's public key is distributed via DNS, separate from the TCP connection. That means an attacker has to intercept both DNS request and the TCP connection in order to successfully pull of a MitM attack. Further, the DNS records can be cached at various points around the Internet, making it further difficult for the attacker to spoof a DNS response. The attacker would likely have to employ separate specific DNS attacks (such as the recent Kaminsky brouhaha) just to inject the right info into DNS in order for the TCP intercept/MitM to correctly work. The amount of effort and coordination to pull this off is far greater than a single TCP intercept/MitM attack by itself.
Overall the ObsTCP project is in alpha stages, but the idea is intriguing. It does seem to fill a need that is growing and becoming more vocalized (i.e. encryption without authentication). It will be interesting to see whether the project becomes adopted enough to start gaining public traction and attention. We figure it will be the usual circular catch-22 situation often encountered with new Internet technology: server admins forego deploying the technology because not enough clients support it, and clients forego implementing the technology because not enough servers support it. Oh well, it’s still a good idea.
- Jeff

The ‘SSL Encryption without Authentication’ debate

Every so often I encounter a debate where an individual is making a case for the value of supporting/accepting self-signed SSL certificates in browsers. Basically their argument is “I do not care about authentication of SSL, I just want the encryption part…so why should I have to pay VeriSign or another commercial CA all that money for an SSL certificate that verifies my identity?” This question seems to be newly fueled by the fact that Firefox 3 now requires the user to go through a laborious 4-step process to allow the browser to connect to an SSL site utilizing a self-signed certificate.

The problem is: anyone who asks the above question is ignoring how SSL works and how SSL employs encryption in the first place. If you are trying to keep an evil person from learning your secrets, but you do not authenticate who you are talking to, you are basically overlooking that you may well be telling your secrets to the evil person directly! If you don’t authenticate the identity of someone, they are essentially an unidentified stranger to you. And the idea of wanting to keep your secrets from strangers (i.e. encryption) but also be willing to give your secrets to strangers (i.e. no authentication) is contradictory. If you have no idea of who you are talking to, then what value is the encryption really providing? How do you tell a complete stranger a secret in private and still expect the secret to remain safe from strangers?

Let’s look at how SSL tackles authentication via the use of certificates. A signed (i.e. authenticated) certificate is essentially a digital record that says “My name is Bob, and this big trusted company over here agrees with that statement.” The idea is that browsers trust a set of big trusted companies (Certificate Authorities such as VeriSign, Thawte, etc.), and that creates a trust chain: we trust the browser, the browser trusts the CA, the CA says this is Bob, so we trust it is Bob. On the other hand, a self-signed (i.e. non-authenticated) certificate is a digital record that says “My name is Bob, and you will just have to trust me that what I am saying is true.” It’s almost like the honor-system approach of everyone stating who they are; but how do we know if they are lying? Essentially, you don’t…because self-signed certificates can be created by anyone to say anything (that is the whole purpose of self-signed certificates). An evil attacker can trivially generate certificates that say “My name is Paypal, and you will just have to trust me,” “My name is eBay, and you will just have to trust me,” “My name is Bank of America, and you will just have to trust me,” etc. The only thing that prevents the attacker from deceiving you with these malicious self-signed certificates is your browser’s better judgment of not trusting these arbitrarily fabricated declarations of identity having no proof. Remember: security is about keeping you safe despite lies and deception; we need to ensure that a simple lie by an attacker won’t compromise the entire process. In this case, self-signed certificates offer a way for attackers to lie about their identity with impunity.

So let’s go back to the original premise of the question and look a bit more technically at what’s going on. The argument is the desire to have encryption without authentication. That means the sensitivity and secrecy of the data is still an issue/desire, otherwise, why bother with encryption? The primary threat vector mitigated by end-to-end encryption on a network is passive eavesdropping (a.k.a. network sniffing). But keep in mind that, in SSL, the encryption keys are dynamically negotiated by the two endpoints at the start of the connection (after authentication has concluded). Thus encryption by itself offers no security value if the passive eavesdropping attacker decides to switch to an active man-in-the-middle or interception attack (which is technically viable if they were already in a position to eavesdrop your network traffic to begin with); this just means you are now negotiating an encryption key with the attacker and directly sending them your data. SSL normally mitigates these attacks by the use of authentication, to ensure the endpoint you negotiate your encryption key with is indeed who they say they are. However if we allow self-signed certificates to be used and therefore overlook the authentication aspect, there is zero guarantee that the person you just negotiated an encryption tunnel with isn’t the person you were trying to secure your information from (via encryption) in the first place. True, it does require the attacker to switch from a passive attack to an active attack, but that is of little consequence if the attacker truly wants to compromise the data. And attackers are already playing very active roles in attacks today (setting up an entire phishing site and sending out phishing emails isn’t exactly a passive affair…).

I have a hunch the real motive behind petitioning for self-signed certificate support is purely economic. Web site operators want to appear to conform to user expectations of security and privacy via the use of SSL (the whole “make sure the little lock icon appears in your browser before you send sensitive info” mantra), but without having to shell out cash for a real SSL certificate (if they just paid the money for a proper CA-signed certificate, this whole debate is moot). It’s the façade of security without actually delivering on the promise. But those that are using self-signed SSL certificates for production uses, even prior to the newer crop of browsers handling them less favorably, are already doing a slight injustice to security as whole—because they are forcing a user to essentially make a “Yes I know this is insecure, please proceed anyways” decision. Accepting self-signed certificates in older browsers is usually just a semi-scary dialogue followed by a one-click override from the user….and apparently the protagonists of this debate believe this (was) acceptable for users to do. But isn’t that just exacerbating the phenomenon of users continually making bad security choices, by explicitly encouraging them to do so? We should not be encouraging users to bypass or override security protection mechanisms put there for their own good; what starts as an encouraged exception may eventually become an assumed norm (I’d like to make a Pavlov reference here, but I don’t want it seen as belittling the behavior or intelligence of users).

All of that said, I suppose there are some certain approaches that may offer a balanced compromise. If we look at SSH, we encounter the same basic problem: when the client first connects to the server, it doesn’t know if the server is actually the right server or not. So usually the client prompts the user with a small fingerprint of the server’s identity in order to verify that identity out-of-band. If the user instructs the client to proceed, the client caches the server’s identity fingerprint. From that point on, as long as the server’s identity fingerprint matches what is cached, life is good. If that identity fingerprint ever changes, then lots of security bells and whistles go off because something is afoot, such as a man-in-the-middle attack (or the server admin re-generated their identity information, which is not something done arbitrarily). Basically it reduces the “no-authentication” scenario down to only the very first, initial connection that the client makes to the server. An attacker would have one chance—and one chance only—to intercept that very first connection and supply impersonated credentials. But also keep in mind, if the attacker stops the interception ruse and allows the connections to proceed to the proper server, the client will immediately alert the user to something fishy because the server identity (as seen by the client) has changed. So an attacker can remain undetected if and only if they intercept that very first connection, and only for as long as they actively and continually intercept all future connections. That reduces the chance of successful attack to a very small window, and requires moderate effort on part of the attacker to remain undetected. Perhaps this approach could be adapted to browsers, where a self-signed certificate for a given site can be manually verified once (the first time), and then cached so that as long as the certificate doesn’t change, it can be assumed to be the same site. It is entirely a change to the client browser and how SSL certificates are validated; no SSL protocol or server-side changes are necessary.

But unless browsers were to enact such a change, the use of self-signed certificates in this day in age is a risky proposition. They are fine for testing purposes, but they should never be used in production with real users. An alternate approach to using self-signed certificates is to create your own CA (you can use the free OpenSSL suite to do so) and use your CA to sign your server certificates; then encourage your users to install your CA certificate. This at least maintains the integrity and security value of the SSL protocol, and would allow the users' browsers to function without any security warnings requiring user interaction. However, you must then guard your CA private keys thoroughly, as you have now because a trusted entity in the browser’s eyes; if your CA keys are stolen, it would allow attackers to generate arbitrary certificates that are signed by your CA. In other words, the attacker could create the equivalent of arbitrary self-signed certificates but would actually use you as the trusted signing authority, and since the users’ browsers now trust your CA, the browsers would inherently trust all of the attacker’s certificates.

Regardless of what you do, one thing is for certain: you do not want to be the weakest link in the security chain. SSL literally has a trust chain established by the use of authentication certificates, and trying to bypass authentication (and the associated trust chain) compromises all security (including encryption) offered by SSL. No one likes being identified as the weakest link, so save your company the PR trouble and just buy that SSL certificate from a proper CA. It’s what is best for everyone involved, and your wallet will recover.

- Jeff