You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Pratik Shrestha <pr...@gmail.com> on 2020/09/15 05:20:30 UTC
Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys
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 <pr...@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 <
> chris@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys
Posted by Martin Grigorov <mg...@apache.org>.
hi,
On Tue, Sep 15, 2020 at 8:20 AM Pratik Shrestha <pr...@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 <pr...@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 <
> > chris@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
>