On 26/08/2020 08:14, Martin Grigorov wrote: > Hi, > > On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha <pratik...@gmail.com> 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 >> >> <error-page> >> <error-code>400</error-code> >> <location>/error.jsp</location> >> </error-page> >> > > 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
