[Swan] Security

[Paul Wouters]

On Tue, 2 Jan 2018, Colony.three wrote:

> There are those who say that Strongswan is 'more secure' than Libreswan.

These kind of vague "those who say" statements are kind of useless,
unless you cite actual facts, so I'll refrain from further comments
on this. If you have specific concerns or praise, let me know.

>  Personally, I wouldn't know.  But I do know that
> Strongswan has the option of lattice encryption, which is a strong indicator to me. (... although, their Android app doesn't
> support it)  And they have a special Android app.

The IETF, and specifically the CFRG, has not made any decisions on which
post-quantum protocols to pick. While experimentation is good, this is
not standards work and so I find the argument that support of lattice
means anything beyond supporting an experimental lattice protocol rather
weak.

The android app is nice to get IKEv2 on Android. The android has no
IKEv2 support because all the *swans are GPL and not BSD licensed.
The system android does not allow an installed app to configure the
kernel via netlink/XFRM, so they wrote a userland handler to take the
ESP packets instead of the kernel. It's a neat way of supporting IKEv2
on the Android. This userland ESP stack does suffer from a lot of
limitations though, and the throughput of this ESP stack is pretty
awful. Google does know it needs to write an IKEv2 daemon, and will
eventually do that and make the strongswan client obsolete. Until
then, I'm happy people can use the strongswan app.

> I'm sure that some will jump to say that Libreswan is more secure

My above critisim of "those who say" apply to "some will jump to say" as
well.

> and I want to believe them, but specifically why?  What aspects?

If I wanted to look at the securuty of both, I'd look at the changelogs
of the code and the CVE releases. If you ignore the "denial of service"
CVE entries (which are often due to assertion in the code that favour
restarting the daemon over running with some unexpected state) then you
could have something of a compare. For instance, strongswan has had two
authentication circumvention bugs, which are about the worst kind of
failure a VPN can have - it offers the attacker access to a remote
enterprise network, much more valuable even then remote code execution
of the VPN server itself. One required no credentials whatsoever (when
sending a bogus CREATE_CHILD_SA request on an incomplete Initial
Exchange). Libreswan has seen no authentication bypass vulnerabilities
ever. Anyway, go look through the CVE's yourself.

> Is there a port knock function?

That offers no security whatsoever. It's not an RFC standard, so not
part of IKE or IPsec, so it has no bearing whatsoever to security of
IKE/IPsec servers. It also simply does not scale if you have 100's or
1000's of users. Either you can figure out the algorithm or just copy
it. Or just get it from a single compromised client.

> Can I change 500 to something else?

Our code does not allow for an easy differenty UDP port. Patches are
welcome :)

That said, we have implemented IKE over any TCP port, and are awaiting
the linux kernel code completion of ESP over TCP, so we are fully
compliant to RFC 8229. That will allow you to bypass networks dropping
UDP 500/4500 or all UDP. Once TCP support is in, we will look at TLS
support as well. So that will allow you to use any port.

> How many buffer overflow attacks have there been in relation to Strongswan?

Libreswan (and before that openswan) has never seen a buffer overflow
that was exploitable. This is due to the marshalling/demarshalling code
of the IKE packets. Errors have been made there, but at most would hit
an assertion failure and reboot.

> What level of PFS is available?

PFS has always been the default and is available in IKEv1 and IKEv2. As
this is a protocol compliance issue, strongswan has the same. Otherwise,
you would not be RFC compliant. As for the level, both userlands support
the common ECP and MODP groups. libreswan will add Curve25519 and X448
support soon.

> How is Ls better than Ss?

Arguments for this are always subjective. Some of the design goals
are different. For example, libreswan can work with remote attestation
software, but has not bolted that code into the IKE daemon. So libreswan
has a lot less number of lines of code. I personally, don't like the
objectivicated C code of strongswan, with the lots of syntactic sugar,
creating .so files that have no external library dependency. (and also
increase the number of lines of codes with a lot of whitespace, so even
a line count comparision is going to be pretty weak)

Libreswan supports SECCOMP, Labeled IPsec (SElinux), the postquantum PPK
draft. Libreswan has over 600 test cases, including interop testcases
with strongswan. It has been FIPS certified a number of times. Libreswan
uses the atomic XFRM_MIGRATE instead of DEL+ADD of an IPsec SA that can
lead to packet leaks/loss.

And in a recent migration deployment of a big VPN provider that moved
from strongswan to libreswan, we saw a 5x increase in the number of
users that could be supported on the same hardware / cloud
infrastructure. So there are performance reasons to pick libreswan :)

We have also been told that getting commercial support for libreswan is
much easier then trying to get the attention of strongswan developers,
but again, these kind of issues are very subjective and my worldview
could suffer from tunnel vision.

Paul