[Swan-dev] Working in Libreswan project for GSoC

[Paul Wouters]

On Wed, 1 Mar 2017, Asad Salman wrote:

Hi Asad,

> Hi!I'm a third-year undergrad student of software engineering from Islamabad, Pakistan.
> I have a strong, personal interest in information security, and was absolutely delighted to see a
> new security related project accepted this year in GSoC'17. I really hope to get the chance to work
> with you guys!

Thanks for your interest in libreswan!

> I liked the Opportunistic IPsec (using LetsEncrypt) project. Because a) it is was one of the initial
> goals of Libreswan when it started out, and b) zero knowledge/config encrypted traffic by
> default would be a really cool thing to have in real life. Also, having some knowledge of IPsec, I
> think I can genuinely contribute to this project. I also liked the TCP encapsulation project too,
> though don't think kernel development is my forte.

Yes, our goal is of course to encrypt all internet traffic by default.
We want to support different methods of obtaining a public key. This
can be via DNSSEC, a known CA like LetsEncrypt, or GSSAPI/Kerberos, or
even a blockchain. The first step for all of these methods is an
external script that can take and verify such a public key, and then
give the remote IP address, ID and pubkey to our IKE daemon pluto,
which can then do the IKE authentication and setup the IPsec tunnel.

And, with AUTHNULL, which we already support, we can also do a "better
then nothing" encryption without authentication. Of course, it is
important that authenticated encryption is tried first, as we need
to protect against downgrade attacks.

An idea we have that was not yet on the list is to provide a "tcpcrypt
library" like solution so that applications can use such a library
to ask via standard setsockopt/getsocktopt that the connection must
be encrypted and/or authenticated. This is basically an overlay over
the real getsockopt/setsockopt, with the idea that one day this might
become a real kernel socket option.

The TCP encapsulation support is also something that we are excited
about. The use case for this is accidentally or purposefully broken
networks that block UDP packets. When behind NAT, IPsec tunnels do
not use the ESP protocol directly, but encapsulate that in UDP (hence
the name ESPinUDP). But some networks drop all UDP that is not DNS.
This is where TCP comes in. But it gets a little tricky. There is
of course the draft that mentions the kind of things we need to
support with TCP, but the draft purposefully does not mention another
feature needed. It might have to start a fake or real TLS connection
instead of just using raw TCP, so that the ESPinTCP solution also
works when there are MITM devices blocking access. Those MITM proxies
tend to just let the TLS traffic go unmodified/unseen.

Related to this is a rewrite we would like to do on how libreswan
handles interfaces and IP address changes. Libreswan does not listen
to ANY and whenever an IP address or interface is added or removed,
we need to "re-orient" our connections using "ipsec whack --listen".

> I'm really excited to work with you guys and dive into the Libreswan project. Any recommendations on
> how to get involved in the code base (bug fixes, patches etc) would be awesome.

I would recommend first to play with libreswan as an enduser. Look at
the wiki page for our Opportunistic IPsec with LetsEncrypt support. Or
if you have two VM's on a laptop, give them each a subnet and connect
them with libreswan using IPsec. Tcpdump from the host to confirm it is
all encrypted. Of you can look at the developer information on how to
run our test cases, which use a libvirt/qemu setup which will also
cause you to end up with a few VMs (west, east, north,nic and road)
that you can fire up to test and play with. Code changes you do would
be tested by running the full test suite using these VMs anyway, so
it is a good start to get that running. And do ask on the #swan channel
for help if something does not work. Most of us use fedora based VMs
and although it should work on ubuntu/debian too, there might be some
tweaks needed to get it running there.

Then, have a peek at the code. Most of the interesting code lives in
programs/pluto and the names hopefully speak for themselves. The ikev1*
and ikev2* files are related to the respective IKE protocol versions.
The server code lives in server.[ch], sysdep.c[h] and plutomain.[ch]

And do note that our developers live in very different timezones, and
work at odd hours, so if asking questions do hang out long enough to
receive an answer.

Paul (leto* on the #swan channel)