Configure Firefox/Iceweasel 3 to be more secure / usable / bearable

Today seems to be Firefox/Iceweasel 3 Bashing Day on Planet Debian, so let me join the fun :)

I agree with most other people that the default Firefox/Iceweasel 3 config is not ideal, so here's what I did to fix it. Some of these items improve performance, some remove annoyances, some remove privacy issues, some remove security issues. Not everything here may be desirable for people other than me.

General

  • Disable the bookmarks toolbar via "View / Toolbars / Bookmarks Toolbar", nobody needs that and we save some screen space. Remove all pre-defined bookmarks while we're at it.
  • Select "View / Toolbars / Customize".
    • Add the "New Tab" button/icon right after the "Home" button. This is probably the most-used button (for me at least) and it's not available per default...
    • Click "Use Small Icons", there's no reason to waste screen space.
    • Remove the Google search bar (useless).
    • Now move all icons and the URL bar into the menu bar (I'm not kidding). After that you can disable the nagivation toolbar via "View / Toolbars / Navigation Toolbar" and save even more screen space.

Preferences

Select "Edit / Preferences".

Main:

  • Select "When Iceweasel starts: Show a blank page".
  • Set "Home Page" to whatever you see fit.

Tabs:

  • Enable "Always show the tab bar".

Content:

  • At the right-hand side of "Enable JavaScript" click "Advanced" and uncheck all checkboxes. JavaScript stuff shouldn't need to do any of those operations.
  • Uncheck "Enable Java". Nobody needs this crap and it's a huge security risk.

Privacy:

  • Disable "Keep my history for xyz days" completely. Huge privacy risks.
  • Disable "Remember what I enter in forms and the search bar". Huge security and privacy risks, almost no gain.
  • Disable "Remember what I've downloaded". Huge privacy risks.
  • Uncheck "Accept third-party cookies".
  • Choose "Keep until: I close Iceweasel".
  • Click "Show Cookies" and remove all of them.
  • Enable "Always clear my private data when I close Iceweasel". Click "Settings" and check all items. You want to purge everything when closing Iceweasel.

Security:

  • On the right-hand side of "Warn me when sites try to install add-ons" click "Exceptions" and remove all exceptions.
  • Disable "Tell me if the site I'm visiting is a suspected attack site". Useless crap, possibly a privacy issue.
  • Disable "Tell me if the site I'm visiting is a suspected forgery". Useless crap, possibly a privacy issue.
  • Disable "Remember passwords for sites". This is a huge security risk, never ever enable it!

Advanced:

  • "General" tab:

    • Enable "Warn me when web sites try to redirect or reload the page".
    • Disable "Check my spelling as I type". Useless, annoying crap, which probably even impacts performance.
  • "Update" tab:

    • Disable "Automatically check for updates to: Installed Add-ons".
    • Disable "Automatically check for updates to: Search Engines".
    • Select "When updates to Iceweasel are found: Ask me what I want to do".
    • about:config

      Firefox/Iceweasel 3 screenshot

      Open a new tab, enter "about:config" as URL and hit ENTER. Click the annoying "I'll be careful, I promise!" button. Uncheck "Show this warning next time" while we're at it.

      • Set browser.urlbar.matchOnlyTyped = true to disable the new, annoying "AwesomeBar" URL bar feature (which is also a huge privacy risk).
      • Browser tabs are way too huge for my taste (thus only very few fit on the screen). Fix it with browser.tabs.tabMinWidth = 60 and browser.tabs.tabMaxWidth = 60 (needs a browser restart). You can even use less than 60 if you don't need any text and an icon per tab is enough for you.
      • Disable the annoying, flashing auto-search stuff when you select "Tools / Add-ons / Get Add-ons": Set extentions.getAddons.showPane = false.
      • Set bidi.support = 0. You'll probably never need it, so reduce the number of potential bugs and security issues by disabling it.
      • Self-signed certificate handling is annoying, so fix it with: browser.ssl_override_behavior = 2 and browser.xul.error_pages.expert_bad_cert = true (thanks Pierre Habouzit).
      • Set browser.tabs.closeButtons = 3 in order to prevent accidental closing of tabs (no more Close buttons on each tab, only one global Close button on the right). Yes, CTRL+Shift+T helps in case it still happens.
      • Set network.prefetch-next = false to prevent random prefetching of webpages which means wasting CPU cycles and bandwidth, as well as subtle privacy and security issues.

      Plugins

      None. Don't even think about installing crap like the closed-source Flash player if stability or security are important to you. If you absolutely must watch YouTube videos, I recommend youtube-dl.

      Extensions

      Use as few as possible. Every extention may have security problems or bugs, and can negatively affect performance etc.

      Pretty much the only one I use is NoScript to selectively enable JavaScript for some trusted websites (and disable it for all other sites).

DIY secure pseudo-DDNS setup using ssh

Here's a quick HOWTO for setting up your own secure pseudo-dynamic DNS (DDNS) server.

It's not a "real" DDNS service, i.e. you won't be able to use standard DNS tools or protocols to talk to the server, but it covers 98% of all functionality I expect from a service such as DynDNS or similar ones: It tells me the IP address of a certain box which doesn't have a static IP address (e.g. my home-server).

Requirements

You'll need:

  • A Linux box with dynamic IP address (dial-up modem/DSL), I'll call it homeserver from now on. This is the box whose public IP address I want to be able to find out.
  • A public Linux box with static IP address (or known DNS name) where you have a user account and ssh access. I'll call this box publicserver.

Setup

On the homeserver:

  • Add a non-root user account (e.g. user) just for the purpose of this mechanism: adduser user. The user doesn't need any special permissions.
  • Create an ssh key with an empty passphrase for the user: ssh-keygen -t rsa -b 4096. This is required as you'll want to run ssh commands via cronjob later.
  • Add a cronjob which runs a random command such as ls regularly (as user), e.g. once per 10 minutes:

    5,15,25,35,45,55 * * * * user ssh -x user@publicserver ls

    The command to run (e.g. ls) doesn't really matter at all, more on that later.

On the publicserver:

  • Add a non-root user account (e.g. also named user) just for the purpose of this mechanism: adduser user. The user doesn't need any special permissions.
  • Add the public ssh key (/home/user/.ssh/id_rsa.pub) of user@homeserver to the publicserver's /home/user/.ssh/authorized_keys, so that the homeserver user can login on the remote publicserver without password (i.e. non-interactively). We'll also limit which ssh commands this user can run using the command keyword in /home/user/.ssh/authorized_keys file:

    command="echo $SSH_CLIENT | cut -d \" \" -f 1 > /home/user/homeserverip.txt && chmod 644 /home/user/homeserverip.txt",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAAAAAAA...AAAAAAA user@homeserver

    In the above example AAA...AAA is the public key, command specifies which command should be run if this user "logs in" via ssh, and we use some other options such as no-port-forwarding,no-X11-forwarding,no-agent-forwarding to minimize what this user can do via ssh.

So to summarize: the homeserver's user simply executes the above commands on the remote publicserver, which in turn abuses the $SSH_CLIENT environment variable which contains the public IP the ssh connection was coming from (which is exactly what we're looking for). We store that IP in the homeserverip.txt file, which will always contain the latest-known IP address of the homeserver (because of the cronjob).

