VPN, part 2

Well, the configuration I’d put together before turned out not to work when I was at a hotel and trying it out. I got distracted and didn’t do anything about it for a while, but today I had some time and I started digging around. Guess what? Someone solved this problem ages ago and someone else wrote about it last fall!

I uninstalled openvpn from the pi, just to make sure the bogus configuration got deleted, then ran the road warrior script from https://github.com/nyr/openvpn-install. Boom, it worked.

So, VPN

A couple weeks ago I read an article about a guy who set up a caching DNS server for his home network on a Raspberry Pi. The main thrust of the article was, “Hey, checkitout, Cloudflare has a public DNS at 1.1.1.1 and they pinky-swear promise not to write down what IP address originated the resolution request for wombatporn.com or even overthrowthegovernment.com,” but it did get me thinking about the Pi.

Until reading that article, I thought of the Pi as being a cool (I guess) thing if you wanted to build a robot (to do some dumb thing that I don’t wanna do) or if you wanted to let people on the Internet control your irrigation system (what could possibly go wrong?) but that was just my misunderstanding. The cool thing about the Pi is that it’s a super low-power actual computer running an actual operating system that you can use, and it costs hardly anything.

So, I bought a Pi Zero-W and installed bind on it. Ever since the FCC decided that it’s okay for ISPs to provide different service levels to sites based on their whim, I’ve been thinking about how that really hoses applications that depend on the network being always on. So that got me thinking about store-and-forward and periodic connections to the Internet (psst, there’s this awesome thing called “mosh” that’s pretty cool) and inevitably that raises other questions like, “Who’s looking at your traffic,” and, “What if you don’t want your hotel to be providing all your packets to GCHQ?”

Well, I thought and poked and installed OpenVPN on the Pi and, third time around^*, got a configuration that lets my laptop connect. However, it doesn’t seem to route traffic properly (at all) and I was never a network engineer. This is going to be a heck of a learning experience.

^* It turns out that the micro-USB port on the Pi Zero-W doesn’t actually work. I tried several different connectors on it and nope, keyboard and mouse didn’t work. So I got to do a complete headless setup and spend an afternoon debugging that. Then, the first time around with OpenVPN, the server would start up and then immediately shut down again. Then, the server would start up but the client’s certificate somehow didn’t match what the server expected, so the connection would fail. Regenerate the client, turn off some options in the server, and finally it all connects, but the Internet isn’t reachable over the tunnel. Well, maybe it’ll be better when I’m not on the network I’m tunneling to.

Stupid Email Tricks

I’ve been working on adding play-by-email support to my turn-based game server. The first problem I hit was that the PGP signatures on the server’s messages were invalid when I checked them on my email client. This led to lots of debugging and unit tests in my crypto utility. That’s not really wasted effort, but it also wasn’t the problem.

It turns out that even though the RFC limit on line length is 1000 characters and there are well-known implementation limits that are only slightly lower, there exists somewhere in the chain from Google AppEngine to Apple Mail some chunk of code that inserts newlines into lines that are much shorter. I didn’t do exhaustive testing, but it seems to happen before 80. The perfectly valid signatures were being rendered invalid because somebody was altering the message after the server signed it and handed it off to the transport agent.

The solution I chose was to use WordUtils from commons-text and to wrap the message at 70 characters before signing. This seems to work. It’s just kind of dumb that it’s necessary, but it’s a good reminder that the thing in your inbox may not actually be the thing sent to you by whomever, and that PGP signing your messages is a good idea even if you don’t encrypt them.

Once Again, Most Documentation Sucks

I have been having fun, recently, programming a couple of services that run in Google’s App Engine. One thing they do is maintain some data in that cloud’s version of a database, so one of the important aspects of the services is controlling just who, exactly, is allowed to see or modify the data. I’ve actually got a solution in place that means it all works just fine for me.

Why Crypto?

I know a few people who are concerned about their online privacy, but who don’t have a good handle on what to do about it. There is always some story about some company leaking private data, or some government spying on people, or some “hackers” stealing information for nefarious purposes. So people are worried, but the defensive measures they might take aren’t always clear or easy to understand, let alone implement. I thought I’d write some easier to understand instructions and analysis for my less technically inclined friends.