[strongSwan-dev] [RFC] Be lenient about downstream encryption

[Paul Stewart]

On Mon, Apr 14, 2014 at 7:00 AM, Paul Stewart <pstew at chromium.org> wrote:
> On Mon, Apr 14, 2014 at 5:56 AM, Martin Willi <martin at strongswan.org> wrote:
>> Hi Paul,
>>
>>> I discovered an interop issue with XAUTH authentication
>>> with StrongSwan VPNs.  Does anyone have a deep enough
>>> knowledge of this frame to understand what the remote
>>> VPN is giving away?
>>
>> Thanks for your analysis, and the patch.
>>
>> It seems that Sonicwall sends the ID/Hash payloads unencrypted even in
>> Main Mode, probably to select different PSK keys based on the peer
>> Identity. Something like an "Aggressive Mode light"?
>>
>> If that helps for interoperability, I'm not against upstreaming a
>> work-around, even if it is not strictly within the specs.
>>
>> How about the (untested) patch at [1]? It introduces a
>> charon.sonicwall_quirk strongswan.conf option to enable that behavior.
>
> My only reservations to it being optional:
>
>  - 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
> me".
>  - By not supporting this option by default, you could argue slightly
> better security, 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.
>
> That said, as someone who knows about this issue, I'd be okay with [1]
> (haven't tested it yet -- will do) since I'd probably enable it by
> default.

Oh, one more point -- the SonicWall does send a vendor ID in the
initial exchange.  I couldn't see a straightforward way to pass that
downwards into this logic, but perhaps that might be an alternate /
additional approach.
>
>>
>> @Tobias: What do you think about such an option? Don't know if it is
>> worth it, as remote sends these unencrypted payloads anyway. On the
>> other side, it can make the implications clear to the
>> administrator/user, given that an attacker can snoop these identities
>> sent in clear-text.
>>
>> Best Regards
>> Martin
>>
>> [1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/sonicwall-quirk
>>