darkness

I needed to find out how to revoke some of the certificates we’re using for our IPsec VPN. Turns out it’s pretty easy with openssl ca:

1. Find certificate that you want to revoke. You have to have the certificate. When you use a setup akin to that used by the CA script that ships with OpenSSL, you should have a newcerts directory (i.e., demoCA/newcerts by default). index.txt holds information about which file in that directory corresponds to which certificate.
2. Now that you’ve got the certificate file, openssl ca -config conf/openssl.cnf -revoke newcerts/XX.pem. newcerts/XX.pem is the certificate you want to revoke. If you have your own configuration file, specify it like above; otherwise, leave that parameter off. I find it useful to make my own configuration file to say where the CA root directory is located.
3. I’m guessing that you can do the above for each certificate you want to revoke, and then…
4. Generate the certificate revocation list (CRL) with openssl ca -config conf/openssl.cnf -gencrl -out crl.pem. Same instructions apply WRT -config. I’m pretty sure this CRL will contain information about every certificate you’ve ever revoked within this CA, not just the certificates you revoked in steps 2-3.

Now you’ve got a CRL in crl.pem. For FreeS/WAN and variants (search engine words: OpenSwan, strongSwan) toss crl.pem in /etc/ipsec.d/crls and ipsec auto --rereadcrls.

There is a CRL update date in each CRL. I’m not sure how important this is: will I get warnings that the CRL needs to be updated? Will the CRL actually stop working when it’s out of date? (That seems dumb, so lets hope that’s not the behavior: better to have stale revocations rather than forgetting about all revocations.)

Trying to talk to a serial device spitting out DEADBEEF\n wasn’t working from Python (within Emacs) on Cygwin. Turns out the trick was setting the environment variable CYGWIN=reset_com. All of a sudden, I can do:

import serial
port = serial.Serial(0, baudrate=115200)
print port.readline()

without incident. (To clarify, from bash for testing this I just ran CYGWIN=reset_com emacs and then Emacs started Python, so Python saw this variable.)

I say Strongswan, but really FreeS/WAN, OpenSwan, no difference I suspect.

I’ve had this problem with Cisco people telling me “well, just put hosts X, Y, and Z in your access list,” when *S/WAN just gives me a single left/rightsubnet parameter. My fears were realized: this means they want a separate connection description in ipsec.conf for each access list entry.

I’m thinking the PIX configuration looks something like (excerpt):

access-list 100 permit ip 10.0.0.1 255.255.255.0 192.168.0.100 255.255.255.0
access-list 100 permit ip 10.0.0.1 255.255.255.0 192.168.0.101 255.255.255.0
access-list 100 permit ip 10.0.0.2 255.255.255.0 192.168.0.100 255.255.255.0
access-list 100 permit ip 10.0.0.2 255.255.255.0 192.168.0.101 255.255.255.0
crypto map mymap 10 match address 100

Which, to me, says “10.0.0.1 and 10.0.0.2 can access 192.168.0.100 and 192.168.0.101.” So your ipsec.conf might look something like:

conn pix-1-1
    also=pix-1
    also=you-1
    auto=start

conn pix-1-2
    also=pix-1
    also=you-2
    auto=start

conn pix-2-1
    also=pix-2
    also=you-1
    auto=start

conn pix-2-2
    also=pix-2
    also=you-2
    auto=start

conn pix-1
    also=pix
    rightsubnet=192.168.0.100/32

conn pix-2
    also=pix
    rightsubnet=192.168.0.101/32

conn you-1
    leftsubnet=10.0.0.1/32

conn you-2
    leftsubnet=10.0.0.2/32

conn pix
    authby=secret
    left=1.2.3.4
    leftnexthop=%defaultroute
    right=5.6.7.8
    rightid=@the.pix.id
    rightnexthop=%defaultroute
    keylife=86400
    pfs=no

Needless to say, this is not a fun-looking configuration. It is long, and can’t possibly scale well.

Some notes:

• *S/WAN is the left, PIX is the right. This might need to be the case anytime you want to talk to a PIX.
• At least you only have to have the actual IP addresses listed once. I’m thinking I can make this go better with policies.
• authby=secret because I’ve never had a PIX admin give me anything other than a PSK.
• rightid is apparently in some “RSA key”? Per the PIX admin I was talking to. I doubt this, in retrospect, but it is important to use the right ID when talking to the PIX. Don’t forget to list this ID in /etc/ipsec.secrets for the key you’ll be using.
• Around the same time I started seeing messages about the wrote ID being sent by the PIX (not the IP, as is the default without something like rightid), I also started getting key lifetime errors. The person I was working with said his was explicitly set to one day (86400 seconds). Don’t know if this is a default or not.
• No PFS on PIX, at least not by default.

I wanted to take some completely legitimate AVI files and burn them to DVD so I could watch them on the DVD player/TV in the living room. Up until now I’ve been using NeroVision Express to do this. After burning to DVD with NVE, though, I noticed the DVD audio and video were out of sync (I think the video was delayed compared to the audio).

I dug around all over. There didn’t even appear to be a straightforward way to do this… at least not a recent one, one that didn’t involve command line tools (command line tools, with lots of options, in Windows where I’m not used to this sort of thing). Eventually I did settle upon the AVI to DVD guide at afterdawn.com.

My AVI had Xvid video and two channel AC3 audio. I used VirtualDubMod to extract the AC3 out, then TmpgEnc to encode the video, then Ifoedit to recombine the two into VOBs. But I wanted menus too, so I ended up pointing NVE at the VOBs and used it to actually burn the DVD with a menu. Let me speak about the times involved here: VDM quickly demuxed the stream, TmpgEnc took 12 hours for a 45 minute video, then NVE took a reasonably long time (say, 20-30 minutes?) to “read” the VOB files. Burning took only about 10 minutes. The result? Audio/video were synced, but the AVI was in 16:9 and TmpgEnc encoded in 4:3, so the aspect ratio was off.

Next I tried a similar procedure and instead had a friend use Cinema Craft SP to encode. That encoder was way faster: it only took about 90 minutes to encode the 45 minute clip. (I don’t know the processor in this machine, to be honest, but it was a pretty recent laptop in both cases, almost identical speeds I think.) This time I got the aspect ratio right… I think. The bars at top/bottom (playing 16:9 on my 4:3 TV) didn’t look big enough. Process was the same otherwise. Everything looked fine here.

My next experiment is using VirtualDub-MPEG2 to make a new AVI, using direct stream copy on both audio and video, in hopes that just “remuxing” the AVI is enough to fix whatever NVE’s damage is, then just have NVE start on these “remuxed” AVIs. I say “remuxed” in quotes, because I’m not sure how different the output AVIs are from their source when using direct stream copy for everything. An AVI I transcoded/burned yesterday with this method (VD then NVE), from the same set of AVIs with desynced audio/video, seems to be properly synchronized. For a real test I’d want to go back and try this method on one of the AVIs I know for a fact to be desynced when transcoded by NVE; but encoding takes a long time (probably 2-3 hours for a 45 minute AVI with NVE on multi-pass VBR) and I’m not around all the time to start/stop, eject/insert, etc. So when I get a burn started, I like it to be for something I actually want to watch.

BTW, the AVIs were synchronized just fine when played directly on a PC, so I assume the desynchronization is an effect of the transcoding that NVE does. GSpot and AVIcodec are useful utilities. Everything seems to say the AVIs have 0 delay on the audio stream.