[strongSwan] SHA1 vs SHA256

[Dusan Ilic]

Hi Thomas,

I tried your suggested proposal, but that doesnt work either.

Unfortunately, both endpoints are Linux embedded (routers), so I think 
that isn't an option.
However, I see that in version 5.5.3 there is a new option in Strongswan.

/sha256_96 =*no*| yes/

HMAC-SHA-256 is used with 128-bit truncation with IPsec. For 
compatibility with implementations that incorrectly use 96-bit
truncation this option may be enabled to configure the shorter 
truncation length in the kernel. This is not negotiated, so this
only works with peers that use the incorrect truncation length (or have 
this option enabled). Available since5.5.3 
<https://wiki.strongswan.org/versions/65>.



Maybe I'll have to wait for the next version beeing released in the 
repository on the endpoint currently running 5.5.2.

Just to clarify, which of the endpoints are the failing endpoint here? I 
mean, which endpoint is truncating it to 96 bits?


Den 2017-08-08 kl. 09:39, skrev Thomas Egerer:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi Dusan,
>
> On 08/06/2017 08:13 PM, Dusan Ilic wrote:
>> Hi Thomas,
>>
>> I haven't upgraded it cause that's not an option, both endpoints are routers with Linux embedded.
>> Below is the output after some pings from both sides.
>>
>> Strongswan 5.5.2
>>
>> ip -s x s s
>> src 85.24.241.x dst 94.254.123.x
>>          proto esp spi 0xce291943(3458799939) reqid 1(0x00000001) mode tunnel
>>          replay-window 0 seq 0x00000000 flag nopmtudisc af-unspec (0x00100100)
>>          auth-trunc hmac(sha256) 0xc45dd8403c10cfd32f8fe74003cc80a309b7a0decb185826ef62ac1763ae4bcd (256 bits) 128
>>          enc cbc(aes) 0x0abb9115383986028a844ff1e71bd0f55aa22099d76785b288803ed7204aa23e (256 bits)
>>          lifetime config:
>>            limit: soft (INF)(bytes), hard (INF)(bytes)
>>            limit: soft (INF)(packets), hard (INF)(packets)
>>            expire add: soft 2762(sec), hard 3600(sec)
>>            expire use: soft 0(sec), hard 0(sec)
>>          lifetime current:
>>            1416(bytes), 25(packets)
>>            add 2017-08-06 20:08:26 use 2017-08-06 20:08:31
>>          stats:
>>            replay-window 0 replay 0 failed 0
>> src 94.254.123.x dst 85.24.241.x
>>          proto esp spi 0xc9359a4e(3375733326) reqid 1(0x00000001) mode tunnel
>>          replay-window 32 seq 0x00000000 flag nopmtudisc af-unspec (0x00100100)
>>          auth-trunc hmac(sha256) 0xfe9408ba634fe4276972fa79c9b60f12bffc766434298cb25738396d2b94dda9 (256 bits) 128
>>          enc cbc(aes) 0x1fd6fd06781cee3bab6ed97a2f01793eded22f7360691430fdfb604c4e424066 (256 bits)
>>          lifetime config:
>>            limit: soft (INF)(bytes), hard (INF)(bytes)
>>            limit: soft (INF)(packets), hard (INF)(packets)
>>            expire add: soft 2895(sec), hard 3600(sec)
>>            expire use: soft 0(sec), hard 0(sec)
>>          lifetime current:
>>            0(bytes), 0(packets)
>>            add 2017-08-06 20:08:26 use 2017-08-06 20:08:28
>>          stats:
>>            replay-window 0 replay 0 failed 49
>                                              ^^- this indicates a crypto-
> graphic error with the received packets. As suspected in this thread
> before, your peer -- which by the way has a very very sparse iproute2
> output, did it get truncated -- most likely uses sha256 with a 96 bit
> truncation.
> - From quickly reading this entire thread I did not whether you have
> tried the following proposal on both sides:
>
> esp=aes128-sha256_96-modp2048!
>
> Is building your own strongswan instance for the regular linux box an
> option for you?
>
> Cheers, Thomas
>> Strongswan 5.2.2
>>
>> ip -s x s s
>> src 94.254.123.x dst 85.24.241.x
>>          proto esp spi 0xc9359a4e(3375733326) reqid 1(0x00000001) mode tunnel
>>
>> Den 2017-08-06 kl. 16:49, skrev Thomas Egerer:
>> Hello Dusan,
>>
>> if you haven't yet updated your kernel, we might shed some light on
>> the problem. Set up the tunnel with SHA256 and send a couple of
>> packets from both sides. Then provide the output of
>> 'ip -s x s s'
>>
>> Cheers,
>> Thomas
>>
>>
>> On 08/04/2017 12:23 PM, 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?
>>>>>
>>>>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJZiWqTAAoJEGK31ONirBTGwM4P/09h6ueOW0FyL+ajqr2HfwA6
> ubk9vbcGAZg4AlBcwgkg46lABucWWLhMN1ayaRNaLiK5pvn5pqYHOB0gk6RivDQg
> gfj9koQlYrQQ2KHUt6ZOrosKSW2jzoIjz4U/aeOuI+ScHfTHuzLgSwmAi/qB17Ov
> /i6Jbx25aChb+ioms4BmkQpacY37Shuq09sAh1coVZC7JMDEpsKvpsPhCV+dCWUM
> FxBZOZJeWNVKPILPstF/zyc4nJFzvWssUEutJ/1tpUd8Mlehrt3xc78HbcLru5In
> JWYAKLg1qjSd5nmlqJQ2at2uwOf3wfdykBZkGjVWsDGGtoLGA6+T8XMyKML0byhC
> jR5+8I2NKLdtiPOoM1NbchZKjCCBR2zqNOsI833pEiqmFpjFfp4+gWqmmC0uR9cM
> DAPbMCrckA6rhisqphT2i0tRAhnh4sqxCa1TjwuR+BcNWm+KKiIkhaP4NvfmHoH1
> IVzZzHVCkr5/qJGOBCJM2Jc0ONI79e0xe26f4SJDn3sfEMsO5lxbM5cvN2XiZ8J7
> Wu5f8aytiR4wLKHCRGvqw4hqaj0hoR505+jq4Ywos3GnEM5ylOoxLgEHT169aou+
> vL1VwKYehCfQFKwI0uL70dOj3ASyjuR1dIEEBFgNL2xbGfJVEMZ1Rm7SMZb2hHph
> UchHB0r5u4A2AcuTVBDR
> =X/NO
> -----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170808/38b1897a/attachment.html>