On 26/08/2020 17:50, Christopher Schultz wrote: > On 8/26/20 05:27, Mark Thomas wrote: >> On 26/08/2020 08:14, Martin Grigorov wrote: >>> Hi, >>> >>> 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. > >> On what basis? > >> I fail to see any security issue here other than "Qualys says so" >> which is not a valid description of a security vulnerability. > > My guess is that this is some form of "server fingerprinting" that > they are claiming, like "Zomg! It says Server: Apache-Coyote/1.1! You > are $uper vulnerable to 0days, now!".
The entire response, including headers is, ===== HTTP/1.1 400 Content-Type: text/plain;charset=UTF-8 Connection: close Bad Request This combination of host and port requires TLS. ===== > Pratik, can you please be very clear about what the actual complaint > is? Are they objecting to one or more of the following: > > 0. Any legible response at all (meaning they just want a > connection-drop response) > 1. Server: Apache-Coyote/1.1 response header > 2. Predictable / stock text (e.g. "Bad Request. This > combination of host and port requires TLS." identifies the server as > Tomcat v.x.y or later) > 3. Actual Tomcat version number in response > >> Absent a description of how this can be exploited (and I'll be >> very surprised if this can be exploited), there is no security >> issue here and Tomcat will not be making any changes. > > It seems reasonable to (configurably) strip-out version information if > there is anything in there... which there probably is not. Correct, there isn't. > I'm interested in having Tomcat be able to pass these (admittedly > stupid) security requirements, I have no interest in adding bloat to Tomcat so it can pass so called security requirements that have no relevance to actual security. Those sort of changes are the sort that get me starting to think about using a veto. > so maybe we could have a setting on the > <Connector> that can allow ERR_EMPTY_RESP to be sent if the handshake > fails due to probably-not-encrypted just like older versions of Tomcat> did. That sounds suspiciously like bloat to me. I've never been particularly convinced by the fingerprinting argument. Either you are running a version without any published security vulnerabilities that affect you (in which case fingerprinting doesn't help the attacker) or you are running a version with published security vulnerabilities that do affect you and you are relying on security by obscurity - which is no security at all. > IMO, being able to reply in plaintext like this is a *feature* (one > that I personally and specifically lobbied to have added to Tomcat) > and shouldn't be removed. If it's not the end of the world to add an > option to disable it, though, I think we ought to do it. I'm not (yet) convinced of the benefits of such an option. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
