Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Martin Grigorov]

hi,

On Tue, Sep 15, 2020 at 8:20 AM Pratik Shrestha  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 
> 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
> >>
> >>
>

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Pratik Shrestha]

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

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Pratik Shrestha]

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

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Christopher Schultz]

-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

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Mark Thomas]

On 27/08/2020 11:32, Phoenix, Merka wrote:



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

What, exactly, are the security concerns here? Your comment suggests
there is some form of information disclosure vulnerability. What
information?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Phoenix, Merka]

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Thursday, 27 August, 2020 00:42
To: users@tomcat.apache.org
Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys
 ... (from earlier in this thread)
> On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha  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.
...

>> > With HTTPD rewrite, whether or not the request is encrypted or sent to
>> > the correct port can be detected and the request redirected as
>> > appropriate. Maybe the same can be done with the rewrite valve used with
>> > Tomcat.

> This isn't currently possible with Tomcat because of detection of plain
> text HTTP when TLS should be used (and the generation of the associated
> response) is much, much earlier in the processing chain than the rewrite
> valve.

Since the server side is expecting a TLS connection, and the TLS session must 
be established first _before_ the HTTP request can be sent across that 
connection, wouldn't it be more logical to simply return a TLS error and reject 
the connection attempt since the TLS session setup failed. How and why is the 
server attempting to respond to the HTTP before the TLS session has been 
established? 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. 

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

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. 

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

Cheers!

Simba
Engineering

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Peter Kreuser]

Mark,

Sorry for Top-posting.

I’m still wondering what is causing this Qualys finding.

I remember times when you got only garbage when you connected with http to 
https. Probably Qualys was fine with that.

Now you get a nice 400 message that helps the user understand his mistake and 
Qualys jumps on that!
From my point of view we should not change that behavior as it will not change 
the users settings or mistyping.

I wonder how Nginx or httpd are reacting to this finding - if Qualys reacts in 
the same way?
Basically the scanner already has the information that this is an SSL port!
To me a bug in the scanner plugin!

My 2ct.

Peter

> Am 27.08.2020 um 09:47 schrieb Mark Thomas :
> 
> On 27/08/2020 06:31, Terence M. Bandoian wrote:
>> On 8/26/2020 11:27 PM, Pratik Shrestha wrote:
> 
> 
> 
>>> 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.
> 
> 
> 
>> With HTTPD rewrite, whether or not the request is encrypted or sent to
>> the correct port can be detected and the request redirected as
>> appropriate. Maybe the same can be done with the rewrite valve used with
>> Tomcat.
> 
> This isn't currently possible with Tomcat because of detection of plain
> text HTTP when TLS should be used (and the generation of the associated
> response) is much, much earlier in the processing chain than the rewrite
> valve.
> 
> 
> 
> On 8/26/20 13:59, Mark Thomas wrote:
>> On 26/08/2020 17:50, Christopher Schultz wrote:
> 
> 
> 
>>> 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.
> 
> One of the things I love about working Tomcat is when this sort of
> security nonsense comes along, I can a) call it out and b) veto (if I
> have to) the implementation without someone higher up the organisational
> hierarchy able to play the "I don't care if it is nonsense, our
> customers want it so you have to implement it" card.
> 
> My objection to implementing or changing features in response to
> "security nonsense" is that it perpetuates the problem. If people who
> know this is "security nonsense" just accept it rather than arguing
> against it, that nonsense eventually becomes "security fact". I think
> the world could do with a little more security fact and a little less
> security nonsense.
> 
> That said, I'm not against changing this feature where that change
> offers real benefits to users.
> 
>> How about being able to specify the response text, possibly blank?
> 
> While I remember, there was the issue raised that the response wasn't
> UTF-8 and we changed hard-coded response to UTF-8 rather than provide an
> option.
> 
> My concern with anything along the lines of making it configurable is
> that because this response is generated outside of the normal HTTP
> processing infrastructure you can quickly get into the situation where
> you end up replicating functionality we already have elsewhere.
> 
>> 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.
> 
> My reading of the thread so far is that the security scanner expects
> either a TLS error or a redirect to https.
> 
> The redirect option is interesting. I can see user benefit in http
> requests to an https port getting redirected to https. The tricky part
> is implementing it. Redirection to a fixed URL is quite simple. As soon
> as you get into redirecting the actual user's request you open up the
> HTTP request parsing can of worms.
> 
> I'm wondering if there is a way to utilise the standard request
> processing 

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Mark Thomas]

