[strongSwan-dev] [RFC] Be lenient about downstream encryption
martin at strongswan.org
Thu Apr 17 09:21:22 CEST 2014
I've merged a slightly modified patch to master at . I renamed the
option to be vendor-neutral, and changed the patch to make it work for
both as initiator and responder.
> - There's a very high bar to discovering the need for this option,
> for someone who may have only discovered that "it doesn't work for
This is certainly a valid point, however: The patch has security
implications (see below). If we just allow that behavior, we put users
at risk. We think that "it doesn't work for me, please help?" is
certainly better than supporting insecure configurations by default.
> - By not supporting this option by default, you could argue slightly
> better security
Especially when using PSK authentication, I don't think "slightly better
security" is an appropriate description: Using this option with
PSK(+XAuth) is just as bad as using Aggressive Mode with PSK (but with a
misleading "Main Mode security label").
While an unencrypted ID payload just discloses user identities,
unencrypted HASH payloads open the door to brute-forcing the PSK for
passive attackers. Unfortunately PSKs are often too weak, making this
trivial. Then you can impersonate that server, and happily collect all
XAuth username/password combinations :-/.
> but only because the user will give up after a while (see the point
> above), and not because we prevent the un-encrypted data from being
> sent, since by the time the connection fails, it already has.
True, but the user/administrator will reconsider (and possibly even
understand!) the configuration after some failures, instead of using it
> That said, as someone who knows about this issue, I'd be okay with 
> (haven't tested it yet -- will do) since I'd probably enable it by
Enabling it by default might make sense; but I'd recommend to enforce
security at other places, i.e. prevent PSK authentication or reject weak
PSKs in the configuration.
More information about the Dev