On 26 Sep 2012, at 12:22 AM, Daniel Ruggeri <[email protected]> wrote:
> On the flip side, giving this information out in http headers could be > dangerous. Taking httpd out of the equation, this has pretty wide > implications. Depending on how the calculations are communicated, one > may be able to determine how effective a denial of service attack is > based on the numbers returned by the server. If the end user has a way > to influence the load balancer and pick the backend, they could > systematically target each backend (with realtime feedback) and take one > out at a time. Sure, httpd could drop this header before replying to the > client, but I foresee a huge lack adoption because httpd isn't the only > webserver in the world (it's just the best). What I have been keen to do for a while is to come up with a generic way for httpd to sign a group of headers, and then pass through a header with that signature attached. A receiving server then verifies the signature header, and if the signature is valid, the headers affected are passed, but if invalid, the headers are blacked out in some fashion (blacked out not removed because the long suffering admin wants a fighting chance at debugging where his header went, while passing through servers and/or load balancers to which he may or may not have access), or the request can be rejected outright. I have done this very successfully with single headers, but a generic way to do it with multiple headers will be ideal. This is useful in load balancing scenarios where the outermost server reads a userid and/or extracts the DN or SAN from a client certificate, and then makes that information available to inner layers, of which there may be many. In this scenario you need a way to ensure that headers can't be injected when there any many points of entry. If the headers are outbound, you might strip the headers at the point of exit, or encrypt them. Regards, Graham --
smime.p7s
Description: S/MIME cryptographic signature
