OpenConnect

The organization I work for uses a Cisco ASA VPN network appliance for managing
remote VPN access to the internal network. This is a common and popular choice
for many organizations. When you access it remotely for the first time, it
wants to detect your platform and then download and install the AnyConnect
Secure Mobility Client. This client application is how you then connect and
authenticate your VPN connection. Our organization assumes that everyone in
the world uses Microsoft Windows all the time. Of course, why not?
Anyway, the Java-based client and installer do not work too well on Linux
for some reason. And our organization in particular is not too keen on helping
anyone who is not using Windows. They do not prohibit the use of Linux or other
operating systems, but they will not help you with them either.

So a couple years ago, whatever black magic they had been performing to make
Linux clients work stopped. Our team uses Linux and we were suddenly locked out
of VPN access. And they did not care despite out best pleading. In fact, their
final, formal answer on the matter was to "just use Windows". Nice. Thanks.

So we started digging around the interwebs and found that a lot of other Linux
users had the same story in regards to the Cisco AnyConnect client. And some of
them had gotten fed up enough to devise their own solution. We discovered a
project called 'openconnect'. This is an open-source program that is compatible
with the Cisco VPN appliance.

OpenConnect is not part of most Linux distros including RHEL, but you can now
get an rpm from EPEL. You can also build it from source if you desire.

OpenConnect uses OpenSSL which must be able to validate the signing chains on al
l the certificates involved. Our organization uses smart cards with security
certificates, so a VPN connection involves you presenting a client-side SSL
certificate. This means you need to have all the signing certificates up to the
root installed in your local store.

These go under the /etc/pki/ca-trust/source/anchors directory.
You simply copy the .cer certificate files there and then update using the
'update-ca-trust' command.

Then the command line to use openconnect looks like this.
You will need root privilege.

   sudo openconnect -c 'pkcs11:token=LAST.FIRST.MIDDLE.number;id=%02' https://vpn.foo.org

It prompts for the sudo password and then for the PIN on the smart card and
then it connects.

One tricky point is the 'pkcs11' parameter. You need to see exactly what your
token name and id number on the card are so you can reference them to the
openconnect command parameters.

With your card inserted, you can use 'p11tool' to get a list of all the
specific certificates on the card and their 'id' values.

   p11tool --list-tokens

   p11tool --list-all-certs pkcs11:token=LAST.FIRST.M.123456789

It should list some number of "objects", which are the certificates on your
card. If you don't know which one of these the VPN is expecting for
authentication, you can always use some trial-and-error experimenting.
There are not so many on there that this is prohibitive.

Now look at the 'ID' field for that object, e.g. "00:02".
You need to replace the "00:02" with "%02" in the 'id' portion of the pkcs11
string.

If you get the 'id=' syntax wrong, you will get some non-obvious errors from
openconnect and then a WebVPN cookie error and no connection.

We also ran into difficulty with some applications communicating over the VPN.
The problem is that the VPN tunnel uses DTLS over UDP. This requires a little
overhead for some protocol headers and starts eating up your MTU.
Your application has no idea it's using a somewhat limited connection and does
not account for this. So if its protocol also has some headers, you may have to
tweak the MTU down to account for that.

You can tweak the MTU on the tun0 device established by openconnect.

   sudo ip link set mtu 1402 dev tun0

An example is newer versions of OpenSSH whose key exchange algorithms have
rather large payloads. When these get fragmented over the DTLS/UDP connection
while communicating with an older version of OpenSSH on the server side,
something goes wrong, the key exchange stalls, times out and then fails.
You can edit the SSH config to not offer so many choices in the key exchange,
but it is simpler to bump the MTU down until it's happy. This is easily done by iterative experiments until it works.

Other authentication factors

In computer security, when we talk about authentication factors it is usually
the traditional "something you know", "something you have" and "something you
are" (i.e biometrics). There are other things being used as types of factors
more recently.

First up are behavioral factors, which are they way you do something.
This must be something that can be reasonably uniquely attributed to you and
only you. Some examples are your keyboard typing patterns, touch surface swiping
patterns, maybe how you typically interact with some graphical user interface.
The point is that, in theory, no two people use these interfaces exactly the
same way and that means the uniqueness can be used as a form of authentication.

