Closed GianpaoloPedrazza closed 8 years ago
Am 11/12/2015 um 03:07 PM schrieb GianpaoloPedrazza:
It seems to me that a server is marked as vulnerable against Secure Client-Initiated Renegotiation if a client-initiated renegotiation works. I tested against the save server and I got:
1.
./testssl.sh --openssl=/usr/local/ssl/bin/openssl --wide DUT Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
2.
python sslyze.py DUT:443 --reneg
*
Session Renegotiation : Client-initiated Renegotiations: Honored Secure Renegotiation: Supported
- openssl s_client -connect DUT:443
Secure Renegotiation IS supported
Thx Gianpaolo. But bugreports are useless without the IP/hostname.
Pm is fine too.
/Dirk
Hi @GianpaoloPedrazza,
this issue automatically closes soon if I do not get more input from you.
Cheers, Dirk
I have found on your code at line 3056 echo R | openssl s_client -legacy_renegotiation -msg -connect DUT:PORT According with following blog post http://www.exploresecurity.com/the-small-print-for-openssl-legacy_renegotiation/ it is not the best solution. I would suggest to use instead the tlsextdebug option like echo R | openssl s_client -tlsextdebug -msg -connect DUT:PORT If secure renegotiation is supported, it will show RENEGOTIATING TLS server extension "renegotiation info" (id=65281), len=25 which according with RFC 5746 is a proof that the DUT is protected. See the link below for more informations about http://www.oracle.com/technetwork/java/javase/overview/tlsreadme2-176330.html
Ok && thx @GianpaoloPedrazza, I'll look into that.
You still have a hostname for me? (BTW: exploresecurities table doesn't reflect that either, so isn't Ivan's latest edition of his book. Not sure about the one statement in the errata though).
Sorry I don't have any hostname I can tell you because the server is running on a private LAN and is unreachable from external IPs.
Thx anyway, @GianpaoloPedrazza.
If anybody else has an example where my test so far seems to fail pls let me know.
It seems that Secure Renegotiation (CVE-2009-3555) refers to whether the server implements RFC 5746.
And Secure Client-Initiated Renegotiation refers only to DoS and not to RFC 5746. It will be marked as "VULNERABLE (NOT ok), DoS threat" if a server allows renegotiation, because it potentially may be susceptible to DoS.
Am I right???
@drwetter: a few months later I have a hostname for you, but it is only for you. Please let me know how I can tell you
:-) Sure, shoot!
(mail address: grep SWCONTACT testssl.sh)
Bear with me a bit pls. Currently my workload is high.
It reports insecure on my exim servers, but I assumed it was reporting the correct result, however I tested just now on proftpd which I know is not vulnerable and yes is a false positive.
I will try again with the proposed code changes. My hostname is the same as in the other ticket.
Ok so I adjusted the following line from
legacycmd="-legacy_server_connect"
to
legacycmd="-no_legacy_server_connect"
and the false positive is gone.
reference here http://www.exploresecurity.com/the-small-print-for-openssl-legacy_renegotiation/
What line is this and in what version? The version updated 5 days does not hav:
"legacycmd="-legacy_server_connect"
# cat testssl.sh | grep legacycmd
local legacycmd=""
legacycmd="-legacy_renegotiation"
echo R | $OPENSSL s_client $OPTIMAL_PROTO $BUGS $legacycmd $STARTTLS -msg -connect $NODEIP:$PORT $SNI $PROXY >$TMPFILE 2>>$ERRFILE &
echo R | $OPENSSL s_client $legacycmd $STARTTLS $BUGS -msg -connect $NODEIP:$PORT $SNI $PROXY >$TMPFILE 2>>$ERRFILE
Thank you.
To be honest I am definitely not sure in what I posted been accurate, plus another tester is reporting exim vulnerable as well.
I have access to a second exim server where the other tester says its not vulnerable, I checked the exim config, but there is nothing special in there which would affect ssl renegotiation so is odd. The second exim server is still marked as vulnerable with this script.
I am pretty sure my proftpd is a false alarm as it has a specific setting for this which I have configured.
Also the version is the dev version.
--edit--
I see in the latest dev the line is different now.
Hi,
Just tested against a jabber server - seeing this issue still:
The problem is the comparing of the return (the openssl check itself is completely valid):
# second try in the foreground as we are sure now it won't hang
echo R | $OPENSSL s_client $legacycmd $STARTTLS $BUGS -msg -connect $NODEIP:$PORT
$SNI $PROXY >$TMPFILE 2>>$ERRFILE
sec_client_renego=$? # 0=client is
renegotiating & doesn't return an error --> vuln!
case "$sec_client_renego" in
0)
pr_svrty_high "VULNERABLE (NOT ok)"; outln ", DoS threat"
fileout "sec_client_renego" "NOT OK" "Secure Client-Initiated
Renegotiation : VULNERABLE (NOT ok), DoS threat"
Calling it manually:
# Note: on os X w/ homebrew client - thus the path
echo R | /usr/local/opt/openssl/bin/openssl s_client -legacy_renegotiation -msg -connect host.tld:port#
Produces this result:
CONNECTED(00000003)
>>> TLS 1.2 [length 0005]
16 03 01 01 2f
>>> TLS 1.2 Handshake [length 012f], ClientHello
01 00 01 2b 03 03 c4 65 79 1f 2d 95 07 59 9a 37
d4 77 be d1 a3 ce 05 66 9c 96 0b 03 27 05 f9 ef
fa 7a dc 4b 56 8f 00 00 ac c0 30 c0 2c c0 28 c0
24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00
6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00
87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0
05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00
40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00
99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0
2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00
96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00
04 c0 12 c0 08 00 16 00 13 00 10 00 0d c0 0d c0
03 00 0a 00 ff 02 01 00 00 55 00 0b 00 04 03 00
01 02 00 0a 00 1c 00 1a 00 17 00 19 00 1c 00 1b
00 18 00 1a 00 16 00 0e 00 0d 00 0b 00 0c 00 09
00 0a 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02
06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01
03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01
140735129973584:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1458792783
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
The part that should be detected is the string:
Secure Renegotiation IS NOT supported
Am 24. März 2016 05:17:44 MEZ, schrieb Ventz Petkov notifications@github.com:
Hi,
Just tested against a jabber server - seeing this issue still:
The problem is the comparing of the return (the openssl check itself is completely valid):
# second try in the foreground as we are sure now it won't hang echo R | $OPENSSL s_client $legacycmd $STARTTLS $BUGS -msg -connect $NODEIP:$PORT $SNI $PROXY >$TMPFILE 2>>$ERRFILE sec_client_renego=$? # 0=client is renegotiating & doesn't return an error --> vuln! case "$sec_client_renego" in 0) pr_svrty_high "VULNERABLE (NOT ok)"; outln ", DoS threat" fileout "sec_client_renego" "NOT OK" "Secure Client-Initiated Renegotiation : VULNERABLE (NOT ok), DoS threat"
Calling it manually:
# Note: on os X w/ homebrew client - thus the path echo R | /usr/local/opt/openssl/bin/openssl s_client -legacy_renegotiation -msg -connect host.tld:port#
Produces this result:
CONNECTED(00000003) >>> TLS 1.2 [length 0005] 16 03 01 01 2f >>> TLS 1.2 Handshake [length 012f], ClientHello 01 00 01 2b 03 03 c4 65 79 1f 2d 95 07 59 9a 37 d4 77 be d1 a3 ce 05 66 9c 96 0b 03 27 05 f9 ef fa 7a dc 4b 56 8f 00 00 ac c0 30 c0 2c c0 28 c0 24 c0 14 c0 0a 00 a5 00 a3 00 a1 00 9f 00 6b 00 6a 00 69 00 68 00 39 00 38 00 37 00 36 00 88 00 87 00 86 00 85 c0 32 c0 2e c0 2a c0 26 c0 0f c0 05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0 23 c0 13 c0 09 00 a4 00 a2 00 a0 00 9e 00 67 00 40 00 3f 00 3e 00 33 00 32 00 31 00 30 00 9a 00 99 00 98 00 97 00 45 00 44 00 43 00 42 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 00 9c 00 3c 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 0c c0 02 00 05 00 04 c0 12 c0 08 00 16 00 13 00 10 00 0d c0 0d c0 03 00 0a 00 ff 02 01 00 00 55 00 0b 00 04 03 00 01 02 00 0a 00 1c 00 1a 00 17 00 19 00 1c 00 1b 00 18 00 1a 00 16 00 0e 00 0d 00 0b 00 0c 00 09 00 0a 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03 02 03 03 02 01 02 02 02 03 00 0f 00 01 01 140735129973584:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 308 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1458792783 Timeout : 300 (sec) Verify return code: 0 (ok) ---
The part that should be detected is the string:
Secure Renegotiation IS NOT supported
You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/drwetter/testssl.sh/issues/234#issuecomment-200657319
Hi Petkov,
thx for catching ip.
I take care of that during Eastern.
Sent from my mobile
Update: I did some weeks back a comparison of the IP @GianpaoloPedrazza supplied privately and checked also some other hosts with SSLlabs. That all was consistent, i.e. not difference between SSLlabs and testssl.
no_legacy_server_connect
is not in every openssl binary available. On one of my machines there's openssl 1.0.1X, it is supported. This current branch with @PeterMosmans fork has not support for it anymore.
Besides I couldn't find this option in the checklist of Jerome (exploresecurity), though he's explicitly referring to it in the link above.
Classic example of a vulnerable host -- don't ask me why akamai is having this:
dirks@laptop:~|0% openssl s_client -connect blogs.akamai.com:443 -no_ign_eof <<< R
CONNECTED(00000003)
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./OU=Corporate Communications/CN=blogs.akamai.com
i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root
i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFjDCCBHSgAwIBAgIULbJODICxcm1FIY0wfUjAcUEZhVcwDQYJKoZIhvcNAQEL
BQAwgY0xCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xJTAjBgNVBAoT
[..]
----END CERTIFICATE-----
subject=/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./OU=Corporate Communications/CN=blogs.akamai.com
issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2
---
No client certificate CA names sent
---
SSL handshake has read 4448 bytes and written 416 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 14EDD21D1A77704EA43CF6F471E7F8E6724FFA22F97641A2586461EF976CCE8F
Session-ID-ctx:
Master-Key: 7F682960655A2DDDE4A1851C9795914228140E21AA8EB03042AEDE8185BC81BC290637D8C24AC742D7F8B16B83940264
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - c2 9a a3 f3 de 01 f8 68-fc ce da 21 41 46 6d 84 .......h...!AFm.
0010 - de af 4b 02 52 f3 53 a2-88 96 16 99 42 61 5b 46 ..K.R.S.....Ba[F
0020 - e3 07 cf 3c 97 be 60 51-4a 24 b2 72 36 50 41 cd ...<..`QJ$.r6PA.
0030 - e5 f7 09 f8 47 43 fe 56-f7 f5 32 78 6f de 85 48 ....GC.V..2xo..H
0040 - bc 38 82 11 c9 62 f4 81-da a4 07 37 09 43 2f cd .8...b.....7.C/.
0050 - de e7 ba 93 6f f8 e0 67-de 91 83 3b 2b 1a 1f eb ....o..g...;+...
0060 - 21 3d 24 c7 d8 db 59 44-35 e3 9a d6 c8 1d de 95 !=$...YD5.......
0070 - 8d d3 c0 d5 4d d5 ba 5e-fe 89 3f 28 b2 1b 36 6f ....M..^..?(..6o
0080 - 79 c8 ba a8 a8 f2 86 d7-48 6b d8 a4 53 8b 48 be y.......Hk..S.H.
0090 - ca 82 e6 ef c3 2d e5 64-6f 17 09 f9 9f 97 da 14 .....-.do.......
Start Time: 1473450842
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
RENEGOTIATING
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
dirks@laptop:~|0% echo $?
0
dirks@laptop:~|0%
You see after RENEGOTIATING it comes again a part of the certificate. It's more obvious if you use the openssl option state or trace.
A non vulnerable host shows the following:
dirks@laptop:~|0% openssl s_client -connect mail.ru:443 -no_ign_eof <<< R
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., CN = GeoTrust SSL CA - G3
verify return:1
depth=0 C = RU, ST = RUSSIAN FEDERATION, L = Moscow, O = LLC Mail.Ru, OU = IT, CN = mail.ru
verify return:1
---
Certificate chain
0 s:/C=RU/ST=RUSSIAN FEDERATION/L=Moscow/O=LLC Mail.Ru/OU=IT/CN=mail.ru
i:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
1 s:/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF7jCCBNagAwIBAgIQafrjsoNQMIGwkH5fIxdtMDANBgkqhkiG9w0BAQsFADBE
[..]
JtvFn/OuFARJneRlrHY4zGY2G8FntzkESTaAnmzR/JAm3g==
-----END CERTIFICATE-----
subject=/C=RU/ST=RUSSIAN FEDERATION/L=Moscow/O=LLC Mail.Ru/OU=IT/CN=mail.ru
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust SSL CA - G3
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3307 bytes and written 516 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 4C7CFD446D616CE600192433E97DB2658E904D0172C87786083678D108194B78
Session-ID-ctx:
Master-Key: 799A0FBA9885584F3255CDE90632E39A28CF7594647919276AEC154D55DD238059F87C634017FFAED3A5E8B017872AFE
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - ba e2 15 9b 7a ab d9 68-ea 83 ea 2f 45 20 73 39 ....z..h.../E s9
0010 - 6c af da 18 fa 48 ee fe-84 e7 b5 b6 7d bb 1b f9 l....H......}...
0020 - f9 06 6e 82 f0 8e b1 32-2a 75 20 bd 64 1b 6f 38 ..n....2*u .d.o8
0030 - 2a 61 0b 48 53 24 8a 1c-3a f0 02 64 c6 6c cd 8b *a.HS$..:..d.l..
0040 - e4 b9 4e 97 16 a2 7c d4-fa 2d f3 03 03 5c 2d 0d ..N...|..-...\-.
0050 - e2 3a 1e b4 68 ed e4 96-7f 47 a1 a6 92 f3 a3 b9 .:..h....G......
0060 - 00 c9 32 55 31 55 99 c7-67 39 51 6a cd ea fc c6 ..2U1U..g9Qj....
0070 - 21 41 3f 52 e0 2f 46 3e-45 05 ab b8 80 10 bf c1 !A?R./F>E.......
0080 - d9 90 75 f1 0a 88 b8 16-9a e2 f2 ca fd fb 6a a8 ..u...........j.
0090 - 86 3b 04 45 14 d9 89 8b-aa 22 0a 0b 34 d8 f1 cc .;.E....."..4...
00a0 - 47 7d 8a fd 1d c3 6a ff-a8 6b 46 66 19 9a 56 d7 G}....j..kFf..V.
Start Time: 1473451170
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
RENEGOTIATING
140053718468496:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
dirks@laptop:~|1%
echo $?
1
dirks@laptop:~|0%
For a pentest last year I was confirming this bug on a webserver by a DoS tool from THC.
DISCLAIMER: Don't run this on machines which aren't yours or you didn't ask for permission. This can have legal consequences for you...
That is cool Also visit my github and download my hacking new tool https://github.com/kittyzomm/ColtSploit
It seems to me that a server is marked as vulnerable against Secure Client-Initiated Renegotiation if a client-initiated renegotiation works. I tested against the save server and I got:
./testssl.sh --openssl=/usr/local/ssl/bin/openssl --wide DUT Secure Client-Initiated Renegotiation VULNERABLE (NOT ok), DoS threat
python sslyze.py DUT:443 --reneg Session Renegotiation : Client-initiated Renegotiations: Honored Secure Renegotiation: Supported
openssl s_client -connect DUT:443 Secure Renegotiation IS supported