06-06-2012 05:15 AM - edited 03-17-2019 11:17 PM
Hi guys,
a security audit (also in the video environment) brought up a "small risk" regarding SSL / TLS Renegotiation Handshakes on a VCS Expressway (X7.1).
This VCS-E is a dual network port installation and the audit result relates to the test which were made on the external port with a static public ip adress.
The SSL / TLS renegotiation function requires for a handshake server-side at least ten times more computing time than the client. This is the risk that an attacker can restrict a massive flood of SSL handshake, the server availability.
Explication of F5:
The question is, how we can close this security breach?
Many thanks in advance,
Fabian
06-06-2012 05:31 AM
Hi Fabian,
the recommended way of deploying a VCS-E is to ensure that the management services of the VCS-E (http, https, ssh, telnet etc) are not directly accessible from public networks. This is normally achieved by placing a firewall in front of the VCS-E blocking off access to the ports associated with these management services.
Additionally, the VCS-E supports being deployed in a private DMZ with a private IP address (With the use of the 'Dual network interfaces' option key) using static NAT, which will further help protect the VCS from unauthorised outside access
NAT itself is not a real security measure but deploying the VCS using static NAT means that you will have a router/firewall in front of the VCS-E which will enable you to block access to your VCS-E for http, https,ssh and so forth from public networks.
Another thing worth noting is that for the upcoming X7.2 release for the VCS, we are looking at including a basic built-in firewall on the VCS itself which could also be used to only permit access to certain services from certain hosts or subnets. It is however not currently certain whether or not this feature will actually make it into X7.2, so you will just have to wait and see.
Finally, even if/when the VCS(-E) has built-in firewall capabilities, we would always recommend having a dedicated firewall protecting the VCS(-E) from unauthorised external user access from public networks whenever possible.
Hope this helps!
- Andreas
06-06-2012 05:35 AM
Hi all,
What Andreas states is true for management, although doesn't help for TLS use in SIP etc.
Do you have a CVE number for this risk?
Thanks,
Guy
06-06-2012 06:09 AM
Looking in the OpenSSL http://www.openssl.org/news/vulnerabilities.html list I can see
CVE-2009-3555: 5th November 2009
Implement RFC5746 to address vulnerabilities in SSL/TLS renegotiation.
Fixed in OpenSSL 0.9.8m
So VCS should have that fix as it runs a more recent verions of OpenSSL in X7.1
I cannot find any newer published CVE on this. So a CVE number and the output and information on the scan tool used would be very helpful.
06-06-2012 07:18 AM
Thanks Andreas.
Thank you Guy for your efforts.
I'll go on to get the CVE No. and also the output information.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide