An SSL/TLS renegotiation attack has been carried out against Twitter. The Register has some details on the Twitter attack, while Educated Guesswork has the technical details on the renegotiation vulnerability itself.
SSL/TLS renegotiation has been used to get a web server to downshift its cipher and key length before. The new angle is using renegotiation to cause both the web server and the browser to renegotiate and create a man-in-the-middle scenario. Once in the inserted in the middle of web server and browser, the attacker can access the HTTP stream unencrypted.
Being an IT operations security guy, my focus is on auditing for and protecting against the weakness. The mitigation is simple: disable renegotiation. As for auditing, you can use openssl on any Linux OS to test.
sudo openssl s_client -connect www.yourhosthere.com:443
You will see the certificate chain, server certificate, SSL handshake, and SSL session details. The session is established when you get prompted verify return code: 0 (ok).
Now suppose OpenSSL reports verify error:num=20:unable to get local issuer certificate.)I have seen this error on GoDaddy websites. To resolve, browse to the website with Firefox. Open the certificate viewer and click the details tab. There, below the details, click the Export button. Save the certificate file in the x.509 PEM format with a .pem extension (Example: godaddy.pem). Then rerun OpenSSL and specify the certificate authority file.
sudo openssl s_client -connect www.yourhosthere.com:443 –CAfile godaddy.pem
Make an HTTP request and then request renegotiation.
HEAD / HTTP/1.0
R
The error ssl handshake failure indicates the web server is denying renegotiations. If OpenSSL renegotiates successfully, you will see a new certificate path and then read read:errno=0. Contact your web server administrator if the server renegotiates.
(Update 2009-12/18: You can use the Matriux distro to perform the above steps.)