Re: Nessus scan claims vulnerability in Tomcat 6
Hi Mark, thank you for the feedback! On Tue, Feb 26, 2013 at 2:27 AM, Mark Thomas ma...@apache.org wrote: 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. That's what I figured. - TLS advertises the SPDY protocol earlier than version 4. There is no spdy support in any released Tomcat version. OK, that confirms what I was able to dig up. We have in server.xml: Connector SSLCertificateFile=/path SSLCipherSuite=*** protocol=HTTP/1.1 connectionTimeout=2 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. So one solution would be to remove APR lib from the system. Another one would be to change above to Connector SSLCertificateFile=/path SSLCipherSuite=*** protocol=org.apache.coyote.http11.Http11Protocol connectionTimeout=2 SSLCertificateKeyFile=/path secure=true scheme=https maxThreads=500 port=4712 maxSavePostSize=0 server=*** SSLProtocol=TLSv1 maxPostSize=2048 URIEncoding=UTF-8 SSLEnabled=true / and add all necessary configurations to make that work. And I guess a third option is to use export OPENSSL_NO_DEFAULT_ZLIB=1 before starting the JVM. 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. OK, then it's no surprise that they do not mention it in the Javadocs. :-) APR/native does. An option was recently added. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=54324 I found that but wasn't aware that this is actually used in Tomcat. There is no 6.0.x release with the necessary options yet. Do you know whether there will be? 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
Re: Nessus scan claims vulnerability in Tomcat 6
On 26/02/2013 03:09, Robert Klemme wrote: On Tue, Feb 26, 2013 at 2:27 AM, Mark Thomas ma...@apache.org wrote: On 25/02/2013 08:42, Robert Klemme wrote: 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: We have in server.xml: Connector SSLCertificateFile=/path SSLCipherSuite=*** protocol=HTTP/1.1 connectionTimeout=2 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. So one solution would be to remove APR lib from the system. Yes, although you will see performance for SSL drop. Another one would be to change above to Connector SSLCertificateFile=/path SSLCipherSuite=*** protocol=org.apache.coyote.http11.Http11Protocol connectionTimeout=2 SSLCertificateKeyFile=/path secure=true scheme=https maxThreads=500 port=4712 maxSavePostSize=0 server=*** SSLProtocol=TLSv1 maxPostSize=2048 URIEncoding=UTF-8 SSLEnabled=true / and add all necessary configurations to make that work. And I guess a third option is to use Yes, with the same performance issue. export OPENSSL_NO_DEFAULT_ZLIB=1 before starting the JVM. I don't know if OpenSSL will honour that. APR/native does. An option was recently added. See: https://issues.apache.org/bugzilla/show_bug.cgi?id=54324 I found that but wasn't aware that this is actually used in Tomcat. SSLDisableCompression on the APR connector as of 7.0.37 There is no 6.0.x release with the necessary options yet. Do you know whether there will be? There will be but I'm not aware of any planned timing at this point. The changelog isn't that long but it has been a while since the last release so I guess we should start thinking about it. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Nessus scan claims vulnerability in Tomcat 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/26/13 7:04 AM, Mark Thomas wrote: On 26/02/2013 03:09, Robert Klemme wrote: I found that but wasn't aware that this is actually used in Tomcat. SSLDisableCompression on the APR connector as of 7.0.37 There is no 6.0.x release with the necessary options yet. Do you know whether there will be? There will be but I'm not aware of any planned timing at this point. The changelog isn't that long but it has been a while since the last release so I guess we should start thinking about it. This has been proposed for Tomcat 6.0.x and there are 2 votes for it thus far. Once we get another vote, someone (probably I) will commit the patch and then you just have to wait for another release. 6.0.x releases are less frequent than 7.0.x because Tomcat 6 is ... mature. I'm in Portland with several other Tomcat devs and I'm sure I can a) get someone else to vote for my patch and b) convince someone to roll a release in the near future. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEs0iEACgkQ9CaO5/Lv0PCBYgCfW4BvnsZQHrJ8JAQvSQuryGzH g7oAniHyy2NoH/KO/iVjpsPtAHjmjYY9 =8+mX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Nessus scan claims vulnerability in Tomcat 6
On Tue, Feb 26, 2013 at 4:04 PM, Mark Thomas ma...@apache.org wrote: On 26/02/2013 03:09, Robert Klemme wrote: So one solution would be to remove APR lib from the system. Yes, although you will see performance for SSL drop. Yes, of course. That's not important in our case. export OPENSSL_NO_DEFAULT_ZLIB=1 before starting the JVM. I don't know if OpenSSL will honour that. I'll let you know once I find out. There is no 6.0.x release with the necessary options yet. Do you know whether there will be? There will be but I'm not aware of any planned timing at this point. The changelog isn't that long but it has been a while since the last release so I guess we should start thinking about it. Good! Thanks for the update! 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
Nessus scan claims vulnerability in Tomcat 6
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=2 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
Re: Nessus scan claims vulnerability in Tomcat 6
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=2 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
