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.
Select "Edit / Preferences".
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.
browser.urlbar.matchOnlyTyped = trueto disable the new, annoying "AwesomeBar" URL bar feature (which is also a huge privacy risk).
browser.tabs.tabMinWidth = 60and
browser.tabs.tabMaxWidth = 60(needs a browser restart). You can even use less than
60if you don't need any text and an icon per tab is enough for you.
extentions.getAddons.showPane = false.
bidi.support = 0. You'll probably never need it, so reduce the number of potential bugs and security issues by disabling it.
browser.ssl_override_behavior = 2and
browser.xul.error_pages.expert_bad_cert = true(thanks Pierre Habouzit).
browser.tabs.closeButtons = 3in 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+Thelps in case it still happens.
network.prefetch-next = falseto prevent random prefetching of webpages which means wasting CPU cycles and bandwidth, as well as subtle privacy and security issues.
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.
Use as few as possible. Every extention may have security problems or bugs, and can negatively affect performance etc.
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).
On the homeserver:
5,15,25,35,45,55 * * * * user ssh -x user@publicserver ls
On the publicserver:
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
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).
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`'
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:
Personally I'm currently using this mechanism for two things, more might follow:
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.
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:
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 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
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
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).
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).
I've bought a new hard drive for my laptop recently, because I finally got fed up with my constantly-full disk. Having to browse around in $HOME looking for stuff which can be safely deleted just because I want to run
fetchmail (and that would fill up my disk) just sucks. So, after getting a cheapo 160 GB 2.5" disk (the old one was 80 GB), I had to move all my data to the new disk.
As I didn't want to re-install from scratch I started with
dd'ing the whole disk over to the new one (using a live CD and an external USB hard-drive enclosure). This took pretty long, but went fine otherwise.
The new disk then contained all my partitions (hda1-hda3) and also GRUB in the MBR etc., as expected, but was still only 80 GB in size, of course. So the first step is to enlarge the hda3 partition, which is a dm-crypt volume that contains various LVM logical volumes (for /home, /usr, /var, swap, etc.), each of them using the ext3 filesystem (except for the swap volume, of course).
0. Perform backups, boot from a live CD
Important: If you plan to perform any of these steps, make sure you have recent backups! I take no responsibility for any data loss you might experience. You have been warned!
First off, you should boot from a live CD which has all the tools you'll need, including cryptsetup, LVM tools, resize2fs, etc. You can use the nice grml live CD for instance.
1. Resize partition
This sounds scary (and it is!), but the way I enlarged the encrypted hda3 partition was by first deleting it via
fdisk. First, issue the "p" command in fdisk, write down the exact start cylinder of hda3. Then delete hda3. Now create a new hda3 partition which starts at exactly the same cylinder as the old hda3 but is larger, i.e. in my case it has ca. 80 GB additional space.
Your data will still be there if you don't screw up, and the partition is bigger now. Using something like gparted will likely not work as expected, as the partition is encrypted!
2. Resize dm-crypt volume
Nothing to be done, it seems dm-crypt automatically adapts and notices that the partition is bigger. Just "open" the encrypted volume using
$ cryptsetup luksOpen /dev/hda3 foo
3. Resize LVM physical volume
Next step is to tell LVM about the new space. We first resize the LVM physical volume on the
foo "partition" to use up all newly-available space.
$ pvresize /dev/mapper/foo
4. Resize LVM logical volume
Now we can pump the new space into any of the logical volumes (or into multiple ones). I only increased one logical volume, my /home:
$ lvresize -L +74 GB /dev/vg-whole/lv-home
5. Resize ext3 filesystem
The final step is to resize the ext3 filesystem on the
lv-home logical volume (after running the obligatory fsck -n). I first used ext2resize, but that failed horribly:
$ fsck -n /dev/vg-whole/lv-home $ ext2resize /dev/vg-whole/lv-home error: Invalid argument: seeking to 3258921205760
This seems to be a known bug, ext2resize apparently cannot handle large disks or something, and as I found out a few minutes later it's pretty much deprecated anyway. The better solution is to use resize2fs:
$ fsck -n /dev/vg-whole/lv-home $ resize2fs /dev/vg-whole/lv-home
That's it. We can now reboot the system from disk and enjoy ca. 80 GB of additional hard drive space. Yay!
Just in case you haven't already read about this... Some researchers from Princeton have published a paper about methods which can be used to attack full-disk-encryption (FDE) schemes.
They have demonstrated that at least BitLocker (Windows Vista), FileVault (MacOS X) and dm-crypt (Linux) are vulnerable to this type of (partly hardware-based) attack scenarios. Quite likely lots of similar other solutions are vulnerable as well.
The main problem is that (contrary to popular belief) RAM does indeed retain its data for a non-trivial amount of time after power is cut (seconds, even minutes or hours if it's cooled down enough), so you can mount some new attacks such as:
Yes, all attacks assume that the attacker has physical access to your PC/RAM, in which case you already have several other problems. Still, the new thing about this is that even full-disk-encryption doesn't help much in some cases. You probably shouldn't depend too much on it (but you shouldn't stop using disk encryption either, of course!).
Make sure to read the comments of the various articles for more scenarios and possible ideas for how to prevent such attacks. Some ideas include enabling the BIOS RAM checks (which might explicitly erase RAM contents on reboot; that doesn't help in all cases, though) or using coreboot (previously LinuxBIOS) to erase RAM contents at boot-up and/or shutdown.
It's a highly non-trivial issue, though, there's no easy and complete fix so far. The only sure way is to not have your laptop or PC stolen and to not give attackers physical access to your computers.