Re: Dropping connection instead of returning 400

On 2005-03-01 20:59:37 -0800 (Tue, Mar), christopher@baus.net wrote:
> One thing that keeps coming back to me is 400 Bad Request handling.  It is
> now my opinion that security proxies should just drop connection when
> faced with traffic they refuse to handle.
>
> I put some thoughts on this on my blog here:
>
> http://www.baus.net/400-bad-request
>
> Which cause one client developer to call me a non-compliant wanker here:
>
> http://www.mackmo.com/nick/blog/java/?permalink=Please_send_400_Bad_Request_and_.txt
>
> I then followed up with the general thought that I'm willing to be
> non-compliant in the name of security:
>
> http://www.baus.net/breaking-the-spec-in-the-name-of-security
>
> So what do you think?  Is security worth non-compliance with the HTTP spec?

I humbly believe that it's not good to 'drop connection' instead of
returning 400.
What would I do when connection dies after I send my request?
I would retry. If it dies again I retry wondering 'What the ...?'

It may be good to limit the response to something really short, but
there should be SOME response.

As a more 'general' answer to the question whether security is worth
non-compliance I would say: NO, it is not.
The standards are something that gives us confidence in the world. ;-)

To be secure ensure that your program can catch bad request. If it does,
why wouldn't you tell them back: "I am secure! Your request was bad.
Don't waste your time trying to crack me!"


-- 
$ ls -lart
/bin/ls: you must be root to use LART

pgpvw7qugC03i.pgp
Description: PGP signature