Did Qualsys include a QID with their report?
Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Wednesday, August 26, 2020 12:59 PM To: users@tomcat.apache.org Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys 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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
