SSL re-negoiation vulnerability & how do I check ?

Okay this post goes hand-in-hand with the previous openssl tip.  I forgot this one tip,  and I promised this is the last one.... will for now :)


SSL is subject to a major flaw know as "SSL Renegotiation vulnerabilities". What this means, a MiTM attacker could easily hijack an already  establish ssl connection, & renegotiated with the server ( if the server was vulnerable and exposed ).

Or conduct a flood, causing unwanted cpu cycles re-negotiation a client.

So how do you know if your server is vulnerable?

Okay, very easy.

We use  OpenSSL to test the server,  and it's action upon a request to reneg from a client.

Here's how;

openssl s_client  -connect www.example.com:443 -state

Once connected, you issues a capital  R all by it's self and with a carriage return.

If the server support renegotiation, you will see the following displayed;

R
RENEGOTIATING
SSL_connect:SSL renegotiate ciphers
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
R
RENEGOTIATING
SSL_connect:SSL renegotiate ciphers
SSL_connect:SSLv3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Somewhere/L=Somecity/O=CompanyName/OU=Organizational Unit Name (eg, section)/CN=Common Name (eg, YOUR name)/emailAddress=Email Address
verify return:1
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
SSL3 alert read:warning:close notify
closed
SSL3 alert write:warning:close notify
hackbox:

Okay so that's the quick easy way to test. But how do you protect yourself from this attack?


Easy;

• patch all of your systems, and all applications that uses ssl/tls
• determine if you need renegotiation
• eliminate any weak cipher supports
• upon openssl s_client establish check for "Secure Renegotiation IS NOT supported", if present , deny and/or fix the server or just turn off re-negotiation
• review your server logs
• disable SSLv2 ( anything modern , should already have been disable ,, but ..... always check )
• contract with a security auditor and pen-tester like myself  and schedule regular vulnerabilities testing
• install a WAF or some other application firewall,  or other  mitigation gear ( i.e F5 SLB,IPS )  
• install SSL offloader  and accelerator 

The above sample output ,  was from a server and a past  gig that I completed. We identified this risk and worked with the SySAdmins, to fix the issues.

I hope you found this post useful and helpful.

Ken Felix
Freelance Network/Security Engineer
kfelix-a@t-hyperfeed-dot-com