Hi Guys, Just wanted to know if anyone found an idea on fixing it or a workaround.
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 >> >>