On 25/02/2013 08:42, Robert Klemme wrote:
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.
It is this one.
- TLS advertises the SPDY protocol earlier than version 4.
There is no spdy support in any released Tomcat version.
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" />
That is the APR/native HTTPS connector.
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
You won't. My recollection is that Java does not support compression.
APR/native does. An option was recently added. See:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54324
There is no 6.0.x release with the necessary options yet.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
