[Swan] Security

Colony.three colony.three at protonmail.ch
Wed Jan 3 19:41:53 UTC 2018


Some very able responses, thank you Paul.

Only one comment about port knocking and changing ports:  my main concern is zero-days.  We can't know whether these do or will exist, and to me it's best to layer defenses with these methods.  I can simulate port changing with Shorewall, but I wish that port-knocking were an option.  True, being open-source this feature would be known by some, but if the nature and location of a VPN is unknown it makes cracking it infinitely harder.

But this tears it;  I'm switching to Libreswan.

>> 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.
>> We disagree here.  Those developing early are likely to be included in the final standard.  It's an indicator of
>> resources and determination.
>
> CFRG develops early. Pretending we know better what to do then CFRG
> would do is silly. I agree it is good to have experimental code for
> the things that will come out of CFRG, but that does require a draft
> to implement. While we keep our eyes open, we won't rush things. For
> example, we are monitoring this draft:
>
> https://tools.ietf.org/html/draft-tjhai-ipsecme-hybrid-qske-ikev2
>
>> I see.  For me IKEv2 is the only viable option, and there seems to be no alternative to the Ss app.
>
> True for Android. Everything else has native IKEv2 support now.
>
>> 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.
>> The question is, what is the main threat?  If it's a targeted one Ok, your point is taken.  But there are
>> thousands of bots trying every second to get into well-known ports with the relevant protocol using known and
>> zero-day vulns.  In my opinion port-knock is a defense from these, as is relocating to an unprivileged port where
>> these wholesale attempts are vastly less likely.
>
> I'm not worried about those, because those bots have no credentials,
> so after an IKE_INIT exchange, they cannot pass AUTH. I'm pretty
> confident our (de)marshalling code does not allow for RCE, at worst
> it will crash/restart our daemon causing a Denial Of Service.
>
> Once a client is authenticated, they would have a much better chance
> at doing something. This is also true for the Opportunistic IPsec
> use case, where the client does not authenticate to the server. I'm
> still confident about not having authentication bypass or RCE. We
> have a good track record.
>
> If you have thousands of bot knocking your wellknown port, and
> "wholesale attempts are vastly less likely", you still have them
> knocking at your non-500 port pretty regularly.
>
> I have run opportunistic on a busy open DNS server, resulting in
> thousands of weird things responding to my IKE requests. While that
> did find one error (remote peer sending a 0 DH KE payload causing
> an assertion to crash+reboot our daemon), no crashes that could cause
> RCE were found after tens of thousands of IPs with rogue stuff
> contacting us (those using my open DNS server are usually pretty
> malicious people)
>
>> Can I change 500 to something else?
>>
>> Our code does not allow for an easy differenty UDP port. Patches are
>> welcome :)
>
> I mean, I do consider this a bug and do want to fix it. It is just not
> a very high priority for us.
>
>> 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.
>> Is your TCP functionality usable now?  Is there a reference I can study?
>
> The IKEoverTCP part of the RFC has successfully interoperated with
> Apple's code. Both parties are now working on their ESP code and we
> expect to do ESPoverTCP interop this month.
>
>> No Curve25519, hm.
>
> We had to wait a bit longer for Curve25519 to be available to use via
> the NSS crypto library. Now it is there, we will add support for it.
>
>> I HEARD THAT.  Strongswan is a priesthood, where mere users are unworthy of response.  This has wasted WEEKS of my
>> time in trying to suss out the deep secrets of VPN, when 15 minutes of answers would have gotten me there.  Ls
>> devs have been pretty responsive, and I'd like to thank you Paul and bleve on IRC.
>
> I file strongswan bugs when I find interop issues, and even I get
> smacked and slammed in their bugtracker (and never are personally
> contacted). I've read some of their bug reports and how they treat
> their customers or potential customers would get you fired from any
> real company.
>
>> What drove me from Libreswan originally was that it runs the pluto daemon, which looks for all the world to me
>> like IKEv1.  And even if it also supports IKEv2 that old name indicates low progress. (I have few ways of knowing)
>
> You are very wrong. Look at the updated to late 2017 commit statistics
> covering openswan and libreswan from 2006 - 2017
>
> https://nohats.ca/wordpress/blog/2014/02/16/development-of-libreswan-vs-openswan/
>
> libreswan has seen vastly more development then openswan ever did before
> we were forced to rename.
>
>> But I am fairly angry with Strongswan at this point for costing me all this time.  I am disappointed with no
>> lattice, and the inability to change 500, but it's encouraging that Ls has SECCOMP, and I'd like to learn how to
>> switch to TCP, although I may well stay with UDP for its speed, and I can switch ports in the router which DNATs
>> the tunnel in to my VPN VM.
>
> The TCP part will be auto-detect, although you can explicitely override
> to skip trying UDP. As the RFC explains, it is always better to use UDP
> (technically, ESPoverUDP) because otherwise you have multiple TCP layers
> doing guaranteed delivery and retransmits. There were very good reasons
> why ESP is stateless and not stateful like TCP.
>
> We haven't released the TCP code because you will get only the IKE SA
> established but all traffic would still be ESP or ESPinUDP. Once the
> kernel supports ESPoverTCP, and tells us how to mark the socket as such,
> we can add that to the code and release it.
>
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20180103/10ba351d/attachment.html>


More information about the Swan mailing list