Blargh

I've previously blogged about a secure connection between browser and proxy . Unfortunately that doesn't work on Android yet, since except if you use Google for Work (an enterprise offering) you can't set Proxy Auto-Config. This post shows you how to get that working for Android. Also it skips the stunnel hop since it doesn't add value and only makes Squid not know your real address. I'm here also using username and password to authenticate to the proxy instead of client certificates, to make it easier to set up. Hopefully this feature will be added to Chrome for Android soon ( bug here ) but until then you'll have to use the Android app Drony . First, why you would want to do this You have machines behind NAT, and a proxy that can see the inside while still accessible form the outside This way you can port forward one port from the NAT box to the proxy, and not have to use different ports everywhere.

This is just a quick note on how to create .icc colour profiles in Linux. You need a colour calibrator (piece of hardware) for this to be useful to you. #!/bin/sh NAME=$1 COLOR=$2 DESC="Some random machine" QUALITY=h # or l for low, m for medium set -e dispcal -m -H -q $QUALITY -y l -F -t $COLOR -g 2.2 $NAME targen -v -d 3 -G -e 4 -s 5 -g 17 -f 64 $NAME dispread -v -H -N -y l -F -k $NAME.cal $NAME colprof -v -D $DESC -q m -a G -Z p -n c $NAME dispwin -I $NAME.icc

Let's say you don't have a TPM chip, or you hate them, or for some other reason don't want to use it to protect your SSH keys . There's still hope! Here's a way to make it possible to use a key without having access to it. Meaning if you get hacked the key can't be stolen. No TPM, but key can't be stolen anyway? Surely this is an elaborate ruse? Well yes, it is. My idea is that you essentially bounce off of a Raspberry Pi. But doing that straightforward is too easy. I've instead made an SSH proxy, and will show you how to automatically bounce off of it. You could do the same by setting up a second SSH server (or the same one), and hack around with PAM and a restricted shell. But this solution can be run as any user, with just the binary and the set of keyfiles. Very simple. The goal here is to log in to shell.foo.com from your workstation via a Raspberry Pi. The workstation SSH client presents its SSH

The wonder of UNIX is that you can delete running binaries and loaded shared libraries. The drawback is that you get no warning that you're still actually running old versions. E.g. old heartbleed -vulnerable OpenSSL. Server binaries are often not forgotten by upgrade scripts, but client binaries almost certainly are. Did you restart your irssi? PostgreSQL client? OpenVPN client ? Find processes running with deleted OpenSSL libraries: $ sudo lsof | grep DEL.*libssl apache 17179 root DEL REG 8,1 24756 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 Or if you're extra paranoid, and want to make sure everything is using the right OpenSSL version: !/bin/sh set -e LIB="/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0" if [ ! "$1" = "" ]; then LIB="$1" fi INODE="$(ls -i "$LIB" | awk '{print $1}')" lsof | grep libssl.so | grep -v "$INODE" A few

In my last blog post I described how to set up SSH with TPM-protected keys. This time I'll try to explain how it works. SRK The SRK is a public key pair that is the main secret inside the TPM chip. It is always generated by the chip, and the private key cannot be read or migrated. In order to use the SRK key with any operation, the SRK password must be supplied. The SRK password is just an access password. It's not related to the key itself. The SRK password is usually set to the Well Known Secret (20 null characters), or sometimes the empty string, or something silly like "12345678". There is not much point in having a good SRK password, since you probably have to store it on disk somewhere anyway, to allow TPM operations by daemons. If you want a password then you probably want to set that per key, not chip-wide like the SRK password is. Key generation The stpm-keygen binary asks the TPM to generate a

Not long after getting my TPM chip to protect SSH keys in a recent blog post , it started to become obvious that OpenCryptoKi was not the best solution. It's large, complicated, and, frankly, insecure. I dug in to see if I could fix it, but there was too much I wanted to fix, and too many features I didn't need. So I wrote my own. It's smaller, simpler, and more secure. This post is about this new solution. Why not Opencryptoki? It generates at least some keys in software. As I've explained earlier, I want to generate the keys in hardware . It generates migratable keys. This is hardcoded, and some people obviously want migratable keys (for backup purposes). So a fix would have to involve supporting both. Opencryptoki has no way to send such parameters from the command line key generator to the PKCS11 library. So not only would I have to implement the setting , but the whol

A Hardware Security Module (HSM) is any hardware that you can use for crypto operations without revealing the crypto keys. Specifically I'm referring to the Yubikey NEO and TPM chips , but it should apply to other kinds of special hardware that does crypto operations. I'll refer to this hardware as the "device" as the general term, below. Some background When describing the Yubikey NEO I'm specifically referring to its public key crypto features that I've previously blogged about, that enable using Yubikey NEO for GPG and SSH , not its OTP generating features. To generate keys for these devices you have two options. Either you tell the device to generate a key using a built in random number generator , or generate the key yourself and "import" it to the device. In either case you end up with some handle to the key, so that you command the device to do a crypto operation using the key with a given handl