Authenticating hams over the Internet

This documentation is to create a VPN service that uses ARRL Logbook of the Word (LoTW) credentials to connect.  Instead of requiring the server operator intervention to issue keys etc.  Inspired by OH7LZB's 2013 DCC presentation.   He setup a simple proof of concept service, but only documented the client end of it.

The purpose of this document is to document both the server and client end of this.  I should note that I am implementing it a bit different, as I am not setting up a private CA (simple using the ARRL LoTW CA) and thusly not issuing a server certificate.  This greatly simplifies the process for both the client and server.  You can read the server configuration details below for further information on that.  I have revised OH7LZB's original client documentation below to reflect the difference.

With this info once should be able to set up a service that may be useful to hams who need another public (static) IP or do not have access to the port forwarding to one they are behind.  It's pretty common for mobile internet providers (cellular/3G/4G) to not provide a public IP or a method to forward ports. This could be useful for IRLP, EchoLink, AllStar, D-Star, and other ham radio server operators.   It could use of the 44net public IP address space.  It could provide a publicly routed 44net IP via OpenVPN to licensed amateurs.  Or perhaps you are simply setting up a VPN server so that hams can access a remote HF station etc.

Related concepts:

http://authtest.aprs.fi - Web based authentication demo site (OH7LZB)
https://github.com/hessu/ham-cert-web-demo - Wed authentication Apache configuration and PHP scripts
W3KD and W1RFI predict and speculate what ham radio will be like in 25 years (2012 webinar)
Raspberry Pi Web Based Rig Control
Remote Ham Radio Station Control
Also see ARRL publication "Remote Operating for Amateur Radio"


Client Documentation:

Extracting the certificate from LoTW

LoTW uses a custom file format (.TQ*) to exchange certificates, but after the LoTW certificate process is done and the TrustedQSL software has your certificates, they can be easily copied from TrustedQSL's directories. You'll need four files: the root CA certrificates, your user certificate, an intermediate certificate that was used to sign it, and your private key. The only secret piece of information is the private key - you should not reveal it to anyone at any point, as they could then use services on your behalf, using your callsign.

You will note the TQSL program creates a CALLSIGN.P12 file.  A few VPN clients are starting to support a PCKS12 file. Once such program at the time of writing this is Secure Point.  If your client supports this you won't need to extract the ca.crt, client.crt, and client.key files.  You can simply import the a .ovpn client config file and the TQSL CALLSIGN.P12 file.


Windows

Make copies of those files in another directory, and work on those copies in order to avoid breaking the originals.

The user and intermediate certificates need to be concatenated to a single file named client.crt. The user certificate must be first, followed by the intermediate certificate. That can be done by an ascii editor such as Notepad (Wordpad or Word is likely to mess it up in a big way).

The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31

0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw
-----END RSA PRIVATE KEY-----

Copy-paste that block to a separate file named client.key.

Linux

The user and intermediate certificates need to be concatenated to a single file named client.crt. The user certificate must be first, followed by the intermediate certificate. That can be done by a single command:

cat ~/.tqsl/certs/user ~/.tqsl/certs/authorities > client.crt

The private key needs to be extracted from the YOURCALL file. The file is a regular ASCII text file, and contains a block which looks something like this (just longer):

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,0C7B5495F6A91F31

0xmWfliK/v9U88MFyYtUbteRoAkfVMK6BllcdID3pZzmdykHaPLZUjXOCUh3vFUX
1bjnYwXpLX/CxgZ6NIxQIk7jMjL3iaP5SkWzCswqi9mCO+zHxuS6PWq7YwbWNFgo
7smNcko1yTp7f/VbS4CZ5kgIF9kCgNaiqdxq+v0IcphQHRR4xjfLpBQ4ckYOi4nC
jqFR1BitwBL4K2JeE9PGUkkUBwvU4oOi9PGChuoxMXs8PwKi/dZTmSWM7kOfMiBw
-----END RSA PRIVATE KEY-----

Copy-paste that block to a separate file named client.key. If you're going to open up the original private key file in a text editor, it's a good idea to make a backup copy of that file first in case of an accidental corruption of its contents.

The root ca certificate can simple be renamed ca.crt.

Configuring The VPN

Windows: OpenVPN

  1. Download the Windows Installer, it's free and open source.
  2. Run the installer to install it.
  3. In Start menu, under OpenVPN => Shortcuts you'll find an entry named OpenVPN configuration file directory. Open it, and move the client config file to the configuration file directory.
  4. Place ca.crt, client.crt and client.key, which were created previously, in the configuration file directory.
  5. Ensure that the server certificate checking options are disabled (ns-cert-type/remote-cert-tls)
  6. Run the OpenVPN GUI from the desktop icon or start menu. A new icon will appear in the lower right corner (two computers with red screens + a globe on the side).
  7. Right-click the OpenVPN toolbar icon and select Connect.

