hi, On Tue, Sep 15, 2020 at 8:20 AM Pratik Shrestha <pratik...@gmail.com> wrote:
> Hi Guys, > > Just wanted to know if anyone found an idea on fixing it or a workaround. > Did you find what is the expected behavior by Qualis ? > > Thanks > > Pratik. > > On Fri, Aug 28, 2020 at 10:46 AM Pratik Shrestha <pratik...@gmail.com> > wrote: > > > Hi Chris > > > > > > > > > > *This wasn't the case for httpd for many years. I don't know what itdoes > > these days, but it used to reply with a nice "400 Bad Request"error just > > like Tomcat is doing. The difference is that httpd has richconfiguration > > options to allow you to override that behavior. * > > > > Correct. By default HTTP also gives 400 Bad Request message. But we can > > override this behavior by using ErrorDocument directive to redirect to > > https URL. Currently in Tomcat this feature is not available. Tomcat has > > RewriteValve but it does not work in this case. > > > > On Fri, Aug 28, 2020 at 12:30 AM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA256 > >> > >> Merka, > >> > >> On 8/27/20 06:32, Phoenix, Merka wrote: > >> > I think what the Qualys scan is trying to flag is that the server > >> > (Tomcat) is listening for both secured and unsecured traffic on > >> > the _same_ TCP port when the server should be listening for just > >> > one of the two options (unsecured or secured), not both. > >> This actually might be a semi-legitimate test. If the client says "Our > >> policy is to only communicate using encrypted connections" and the > >> test says "well, here's a non-encrypted connection right here!" then > >> it makes some small amount of sense. In that case, it's all driven by > >> policy, and the policy can say "we have a carve-out for TLS handshake > >> failures" and then allow that particular test to pass. > >> > >> > The error message returned by the Tomcat service, while certainly > >> > helpful to the remote client, is returning more information than > >> > it should (from a security-viewpoint). > >> Not really. > >> > >> > If the default behavior for Tomcat is to return this "helpful" > >> > message for misconfigured clients, would it be reasonable for the > >> > Connector to have an option (attribute) for turning off this > >> > feature and simply reject with a TLS error any unsecured traffic on > >> > the port? This would address the security concern without imposing > >> > too much "bloat" to the Tomcat side. > >> I think this might actually be better/easier than implementing a > >> redirect. It's a simple flag that says "return nice errors on > >> plaintext-over-TLS connection attempts" (or similar) and the only > >> thing that changes is that we STOP trying to be nice to the client if > >> the setting is set to "fail" versus "be-nice". > >> > >> > For most other web servers (Apache httpd, NGINX, etc.) that offer > >> > https, the normal behavior is that when an http client tries to > >> > speak http to server expecting https, the client sees some garbled > >> > text (the server's TLS response to the connection attempt). > >> This wasn't the case for httpd for many years. I don't know what it > >> does these days, but it used to reply with a nice "400 Bad Request" > >> error just like Tomcat is doing. The difference is that httpd has rich > >> configuration options to allow you to override that behavior. > >> > >> - -chris > >> -----BEGIN PGP SIGNATURE----- > >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > >> > >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9H7ZkACgkQHPApP6U8 > >> pFgOng/8DtMJkQc+MYLRm1iuCD7GZ2f2S7oQ59vFeCGAbmkiUjESvQ42QRGqIMy8 > >> 47giFc3ERm84DxyyyU7O/YDFxinOnCrC/v9A6RzpYKlZBSOq9Oy6732xTUAqGGIw > >> +3QGPXvyjE2Vcg1iavW+7cUKN1Q9R1NGcDRRBpBL0KRQMA3NV9pxGU71/In8TQvi > >> VZ51f7VTNXaJ2l+w6G23XBJkKQk3csFixevVzr4Xr56FLfqPxUc3m6QNu4BaHmgb > >> c95hceV/N7tkR9yHdaRtahpZq0lhGqXbNXfqjf7kElSkRmeAZ3MSsdnFD4fBHThn > >> xvz204xffSE71Z4W24W9gx23+Bg0y2EfPRo1CWC93rEvNRKMK6ILzLczTRA0w6QW > >> 9zP1XC+VwC25LQOGFDgFukQVupPYiMoNSb6DRey5ZUhur6v25nevwbhM0QsAm/oO > >> oZpreKaUMy+ZoixwGhaZ+UFiZRav7DRLSj85BjK9PqcP4VdPzFR9MarvMqLPxRoq > >> YxL/jNet4L+29Z2tDkZv4gfGJqI7oWkfXUsBFBjj5JgXrqE94Q8PzAK87pLeU80y > >> p3IL4krovHbu01j1fE3/aDotEvBu/wxWTCWze9+vL09a82PuTT2pihyCVqFuP9rS > >> kP0DtVTfbaUMyD2dryjyw4q1NdLYht4y/HHkyU/3cPopCbxEopU= > >> =4F4z > >> -----END PGP SIGNATURE----- > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> >
