 |
We had similar reports when SSLv2 support has been dropped. But we don't want to diverge from Debian on this sensitive package... there are some applications that link statically against a libssl configured with SSLv2/SSLv3 precisely to avoid this. |
|
|
On which application is this causing you troubles? (sslscan is the application that is specifically using a static copy of openssl) |
 |
Other than OpenSSL, no specific application. We use the OpenSSL binary to enumerate what parameters a host allows to build its SSL/TLS connections. There are utilities (like sslscan) that replicate some of the functionality, but none do it all, such as sending/receiving data on a raw SSL/TLS socket. I understand why Debian disabled all versions of SSL, but in the case of Kali, it's necessary to still be able to use older (even unsafe) protocols for testing. |
 |
SSLv3 is droppen because of the SSL-TLS Poodle Attack Vector. Correct me if im wrong! |
|
|
Definitely, kimocoder! And that completely makes sense for a production web server. My reasoning is that Kali is most often used in testing, where the threat and damage of a POODLE attack is negligible. And if you /are/ in a situation where it's a possible attack vector, then you should disallow SSLv3 on your own. Just for emphasis: "in the case of Kali, it's necessary to still be able to use older (even unsafe) protocols for testing." |
 |
I disagree. Weakening SSL globally in Kali for the sake of some client tools is not acceptable in my eyes. These kind of modifications are better off made on an individual basis - feel free to recompile the openssl package and make any modifications you need for your specific testing environment. eg: apt-get update dpkg-buildpackage |
- Anonymous