Getting the current homeserver IP address

You can now retrieve the current IP address of your homeserver easily from anywhere (e.g. from your laptop when you're in another, possibly hostile network) in order to connect to your homeserver:

  $ ssh -x otheruser@publicserver cat /home/user/homeserverip.txt

To make this a bit more convenient you can add a shell alias (e.g. into ~/.bashrc):

  alias homeserverip='ssh -x otheruser@publicserver cat /home/user/homeserverip.txt'

Or, to conveniently login to your homeserver as johndoe:

  alias homeserverlogin='ssh -x johndoe@`ssh -x otheruser@publicserver cat /home/user/homeserverip.txt`'

Conclusion, advantages

This may not be the most elegant solution, and it has a number of drawbacks when compared to services such as DynDNS, but it's sufficient for me and it also has some advantages:

  • You're not dependent on the DDNS service provider. For instance DynDNS recently changed their policy to only allow one update per 28 days, which totally sucks. They then disabled the service completely until I updated my ddclient config and contacted them, i.e. I wasn't able to connect to my homeserver for quite a while, which also sucks.
  • The ssh-based solution is secure and encrypted, in contrast to some other DDNS services, which only allow unencrypted HTTP-based connections (yes, some do allow https/SSL connections).
  • This solution doesn't require in-depth DNS server config knowledge, neither does it require a DNS server you control. You only need a (non-root) ssh account on a public server (or virtual server).

Personally I'm currently using this mechanism for two things, more might follow:

  • Connect to my homeserver via ssh.
  • Get the homeserver's IP address so I can update my OpenVPN client config file on my laptop (I use my homeserver as OpenVPN server).

So far it works pretty nicely.

Update 2008-06-24: Various fixes and simplifications. SSH key must be password-less. Don't run cronjob once per minute, that's overkill.
Update 2008-07-02: Simplify setup by removing the need for extra scripts. Limit the commands the user can perform via ssh in the authorized_keys file. Make the RSA keys 4096 bits strong.

Speed up Linux crypto operations on the One A110 laptop with VIA Padlock

One Mini A110 subnotebook

OK, so I've been hacking on and testing my shiny new One A110 mini-laptop during the last few days and I must say I'm very happy with it. I'll write up some more details later (check the wiki if you're impatient), but today I want to highlight a very nice feature of this laptop (compared to, for instance, the Eee PC): The VIA C7-M ULV CPU in the laptop has VIA Padlock support.

