Installing Tor Client on Ubuntu

The use of Tor software to hide your network activity occasionally comes up in the main stream news media as being only for illegal purposes such as drugs or pornography. There are however many instances where individuals or groups rely upon their activity being hidden from prying eyes. Examples are… Journalists, politicians and even common citizens that don’t want to have their personal information gathered and shared/sold.

Installing the client software is easy for most platforms. You can download and verify the signatures from the Tor website to be absolutely certain. If you trust the maintainers of the Ubuntu PPA’s or other compilations, you can also do so… (with appropriate precautions):


sudo add-apt-repository ppa:webupd8team/tor-browser
sudo apt-get update
sudo apt-get install tor-browser



If you have ever used the popular software InSSIDer on Windows or OS/X, you might wonder if there is an equivalent application for Ubuntu/Linux.

LinSSID allows you to visually survey the Wifi networks in your area, identifying networks using the same channel as your own, even if they are not broadcasting SSID’s.

sudo add-apt-repository ppa:wseverin/ppa
sudo apt-get update
sudo apt-get install linssid

— OR —

sudo vi /etc/apt/sources.list

NOTE: it seems that the release version is only available for ‘precise’ and has not been updated for newer Ubuntu releases, I was able to simply go to the terminal and execute "software-properties-gtk" to change ‘trusty’ to ‘precise’ on the PPA and it worked great!



Adobe FlashPlayer 7 added several security features. I first became aware of this one as I saw a large number of HTTP 404 errors for a file named ‘crossdomain.xml’ in my webserver logs. (see also clientaccesspolicy.xml)

If you use flash on your website, I’d suggest adding an appropriate copy of this file to limit your exposure to some potential security issues.

Restricted domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "">
<allow-access-from domain="*" />
<allow-access-from domain="" />

Open to all domains (not recommended, but fully backward compatible)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cross-domain-policy SYSTEM "">
<site-control permitted-cross-domain-policies="master-only"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>


Free website uptime monitoring

Regardless if you host your own websites, or pay to have them hosted elsewhere, up-time, availability and network performance metrics are important to your visiting guests.

Here are two free services that I’ve found useful for monitoring, notification and reporting.

BTW, you can even use these to watch competitors or sites that you frequent.

Conditional Comments cause CSS to block

Here’s an odd one…. I’ve found that if you use the common method of using Conditional Comments to separate MSIE specific CSS, you’ve likely added a performance problem without knowing it… that is, in addition to the network connection and time required for the different CSS files.

It turns out that the standard use of this approach blocks the other downloads until the main CSS is loaded.

The solution is both simple and painless to implement…. a quick solution to this is to add an empty conditional comment early on, that is, before the main content (CSS) is loaded.. This works for all approaches, such as those where comments surround the <body> or various <link>, <style> or <script> tags.

Personally, I like to do this immediately after the DOCTYPE and before the <html> tag. Additionally, since IE10 dropped support for this technique, I’ll just target IE 9 and below for any developer that comes after me.

<!DOCTYPE html>
<!--[if lte IE 9]><![endif]-->
<html lang="en">


Cloudflare CDN (Content Delivery Network)

Best practices for web applications often call for the use of a CDN. Those of you that have worked with YSlow! are likely very accustomed to seeing warnings for this reason. I’ve found that CloudFlare is very easy to setup, and for basic services costs absolutely nothing. In addition to the obvious performance advantages of using a CDN to offload much of your network traffic, it also has the advantage of improved security.

CDN’s work by caching a copy of your static content at several locations around the world, making it closer and faster for your users.

Implementation takes only minutes as it requires that you:

  1. create a (free) account,
  2. retrieve your existing DNS values from your current provider,
  3. determine direct vs. CDN “cloud” routing for each subdomain,
  4. change your DNS records to point to the CloudFlare DNS servers

Some additional advantages I’ve seen since implementing:

  • Site remains available in limited capability to users during server outages or upgrades.
  • Simplified network configuration as all requests can be sent outside of the LAN for users local to the servers
  • IPv6 dual-stack support


HTTP ETag Header

These are useful for some advanced caching behavior, but there are cases where you might find them unnecessary for static files (in particular). Most network analysis tools will call attention to this header value, and while it seems like a trivial amount of bandwidth to send from the server to the client, the real reason for the negative score is more likely related to the behaviors that it causes in the client.

It should be noted that the default value used for the ETag is based upon the ‘inode’ of the file, as such it’s IS problematic in clustered server environments. I’ve shown the correction for this below.

