RE: Tomcat v9 - Insecure transport vulnerability reported by Qualys
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, 27 August, 2020 00:42 To: users@tomcat.apache.org Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys ... (from earlier in this thread) > On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha wrote: > >> Thanks for reply, >> >> Hi Peter - it complains on port 8443 which belongs to Tomcat. >> >> Hi Mark - Yes. making HTTP request on HTTPS is wrong. But this security >> vulnerability is given to us by Qualys scan. It tries to post plain HTTP >> request on HTTPS port and then gets error message "Bad Request. This >> combination >> of host and port requires TLS." which is security loop hole for Qualys. ... >> > With HTTPD rewrite, whether or not the request is encrypted or sent to >> > the correct port can be detected and the request redirected as >> > appropriate. Maybe the same can be done with the rewrite valve used with >> > Tomcat. > This isn't currently possible with Tomcat because of detection of plain > text HTTP when TLS should be used (and the generation of the associated > response) is much, much earlier in the processing chain than the rewrite > valve. Since the server side is expecting a TLS connection, and the TLS session must be established first _before_ the HTTP request can be sent across that connection, wouldn't it be more logical to simply return a TLS error and reject the connection attempt since the TLS session setup failed. How and why is the server attempting to respond to the HTTP before the TLS session has been established? I think what the Qualys scan is trying to flag is that the server (Tomcat) is listening for both secured and unsecured traffic on the _same_ TCP port when the server should be listening for just one of the two options (unsecured or secured), not both. The error message returned by the Tomcat service, while certainly helpful to the remote client, is returning more information than it should (from a security-viewpoint). If the default behavior for Tomcat is to return this "helpful" message for misconfigured clients, would it be reasonable for the Connector to have an option (attribute) for turning off this feature and simply reject with a TLS error any unsecured traffic on the port? This would address the security concern without imposing too much "bloat" to the Tomcat side. For most other web servers (Apache httpd, NGINX, etc.) that offer https, the normal behavior is that when an http client tries to speak http to server expecting https, the client sees some garbled text (the server's TLS response to the connection attempt). Cheers! Simba Engineering - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat won't use TLSv1.2
> . wrote: >>On 2020-03-05 at 23:10 rugman66 wrote: > On Thu, Mar 5, 2020 at 10:44 AM i...@flyingfischer.ch > wrote: >> Try SSLProtocol="TLSv1.2" (mind the case) instead of sslProtocol="-all >> +TLSv1.2". >> >> Had this issue too. The connector parameters for SSL are a huge mess and >> have been changed constantly. >> >> Best >> Markus >> >> On 2020-03-05 at 19:30 rugman66 wrote: >>> Hello, >>> >>> I have both Apache and Tomcat running on the same RHEL. I have successfully >>> configured Apache to use OpenSSL TLSv1.2, but I cannot get Tomcat to use >>> TLSv1.2. Tomcat for some reason >>> >>> will only use TLV 1.0, and that is no good. No matter what parameter I set >>> in the server.xml sslProtocol directive it won’t change. Seems like it’s >>> getting that directive somewhere else but I can't locate. >>> >>> >> scheme="https" >>> secure="true" >>> protocol="org.apache.coyote.http11.Http11AprProtocol" >>> SSLEnabled="true" >>> SSLCertificateFile="/auto/englearn-web/ssl_certificate/server.cer" >>> >>> SSLCertificateChainFile="/auto/englearn-web/ssl_certificate/chain.cer" >>> >>> SSLCertificateKeyFile="/auto/englearn-web/ssl_certificate/server.key" >>> SSLCipherSuite="RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW" >>> SSLHonorCipherOrder="true" >>> maxThreads="150" >>> clientAuth="false" >>> sslProtocol="-all +TLSv1.2" /> >>> >>> >>> >>> OpenSSL 1.0.2d >>> >>> Tomcat 7.0.39 (I know it’s old, but it's what I have to work with at this >>> time) >>> >>> >>> Thank you for any insight. >>> >>> -John >>> > Sorry, that last reply sent before I was done for some reason. > >> Thanks Markus, >> >> One final issue. One version of the URL is still using TLS 1.0, and I >> need to disable or force it to TLS v1.2 and can't find where to do >> that. >> >> https ://server.domain.com (TLSv 1.2) >> https ://server.domain.com/foo (Apache proxy TLSv1.2 >> https ://server.domain.com:8443 (TLS 1.0) >> >> Thanks >> -John >> > These three URLs do use two different connectors: on Port 443 and on Port > 8443. > Make sure you have configured both connectors accordingly. > Best > Markus --- Keep in mind that the Java JVM may need help as well (depending on which version of the Java JVM runtime is hosting the Apache Tomcat). Oracle documentation covers this topic well at the URL See: https://www.java.com/en/configure_crypto.html https:// www. java .com /en/configure_crypto.html Scroll down to the paragraph "Changing default TLS protocol version for client end points : TLS 1.0 to TLS 1.2". Cheers! Simba Engineering
RE: Not sure what to make of this, Re: bringing up HTTPS on Tomcat
IBM's documentation on this web page: http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/topic/com.ibm.websphere.iseries.doc/info/ae/ae/secmigjsse.htm provides instructions on how to export the certificates from DCM into Java keystores. As they mention below, they've moved away from using the proprietary .kdb keystore format and now support using the standard Java .jks format. The use of OS/400 *SYSTEM certificate stores (.kdb files) for WebSphere Application Server applications was deprecated in WebSphere Application Server Version 5.x. In Version 6 and later, only Java keystores (.jks files) are fully supported. You must migrate your applications to use Java keystores. DCM uses PKCS12 format to export client and server certificates, and it uses base64 encoded format to export certificate authority certificates However, you must to convert the base64 encoded data from EBCDIC to ASCII format See the web page for complete instructions, including converting from EBCDIC to ASCII. Cheers! Simba Engineering -Original Message- From: James Lampert [mailto:jam...@touchtonecorp.com] Sent: Friday, 05 October, 2012 09:29 To: Tomcat Users List Subject: Re: Not sure what to make of this, Re: bringing up HTTPS on Tomcat Mark H. Wood wrote: I have no idea what DCM is or does. Maybe it works with PKCS #12 files, which can carry both parts in a single container. That part isn't really relevant here (I hope), but to clarify: DCM = Digital Certificate Manager. It's part of the IBM Midrange operating system (i.e, OS/400, i5OS, or whatever they're calling it this week). It uses an entirely different keystore format from that used by Java and Keytool (and, by extension, Tomcat), and so far as I (and the real IBM Midrange gurus on the various Midrange.com lists) can determine, there's nothing currently available to convert a keystore between the IBM-proprietary format and the Java format. We've had more than one customer who screwed themselves out of a certificate signing fee by failing to appreciate the distinction, even though we do our best to warn them about it. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
