[strongSwan] SHA1 vs SHA256

[Dusan Ilic]

No, not according to loaded plugins in ipsec statusall


Den 2017-08-04 kl. 21:44, skrev Noel Kuntze:
> Okay. Is kernel-pfkey loaded?
>
> On 04.08.2017 21:31, Dusan Ilic wrote:
>> Yep, both endpoints have loaded kernel-netlink.
>> However, the Strongswan versions is 5.2.2 and the other is 5.5.2.
>>
>>
>> Den 2017-08-04 kl. 21:15, skrev Noel Kuntze:
>>> Hi Dusan,
>>>
>>> That is unreliable.
>>> Check the list of loaded plugins in the output of `ipsec stausall` or `swanctl --status`.
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> On 04.08.2017 21:11, Dusan Ilic wrote:
>>>> Hi Noel,
>>>>
>>>> I think I'm already using kernel-netlink on both endpoints.
>>>>
>>>> cat /etc/strongswan.d/charon/kernel-netlink.conf | grep load
>>>>       # Whether to load the plugin. Can also be an integer to increase the
>>>>       load = yes
>>>>
>>>>
>>>> Den 2017-08-04 kl. 21:00, skrev Noel Kuntze:
>>>>> Hi,
>>>>>
>>>>> If the pfkey API (nowadays a wrapper around XFRM) to the kernel is used, SHA-256 with 96 bit truncation is used[1][2]. That is because it is the default truncation length.
>>>>> It is not possible to choose the truncation length using pfkey.
>>>>> If XFRM over netlink socket is used to configure XFRM, one can choose the truncation length. strongSwan uses the 128 bit truncation length for HMAC-SHa256.
>>>>>
>>>>> Since 5.5.3, one can choose the truncation length on a per-conn basis.
>>>>>    From the roadmap[3]:
>>>>>
>>>>> With the sha256_96 compatibility option it's possible to locally configure 96-bit truncation
>>>>> for HMAC_SHA256 (the correct truncation is 128 bit) when negotiated using the official
>>>>> algorithm identifier (12). This is only useful for compatibility with peers that incorrectly
>>>>> use this shorter truncation as the actual truncation length is not negotiated.
>>>>>
>>>>> So the solution is to try using kernel-netlink instead of kernel-pfkey with strongSwan in an attempt to force the kernel to
>>>>> use the 128 bit truncation length, which strongSwan chooses by default.
>>>>>
>>>>> Kind regards
>>>>>
>>>>> Noel
>>>>>
>>>>> [1] https://wiki.strongswan.org/issues/2301
>>>>> [2] https://wiki.strongswan.org/issues/2391
>>>>> [3] https://wiki.strongswan.org/versions/65
>>>>> On 04.08.2017 20:50, Andreas Steffen wrote:
>>>>>> Hi Dusan,
>>>>>>
>>>>>> the only workaround I see is to either upgrade your Linux 2.6
>>>>>> kernel or fall back to a SHA-1 based ESP HMAC.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>>> On 04.08.2017 20:46, Dusan Ilic wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Unfortunately, I'm not following you guys :)
>>>>>>> Could someone please clarify?
>>>>>>>
>>>>>>>
>>>>>>> Den 2017-08-04 kl. 19:04, skrev Noel Kuntze:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> IIRC pfkey still uses the old truncation (It's mentioned in some
>>>>>>>> relatively recent ticket).
>>>>>>>> Try using kernel-netlink instead.
>>>>>>>>
>>>>>>>> Kind regards
>>>>>>>>
>>>>>>>> Noel
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04.08.2017 19:02, Andreas Steffen wrote:
>>>>>>>>> Hi Dusan,
>>>>>>>>>
>>>>>>>>> hmmm, our documentation says that the correct ESP SHA256_128 HMAC
>>>>>>>>> truncation was introduced with the 2.6.33 kernel but your kernel
>>>>>>>>> might not be a vanilla 2.6.36 kernel:
>>>>>>>>>
>>>>>>>>>      https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
>>>>>>>>>
>>>>>>>>>      (ESP integrity algorithm footnote n)
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Andreas
>>>>>>>>>
>>>>>>>>> On 04.08.2017 16:41, Dusan Ilic wrote:
>>>>>>>>>> Hi Andreas
>>>>>>>>>>
>>>>>>>>>> One side is 2.6.36 and the other 3.10.20
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Den 2017-08-04 kl. 12:48, skrev Andreas Steffen:
>>>>>>>>>>> Hi Dusan,
>>>>>>>>>>>
>>>>>>>>>>> this is a Linux kernel issue. Which kernel versions are you running
>>>>>>>>>>> on the two endpoints?.
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>>
>>>>>>>>>>> Andreas
>>>>>>>>>>>
>>>>>>>>>>> On 04.08.2017 12:41, Dusan Ilic wrote:
>>>>>>>>>>>> Hi Noel,
>>>>>>>>>>>>
>>>>>>>>>>>> One side is Strongswan 5.2.2 and the other is 5.5.2.
>>>>>>>>>>>> How do I switch?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Den 2017-08-04 kl. 12:25, skrev Noel Kuntze:
>>>>>>>>>>>>> the remote peer probably uses the DRAFT variant of sha2-256, which
>>>>>>>>>>>>> uses 96 bit truncation. strongSwan uses the actual standardized
>>>>>>>>>>>>> variant that truncates to 128 bit.
>>>>>>>>>>>>> You can switch between the two in the newest version of strongSwan
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 04.08.2017 12:23, Dusan Ilic wrote:
>>>>>>>>>>>>>> Hello!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have a strange issue, with both settings below the tunnel goes up
>>>>>>>>>>>>>> as it should, but only with SHA1 in ESP traffic goes through.
>>>>>>>>>>>>>> When I
>>>>>>>>>>>>>> ping the remote client with ESP SHA256 it times out, even though
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> tunnel reports as being up by Strongswan.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Traffic working:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>>>>>>> esp=aes128-sha1-modp2048!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Traffic not working:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>>>>>>> esp=aes256-sha256-modp2048!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Below combo doesn't work either:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ike=aes256-sha256-modp2048!
>>>>>>>>>>>>>> esp=aes128-sha256-modp2048!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also, are above settings good? I'm having AES128 on ESP because
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> AES256 I loose too much througput. Do you have any suggestions for
>>>>>>>>>>>>>> change?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>