On 27/08/2020 06:31, Terence M. Bandoian wrote:
> On 8/26/2020 11:27 PM, Pratik Shrestha wrote:



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



> With HTTPD rewrite, whether or not the request is encrypted or sent to
> the correct port can be detected and the request redirected as
> appropriate. Maybe the same can be done with the rewrite valve used with
> Tomcat.

This isn't currently possible with Tomcat because of detection of plain
text HTTP when TLS should be used (and the generation of the associated
response) is much, much earlier in the processing chain than the rewrite
valve.



 On 8/26/20 13:59, Mark Thomas wrote:
> On 26/08/2020 17:50, Christopher Schultz wrote:



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

One of the things I love about working Tomcat is when this sort of
security nonsense comes along, I can a) call it out and b) veto (if I
have to) the implementation without someone higher up the organisational
hierarchy able to play the "I don't care if it is nonsense, our
customers want it so you have to implement it" card.

My objection to implementing or changing features in response to
"security nonsense" is that it perpetuates the problem. If people who
know this is "security nonsense" just accept it rather than arguing
against it, that nonsense eventually becomes "security fact". I think
the world could do with a little more security fact and a little less
security nonsense.

That said, I'm not against changing this feature where that change
offers real benefits to users.

> How about being able to specify the response text, possibly blank?

While I remember, there was the issue raised that the response wasn't
UTF-8 and we changed hard-coded response to UTF-8 rather than provide an
option.

My concern with anything along the lines of making it configurable is
that because this response is generated outside of the normal HTTP
processing infrastructure you can quickly get into the situation where
you end up replicating functionality we already have elsewhere.

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

My reading of the thread so far is that the security scanner expects
either a TLS error or a redirect to https.

The redirect option is interesting. I can see user benefit in http
requests to an https port getting redirected to https. The tricky part
is implementing it. Redirection to a fixed URL is quite simple. As soon
as you get into redirecting the actual user's request you open up the
HTTP request parsing can of worms.

I'm wondering if there is a way to utilise the standard request
processing infrastructure for these http over https requests (so we can
use the existing http processing infrastructure to parse the request and
issue a redirect to https) without creating the risk that we process the
http request without the redirect as that would be very bad.

Given the number of times redirect has been mentioned I think I'll spend
some time looking into how possible it is to redirect the user's http
request to https. My instinct is that it isn't going to be doable but it
is worth a look.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Terence M. Bandoian]

On 8/26/2020 11:27 PM, Pratik Shrestha wrote:

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


With HTTPD rewrite, whether or not the request is encrypted or sent to 
the correct port can be detected and the request redirected as 
appropriate. Maybe the same can be done with the rewrite valve used with 
Tomcat.


-Terence Bandoian


On Thu, Aug 27, 2020 at 3:16 AM 
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 
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
 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

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Pratik Shrestha]

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

RE: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[jonmcalexander]

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

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Christopher Schultz]

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

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jon,

On 8/26/20 14:01, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Did Qualsys include a QID with their report?

No, but the OP did include this:

"
Insecure transport
Group: Information Disclosure
CWE CWE-319
OWASP A3 Sensitive Data Exposure
WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
"