If you chose to encrypt your private key with a password (or passphrase) when initially applying for a LoTW certificate and generating the Certificate Request, OpenVPN will ask you for that password when connecting.

To rephrase: When OpenVPN says "Enter Password", the password being asked is the one you picked when you first applied for a LoTW certificate. It's not something the VPN operator knows (or should know). It's not the one you got on a postcard. Only you have ever been aware of that password (hopefully).

Linux: OpenVPN

Ubuntu 15.10

Here is steps to install the VPN to Ubuntu 15.10 destop. Install OpenVPN plugin to network manager. Open terminal and type

sudo apt-get install network-manager-open vpn-gnome

Then add VPN-connection information to NetworkManager

  1. Click network manager icon on taskbar
  2. Edit connections
  3. Add
  4. OpenVPN
  5. Create
  6. Click Advanced
  7. Click OK
  8. Click Save
  9. Click Close

Now you can connect to VPN

  1. Click network manager icon on taskbar
  2. VPN connections -> AMPRNet
  3. Connection should be established

Linux (Raspberry PI): OpenVPN

Log in to Raspberry Pi console. Install openvpn software.

sudo apt-get install openvpn

Create openvpn client configuration file with your favorite editor to /etc/openvpn/client.conf

client
dev tun
proto udp
remote IP-ADDRESS-OF-SERVER 1193
resolv-retry infinite
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 3

Extract your client certificate and key as explained above section Extracting the certificate from LoTW. Copy your certificate files ca.crt,  client.crt and client.key to /etc/openvpn/ . 

Restart openvpn

service openvpn restart

All done.


Server Documentation:

This assumes installation of openvpn on a Linux platform.  

apt-get install openvpn openssl

After the install finishes, you will need the 'easy-rsa'-tool to generate the Diffie Hellman dh1024.pem file  It's easiest to copy the example folder and work from there.

cp -R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn
cd /etc/openvpn/easy-rsa/2.0

In our example server configuration file:

/etc/openvpn/server.conf
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 44.92.21.192 255.255.255.192
ifconfig-pool-persist ipp.txt
;Split tunnel
;push "route 44.0.0.0 255.0.0.0"
;Full tunnel
push "redirect-gateway def1"    
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

Files explained:

- ca.crt = The latest LotW Root CA cert

            certs\root* (no need to break them apart)

- server.crt = Your personal LotW cert concatenated with the intermediate that signed it.

            certs\user* + certs\authorities* (if multiple concatenated authorities, you will need to break them apart and choose one)

Quote:

OH7LZB>"I don't think that will work. Your personal LotW cert does not contain
"key usage" parameters that would allow it to be used as a server
certificate.

You should set up a private CA and have it issue a server certificate to
be used for the server cert, and the client should use that private CA's
certificate as the "ca cert"."

NQ1E> Checking for server key usage in OpenVPN is an optional configuration
of the client.  Going through the extra steps of creating your own
root CA and distributing it to your clients is only necessary if you
want your them to turn that check on.  The only benefit of doing that
would be to prevent other LotW certificate holders from being able to
impersonate your server after a successful man-in-the-middle attack on
your external network traffic or DNS.  They wouldn't be able to do
that to you without exposing their own identity (by proving they have
access to the private key of their LotW cert)."

KB9MWR> Cory is correct.  I just followed his steps and the openvpn server
started up fine.  When I went to connect using my windows Securepoint
client I got a TLS error till I went in and unchecked the server
certificate box.  Else ensure ns-cert-type/remote-cert-tls is not declared 
in the client config

Still a little confused on what OH7LZB is describing.  But I think it 
equates to:

./build-ca

./build-key-server server

Do I just discard the ca.crt that the first step produces and continue
to use the certs\root file?




- server.key = The private key associated with your personal cert

            keys\YOURCALL* will need to be cleaned to remove XML

- dh1024.pem = The Diffie Hellman must be defined/exist.

            You build this using the easy rsa tool  ./build-dh


*References are to the Windows TQSL program:
C:\Documents and Settings\your-username\Application Data\TrustedQSL\

The best way to use this with 44net IP's would be to coordinate with network operator that can provision BGP routing.  If you have a smaller number of VPN clients and don't have those connections you can connect to the central router at UCSD using IPencap.  This adds an unnecessary second point of failure, trip time and reduced throughput however.

#!/bin/bash
sysctl -w net.ipv4.ip_forward=1
modprobe ipip
# Routing bootstrap for the above OpenVPN server
# Simplistic test setup to outside internet via UCSD
#
ifconfig tunl0 up 44.92.21.129 netmask 255.255.255.255
ip route add default dev tunl0 via 169.228.66.251 onlink table 44
ip rule add from 44.92.21.192/26 table 44
#

You'll also need to have entries in the Ampr DNS to achieve world routeable addresses, and obviously a gateway IP defined in the Ampr Portal.


Go back to the TCP/IP page.

Go to the WAPR Home Page and index