technology
On technology
PGP Usability Regression thanks to Enigmail
The latest auto update to Enigmail, the essential plugin for Thunderbird for encrypted mail, is a fairly dynamic project that occasionally makes UI and usability decisions that not everyone agrees with.
The latest is a problem for me. I use K9 for mobile mail and K9 doesn’t support PGP/MIME, but Enigmail just:
Why? OK – PGP/MIME leaks less metainformation than inline PGP, but at the expense of compatibility. K9 should support PGP/MIME, but it doesn’t. Enigmail should have synchronized with K9 and released PGP/MIME when mobile users could use it.
But encryption people often insist that the only use case that matters is some edge case they think is critical. They like to say that nobody should read encrypted mail on a mobile device because the baseband of the device is intrinsically insecure (all cell phones are intrinsically insecure – phones should treat the data radio as a serial modem and the OS and the data modem should interact only over a very simple command set – indeed, the radio should be a replaceable module, but that gets beyond this particular issue).
For now, make sure your default encoding is Inline-PGP or you’ll break encryption. Encryption only works if it is easy to use and universally available. When people can’t read their messages, they just stop using it. This isn’t security, this is a mistake.
Signal Desktop: Probably a good thing
Signal is an easy to use chat tool that competes (effectively) with What’sApp or Viber. They’ve just released a desktop version which is being “preview released/buzz generating released.” It is developed by a guy with some cred in the open source and crypto movement, Moxie Marlinspike. I use it, but do not entirely trust it.
I’m not completely on board with Signal. It is open source, and so in theory we can verify the code. But there’s some history I find disquieting. So while I recommend it as the best, easiest to use, (probably) most secure messaging tool available, I do so with some reservations.
- It originally handled encrypted SMS messages. There is a long argument about why they broke SMS support on the mailing lists. I find all of the arguments Whisper Systems made specious and unconvincing and cannot ignore the fact that the SMS tool sent messages through the local carrier (Asiacell, Korek, or Zain here). Breaking that meant secure messages only go through Whisper Systems’ Google-managed servers where all metadata is captured and accessible to the USG. Since it was open source, that version has been forked and is still developed, I use the SMSSecure fork myself
- Signal has captured all the USG funding for messaging systems. Alternatives are not getting funds. This may make sense from a purely managerial point of view, but also creates a single point of infiltration. It is far easier to compromise a single project if there aren’t competing projects. Part of the strength of Open Source is only achieved when competing development teams are trying to one up each other and expose each other’s flaws (FreeBSD and OpenBSD for example). In a monoculture, the checks and balances are weaker.
- Signal has grown more intimate with Google over time. The desktop version sign up uses your “google ID” to get you in the queue. Google is the largest commercial spy agency in the world, collecting more data on more people than any other organization except probably the NSA. They’re currently an advertising company and make their money selling your data to advertisers, something they’re quite disingenuous about, but the data trove they’ve built is regularly mined by organizations with more nefarious aims than merely fleecing you.
What to do? Well, I use signal. I’m pretty confident the encryption is good, or at least as good as anything else available. I know my metadata is being collected and shared, but until Jake convinces Moxie to use anonymous identifiers for accounts and message through Tor hidden nodes, you have to be very tech savvy to get around that and there’s no Civil Society grants going to any other messaging services using, for example, an open standard like a Jabber server on a hidden node with OTR.
For now, take a half step up the security ladder and stop using commercial faux security (or unverifiable security, which is the same thing) and give Signal a try.
Maybe at some later date I’ll write up an easy to follow guide on setting up your own jabber server as a tor hidden service and federating it so you can message securely, anonymously, and keep your data (meta and otherwise) on your own hardware in your own house, where it still has at least a little legal protection.
Successful connect to WPA2 with Linux Mint 17
I found myself having odd problems connecting to WPA2 encrypted wireless networks with a new laptop. There must be more elegant solutions to this problem, but this worked for me. The problem was that I couldn’t connect to a nearby hotspot secured with WPA2 whether I used the default config tool for mint, Wicd Network Manager, or the command line. Errors were either “bad password” or the more detailed errors below.
As with any system variation mileage may vary, my errors look like:
wlan0: CTRL-EVENT-SCAN-STARTED wlan0: SME: Trying to authenticate with 68:72:51:00:26:26 (SSID='WA-bullet' freq=2462 MHz) wlan0: Trying to associate with 68:72:51:00:26:26 (SSID='WA-bullet' freq=2462 MHz) wlan0: Associated with 68:72:51:00:26:26 wlan0: CTRL-EVENT-DISCONNECTED bssid=68:72:51:00:26:26 reason=3 locally_generated=1
and my system config is reported as:
# lspci -vv |grep -i wireless 3e:00.0 Network controller: Intel Corporation Wireless 7260 (rev 6b) Subsystem: Intel Corporation Dual Band Wireless-AC 7260 # uname -a Linux dgzb 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
I found useful commands for manually setting up a wpa_supplicant.conf
file here, and for disabling 802.11n here. The combination was needed to get things working.
The following successfully connects to a WPA2-secured network:
$ sudo su $ iw dev ... Interface [interfacename] (typically wlan0, assumed below) $ iw wlan0 scan ... SSID: [ssid] ... RSN: (if present means the network is secured with WPA2) $ wpa_passphrase [ssid] >> /etc/wpa_supplicant.conf ...type in the passphrase for network [ssid] and hit enter... $ sh -c 'modprobe -r iwlwifi && modprobe iwlwifi 11n_disable=1' $ wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf
(should show CTRL-EVENT-CONNECTED
)
(open a new terminal leaving the connection open, ending the command disconnects)
$ sudo su $ dhclient wlan0
(should be connected now)
United’s Magic Trays
@United has new coach trays that are coated with a material that has an amazing coefficient of friction. They are not sticky at all—there’s no adhesion effect—it is all friction. Even low surface energy plastics don’t slide on it at all.
The approximately 75-80° angle in the picture is the point at which the cup topples over itself. It isn’t adhered to the surface and it doesn’t appear to slide at all before toppling.
This would be the perfect coating for a smart phone pad in a car.
Disk Checks for Large Arrays
If you have a large array of disks attached to your server, which is obviously going to be running FreeBSD or OpenBSD if you care about security, stability, and scalability; there are some tricks for dealing with large numbers of disks (like having 227 4TB disks attached to a single host).
Using Bash (yes there are security issues, but it is powerful)
# for i in `seq 0 227`; do smartctl -t short /dev/da$i; sleep 15; done
1Thanks Jared
executes a short smart test on all disks. Smartctl
seems to max out at 32 concurrent tests, so sleep 15
ensures the 3 minute tests are finishing before new ones are executed. If you’re in a hurry, sleep 5
should do the trick and ensure all of them execute.
to get results try something like:
# for i in `seq 0 227`; do echo "/dev/da$i"; smartctl -a /dev/da$i; sleep .5; done
Bulk Fixes
Problem with the disks – need to clear existing formatting?
unmount each disk
# for i in `seq 0 227`; do umount -f /dev/da$i; done
unlock (if needed)
# sysctl kern.geom.debugflags=0x10
Overwrite the start of each disk
# for i in `seq 0 227`; do dd if=/dev/zero of=/dev/da$i bs=1k count=100; done
Overwrite the end of each disk
# for i in `seq 0 227`; do dd if=/dev/zero of=/dev/da$i bs=1m oseek=`diskinfo da$i | awk '{print int($3 / (1024*1024)) - 4;}'`; done
Recreate GPT (for ZFS)
# for i in `seq 0 227`; do gpart create -s gpt /dev/da$i; sleep .5; done
Destroy multipaths
# for i in `seq 1 114`; do gmultipath destroy disk$i; done
Disable multipath completely
# for i in `seq 1 114`; do gmultipath destroy disk$i; done
# gmultipath unload
# mv /boot/kernel-debug/geom_multipath.ko /boot/kernel-debug/geom_multipath.ko.bad
# mv /boot/kernel/geom_multipath.ko /boot/kernel/geom_multipath.ko.bad
Footnotes
1. | ↑ | Thanks Jared |
A Solution for Mosh Scrollback
Mosh is a pretty good tool, almost indispensable when working in places with crappy internet. While it is designed to help with situations like “LTE on the beach,” it actually works very well in places where internet connectivity is genuinely bad: 1500msec RT, latency, 30% packet loss, and frequent drops in connectivity that last seconds to hours, otherwise known as most of the world. On a good day I lose an SSH connection randomly about every 3-6 hours but I’ve only ever lost a Mosh session when my system went down.
It does a lot of things, but two are key for my use: it syncs user input in the background while local echoing what you type so you can finish your command (and correct a typo) without waiting 1500msec for the remote echo to update; and it creates persistent connections that survive drop off of almost any type except killing the terminal application on one end or the other (anything between can die and when it recovers, you catch up). This means compiles finish and you actually get the output warnings…
…well…
…some of them. Because Mosh’s one giant, glaring, painful, almost debilitating weakness is that it doesn’t support scrollback. So compared to tmux or something else that you can reconnect to after your SSH session drops, you really lose screen content, which is a PITA when ls-ing a directory. I mean, it isn’t that much of an efficiency gain to have to type “ls | less” instead of just “ls” every time you want to see a directory.
I found a solution that works for me. I also use Tmux with Mosh because Tmux will survive a dead client and working with Windows client reboots are a fact of life (I know, sad, but there are some tools I still need on windows, hopefully not for much longer).
Tmux has a facility for creating a local log file, which I then “tail -f” using a separate SSH window. If the SSH client disconnects, no loss, I can pick up the log anytime. It is just mirroring everything that the mosh terminal is doing and the scroll bar scroll back works fine. And it is a raw text file, so you can pipe the output through grep to limit what’s displayed to something of interest and review the log asynchronously as, say, a build is progressing.
Although there are some nice advantages to this, when/if Mosh supports scrollback, it’ll be far more convenient having it in the same window, but for now this is the easiest solution I could come up with.
FreeBSD:
# portmaster sysutils/tmux # portmaster net/mosh # ee ~/.tmux.conf -> bind-key H pipe-pane -o "exec cat >>$HOME/'#W-tmux.log'" \; display-message 'Logging enabled to $HOME/#W-tmux.log' -> set -g history-limit 30000 Start a Mosh session (for example with Mobaxterm on windows) # tmux # [CTRL]-b H start SSH session (Mobaxterm or Putty on windows) # tail -f csh-tmux.log ("csh" will be the name of the mosh window - so really "(MoshWindowName)-tmux.log"
You can tmux the ssh session too and still have scrollback and then just reconnect into the same tail command, which preserves the whole scrollback. If you’re on a connection like I’m on, your scrollback logfile will drop off a couple of times a day, but you won’t lose your Mosh session, and it’ll be waiting for you when you’re reminded that you need to see those security warnings from the compile that just scrolled off the Mosh screen forever.