-----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 <pratik...@gmail.com> 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
