Firefox add-on to highlight insecure links

Insecure Links Highlighter does what it says on the tin. On a web page like

it adds a bright red border around any insecure links, turning it into

It supports HTTP, FTP and (by default) links with event handlers which may or may not be doing bad things. Useful for security and privacy-oriented users and web devs alike.


The HTTPS-only experience

EFF recently announced that We’re Halfway to Encrypting the Entire Web.” As a celebration of this achievement I’ve started an experiment: as of yesterday, no unencrypted HTTP traffic reaches this machine*.


Even though securing your web site is easier than ever it will take some time before everybody encrypts. But there are a bunch of sites which support both secure and insecure HTTP transfer, and there are a few tricks to tilt the scales and make the current experience better:

  • The HTTPS Everywhere browser extension ensures that you use HTTPS whenever possible on thousands of sites.
  • Editing the URL to add “https://” at the start works for some sites. If you get the dreaded certificate error page make sure to report them, and only add an exception if … well, that subject is too big to get into here. Just don’t.

Many sites have excellent HTTPS support, and have enabled HTTP Strict Transport Security (HSTS). In short, if your browser knows that the domain supports HTTPS (by visiting it or the browser being installed with it) you can simply type the domain name in the URL field and the browser will default to fetching the secure version of the site. On the other end of the spectrum I can still visit sites which have no HTTPS support at all if I really need to by using Tor, which provides privacy but not integrity or authenticity.

pacman stopped working after setting this up. It turns out the package database is fetched using unencrypted HTTP by default, but it was easy to generate a new list of only HTTPS mirrors.

Some sites have a strange HTTPS setup. The BBC only support HTTPS for the front page, which is just weird. Why go to all that trouble for 1% of the gain? Other sites require authentication to access using HTTPS, possibly not realising that setting up HTTPS for everyone would be easier.

My home router runs DD-WRT, and the web interface for it is only accessible by HTTP by default. This is easy to configure though.

OCSP uses HTTP (at least in Firefox), since the returned file signature has to be checked separately anyway. So if I go to about:config, change security.OCSP.require to true, and visit a site I haven’t seen for a while, I get an error message like this:

An error occurred during a connection to The OCSP server experienced an internal error. Error code: SEC_ERROR_OCSP_SERVER_ERROR

The solution is to either allow OCSP queries specifically or to allow HTTP to specific hosts. Let’s see what can be done…

The Steam client uses insecure HTTP for both game updates and the store pages. There doesn’t seem to be any way to force it to use HTTPS, so I have submitted suggestion to Valve using the official channel.

These have been the only major hassles so far. The only other sites I really can’t get to work over HTTPS are various hold-outs like Wikia and BBC.


The change was a simple addition to my Puppet manifest:

firewall { '100 drop insecure outgoing HTTP traffic':
  chain  => 'OUTPUT',
  dport  => 80,
  proto  => tcp,
  action => reject,

The resulting rule:

$ sudo iptables --list-rules OUTPUT | grep ^-A
-A OUTPUT -p tcp -m multiport --dports 80 -m comment --comment "100 drop insecure outgoing HTTP traffic" -j REJECT --reject-with icmp-port-unreachable

* Technical readers will of course notice that the configuration simply blocks port 80, while HTTP can of course be served on any port. The configuration wasn’t meant as a safeguard against absolutely every way unencrypted HTTP content could be fetched, but rather focused on the >99.9% of the web which serves unencrypted content (if any) on port 80. I would be interested in any easy solutions for blocking unencrypted HTTP across the board.

Subversion server using HTTPS on Ubuntu Hardy setup

Yay, it’s up and running! And here are the steps to do it, mostly copied directly from the shell as I ran them. In any case, it may or may not work for you, so make sure you check with the proper documentation if anything fails.

By the way: Back up old repositories if you have any!

  1. Install the software:
    sudo apt-get install apache2 libapache2-svn openssl ssl-cert subversion
  2. Create directory for server certificates:
    sudo mkdir /etc/apache2/certs
  3. Create password-free SSL certificate (remember what you put as “Host Name” for the next step):
    sudo /usr/sbin/make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/certs/server.pem
  4. Add the Apache certificate settings to /etc/apache2/httpd.conf (use the “Host Name” value from the previous step instead of “” to avoid a warning in /var/log/apache2/error.log):
    SSLEngine on
    SSLCertificateFile /etc/apache2/certs/server.pem
  5. Enable Apache SSL module (necessary for HTTPS):
    sudo a2enmod ssl
  6. Create directory for Subversion repository files:
    sudo mkdir /var/lib/svn
  7. If you have any old repositories, copy them to /var/lib/svn/, and make sure the Apache user can read & write them:
    sudo chown -R www-data:www-data /var/lib/svn/
  8. Create Apache’s Subversion password file with one user (replace username with one of your choice):
    sudo htpasswd -c /etc/apache2/dav_svn.passwd username
  9. Uncomment the following lines in /etc/apache2/mods-available/dav_svn.conf to point Apache to your repositories:
    <Location /svn>
      DAV svn
      SVNParentPath /var/lib/svn
      AuthType Basic
      AuthName "Subversion Repository"
      AuthUserFile /etc/apache2/dav_svn.passwd
        Require valid-user
  10. Disable the default site (it clashes with the SSL settings somehow):
    sudo a2dissite default
  11. Restart Apache:
    sudo /etc/init.d/apache2 restart
  12. Test (replace repository_name with an existing repository name):
    svn co https://localhost/svn/repository_name