Dear all,
Thanks for so many replies and your discussions.
For me, there are two options for the fix which I am not able to make them
work.
1. Either show 'ERR_EMPTY_RESP' like old Tomcat version 7 used to show. As
far as I know, with Tomcat 7 giving that error, Qualys did not use to show
this vulnerability.
2. *Best is to do a redirect* when Tomcat sees error 400 to https URL. Like
in Apache, we can add below.
'ErrorDocument 400 "*https*://xxx.xxx.xxx.xxx"
But as understood, redirect only works with error 3XX and ErrorDocument
feature is not there in Tomcat yet.
@Jon, yes, what we want is redirect on error 400 (explained in #2 above).
And please ignore port 9443.
Regards,
Pratik
On Thu, Aug 27, 2020 at 3:16 AM <jonmcalexan...@wellsfargo.com.invalid>
wrote:
> 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
>
>
