To follow-up, are we clear that the bug is when a remote HTTP server is called via to(http4:...) ? The remote side gets to see all the exchange headers, which is the leak.
>From your email I was reading you thought it was to do with the consumer being wrong but it's the producer we're seeing bad things on. I'm no expert but I'm not seeing anything obvious to fix this in the commit. Thanks, James On 5 August 2015 at 10:04, James Green <[email protected]> wrote: > We're using to - i.e. a producer. ..to(http4:some.host) and some.host gets > all the headers in the request. > > > On 5 August 2015 at 09:57, Claus Ibsen <[email protected]> wrote: > >> Hi >> >> Yeah the http filter was filtering only for the producer. We should do >> it for the consumer as well, so camel-jetty etc do not include Camel >> headers in the http responses by default. >> >> There is plenty of options already we should not add more. >> >> I logged a ticket to let the http filter strategy filter those for >> both the producer and consumer >> https://issues.apache.org/jira/browse/CAMEL-9052 >> >> >> >> On Wed, Aug 5, 2015 at 9:51 AM, James Green <[email protected]> >> wrote: >> > We recently had cause to tcpdump an http request from the http4 >> component >> > to a web site. We were most surprised to find a load of exchange headers >> > listed as HTTP "header: value" pairs. >> > >> > A quick search on-line brings up a couple of Red Hat / Fuse documents >> > saying that headers named 'Camel...' are not transmitted onwards, others >> > are. >> > >> > Two concerns: >> > >> > 1. We see no documentation concerning this on the http4 component's page >> > 2. There may be a great many applications deployed unintentionally >> > transmitting internal headers to third parties potentially in breach of >> > policy or legal restrictions without human knowledge >> > >> > I suggest adding a new option, CopyAllHeadersToHttpHeaders, defaulted to >> > false. This would allow developers to "correct" their applications >> without >> > code changes, and those taking advantage of this facility can switch it >> on >> > explicitly. >> > >> > This isn't a Camel security vulnerability but I very much expect it to >> be >> > leading to information leakage "out there". It is certainly not a >> behaviour >> > we expected to see given the documentation. There may be other >> components >> > that require similar attention. >> > >> > Thoughts? >> > >> > James >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2nd edition: http://www.manning.com/ibsen2 >> > >
