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 <ma...@apache.org>: > > On 27/08/2020 06:31, Terence M. Bandoian wrote: >> On 8/26/2020 11:27 PM, Pratik Shrestha wrote: > > <snip/> > >>> 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. > > <snip/> > >> 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. > > <snip/> > >>>>> On 8/26/20 13:59, Mark Thomas wrote: >>>>>> On 26/08/2020 17:50, Christopher Schultz wrote: > > <snip/> > >>>>>>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
