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 _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
