PROXY protocol

[Martin Blix Grydeland]

Hi Roger,

The PROXY protocol is something that has been discussed, and it's addition
seen as something we'd like to have in Varnish. There is however, as far as
I know, no work in progress other than your own to add it to Varnish. And
as you write, it would make it much more convenient to use SSL terminators
with Varnish.

I have had a look at your current patch, and while it will work, I believe
it is a bit too hackish to be considered for inclusion in it's current
form. As the PROXY protocol is a wrapper protocol of sorts, it should be
handled specifically with it's own parsing and verification, and then
handed over to the HTTP parsing when that has been verified. Your current
automagic parsing by piggybacking on the HTTP parsing also has security
implications, as it allows a client to craft PROXY lines into the stream
that will be picked up, which can be used as an attack vector.

I believe that adding this to Varnish will be much easier to accomplish
using current master as the basis. This because a lot of structural changes
in preparation for multiprotocol support has already been done there, and
this work is not available on the 3.0 or the -plus branch. Some thoughts
outlined:

   - The support should be linked to the listening socket, so that the
   wrapper protocol can be verified and completed before treating it as an
   HTTP socket. (This socket will then only accept PROXY connections, not
   regular HTTP connections)
   - Either a separate FSM should be defined, or special steps of the
   http1_fsm defined, to handle the PROXY initial states. When the PROXY
   protocol has been dealt with, state processing should jump to the HTTP.
   (Requiring some FSM indirection pointer on the sessions, pointing to the
   current FSM in use).
   - The addresses parsed from the PROXY lines should replace the client.ip
   and client.port values. This will allow it to be used with existing VCL
   scripts and ACL checks, without having to code in special support in VCL
   configurations. (Discussion item: Should the PROXY ip and port be visible
   to VCL?)
   - Any memory allocations necessary should be done on the request
   object's workspace. This should then be allocated at the front of this
   before handing the request object to the HTTP FSM. (If the PROXY ip and
   port is not stored, there might not be need for any dynamic memory
   allocation)

These thoughts are subject to Poul-Henning's review and opinions as he is
the architect of Varnish. He is busy with other major changes at the
moment, so he might not have the time to look into this in detail at this
time.

Regards,
Martin Blix Grydeland

On Mon, Dec 3, 2012 at 3:10 PM, Roger Nesbitt <roger at seriousorange.com>wrote:

> Replying to myself, I decided to jump in and just see how far I could get.
>  Looks like I've got something working, a patch of my prototype is here:
>
>   http://seriousorange.com/varnish-proxy-proto.patch
>
> The one obvious thing wrong with it is that I'm using malloc() to get some
> memory for configuration (and never freeing it); I can't figure out which
> memory routines are the right ones to use.  Hopefully someone can point me
> in the right direction with that.
>
> Comments gratefully appreciated.
> Roger
>
> Le 3 déc. 2012 à 08:35, Roger Nesbitt a écrit :
>
> Hello,
>
> I've got a big chunk of time free and would like to scratch my own itch by
> implementing the PROXY protocol, as defined at this URL:
> http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
>
> My thoughts are to initially implement version 1 of the protocol as part
> of the HTTP server component.  This will allow SSL frontends such as
> stunnel to pass through client IP information, a feature that seems to be
> often requested.
>
> I'm completely new to the Varnish source; after having a little look today
> I assume that a VMOD will not be possible due to the integration required
> into the HTTP parser.
>
> On first looks, I'm thinking of a detection hook in http1_detect(),
> although I'd have to figure out some way to indicate that it's the first
> http request handled on a new connection.  If a PROXY line is detected, the
> code would put the source/destination IP addresses and ports into new
> variables (maybe something like proxy.source_ip, proxy.dest_ip,
> proxy.source_port, proxy.dest_port) and leave it up to the user to build an
> X-Forwarded-For header in VCL should they wish (after checking that
> client.ip is trusted.)
>
> Detecting the PROXY line should just be a single memcmp; I'm not sure
> whether the community would want this feature to be able to be manually
> enabled and disabled.
>
> Is anyone else currently working on this?  Does this idea and general
> strategy seem sound?
>
> Thanks for your help and suggestions.
> Roger
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>
>
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>



-- 
<http://varnish-software.com>*Martin Blix Grydeland*
Senior Developer | Varnish Software AS
Cell: +47 21 98 92 60
We Make Websites Fly!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20121212/02bfc433/attachment.html>