What is the URL they are testing? Is there a reason there is a 9443 port open? How about adding a blank page with a redirect, or use the rewrite valve to rewrite to https?
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: Christopher Schultz <ch...@christopherschultz.net> Sent: Wednesday, August 26, 2020 2:56 PM To: users@tomcat.apache.org Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark, On 8/26/20 13:59, Mark Thomas wrote: > 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. Understood. But what does the OP have in terms of options at this point? 1. Ignore the complaint (probably not possible) 2. Request a waiver for this issue (probably not possible, or at least would require 10 years of red tape) 3. Front the server with httpd + "ErrorDocument 400" (which ... I think will *also* reply with a plaintext response, right?) 4. Switch to Jetty I'm trying to avoid "the easiest thing" which is probably to switch to Jetty. I know our "customers" don't pay for Tomcat, but losing a "customer" sucks. >> 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. How about being able to specify the response text, possibly blank? I think "ErrorDocument 400" with nothing else might mean the same thing as [[ErrorDocument 400 ""]] meaning that the response will include NO CONTENT. Maybe that's what Qualys is looking for. > 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. Yes, "obscurity" doesn't count as a meaningful "security layer", but you usually can't argue with "industry best practices" and "security audits". (I once had a security auditor tell me that we weren't ever allowed to have an encryption key and encrypted data in the same place at the same time, because that would be a violation of a security control.) >> 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. Just what I call "checkbox security". That is... no actual benefit at al l. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9GvlsACgkQHPApP6U8 pFhNvQ/+PqxGIhBt9uTYCecFb9nowQH9CggVlWuBdOmcbxBmkdzG8sTkqEz+CLt2 y4d79y35/OzPFmZLnlO5vALuUf4JRAUMM13cEkSaQN1lsbCfHQU+4IcTIIqlWhQh HZf+SvG1GjLc9ufdTxJQbAc3PThhXTusTGz+FkvYR/KNWtcF+WUcAbpAYH4LqJXY uN9jzLDqz5BiK/7/AuFEZgNOELQgQIyEgptmBdsOsKeJCOfLcVak/yZEPi6Yv9W3 VPoi6HdfqsKvmgGRDN56kSm2gbg/vTa9Y5IKte6Uz+HEH7YCwXE6Ewyxe1WG+V8D Zmh4CwoSRympRxLIU8wWd1hhh74M3OjhuCyMuWbprC+vgqxivStt3Z1WohpGK+G1 SSBKjW3xMCnupagHZvo9jdiYdo4ZgnGDcSCKa1fOP4fWGIfWONYz7CdalQIanrw1 7eG6kfCKrxIvStE1ILIOzkVXnuTGHtOkKX+tLTI1TkCkx6OubBsRPHGOzuQS/rtW KxRPctHaFCe8wEq+7RgZQQEijlWz7P4q5V+/SDCnVvnJRhWEZSvvMwGlzLQTbJZa lKl8ETyBJ4neYS7CJVyiE9Hv5W3g1vszK6s732g5LQdOqFcvI5/Jtqxxx+9WrcLd jmBvfZcCpKi6RUN1PxyP84LtYIJIJsqxnAHc931dSR5p9kgCYwc= =abbf -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