Upon further inspection, I think this might actually be "zomg! We got
a non-encrypted response to an encrypted message! Teh site is
insecurez!!eleven"

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9GudkACgkQHPApP6U8
pFjroRAAoIW4n0WRzoK9xFsjhCq2/c6NqTY8q4AD2jypsjBnYfBNJK9AwCGsHRTH
l830zC5KvHn9Qw42wdXdKhBDzLvBovG4TkeYbsTVXtNj3wowhihytahUmZYqwWem
bV3YXQGMDVaCkUHDD0gN8y8NhWk3IE/JwSwmFKEURkR+Tz5nHmUjwEN1A/fhFyj2
Ab3/pKdiyz4vSVec4SxZ8MUQQi0bmueiR4PRpKg7IUESSIp5rjp6wY22IG9VyWoc
jxN3xmCmYUaYqxLQufQY8xgbUtCgKZzX56UM0DpuvneZIImZX1quj3KXnSkwBPAi
ei/bZmnCmz7p7Wukt9nykExPGm/Mvbkhf11k2cdwxdHdkOwNN2rF/ynuAlnyzJdV
Oy1wMgkKTGDb6UahDexeAia4L248jSIn4kC+6T71ppwbLfbVMlkAuEBVjAAQMHOy
YRit5qk4aJh94MSX6M3k12MYwR018SoxSX2RccSYx+S6odN0pKYt4OxVvcOVgWkT
y2ilwPNcVDY8/wkGz4aeMK9kLlstw3K279d9R/cfCFHCko32dnct6rCkUZm4+nqS
W+SaobV6VUcCWVQLTaURaT18hyeohJOHYonkAM6vGERkVoez5xYgQwRfu4tL3mud
76vgLTiGHvVh4fi3wnI99rIYXKvZW7B/SC/WJLFJY7n/Xa5hgjM=
=cDjm
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[jonmcalexander]

Did Qualsys include a QID with their report?


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: Mark Thomas  
Sent: Wednesday, August 26, 2020 12:59 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

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

> so maybe we could have a setting on the  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.

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.

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

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Mark Thomas]

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

> so maybe we could have a setting on the
>  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.

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.

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

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

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
>>  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!".

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.

I'm interested in having Tomcat be able to pass these (admittedly
stupid) security requirements, so maybe we could have a setting on the
 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.

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.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9GkuAACgkQHPApP6U8
pFiGYRAAtvVTw1CKi+epZULpmSHDuO9ipm+I37a6eKMufhIUevCl6MfBQN0kgrfu
Hfh9ByaLIN2JogyCuMehhZv5McGpKT7i9t0OWV9eLzlSvmVh+wzDUvAR83bj8Qk4
woOaiU23DM0jZTfPPtsCGGkJ6FGTzNuwrYzIyjQ8f4OKYopkHffeJ59fQoqmlKeW
hA0+m4xcKgvmRjPmbE+4E5gpV8ylYAyAxQYdpVESpWI4pXViqwn2QfrWMgFZGEE3
7NTTAlQLB3N0jgJCt9dvi4aFzKZOLdYEQ0ooCP34EqfU6S/WQGfR6BZxbcQSyzMa
qOBLnTfe9LBC9DIVQAKenDkkDCWen+7e/EEcRmaAvrlbD9ZfCJ/pNl5WlzymkXfq
y2W6laFR985am5RTAZIfiiOYX2wBW1kna0q7tpDji7wtTag+ZbrqdcFQF3FH3/+u
5l9RWWIMhasQPtC0YiEyeDvCR9iwpjyB6kqIOpMYPR8CCnpq4qtRtbLFpXqXT4QF
MxKNcssX0sZFzsqz/j7VGafg2fq545vCkZFb13HG3Fp0xeNgnwz4WC5yzEHtUWMq
EEacHJaHDusgyjn9Mk5+kT0NNPaerIA/mZEKhjQAORqJPMHRxHGgRN1A4H49SQvL
b7jrlkZc55XqCV5dq+/eR8XIKuXemWKKb4bp0BT9c0WR3mE0FtM=
=HTAL
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Mark Thomas]

On 26/08/2020 08:14, Martin Grigorov wrote:
> Hi,
> 
> On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha  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.

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.

