The vulnerability exists in the protocol itself and not a specific implementation of the protocol e.g., OpenSSL, GnuTLS, etc. Thus, the mitigation is to stop using SSLv3 and to have TLSv1+ as the minimum.
Both clients and servers are vulnerable to the attack. Server administrators should configure all services to disable the use of SSLv3. There are numerous sources[2] documenting the disabling of SSLv3 on browsers. Again, unfortunately Apple's Safari does not appear to be as configurable has not provided such control for Safari to disable SSLv3. In fact Apple's approach seems to have been to disable CBC mode encryption if TLS negotiation fails. However Safari Version 8.0 (10600.1.25) on Yosemite, i.e Mac OS X 10.10 still appeared to be vulnerable using the poodletest.com website[4].
In addition to disabling SSLv3 at the servers and browsers, it may also be desirable to block SSLv3 traffic at the network perimeter in case something is not patched. This would require examining the SSL handshakes for the cipher suite negotiation, and blocking SSLv3 connections. Fortunately someone has already done the hardwork[1] of finding the offsets, etc.
References
- https://blog.g3rt.nl/take-down-sslv3-using-iptables.html
- https://zmap.io/sslv3/browsers.html
- http://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability
- https://www.poodletest.com/
Thank you for the good article.
ReplyDelete