Re: tcnative CVE-2015-4000 (Logjam)
I have working binaries for Linux x64 and Windows x64 if anyone needs them. It should still work with newer versions of tomcat 7 providing the SSLProtocol is set to TLSv1? The Windows binary has SSLv2 and SSLv3 disabled at compile time. On 6/13/2015 3:30 PM, Arthur Ramsey wrote: Building the latest from svn branch 1.1.x seems to work. I had to do some modifications to get TLSv1.1 and TLSv1.2 when using |SSLProtocol=all |because I'm using tomcat 7.0.55. Thanks for the help, Arthur On 6/11/2015 3:34 PM, Arthur Ramsey wrote: On 06/11/2015 02:35 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Arthur, On 6/11/15 2:14 PM, Arthur Ramsey wrote: Is anyone aware of a way to mitigate the Logjam attack with tomcat 7 and java 7? Disable DHE_EXPORT on the server? I believe I have, but Qualys SSL Server Test still fails me on the Logjam check. SSLCipherSuite=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK I use tcnative and openssl-1.0.2a both compiled from source in production today, but I would be open to JSSE too. I believe I need Java 8 to mitigate CVE-2015-4000 with JSSE. Why? See http://stackoverflow.com/questions/30352105/how-to-set-custom-dh-group-in-java-sslengine-to-prevent-logjam-attack I don't see anyway to use a unique 2048-bit or greater DH group with tcnative currently. I believe you are correct; there is a bug in BZ: https://bz.apache.org/bugzilla/show_bug.cgi?id=56108 It looks like 1.1.34 will have this feature. You can build the current trunk of the 1.1 branch and probably be okay. Thanks, I'll give it a try. Scary to use in production, but it may be my best answer. I'm not sure if there is anything I can do at compile time. I'd rather not change the cipher suites as I want to maintain browser support. You should disable EXPORT certificates no matter what. Or were you talking about the DH parameters? I was talking about DH parameters. My server configuration passed the Qualys SSL Server Test with flying colors until Logjam, so I would be worried about regressions on other security fixes if I used JSSE. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVeeL0AAoJEBzwKT+lPKRYkJQQAIyplWF0F65zvlzuQTrsFYPC Ioh+w4ddwalB1OFzaxGjnulwN9eO91iudqFiZyFpZnh7jV8GOJCQVO5whbBIXvQm l4RUispklWXNh2ClFfkW2YoXwfZPBhk4um5oVo2KHN7wf3F9AhvA/oz3Ecm2WUdg lQ7q4+WapZknWS6YdxwMzG7Jl7k6gGgnhfe6SmtEYMDKE8ktTcyAjpHX+NhXXC+e iCiZ0+DH1lYmUIHdVJu2FIgdui0CVecArJ9ufniiIpbYOnjWFxu+IZGlBuTgoAHg 8Lu7koGDOOnagSdJ6DNJeEyniRVPA61zcKRIqB1IWJJzgZVIpo8/wF4r9jGFIH3b x+3cqqSiDLppHar48ENIGbqYRCwybRCiJu3SvKLJ/zRs51ybxKbSXOondPWqIRD/ rbLQN6Z/2nQUeSp7A7iKGQj1CqFSDp5IFBqwvP4A9xWFbqCbwOWUfKhgM8UrToLN DRbtjdpGZvA0lJqxmR9nKWn9K9nNRcViI2wlcDOB22RFjz2S+fUToylf8utUJbW0 MJ5GdqnPYMp3r0NajnWaY8z1POneaqnLHnW5xnhLA2UgDBoClUA2Xe/UmU+ngUT3 OOJDb52+Xr3V+JvsDuK6cgoHTM7X+2i3+75acigwMyPYO34hA1uanVhx7XTvheqA XkCixeOIXgynHCDcWYDc =Lycq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks, Arthur
Re: useServerCipherSuitesOrder in 7.0.62
2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com: Hi, I was looking at [1] and it looks the new attribute is available in 7.0.61 onwards as per Violeta's comment. However I cannot find this new attribute in the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm or deny the availability of this attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62. #55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60). useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and NIO section). Note that this feature requires running with Java 8. As a follow up question, I seem to remember that 8.0.latest supports OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also support this or it wasn't backported? It was not backported. Relevant classes are in package org.apache.tomcat.util.net.jsse.openssl: OpenSSLCipherConfigurationParser etc. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with Transfer-Encoding: chunked
On 13/06/2015 15:13, James Nord wrote: On 20/03/2015 16:12, James Nord wrote: Hi all, We have a webapp that when run with tomcat (7.0.52) on a certain host after a period of time has issues with chunking. The issue is that the terminating Zero length chunk is not sent by tomcat even though looking at the last chunk the data is complete. Whilst at first glance this would appear to be our webapp not finishing the request correctly tomcat initiates a TCP level close on the connection 20s after the last chunk has been sent. This 20s corresponds to the keepalive timout so it appears as though Tomcat thinks it is waiting for the next request to come from the client (and the client is still waiting for the terminating chunk). I have written a simple webapp with a servlet that behaves badily in various different ways I can image - and if the serverlet does not return from the doGet method then tomcat will not try and close the tcp connection and it remains open for a long time. We have ruled out network appliances/proxies/ssl and are seeing this when we talk directly to the tomcat http port. The more I look into this the more I think it appears to be a tomcat issue (we have had 3 reports of this and only when our app is run in Tomcat). I'm stuck now as to where I could possible look to get more information or if there is any extra logging in tomcat that I could enable around this area (I looked but didn't see any) to try and narrow the cause down to an area of Tomcat or our app. So I am reaching out with the hope that someone has some ideas... Is it possible for you to re-test with Tomcat 7.0.59? I don't see anything in the changelog that seems to apply directly, but this might be something that was fixed between 7.0.52 and 7.0.59. What connector are you using? Can you supply the (sanitized!) Connector configuration from the server.sml? - -chris I just realized I never circled back on this. Our customer upgraded to 7.0.59 and the issue has not happened since. Dam sent to early. The connector was/is the standard out of the box tomcat configuration. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Issue with Transfer-Encoding: chunked
On 20/03/2015 16:12, James Nord wrote: Hi all, We have a webapp that when run with tomcat (7.0.52) on a certain host after a period of time has issues with chunking. The issue is that the terminating Zero length chunk is not sent by tomcat even though looking at the last chunk the data is complete. Whilst at first glance this would appear to be our webapp not finishing the request correctly tomcat initiates a TCP level close on the connection 20s after the last chunk has been sent. This 20s corresponds to the keepalive timout so it appears as though Tomcat thinks it is waiting for the next request to come from the client (and the client is still waiting for the terminating chunk). I have written a simple webapp with a servlet that behaves badily in various different ways I can image - and if the serverlet does not return from the doGet method then tomcat will not try and close the tcp connection and it remains open for a long time. We have ruled out network appliances/proxies/ssl and are seeing this when we talk directly to the tomcat http port. The more I look into this the more I think it appears to be a tomcat issue (we have had 3 reports of this and only when our app is run in Tomcat). I'm stuck now as to where I could possible look to get more information or if there is any extra logging in tomcat that I could enable around this area (I looked but didn't see any) to try and narrow the cause down to an area of Tomcat or our app. So I am reaching out with the hope that someone has some ideas... Is it possible for you to re-test with Tomcat 7.0.59? I don't see anything in the changelog that seems to apply directly, but this might be something that was fixed between 7.0.52 and 7.0.59. What connector are you using? Can you supply the (sanitized!) Connector configuration from the server.sml? - -chris I just realized I never circled back on this. Our customer upgraded to 7.0.59 and the issue has not happened since. Regards /James - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: useServerCipherSuitesOrder in 7.0.62
Thanks Konstantin, I apologize for the shortsightness. I guess I must have had a space in the search dialog. Thanks for the answers! Cheers, George -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Saturday, June 13, 2015 7:26 AM To: Tomcat Users List Subject: Re: useServerCipherSuitesOrder in 7.0.62 2015-06-13 15:36 GMT+03:00 George Stanchev gstanc...@serena.com: Hi, I was looking at [1] and it looks the new attribute is available in 7.0.61 onwards as per Violeta's comment. However I cannot find this new attribute in the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm or deny the availability of this attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62. #55988 [1] is mentioned in the changelog, twice (7.0.61, 7.0.60). useServerCipherSuitesOrder is mentioned in [2] (in SSL Support - BIO and NIO section). Note that this feature requires running with Java 8. As a follow up question, I seem to remember that 8.0.latest supports OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also support this or it wasn't backported? It was not backported. Relevant classes are in package org.apache.tomcat.util.net.jsse.openssl: OpenSSLCipherConfigurationParser etc. [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
useServerCipherSuitesOrder in 7.0.62
Hi, I was looking at [1] and it looks the new attribute is available in 7.0.61 onwards as per Violeta's comment. However I cannot find this new attribute in the HTTP connector documentation [2] nor the changelog [3]. Can someone confirm or deny the availability of this attribute (useServerCipherSuitesOrder) in Tomcat 7.0.62. As a follow up question, I seem to remember that 8.0.latest supports OpenSSL-style list for the HTTP connector ciphers attribute. Does 7.0.62 also support this or it wasn't backported? Thanks! George [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=55988 [2] https://tomcat.apache.org/tomcat-7.0-doc/config/http.html [3] https://tomcat.apache.org/tomcat-7.0-doc/changelog.html
Re: tcnative CVE-2015-4000 (Logjam)
Building the latest from svn branch 1.1.x seems to work. I had to do some modifications to get TLSv1.1 and TLSv1.2 when using |SSLProtocol=all |because I'm using tomcat 7.0.55. Thanks for the help, Arthur On 6/11/2015 3:34 PM, Arthur Ramsey wrote: On 06/11/2015 02:35 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Arthur, On 6/11/15 2:14 PM, Arthur Ramsey wrote: Is anyone aware of a way to mitigate the Logjam attack with tomcat 7 and java 7? Disable DHE_EXPORT on the server? I believe I have, but Qualys SSL Server Test still fails me on the Logjam check. SSLCipherSuite=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK I use tcnative and openssl-1.0.2a both compiled from source in production today, but I would be open to JSSE too. I believe I need Java 8 to mitigate CVE-2015-4000 with JSSE. Why? See http://stackoverflow.com/questions/30352105/how-to-set-custom-dh-group-in-java-sslengine-to-prevent-logjam-attack I don't see anyway to use a unique 2048-bit or greater DH group with tcnative currently. I believe you are correct; there is a bug in BZ: https://bz.apache.org/bugzilla/show_bug.cgi?id=56108 It looks like 1.1.34 will have this feature. You can build the current trunk of the 1.1 branch and probably be okay. Thanks, I'll give it a try. Scary to use in production, but it may be my best answer. I'm not sure if there is anything I can do at compile time. I'd rather not change the cipher suites as I want to maintain browser support. You should disable EXPORT certificates no matter what. Or were you talking about the DH parameters? I was talking about DH parameters. My server configuration passed the Qualys SSL Server Test with flying colors until Logjam, so I would be worried about regressions on other security fixes if I used JSSE. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVeeL0AAoJEBzwKT+lPKRYkJQQAIyplWF0F65zvlzuQTrsFYPC Ioh+w4ddwalB1OFzaxGjnulwN9eO91iudqFiZyFpZnh7jV8GOJCQVO5whbBIXvQm l4RUispklWXNh2ClFfkW2YoXwfZPBhk4um5oVo2KHN7wf3F9AhvA/oz3Ecm2WUdg lQ7q4+WapZknWS6YdxwMzG7Jl7k6gGgnhfe6SmtEYMDKE8ktTcyAjpHX+NhXXC+e iCiZ0+DH1lYmUIHdVJu2FIgdui0CVecArJ9ufniiIpbYOnjWFxu+IZGlBuTgoAHg 8Lu7koGDOOnagSdJ6DNJeEyniRVPA61zcKRIqB1IWJJzgZVIpo8/wF4r9jGFIH3b x+3cqqSiDLppHar48ENIGbqYRCwybRCiJu3SvKLJ/zRs51ybxKbSXOondPWqIRD/ rbLQN6Z/2nQUeSp7A7iKGQj1CqFSDp5IFBqwvP4A9xWFbqCbwOWUfKhgM8UrToLN DRbtjdpGZvA0lJqxmR9nKWn9K9nNRcViI2wlcDOB22RFjz2S+fUToylf8utUJbW0 MJ5GdqnPYMp3r0NajnWaY8z1POneaqnLHnW5xnhLA2UgDBoClUA2Xe/UmU+ngUT3 OOJDb52+Xr3V+JvsDuK6cgoHTM7X+2i3+75acigwMyPYO34hA1uanVhx7XTvheqA XkCixeOIXgynHCDcWYDc =Lycq -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks, Arthur