>> This is behaviour of Apache HTTP server also. But in Apache though, we can
>> get rid of this by using "ErrorDocument 400" directive. Do we have similar
>> in Tomcat? I have already tried using
>>
>> 
>>400
>>/error.jsp
>>  
>>
> 
> This won't work because Tomcat stops the request earlier and doesn't pass
> it to your application.
> I haven't tried it but it may work with a custom Valve, extending
> ErrorReportValve.

That won't work. The error message is generated in the low level I/O
code as part of the TLS handshake.

>> Not sure, but my idea was to add redirect code on error.jsp page. But
>> above never works. It never reaches error.jsp page. Just sticks in default
>> error message page mentioned above.
>>
>> Btw..you can see the result from Qualys attached.
>>
> 
> What is the desired behavior expected by Qualys ?
> Because at the moment Tomcat returns a text/html error page and you try to
> "fix" it by returning a custom text/html error page. I don't see how this
> will change the Qualys report.

Indeed.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Martin Grigorov]

Hi,

On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha  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.
> This is behaviour of Apache HTTP server also. But in Apache though, we can
> get rid of this by using "ErrorDocument 400" directive. Do we have similar
> in Tomcat? I have already tried using
>
> 
>400
>/error.jsp
>  
>

This won't work because Tomcat stops the request earlier and doesn't pass
it to your application.
I haven't tried it but it may work with a custom Valve, extending
ErrorReportValve.


>
> Not sure, but my idea was to add redirect code on error.jsp page. But
> above never works. It never reaches error.jsp page. Just sticks in default
> error message page mentioned above.
>
> Btw..you can see the result from Qualys attached.
>

What is the desired behavior expected by Qualys ?
Because at the moment Tomcat returns a text/html error page and you try to
"fix" it by returning a custom text/html error page. I don't see how this
will change the Qualys report.


