All Barracuda Spam & Virus Firewalls
This issue involves BNSF-17277 (CVE-2011-1473), an issue reported in August of 2011.
In order to test for this vulnerability, run the following command using openssl (making sure to replace the <HOST> parameter with the relevant value):
openssl s_client -connect <HOST>:443
You will see a good amount of SSL certificate related output. After this output has completed, enter the first line of a request followed by a capital R, such as:
HEAD / HTTP/1.0
The R directs s_client to renegotiate. The server will respond with:
If the target device then returns a response as shown below to the http request, the device is vulnerable to the issue.
HTTP/1.1 200 OK
Date: Fri, 26 Apr 2013 18:20:05 GMT
Last-Modified: Sun, 27 Jan 2013 21:11:23 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Depending upon the version of the openssl client used, a device that is not vulnerable will respond in one of two ways. Client versions of openssl released since 2010 will close the connection immediately. Earlier versions of the client will block the call for a period of time and eventually close the connection. During that time a user can type additional R commands and it may appear that the renegotiation is happening even though it is not.
In both cases, when the connection drops an error message similar to this will be present in the output:
17424:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:543:
The appearance of this message and the failure of the server to respond to the http request indicates the client side renegotiation did not happen and that the device is not vulnerable to this attack.
Additional Note: Some penetration testing is coming up with this as a false positive because the connection is not immediately terminated. While this is unexpected in most testing results, it is not vulnerable and needs to be understood as currently we have no change for this.
Please see the following link for more information:
Link to this page: