-----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