VIA Padlock is a hardware feature in recent VIA CPUs which provides hardware-accelerated AES and SHA-1/SHA-256 support, among other things. This can be used in Linux (with the proper drivers and patches) to improve performance of dm-crypt, OpenSSL (and all programs using it), scp, sha1sum, OpenVPN, etc. etc.

I have written a quite extensive VIA Padlock HOWTO and benchmarks in the A110 wiki (but all of this will work on other systems which have VIA Padlock, too). To summarize, here are the most important benchmarks:

dm-crypt (256bit AES, cbc-essiv:sha256)

VIA Padlock dm-crypt benchmark

Without VIA Padlock support:

$ hdparm -tT /dev/mapper/hdc2_crypt
/dev/mapper/hdc2_crypt:
 Timing cached reads:   448 MB in  2.00 seconds = 223.47 MB/sec
 Timing buffered disk reads:   22 MB in  3.07 seconds =   7.17 MB/sec

With VIA Padlock support:

$ hdparm -tT /dev/mapper/hdc2_crypt
/dev/mapper/hdc2_crypt:
 Timing cached reads:   502 MB in  2.00 seconds = 250.41 MB/sec
 Timing buffered disk reads:   90 MB in  3.07 seconds =  29.36 MB/sec

The native speed of the SSD in the laptop is 31.01 MB/sec, so there is almost no performance penalty when using VIA Padlock.

OpenSSL

VIA Padlock OpenSSL benchmark

OpenSSL speed benchmark, first line without Padlock, second line with Padlock enabled:

$ openssl speed -evp aes-256-cbc [-engine padlock]
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc       9187.18k    10572.28k    11054.32k    11179.36k    11218.02k
aes-256-cbc      47955.92k   150619.73k   325730.73k   458320.11k   520520.79k

ssh/scp

VIA Padlock scp benchmark

Without VIA Padlock support:

