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