[strongSwan] SHA1 vs SHA256
Noel Kuntze
noel.kuntze+strongswan-users-ml at thermi.consulting
Tue Aug 8 22:45:01 CEST 2017
Hi Dusan,
Huh, curious. Both sides use the same keys and the same algorithms with the same block sizes, key sizes and truncation lengths.
So this isn't a problem with the truncation length. Do you mind dumping the ESP traffic, saving the keys of the SAs and their corresponding SPIs
and sending those things here?
Kind regards
Noel
On 08.08.2017 19:32, Dusan Ilic wrote:
> Strongswan 5.2.2
>
> # ip xfrm state
> src 94.254.123.x dst 85.24.241.x
> proto esp spi 0xc713c2af reqid 1 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha256) 0x6f7a3562e5e18fafa95683bf589c6c98c2be237732a5403e22a3e48c65654314 128
> enc cbc(aes) 0x77bbcc462b7217af56052a6cb6c008af4052542a13d674e1d6136f6df9c8522e
> src 85.24.241.x dst 94.254.123.x
> proto esp spi 0xce1e5159 reqid 1 mode tunnel
> replay-window 32 flag af-unspec
> auth-trunc hmac(sha256) 0x37110356f80804e83ceb23ecb4e7be5508445a4fdd0eb4814dbdde00dffa6033 128
> enc cbc(aes) 0x903c3c6c98c90f49102e839badfc7baa5ee38cf89c9ae0013c75b6556a06a345
>
> # ip -s x s s
> src 94.254.123.x dst 85.24.241.x
> proto esp spi 0xc713c2af(3339961007) reqid 1(0x00000001) mode tunnel
>
> Strongswan 5.5.2
>
> # ip xfrm state
> src 85.24.241.x dst 94.254.123.x
> proto esp spi 0xce1e5159 reqid 1 mode tunnel
> replay-window 0 flag nopmtudisc af-unspec
> auth-trunc hmac(sha256) 0x37110356f80804e83ceb23ecb4e7be5508445a4fdd0eb4814dbdde00dffa6033 128
> enc cbc(aes) 0x903c3c6c98c90f49102e839badfc7baa5ee38cf89c9ae0013c75b6556a06a345
> src 94.254.123.x dst 85.24.241.x
> proto esp spi 0xc713c2af reqid 1 mode tunnel
> replay-window 32 flag nopmtudisc af-unspec
> auth-trunc hmac(sha256) 0x6f7a3562e5e18fafa95683bf589c6c98c2be237732a5403e22a3e48c65654314 128
> enc cbc(aes) 0x77bbcc462b7217af56052a6cb6c008af4052542a13d674e1d6136f6df9c8522e
>
> # ip -s x s s
> src 85.24.241.x dst 94.254.123.x
> proto esp spi 0xce1e5159(3458093401) reqid 1(0x00000001) mode tunnel
> replay-window 0 seq 0x00000000 flag nopmtudisc af-unspec (0x00100100)
> auth-trunc hmac(sha256) 0x37110356f80804e83ceb23ecb4e7be5508445a4fdd0eb4814dbdde00dffa6033 (256 bits) 128
> enc cbc(aes) 0x903c3c6c98c90f49102e839badfc7baa5ee38cf89c9ae0013c75b6556a06a345 (256 bits)
> lifetime config:
> limit: soft (INF)(bytes), hard 104857600(bytes)
> limit: soft (INF)(packets), hard (INF)(packets)
> expire add: soft 2522(sec), hard 3600(sec)
> expire use: soft 0(sec), hard 0(sec)
> lifetime current:
> 6984(bytes), 94(packets)
> add 2017-08-08 19:23:29 use 2017-08-08 19:23:48
> stats:
> replay-window 0 replay 0 failed 0
> src 94.254.123.x dst 85.24.241.x
> proto esp spi 0xc713c2af(3339961007) reqid 1(0x00000001) mode tunnel
> replay-window 32 seq 0x00000000 flag nopmtudisc af-unspec (0x00100100)
> auth-trunc hmac(sha256) 0x6f7a3562e5e18fafa95683bf589c6c98c2be237732a5403e22a3e48c65654314 (256 bits) 128
> enc cbc(aes) 0x77bbcc462b7217af56052a6cb6c008af4052542a13d674e1d6136f6df9c8522e (256 bits)
> lifetime config:
> limit: soft (INF)(bytes), hard 104857600(bytes)
> limit: soft (INF)(packets), hard (INF)(packets)
> expire add: soft 2717(sec), hard 3600(sec)
> expire use: soft 0(sec), hard 0(sec)
> lifetime current:
> 0(bytes), 0(packets)
> add 2017-08-08 19:23:29 use 2017-08-08 19:23:37
> stats:
> replay-window 0 replay 0 failed 24
>
>
> Den 2017-08-08 kl. 18:43, skrev Noel Kuntze:
>> Hi Dusan,
>>
>> I think it'd be useful, if you could post complete outputs of `ip xfrm state` of both hosts.
>> The last time you posted them, one of the outputs was incomplete and cut off just above the relevant lines
>>
>> Kind regards
>>
>> Noel
>>
>> On 08.08.2017 18:36, Dusan Ilic wrote:
>>>> 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 since 5.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:
>>> 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?
>>>>>>>>>
>>>>>>>>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170808/c86ffc54/attachment.sig>
More information about the Users
mailing list