Adding the following to your Apache http.conf file is a start:

# Change ETag to remove the iNode (for multi-server environments)
FileETag MTime Size

#Remove ETag from all static content, this could be done globally without the FilesMatch, but we want better control.
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset ETag



HTTP Cookie Header

Obviously “Cookies” have a lot of advantages in web applications to maintain “state”, unfortunately using standard server configurations leads to even static content serving them up un-necessarily wasting some (minimal) bandwidth.

Adding the following to the Apache httpd.conf file is a start:
#Remove Cookie from all static content (except HTML as javascript could use it)
<FilesMatch "\.(html|htm|js|css|gif|jpe?g|png|pdf|txt|zip|7z|gz|jar|war|tar|ear|java|pac)$">
<IfModule header_module>
Header unset Cookie



JSP Whitespace reduction

I’ve often found that most JSP developers are uncertain as to why their HTML output contains a lot of extra blank-lines, tabs and carriage returns. White space included in the template text of JSP pages is preserved by default. This can have undesirable effects. For example, a carriage return added after a taglib directive would be added to the response output as an extra line. This cruft is known as WhiteSpace, and it is responsible for a lot of wasted bandwidth and many spacing issues in HTML designs.

The challenge:

  • Developers that only use WYSIWYG editors are never even aware of the extra spacing within JSP source code.
  • Developers that work in source code often want to format the markup to allow for better visualization and readability of the source code.
  • Most IDE’s do not show the developers the special characters within the editor environment, external text editors such as NotePad++ and TextPad can be configured to show them.

Here’s a few suggested approaches on removing these, first development items:

  1. Remove comments:
    • Remove any (and all) JSP style comments <%-- comment --%> as each line in them will result in a carriage return being sent to the browser.
    • While you are at it, remove HTML comments <!-- comment --> as they often expose potential attack vectors for individuals trying to hack your website.
  2. Combine your JSP directives, <%@page %> or < /> into a single entry.
  3. Open and close all tags on a single line when possible.

Compiler options are possible for some platforms:

  • The page directive on each JSP can contain the argument to tell the compiler to trim the space in individual JSP’s:
    < language="java" pageEncoding="utf-8" trimDirectiveWhitespaces="true" />
  • For Tomcat (and others?) web.xml can be edited to contain the following in the jsp-config section:

  • For Tomcat (and others?) web.xml can be edited to contain the following for the JSPServlet:

  • The deployment descriptor can also be used to do so by adding a trim-directive-whitespaces element to a jsp-property-group element in the deployment descriptor and set it to true.
  • Some IDE’s expose the attribute, NetBeans 5.5 uses the following:
    1. Open the deployment descriptor file in the editor.
    2. Click the Pages button at the top of the editor.
    3. Select a JSP property group.
    4. Select the Trim Directive Whitespaces checkbox.
    5. Save the deployment descriptor.
  • Custom tag authors can eliminate white space from the output generated by a tag file by setting the trimDirectiveWhiteSpace attribute of the tag directive to true.

JSP Version Matrix for common servers:

Apache Tomcat 7.0.x JSP 2.2
Apache Tomcat 6.0.x JSP 2.1
Apache Tomcat 5.5.x JSP 2.0
Apache Tomcat 4.1.x JSP 1.2
Apache Tomcat 3.3.x JSP 1.1
IBM WebSphere Application Server 7.x JSP 2.x
IBM WebSphere Application Server 6.x JSP 2.0
IBM WebSphere Application Server 5.x JSP 1.2


Happy coding!

HTTP Session Hijacking (Firesheep)

This topic, and Firefox add-on have received a lot of press lately, as such I figured that I’d capture some comments on the topic. HTTP Session hijacking is nothing new, anyone with the ability to monitor your non-secured network traffic can do this with little effort… what’s happened here is that there are now some really simple to use tools to do the job.

In the past, someone would have to passively monitor your network traffic with a tool like WireShark, and all they’d really have to do is wait for you to access a website to watch the ‘HTTP Cookies’ (or even a URL that contains a ‘session id’). With that information, they simply need to use the same value that you do to essentially take over your session and your current state. Banks are particularly at risk for this, but in most cases they use HTTPS/SSL for all secure data including logins. Social websites such as Facebook and even GMail, often default to non-secure logins to maximize their server and network performance.

Best defense here… never use non-secure login forms, especially when using a public wireless (or wired) network.

Interesting enough, there’s now a Firefox add-on that monitors for usage of Firesheep on the network, unfortunately neither of these currently work in Linux… links below!