>
> Thanks again guys for getting back.
>
> Regards,
> Pratik
>
> On Tue, Aug 25, 2020 at 5:36 PM Mark Thomas  wrote:
>
>> On 25/08/2020 11:14, Pratik Shrestha wrote:
>> > Hi all,
>> >
>> > Tomcat version: 9.0.37
>> >
>> > Our website is running on Tomcat. We did Qualys vulnerability scan on
>> our
>> > site. Scan shows below vulnerability.
>> >
>> > Insecure transport
>> > Group: Information Disclosure
>> > CWE CWE-319
>> > OWASP A3 Sensitive Data Exposure
>> > WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
>> >
>> > Please note
>> > 1. HTTP port is not enabled.
>> > 2. We have only opened HTTPS port 8443. But when we connect this HTTPS
>> port
>> > with HTTP (http://www.oursite.com:8443/), we get an error "Bad
>> Request. This
>> > combination of host and port requires TLS."
>> > 3. Due to the above error message, we get this vulnerability error from
>> > Qualys.
>> > 4. We have already enabled HSTS.
>> > 5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But
>> it
>> > never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It
>> just
>> > finds someone is accessing HTTPS port with HTTP protocol and then just
>> > throws error 400 'Bad Request'
>> > 6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP'
>> which
>> > should still be okay.
>> >
>> > We already tried to find the fix for this issue on the web but in vain.
>> >
>> > Kindly help if anyone has found a way to fix it.
>>
>> Fix what?
>>
>> If you make an HTTP request to an HTTPS port, Tomcat provides a helpful
>> error message.
>>
>> I don't see any security issues here.
>>
>> (And before anyone claims the request sent in the clear is insecure I'll
>> point out that the request is sent in the clear irrespective of whether
>> Tomcat responds with an HTTP/1.1 clear text error message or a cryptic
>> TLS failure).
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[logo]

Pratik,


> Am 26.08.2020 um 06:52 schrieb Pratik Shrestha :
> 
> 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. This is behaviour of Apache HTTP server also. But in Apache though, 
> we can get rid of this by using "ErrorDocument 400" directive. Do we have 
> similar in Tomcat? I have already tried using 
> 
> 
>400
>/error.jsp
>  
> 

I see an error 400 on 8443 (8.5.57). As it is on Nginx or Apache. So I don’t 
see why this would be a problem. False Positive one could address with Qualys?

Regards

Peter

> Not sure, but my idea was to add redirect code on error.jsp page. But above 
> never works. It never reaches error.jsp page. Just sticks in default error 
> message page mentioned above.
> 
> Btw..you can see the result from Qualys attached.  
> 
> Thanks again guys for getting back.
> 
> Regards,
> Pratik 
> 
> On Tue, Aug 25, 2020 at 5:36 PM Mark Thomas  > wrote:
> On 25/08/2020 11:14, Pratik Shrestha wrote:
> > Hi all,
> > 
> > Tomcat version: 9.0.37
> > 
> > Our website is running on Tomcat. We did Qualys vulnerability scan on our
> > site. Scan shows below vulnerability.
> > 
> > Insecure transport
> > Group: Information Disclosure
> > CWE CWE-319
> > OWASP A3 Sensitive Data Exposure
> > WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
> > 
> > Please note
> > 1. HTTP port is not enabled.
> > 2. We have only opened HTTPS port 8443. But when we connect this HTTPS port
> > with HTTP (http://www.oursite.com:8443/ ), we 
> > get an error "Bad Request. This
> > combination of host and port requires TLS."
> > 3. Due to the above error message, we get this vulnerability error from
> > Qualys.
> > 4. We have already enabled HSTS.
> > 5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But it
> > never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It just
> > finds someone is accessing HTTPS port with HTTP protocol and then just
> > throws error 400 'Bad Request'
> > 6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP' which
> > should still be okay.
> > 
> > We already tried to find the fix for this issue on the web but in vain.
> > 
> > Kindly help if anyone has found a way to fix it.
> 
> Fix what?
> 
> If you make an HTTP request to an HTTPS port, Tomcat provides a helpful
> error message.
> 
> I don't see any security issues here.
> 
> (And before anyone claims the request sent in the clear is insecure I'll
> point out that the request is sent in the clear irrespective of whether
> Tomcat responds with an HTTP/1.1 clear text error message or a cryptic
> TLS failure).
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org 
> 
> For additional commands, e-mail: users-h...@tomcat.apache.org 
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Pratik Shrestha]

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.
This is behaviour of Apache HTTP server also. But in Apache though, we can
get rid of this by using "ErrorDocument 400" directive. Do we have similar
in Tomcat? I have already tried using


   400
   /error.jsp
 

Not sure, but my idea was to add redirect code on error.jsp page. But above
never works. It never reaches error.jsp page. Just sticks in default error
message page mentioned above.

Btw..you can see the result from Qualys attached.

Thanks again guys for getting back.

Regards,
Pratik

On Tue, Aug 25, 2020 at 5:36 PM Mark Thomas  wrote:

> On 25/08/2020 11:14, Pratik Shrestha wrote:
> > Hi all,
> >
> > Tomcat version: 9.0.37
> >
> > Our website is running on Tomcat. We did Qualys vulnerability scan on our
> > site. Scan shows below vulnerability.
> >
> > Insecure transport
> > Group: Information Disclosure
> > CWE CWE-319
> > OWASP A3 Sensitive Data Exposure
> > WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
> >
> > Please note
> > 1. HTTP port is not enabled.
> > 2. We have only opened HTTPS port 8443. But when we connect this HTTPS
> port
> > with HTTP (http://www.oursite.com:8443/), we get an error "Bad Request.
> This
> > combination of host and port requires TLS."
> > 3. Due to the above error message, we get this vulnerability error from
> > Qualys.
> > 4. We have already enabled HSTS.
> > 5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But it
> > never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It
> just
> > finds someone is accessing HTTPS port with HTTP protocol and then just
> > throws error 400 'Bad Request'
> > 6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP'
> which
> > should still be okay.
> >
> > We already tried to find the fix for this issue on the web but in vain.
> >
> > Kindly help if anyone has found a way to fix it.
>
> Fix what?
>
> If you make an HTTP request to an HTTPS port, Tomcat provides a helpful
> error message.
>
> I don't see any security issues here.
>
> (And before anyone claims the request sent in the clear is insecure I'll
> point out that the request is sent in the clear irrespective of whether
> Tomcat responds with an HTTP/1.1 clear text error message or a cryptic
> TLS failure).
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Mark Thomas]

On 25/08/2020 11:14, Pratik Shrestha wrote:
> Hi all,
> 
> Tomcat version: 9.0.37
> 
> Our website is running on Tomcat. We did Qualys vulnerability scan on our
> site. Scan shows below vulnerability.
> 
> Insecure transport
> Group: Information Disclosure
> CWE CWE-319
> OWASP A3 Sensitive Data Exposure
> WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
> 
> Please note
> 1. HTTP port is not enabled.
> 2. We have only opened HTTPS port 8443. But when we connect this HTTPS port
> with HTTP (http://www.oursite.com:8443/), we get an error "Bad Request. This
> combination of host and port requires TLS."
> 3. Due to the above error message, we get this vulnerability error from
> Qualys.
> 4. We have already enabled HSTS.
> 5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But it
> never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It just
> finds someone is accessing HTTPS port with HTTP protocol and then just
> throws error 400 'Bad Request'
> 6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP' which
> should still be okay.
> 
> We already tried to find the fix for this issue on the web but in vain.
> 
> Kindly help if anyone has found a way to fix it.

Fix what?

If you make an HTTP request to an HTTPS port, Tomcat provides a helpful
error message.

I don't see any security issues here.

(And before anyone claims the request sent in the clear is insecure I'll
point out that the request is sent in the clear irrespective of whether
Tomcat responds with an HTTP/1.1 clear text error message or a cryptic
TLS failure).

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Peter Kreuser]

Pratik,

> Am 25.08.2020 um 12:14 schrieb Pratik Shrestha :
> 
> Hi all,
> 
> Tomcat version: 9.0.37
> 
> Our website is running on Tomcat. We did Qualys vulnerability scan on our
> site. Scan shows below vulnerability.
> 
> Insecure transport
> Group: Information Disclosure
> CWE CWE-319
> OWASP A3 Sensitive Data Exposure
> WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
> 
> Please note
> 1. HTTP port is not enabled.


Which port does it complain on? Maybe it’s not Tomcat, but another service?


> 2. We have only opened HTTPS port 8443. But when we connect this HTTPS port
> with HTTP (http://www.oursite.com:8443/), we get an error "Bad Request. This
> combination of host and port requires TLS."
> 3. Due to the above error message, we get this vulnerability error from
> Qualys.
> 4. We have already enabled HSTS.
> 5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But it
> never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It just
> finds someone is accessing HTTPS port with HTTP protocol and then just
> throws error 400 'Bad Request'
> 6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP' which
> should still be okay.
> 
> We already tried to find the fix for this issue on the web but in vain.
> 
> Kindly help if anyone has found a way to fix it.
> 
> Regards,
> Pratik

Peter


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Pratik Shrestha]

Hi all,

Tomcat version: 9.0.37

Our website is running on Tomcat. We did Qualys vulnerability scan on our
site. Scan shows below vulnerability.

Insecure transport
Group: Information Disclosure
CWE CWE-319
OWASP A3 Sensitive Data Exposure
WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION

Please note
1. HTTP port is not enabled.
2. We have only opened HTTPS port 8443. But when we connect this HTTPS port
with HTTP (http://www.oursite.com:8443/), we get an error "Bad Request. This
combination of host and port requires TLS."
3. Due to the above error message, we get this vulnerability error from
Qualys.
4. We have already enabled HSTS.
5. We have enabled Rewrite Valve also to direct all HTTP to HTTPS. But it
never works. It is like, Tomcat doesn't care about Rewrite or HSTS. It just
finds someone is accessing HTTPS port with HTTP protocol and then just
throws error 400 'Bad Request'
6. Note that Tomcat version 7 used to send the error 'ERR_EMPTY_RESP' which
should still be okay.

We already tried to find the fix for this issue on the web but in vain.

Kindly help if anyone has found a way to fix it.

Regards,
Pratik