J Wolfgang Goerlich's thoughts on Information Security
Audit for SSL/TLS renegotiation

By wolfgang. 16 November 2009 14:43

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.





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.)


Apache | Cryptography | IIS | Security

Apache Versus Internet Information Services Security

By wolfgang. 29 March 2009 19:21

Fresh from a recent debate on Apache versus IIS security, I bring you this summary. I am not in a position to directly compare IIS versus Apache. When I build an IIS server, I am fairly confident in its security. If I were to build an Apache server, I would have little confidence due to my inexperience. So much depends upon the admin's skillset.

Quantitatively, Apache has more known vulnerabilities and attacks than IIS. IIS5 on Windows 2003 has 4 vulnerabilities. IIS6 on Windows 2008 has 1 published vulnerability. By contrast, Apache 2.0.x has 23 vulnerabilities.

The counter-argument to these statistics is this: most of the 23 vulnerabilities were in Apache modules. The attack surface drops significantly if you disable these modules. (And, of course, if you know how to disable the modules.)

Another counter-argument is that the web server depends upon the operating system. A determined attacker goes around your defenses rather than thru them. Thus I would suspect the security would turn more on the OS and the Web applications.

Secunia: IIS 6.x

Secunia: IIS 7.x

Secunia: Apache 2.0.x


Security | Apache | IIS

    Log in