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