Some systems are even using this as a means of "continuous authentication".
After your initial access to the system, the behavior is tracked throughout
use and if it suddenly doesn't look like you any more, then you could be asked
to reauthenticate. I have to wonder how robust this really is. Unlike a
cryptographically strong hash, we don't have any way to prove anything about it.
I think it's just too new for that yet. But I do agree that it is a promising
approach. The overly paranoid might not like it. It could be seen as yet another
intrusion into their privacy and another way they could be tracked or
identified. The EFF has a project that demonstrates just how unique a
fingerprint your web browser presents regardless of which site or page you are
visiting. If multiple sites started sharing and correlating behavioral
measurements, that is one more way you can be tracked across multiple systems
to build a bigger profile of you.

Another factor is location. This could be a geographical location or a logical
network location (i.e. only from certain IP addresses or networks). These days,
a lot of computers either have GPS or an estimate of position based on knowing
where your general area your IP address is in. I play Blizzard games through
their Battle.net site and if they see me come in from a different IP address
than I usually do (maybe I'm visiting relatives and using their computer),
it will challenge me for extra authentication to make sure someone else has not
hacked my account. Of course, it is possible to spoof these mechanisms if you
can hack your local device to report the expected location or spoof the IP
address.

A slight variation on this is the "remember this device" mechanism.
You go through a full authentication once and then tell the site that this
device is a trusted device. Future logins do not ask for all the authentication
factors. This is a convenience for your home computer, tablet, phone, etc.
You assume the risk by protecting access to your devices in trade for more
convenient access. Once again we see the balance between usability and security.
I have had difficulty with this mechanism over time. The "remembering" tends
to fail under various circumstances like software upgrades, maybe an eventual
timeout and so on. This tends to happen with no notice and after you got used
to the convenience it is a jarring pothole in the usability road.

Multi-factor Identification

In the security realm, we talk a lot about multi-factor authentication, but you
can also use multiple factors for identification. Why would we care about that?
If a guy shows up and claims to be "Joe", we take his word for it as long as he
can successfully authenticate using Joe's password, token, biometric, etc.
In other words anyone possessing matching authentication factors is assumed to
be Joe. But maybe he stole Joe's factors? Even some biometrics have been stolen
in both fiction and the real world. Remember Wesley Snipes stealing a guy's
eyeball in the movie Demolition Man? He holds it up to the iris scanner on a
ball-point pen. Nice. And a couple years back, I recall an article about some
thieves cutting off a guy's finger to steal his car whose locks and/or ignition
were biometric fingerprint scanners. So much for convenience. A key can be
replaced. Just saying.

In some applications, we only care about proper authentication and just take the
identification for granted. This is the case when logging into any computer
system, web site, and so forth. But in other cases, it may be really important
to correctly identify someone. In fact, there may not even be any authentication
involved if it's not a security situation. A family member was recently
hospitalized and during the admission process we discovered the hospital had
recently upgraded their check in process with a palm vein scanner. My first
instinct was to figure it had to do with authorizing access to health records.
No, it was to be used in any future admissions for positive and more accurate
patient identification. I thought why not use a fingerprint or something?

It turns out that the palm vein scanning is particularly useful in a medical
environment. The scanner works by using an infrared wavelength to record a
picture of the vein pattern in your palm. This pattern remains the same
throughout your life and can be read even through damaged skin (cut, burned, etc
). And a biometric works even if you are unconscious and there's no one else
present who knows you. So unless your entire hand is damaged, it makes a really
good choice. This particular scanner worked only on the right hand. I asked the
admissions person what about people who were missing their right hand? She sort
of stumbled on that and said they would "figure something out". :)

From a security perspective, it is highly unlikely that someone would want to
obtain a false admission to the hospital. Do you know why Joe was supposed to
be checking in? Maybe you're about to have your heart replaced. Yeah, I don't
see anyone abusing this. And you really don't need multi-factor identification
in a computer application. It would really just end up serving as yet another
authentication factor. Suppose you had to present a user name and biometric first
and then give the authentication factors associated with that pair. How is that
any different from giving only a user name and then one more authentication
factor? It's not. So identification is about getting the correct record, not
about whether you should or shouldn't. In the hospital case, the admissions
person already has permission, so they don't need you to authenticate anything.