Failure with Cisco ACE Loadbalancer

[drwetter]

Hi Peter,

seems that under special conditions a handshake doesn't succeed, see https://github.com/drwetter/testssl.sh/issues/189 .

I tracked that down to the command

echo Q | apps/openssl s_client -tls1_2 -cipher ALL:-AES256-SHA -connect NODEIP:443 -servername NODE 2>&1 | grep Cipher

That fails with this fork (tried 1.0.2b through e) but succeeds with the vanilla 1.0.2d.

Any clues?

Dirk

[PeterMosmans]

Hi Dirk, thanks for reporting. I'll check into it -although this could take a while-

[PeterMosmans]

OK, found the issue. Cisco ACE's can't hande a handshake => 128 ciphers, and the 1.0.2-chacha fork has more than that, fortunately :smile: I know for a fact that this issue has been reported to Cisco before, however I'm unaware of the current status. Please report this to Cisco (again), maybe that will help getting the issue fixed (faster)...

How to reproduce: Run https://github.com/PeterMosmans/security-scripts/blob/master/test_ssl_handshake.sh with the following parameters:

./test_ssl_handshake.sh --openssl=/path/to/openssl/1.0.2-chacha --cipherstring="ALL" --start=125 --128 TARGET

This will iterate over ciphers starting from 125, and it will error out when the 128 cipher limit is reached.

Funny enough was this Cisco thing the reason that I built this testscript in the first place...

(edited: s/ASA/ACE/g thanks to @RamsesRodenburg )

[RamsesRodenburg]

Hi Peter,

I assume you meant to say “Cisco ACEs”, not “Cisco ASAs” ?

Cheers! :) Ramses Rodenburg

IP systems engineer info.nl

[drwetter]

Thx, Peter.

On the first glance that looks like it's an explanation (remember the IIS6 thing?). However in the scenario it hiccuped at there were two handshakes in the following sequence:

1) echo Q | apps/openssl s_client -tls1_2 -cipher ALL -connect NODEIP:443 -servername NODE 2>&1 | grep Cipher 2) echo Q | apps/openssl s_client -tls1_2 -cipher ALL:-AES256-SHA -connect NODEIP:443 -servername NODE 2>&1 | grep Cipher

The second one fails.

Also vanilla openssl 1.0.2 d lists 135 ciphers:

prompt% ./apps/openssl  ciphers -V ALL  | wc -l                           
135
%prompt

According to wireshark (1) is 148 ciphers, (2) 147 ciphers. For vanilla openssl it is in fact 115 for (2). But I do not understand why (1) succeeds.

Cheers, Dirk

[PeterMosmans]

With regards to the first handshake - which cipher is actually being used ? (don't forget that you have to filter out the non-TLS(1.2) ciphers. openssl ciphers only has -ssl2, -ssl3, and -tls1 parameters).

[PeterMosmans]

@drwetter check out https://github.com/PeterMosmans/TLScan/blob/max/TLScan.py - I hacked in a --max flag to minimize the client hello size. Try

TLScan.py -t my.cisco.asa

This will probably fail

Then try

TLScan.py -t my.cisco.asa --max 255

This will probably succeed. The max field limits the size of the client hello. So I still think that's the issue, the size of the hello ( = number of ciphers)

[drwetter]

Am 09/17/2015 um 12:10 PM schrieb Peter Mosmans:

With regards to the first handshake - which cipher is actually being used ?

see https://github.com/drwetter/testssl.sh/issues/189

Cheers, Dirk

[drwetter]

Am 09/17/2015 um 10:48 AM schrieb Peter Mosmans:

OK, found the issue. Cisco ASA's can't hande a handshake => 128 ciphers, and the 1.0.2-chacha fork has more than that, fortunately :smile: I /know/ for a fact that this issue has been reported to Cisco before, however I'm unaware of the current status. Please report this to Cisco (again), maybe that will help getting the issue fixed (faster)...

How to reproduce: Run https://github.com/PeterMosmans/security-scripts/blob/master/test_ssl_handshake.sh with the following parameters:

|./test_ssl_handshake.sh --openssl=/path/to/openssl/1.0.2-chacha --cipherstring="ALL" --start=125 --128 TARGET |

Have you gotten my PM with the IP address? Your script stalls ( It needs a definition of TMP before.) Maybe you could try yourself?

Still I do not understand why a handshake with 148 ciphers work and with 147 not, pls see above.

Cheers, Dirk

[drwetter]

Am 09/17/2015 um 02:54 PM schrieb Peter Mosmans:

@drwetter https://github.com/drwetter check out |https://github.com/PeterMosmans/TLScan/blob/max/TLScan.py| - I hacked in a --max flag to minimize the client hello size. Try

|TLScan.py -t my.cisco.asa |

This will probably fail

prompt% TLScan.py -t HOST && echo OK

TLS/SSL Cipher Scanner

[i] No port specified, setting a default one (443) [i] Processing target: HOST on port: 443... ===============- Protocols -================ [+] Supported encryption protocols: [e] The service does not appear to be supporting SSL/TLS using current settings Length of handshake: 707 Length of handshake: 707 Length of handshake: 707 Length of handshake: 707 Length of handshake: 707 OK prompt%

Then try

|TLScan.py -t my.cisco.asa --max 255 |

prompt% TLScan.py -t HOST --max 255 && echo OK Length of handshake: 301 Length of handshake: 301 [-] Remote service supports: TLSv1.2 Length of handshake: 301 [-] Remote service supports: TLSv1.1 Length of handshake: 301 [-] Remote service supports: TLSv1.0 Length of handshake: 301 ================- Ciphers -================= [+] Supported cipher suites for: TLSv1.2 Length of handshake: 707 [+] Supported cipher suites for: TLSv1.1 Length of handshake: 707 [+] Supported cipher suites for: TLSv1.0 Length of handshake: 707 OK prompt%

Don't know what the bottom line for you is but except the missing ciphers it looks similar to the output e.g. for https://testssl.sh

Maybe you can have a look yourself into it?

Cheers, Dirk

[drwetter]

copied from https://github.com/drwetter/testssl.sh/issues/189

Hi Mark,

good that @PeterMosmans had that much patience with me ;-)

Bottom line: He's right. Cisco can't handle that many ciphers. So you ( @feld ) can try to yell at them, I will try to work around it. Don't know when though, other things have more priority. Probably this will be not fixed in 2.6 but in dev.

Thx all,

Dirk

[drwetter]

Hey Peter,

was that limit for ACE @ 128 ciphers where the problem occurs or over 128 ciphers?

Yes, I can read an know what >= means but I otherwise need to do a workaround for one cipher. And I couldn't find other reliable info.

Cheers, Dirk

[PeterMosmans]

Hi Dirk,

The problem occurs 'instantly' with 128 ciphers (and above, of course). I haven't tested recently with the latest ACE firmware version though...

Cheers,

Peter

[drwetter]

thx!