Hi there, I have been confronted with a Nessus scan result which claims vulnerability to exploit "TLS CRIME". Plugin 62565 allegedly has found this and the report states:
"The remote service has one of two configurations that are known to be required for the CRIME attack: - SSL / TLS compression is enabled. - TLS advertises the SPDY protocol earlier than version 4. ... CVE-2012-4929 CVE-2012-4930 " We have in server.xml: <Connector SSLCertificateFile="/path" SSLCipherSuite="*******" protocol="HTTP/1.1" connectionTimeout="20000" SSLCertificateKeyFile="/path" secure="true" scheme="https" maxThreads="500" port="4712" maxSavePostSize="0" server="***" SSLProtocol="TLSv1" maxPostSize="2048" URIEncoding="UTF-8" SSLEnabled="true" /> (paths and some other info replaced by dummies) XML attribute "compression" is not present which according to the docs means "off". I cannot find indication that SPDY does even exist in Tomcat 6. I also could not find anything in the list of vulnerabilities at http://tomcat.apache.org/security-6.html nor could I by searching for combinations of "tomcat" with the issue numbers given above. Now, what to make of this? To me it seems only compression could be the culprit but is there any other way to enable compression for HTTPS than to include "compression"? Or does the TLS negotiation ignore setting "compression"? I could not find indication of any option to control compression in the Javadocs http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/package-summary.html Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
