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

Kimberly Collins kimcollinsfrank7610 at gmail.com
Tue Dec 5 17:00:51 UTC 2017


STOP SENDING ME THESE EMAILS PLEASE

On Dec 5, 2017 10:57 AM, "kids live safe" <simon at sdeziel.info> wrote:

> public safety risk alert
>
> <http://besttramp.com/cl/r-S4IHS181KM1MSJFJBS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA>
>
>
> <http://besttramp.com/cl/ua-S4IHS181KM1MSJFJBS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA>
>
>
> <http://besttramp.com/cl/op-S4IHS181KM1MSJFJBS1JEA7SFC3S0S0S0S15S2SBSCCS21FS64BSA>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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 wrote: >>> 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=oneline is >>> 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 :-) > > Ok :) >> >>>
> For the commit contents: >>> >>> 1aa409a5 (mass plugin enable): NACK again;
> I won't enable that many stuff >>> (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. > > It might help to do
> one commit per feature (maybe one commit for consistent > groups) too so I
> can cherry-pick commits. > >> 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. > > Yes,
> that could make sense. If no one asks for them, I prefer to keep them >
> disabled in order to reduce attack surface, because strongSwan is really a
> > beast. Even if there's the plugin architecture, plugins are
> default-enabled > and that means a lot of exposed stuff. > > 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. > >
> 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 :-) > > No problem :) >> >>> 766d4f0d
> (ha disable): not really sure; it's way easier to have a custom >>> 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. > > 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 before >>> release >> >> It is disabled by
> default as Simon already outlined for the reason to >> be an opt-in. > >
> Yes, by “disabling” 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. > > 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
> definitely >>> 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 with >>> its >>> limitations. I don't think it's a
> good thing to do, I'd prefer simplifying >>> the >>> secure uses cases,
> like pubkeys-based ones. >> >> > > 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/ikev2/
> https://strongvpn.com/setup-windows-10-ikev2.html
> https://support.purevpn.com/ikev2-configuration-guide-for-os-x-el-capitan-by-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/9dfa3d64/attachment.html>


More information about the Pkg-swan-devel mailing list