Okey, then I'll probably pass :) I can live without SHA256!


Den 2017-08-11 kl. 21:07, skrev Thomas Egerer:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Dusan,

Sorry for the delay. Busy times :)

On 08/09/2017 08:24 AM, Dusan Ilic wrote:
How do I do that?
tcpdump -ni <interface-name> -w /tmp/esp_dump.pcap -s 0 proto 50
The keys are obtained the same way you did in this mail, by
running the 'ip -s x s s' command (which by the way is short
for 'ip -s xfrm state show')

interface-name: e.g. eth0 (or else)
Do I have to obfuscate anything sensitive?
You should be aware of the fact, that anyone with the traffic
dumps and the keys can decrypt and read the *plain* text of the
traffic sent over the tunnel (and this includes IP-adresses, too).

Cheers,
Thomas

---- Noel Kuntze skrev ----

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?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJZjgBqAAoJEGK31ONirBTG0wAP/2daRQj1KuJjhePeBhqbekae
35tTmf1io782nV174fdR/naAevOHeWtk1PXBfo1vHUtBUs2TMnu2PwgKGh+nUZdE
ZCEwvUWaH/ivP3rH2K0mlH3h8UArCk2sJIScGo7A9dhejVXKYqjE9cyjeHAFBePj
ci7f7PjWP5mmvvHUMPorGA1YsEVIam9868+3Xscku6oR8ndsCvEMxavkCN9kkSH/
miRITZm5/+ft5zsZOX2serwRedP3L0R2itrzNIb/HSi0d+KopXU3WDkDuTUr62DK
M9rH62AhGdxxmzZcY0NX439+ISScFfkl7qhcNxtE244rQqh9NYaKPPRV2BDoHNqS
HANGfHln+gyUFhk9A8mjGibXc05Lb75WcpjO8R3lMFGRJI7VO+u9pyhElHkN5uN5
oW1dz0MbjRYmIp/m4rPv5sAQ6/VQDWdOX75T1l15xhLjADWy6K3f+XhlHlFQX2o0
OWiT33Lp6g2Qid0hkw4sYONuf3jgY1zHsOgtQ8KU+wEfZCvTYdkgZvDL3P9IUF0k
/J+vqX7ArAbicKJNGHGEeUEeOkwf5wrPx8y4ad9vNc4E/P0vAxK/3VLoL7D2WiAC
7VS3XjTxu8ROxlTChX7I6S6fnLCR//aks6mROzmz9AT02ypFajyeeNyKPxUVteGh
ZV7Fr9S9BLr6SBYhH+Eo
=Xnt/
-----END PGP SIGNATURE-----


Reply via email to