$ scp -c aes256-cbc bigfile.dat localhost:/dev/null
bigfile.dat                100%  159MB   5.9MB/s   00:27

With VIA Padlock support:

$ scp -c aes256-cbc bigfile.dat localhost:/dev/null
bigfile.dat                100%  159MB  14.5MB/s   00:11

OpenVPN

A real speed benchmark is pending (not measurable easily on 100MBit LAN, will try on a slower link), but as OpenVPN uses OpenSSL it should have roughly the same speedup iff you tell OpenVPN to use AES (it uses Blowfish per default).

Also, there's a measurable difference in CPU load while tranferring large files over OpenVPN: 8% CPU load with VIA Padlock (vs. 20% CPU load without VIA Padlock).

sha1sum / phe_sum

VIA Padlock sha1sum / phe_sum benchmark

phe_sum is a small C program which can be used as drop-in replacement for sha1sum (which doesn't support VIA Padlock yet). Quick benchmark:

sha1sum, without VIA Padlock:

$ time sha1sum bigfile.dat
real    0m6.511s
user    0m5.864s
sys     0m0.412s

phe_sum (with VIA Padlock support):

$ time ./phe_sum bigfile.dat
real    0m1.149s
user    0m0.704s
sys     0m0.424s

All in all VIA Padlock gives you a pretty impressive speedup for many crypto-using applications on Linux, which is especially useful on the A110 mini-laptop (think OpenVPN or scp for mobile usage, and dm-crypt for an encrypted SSD, of course).

Big Buck Bunny video and soundtrack under Creative Commons license

Jan Morgenstern

Just in case you haven't yet watched it: Big Buck Bunny.

Great animated video created mainly using Blender, released under the Creative Commons Attribution 3.0 license.

The soundtrack/score is now also available under a CC license (as is lots of other "raw" material for the movie).

One A110 mini-laptop with pre-installed Linux for 199.- plus Debian installation HOWTO

One Mini A110 subnotebook

OK, so I've spent my last money on the One Mini A110 subnotebook recently. Yep, yet another ASUS Eee PC clone, but this one has the great benefit of costing only 199.- Euros and has similar specs as the Eee PC 2G Surf (700), I think.

This is really a great little machine as far as I can tell. It's a VIA C7-M ULV 1GHz with 512MB DDR2 RAM and a 2 GB Solid-State-Disk (SSD), 7" screen at supposedly 800x480, VGA out, card reader slot for SD/MMC/MS, 2x USB, wireless, modem, audio. No webcam, no bluetooth.

Yesterday I created a wiki at a110wiki.de (for the A110, but also the A120 from the same vendor, which has a 4 GB SSD), where A110 users can collect information, HOWTOs, photos, etc. There's already quite some content there, especially some early tutorials and photos on the inner workings of the A110.

Today I've installed a stock Debian unstable distro on the SSD with 2.6.25 kernel, and I'm currently checking which parts of the hardware work out of the box, and which need further fixing. There's a a bunch of source code tarballs and patches on the vendor website, but most of it seems to be meant for 2.6.22, we'll see if and/or how much work it'll take to merge all this upstream (if it's not already done)...

My Debian Installation HOWTO is also available from the wiki, of course; I'll add more info and photos during the day.

Now for all interested parties: The vendor of the A110 has (again) announced a special weekend offer (valid until Sunday, June 1, 2008, i.e. tomorrow) where they'll sell the A110 for 199,- Euros again, the regular price will be 229,- Euros after that. So if you're thinking about buying one, now is probably the right time.

Check the wiki for issues which are important to you, some quirks remain at this point (but will probably mostly be figured out sooner or later), e.g. the wifi seems to have issues (the vendor said they'll send a driver update to all affected customers), the RAM is builtin and can't be upgraded, and some other, more or less important issues, depending on what you expect from the laptop.

For real-time communication there's also the #a110 IRC channel on Freenode.

Syndicate content