Blargh

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...

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...

STOP! There is a better way. this post explains a simpler and more secure way. Update 2: I have something I think will be better up my sleeve for using the TPM chip with SSH. Stay tuned. In the mean time, the below works. Finally, I found out how to use a TPM chip to protect SSH keys. Thanks to Perry Lorier . I'm just going to note down those same steps, but with my notes. I've written about hardware protecting crypto keys and increasing SSH security before: GPG and SSH with Yubikey NEO Benchmarking TPM backed SSL TPM backed SSL SSH certificates but this is what I've always been after. With this solution the SSH key cannot be stolen. If someone uses this SSH key that means that the machine with the TPM chip is involved right now. Right now it's not turned off, or disconnected from the network. Update: you need to delete /var/lib/opencryptoki/tpm/your-username/*.pem , because otherwi...

I'm a big fan of hardware tokens for access. The three basic technologies where you have public key crypto are SSH, GPG and SSL. Here I will show how to use a Yubikey NEO to protect GPG and SSH keys so that they cannot be stolen or copied. (well, they can be physically stolen, of course). Let's hope pkcs11 support is coming, so that SSH support improves and SSL keys can also be protected. Parts of this howto are all but copied from YubiKey NEO and OpenPGP . I complete it with some details and the SSH parts. GPG GPG normally keeps your private key encrypted using your password. If your keyring is stolen someone can brute force your password and from there decrypt all your files. If someone steals your keyring you should revoke the key as soon as possible, but assuming this revokation gets to all interested parties this will only protect new messages from being encrypted to this key. Old encrypted files could be decrypted by ...

Last time I was at a hacker conference I for obvious reasons didn't want to connect to the local network. It's not just a matter of setting up some simple firewall rules, since the people around you are people who have and are inventing new and unusual attacks. Examples of this would be rogue IPv6 RA and NDs, and people who have actually generated their own signed root CAs. There's also the risk (or certainty) of having all your unencrypted traffic sniffed and altered. For next time I've prepared a SheevaPlug computer I had laying around. I updated it to a modern Debian installation, added a USB network card, and set it up to provide always-on VPN. This could also be done using a raspberry pi, but I don't have one. Always-on VPN is where you have NO network access unless your VPN is up, and then ALL traffic goes through the VPN. By setting up a plug computer as a VPN client you can just plug in an unprotected computer ...

A few months ago I was strolling in the Debian bug tracking system and found a curious bug filed against Arping , a program I maintain. It said that unlike Arping 2.09, in Arping 2.11 the ARP cache was not updated after successful reply. I thought that was odd, since there's no code to touch the ARP cache, neither read nor write. Surely this behaviour hasn't changed? I tried to reproduce the behaviour and sure enough, with Arping 2.09 the arp cache is updated, while with 2.11 it's not. $ arp -na | grep 192.168.0.123 $ # --- First try Arping 2.11 --- $ sudo ./arping-2.11 -c 1 192.168.0.123 ARPING 192.168.0.123 60 bytes from 00:22:33:44:55:66 (192.168.0.123): index=0 time=1.188 msec --- 192.168.0.123 statistics --- 1 packets transmitted, 1 packets received, 0% unanswered (0 extra) $ arp -na | grep 192.168.0.123 $ # --- Ok, that didn't change the ARP cache. Now try 2.09 --- $ sudo ./arping-2.09 -c 1 192.168.0.123 ARPI...

If you split up code into different libraries you can get a diamond dependency problem. That is you have two parts of your code that depend on different incompatible versions of the same library. Normally you shouldn't get in this situation. Only someone who hates their users makes a non backwards compatible change to a library ABI. You don't hate your users, do you? (just kidding about hating your users.) Disclaimer I thought I'd dive into this problem as a weekend project. Don't rely on this article as a source of truth, but please correct me where I'm wrong. I'm not an expert in creating shared libraries, and it's much harder that it would first appear. The existence of libtool proves that. Example project described can be found here . Multiple versions of the same library The lovely land of modern Unix will allow you to have multiple versions of the same library installed at th...

The short version of the problem and solution I will describe is that while TCP gets up to speed fairly fast, and "fast enough" for many uses, it doesn't accelerate fast enough for short-lived connections such as web page requests. If I have 10Mbps connection and the server has 10Mbps to spare, why doesn't a 17kB web page transfer at 10Mbps from first to last byte? (that is, when excluding TCP handshake, HTTP request and server side page rendering) This is pretty Linux-focused, but I'll add pointers for other OSs if I see them. Short version This will get a bit basic for some people, so here's the short version. Make sure you measure the effect of changing these settings. Don't just increase them and think "more is better". On receiver side (requires kernel version 2.6.33 or newer (and a fairly new iproute package. iproute2-ss100519 works). Use your default route instead of "x.x.x.x"): i...

Yubico and their products are awesome. That pretty much sums up this blog post but I'm going to go on anyway. If you're thinking of introducing two-factor authentication to your company, or you're using something that's fundamentally broken (like RSA SecureID) you simply must at least take Yubikeys into consideration. When I say that SecureID (and others) are fundamentally broken what I mean is that when (not if, as recent history has shown) RSA (the company) is broken into YOUR security is now compromised. When I first used SecureID and found out that you as a customer aren't in control of your own keys my first thought was "well that's just stupid". Why are you giving the keys to the kingdom to someone else? Enter Yubikeys. They just beat SecureID in every way (almost). Benefits: Open specification. You can set your own keys (secrets) and don't have to show them to a third party who...

The documentation for OpenSSH certificates (introduced in OpenSSH 5.4) are, shall we say, a bit lacking. So I'm writing down the essentials of what they are and how to use them. What they are NOT They're not SSH PubkeyAuthentication In other words if your .pub file doesn't end in -cert.pub and you haven't used ssh-keygen -s, then you aren't using certificates. They're not SSL Still the same SSH protocol. They're not PEM, x509 ASN.1 or any other insane format This means you cannot get your keys signed by Verisign or any other root CA. And you cannot use multiple levels of CA. They're not easy to google for Most hits will be about normal pubkey authentication. Some will be about older patches to one SSH implementation or another that added some form of PKI, even x509 support. You'll probably have the most luck googling for "ssh-keygen -s" (with quotes). What they do Sign host keys ...

I've started writing a replacement for SSH. Why? Because SSH has some drawbacks that sometimes annoy me. I also wanted an authentication scheme that's more similar to SSL/TLS than what SSH does. With tlssh you don't specify username or password, you simply connect to the server using a client-side certificate to log in as the user specified in the certificate. No interaction until you reach the shell prompt on the server. Of course you can log in using a public key with SSH, but it's only a public/private key pair, there's none of the PKI that SSL has. Specifically, what I was missing in SSH was: Expiring keys, both login-keys and server certificates CRL s (Certificate Revocation Lists) - wouldn't it be nice to just revoke the all certificates that were on a compromised machine and they'll suddenly be unusable everywhere? (I will add OCSP too. Same thing but more "online") Pureness. Not all th...

Yes clipboard, not keyboard. I've made a clipboard sniffer for X called ClipSniff. It periodically saves whatever is in the clipboard (both the "PRIMARY" and the "CLIPBOARD") into a sqlite database. git clone http://github.com/ThomasHabets/clipsniff.git It wasn't that hard when you knew where to look. You just: Connect to the X server. XOpenDisplay() Create a window (you don't need to display it). XCreateSimpleWindow() Ask the X server who owns the PRIMARY and CLIPBOARD atoms, and ask that window to send you the data. XInternAtom() , XConvertSelection() Wait for the reply event. Loop of NextEvent() Helpful links when coding Xlib Minimal XGetWindowProperty Example Xlib Programming Manual (O'Reilly & Associates, Inc.) X Selections, Cut Buffers, and Kill Rings (jwz) X Windows Copy-Paste mini HOWTO (Stelios Xathakis)

I was recently asked why autotools was so good. I thought I might as well post what I answered. Small differences There are always some small differences between OSs. For example if uint64_t exists or if it's called u_int64_t . Instead of doing an #ifdef __linux__ with lots of garbage and another block of #ifdef __OpenBSD__ you can solve the problem right. Otherwise you'll end up with duplicated sections of defines and other things like: 1 2 3 4 5 6 7 8 9 10 11 12 #if __FreeBSD__ # define foo bar # define OStype joonix #elif defined __OpenBSD__ # define foo bar # define OStype joonix #elif defined __linux__ # define foo BAZ # define OStype joonix #else # error "Unknown OS, please add your OS here and define the things that the other OSs do above" #endif Supported interfaces Even if an OS doesn't support some API (such as sendfile() or openpty() ) today, it may do so in a year. It would be a shame if your p...

I've always wanted to be able to move a process from one terminal to another. For example if I've started a long-running foreground process (such as irssi or scp) outside of a screen and I have to log out my local terminal. I looked around and there doesn't seem to be any way to do this. There is a program called retty that I found later on that sort of does this, but it only closes and re-opens stdin/out et al. It doesn't seem to do full terminal handling. Nor does it seem to detach the original terminal. It only allows you to peek into the process, control it for a bit, and then hand it back. If you shut down the original terminal you're still screwed. Attempt 1: pass the fd for the real pty I thought I could ptrace() attach to the process, inject code to dup2() onto stdin/out/err, and do some ioctl()s and that would be that. No such luck as we shall see. The easiest (and most portable way) to do it would be to dlopen() a shared libr...

I'm trying to force a program not to buffer its output to stdout. Any program, all programs. It can't involve changing the source code or depending on weird or unportable stuff. It should be possible. It seems like I'm missing something obvious, but I can't figure out what. Some background info I've written a program ( ind ) that puts itself between a subprocess that it creates and the terminal. It acts as a filter for the output from the subprocess. Like this example, where it prepends "stdout: " to all lines that the subprocess prints to standard output: $ echo hej hej $ ./ind -p 'stdout: ' echo hej stdout: hej The dataflow is, from left to right: echo (the subprocess) -> pipe(2) -> ind -> the terminal (stderr runs through a separate pipe(2). Stdin has not been played with yet) So far so good. The problem is that the subprocess' libc (not the kernel) buffers all output using s...