[Pkg-swan-devel] Bug#848890: public safety risk alert Dz

Brooke bmaxwell74 at gmail.com
Tue Dec 5 17:01:49 UTC 2017


What is this?

Brooke

> On Dec 5, 2017, at 8:55 AM, kids live safe <simon at sdeziel.info> wrote:
> 
> public safety risk alert
> 
> 
>    
> 
>   
> 
>   
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 2017-12-05 04:12 AM, Yves-Alexis Perez wrote: > On Tue, 2017-12-05 at 08:31 +0100, Christian Ehrhardt wrote: >> On Mon, Dec 4, 2017 at 9:56 PM, Yves-Alexis Perez wr= ote: >>> On Thu, 2017-11-30 at 16:31 +0100, Christian Ehrhardt wrote: >>>> Pushed it to the same debian-submission-nov2017 branch as before. >>> >>> Thanks, >>> >>> I don't really have good news though. I took a look and first, it seems >>> that >>> the git commit entries aren't really good. git log --format=3Doneline i= s >>> barely >>> readable, for example. >> >> Yeah the format was meant for another tool which made debian/changelog >> entries out of it. >> I could rewrite them the next time we talk about this topic in >> probably 6 months :-) >=20 > Ok :) >> >>> For the commit contents: >>> >>> 1aa409a5 (mass plugin enable): NACK again; I won't enable that many stu= ff >>> (and >>> especially not in one go) >> >> I can understand, this all is just a suggestion. >> Things came up (way before my time) due to user requests and if I did >> history research correctly at that point it was decided to enable a >> few more to not get requests for extra plugins all the time. >> You are not taking all - that is fine, if you take a few that is good >> enough. >=20 > It might help to do one commit per feature (maybe one commit for consiste= nt > groups) too so I can cherry-pick commits. >=20 >> Since I wasn't part of that old enabling activity I wanted to sync >> with you here and even considered dropping a bunch of them next (post >> LTS) cycle. >> Nobody remembers the particular reasons for some of them, so for all >> that make no sense to you in a hard enough way to not even enable them >> for "-extra-plugins I'd consider triggering bug reports in Ubuntu if >> somebody really used them. >=20 > Yes, that could make sense. If no one asks for them, I prefer to keep the= m > disabled in order to reduce attack surface, because strongSwan is really = a > beast. Even if there's the plugin architecture, plugins are default-enabl= ed > and that means a lot of exposed stuff. >=20 > For stuff like algorithms, there's also the security tradeoffs of default > config. I don't want to endorse stuff that's too young for my test (like = the > various PQ bits) or too exotic. That's one reason why it would be great to have AES-GCM available like ChaCha20/Poly1305. Those are the 2 most reputable AEAD ciphers available today. >> I'm fine either way - all I request is that we look and discuss about >> things every half year or so. >> So far we benefitted both each time we did, so it isn't wasted time. >=20 > Indeed :) >> >>> d83c243b (duplicheck disable): one good reason for the NACK just above: >>> it's >>> not enabled in Debian, you just enabled it in 1aa409a5 :) >> >> That is a bummer, at the time I saw it the first time I thought it was >> enabled in Debian and since then carried on. >> /me feels ashamed and obviously drops that part :-) >=20 > No problem :) >> >>> 766d4f0d (ha disable): not really sure; it's way easier to have a custo= m >>> kernel than a custom strongSwan >> >> Ok, so you had real cases where you or a Debian user used that? >> Very interesting POV, I think neither is easier than the other but I >> see your point. >=20 > I didn't, but I know for sure that building and using a custom kernel is = way > easier than using a custom strongSwan package. >> >>> 85150f06 (kernel-libipsec enable): for reference, this is #739641 and I= 'm >>> still not sure I like it. I might pick it but end up disabling it befor= e >>> release >> >> It is disabled by default as Simon already outlined for the reason to >> be an opt-in. >=20 > Yes, by =E2=80=9Cdisabling=E2=80=9D I meant more disabling at build time. >> >>> a587dc11 (TNC move): I might pick this one because TNC is pretty >>> standalone >>> per-se and it might make sense to split it, but really that's a lot of = new >>> binary packages. >> >> I understand the new-queue fight, but it really came handy for users >> who wanted it standalone. >=20 > Do you have pointers on people asking for it? I would appreciate not having the TNC bits pulled unless I really need them. I never had to deal with TNC so I don't know if a standalone package (cb55e029b7) make sense. On the other hand, I routinely need EAP-MSCHAPv2 and XAUTH and in such cases we don't want the TNC bits that comes from libcharon-extra-plugins. I think that Christian's proposal of having libcharon-standard-plugins (0ef9c2ad736) providing EAP-MSCHAPv2 and XAUTH is a good compromise and I wouldn't mind if the TNC stuff remained in libcharon-extra-plugins. >>> 8dbf648b7 (libcharon-standard-plugin): I can understand the rationale >>> (plugins >>> for common password-based mobile VPN setup), but I don't really like it= . I >>> don't really like adding a new binary package, and the name is definite= ly >>> not >>> good. Also, as far as I understand it, the plugins are useful when you'= re >>> actually configuring a client/roadwarrior to imitate a mobile client wi= th >>> its >>> limitations. I don't think it's a good thing to do, I'd prefer simplify= ing >>> the >>> secure uses cases, like pubkeys-based ones. >> >> >=20 > See my answer above about good practice. Recent iOS can use pubkeys/certs > based setups, not sure about Android (but they can use the strongSwan > application), so there's really no reason to not use them. Every OS I know of support using X.509 certs so it's not a feature support problem but more a lazy sysadmin problem. Certificates are unfortunately very rarely used in the wild for large deployment because they are perceived as hard/cumbersome to deploy. I just did a quick survey of the commercial offering for IPsec VPN providers and all of them required EAP-MSCHAPv2 when using IKEv2: https://www.personalvpn.com/support/setting-up-and-using-your-vpn/android/i= kev2/ https://strongvpn.com/setup-windows-10-ikev2.html https://support.purevpn.com/ikev2-configuration-guide-for-os-x-el-capitan-b= y-purevpn https://nanorep.nordvpn.com/Connectivity/Windows/1047410092/IKEv2-IPSec-for= -Windows-10.htm https://www.acevpn.com/knowledge-base/how-to-setup-ikev2-vpn-android/ The justification for XAUTH is mostly for built-in Android and older iOS/macOS clients where the best you can get is IKEv1+XAUTH using either PSK or X.509. I provided all my arguments so I'll stop barking at this tree ;) and want to thank you both for the excellent work you've been doing! Regards, Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-swan-devel/attachments/20171205/bd6d1c4a/attachment.html>


More information about the Pkg-swan-devel mailing list