From dridi at varni.sh  Fri Jul  1 10:17:10 2016
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Fri, 1 Jul 2016 12:17:10 +0200
Subject: [master] 0577f3f RFC7230/3.2.4 compliance.
In-Reply-To: <E1bIXnV-0007Sx-En@project.varnish-software.com>
References: <E1bIXnV-0007Sx-En@project.varnish-software.com>
Message-ID: <CABoVN9BGw0SuVWj_kA9fym6wszoDr8+7W2J08iTfZXgRMznbXQ@mail.gmail.com>

On Thu, Jun 30, 2016 at 10:58 AM, Poul-Henning Kamp <phk at freebsd.org> wrote:
>
> commit 0577f3fba200e45c05099427eec01610ee061436
> Author: Poul-Henning Kamp <phk at FreeBSD.org>
> Date:   Thu Jun 30 08:56:22 2016 +0000
>
>     RFC7230/3.2.4 compliance.

I'm confused about 3.2.4 compliance, when we have a simple grammar to
follow in 3.2:

     header-field   = field-name ":" OWS field-value OWS

     field-name     = token
     [...]

There is clearly nothing allowed between the semi-colon and the field-name.

> diff --git a/bin/varnishd/http1/cache_http1_proto.c b/bin/varnishd/http1/cache_http1_proto.c
> index f5dbe53..a6934e7 100644
> --- a/bin/varnishd/http1/cache_http1_proto.c
> +++ b/bin/varnishd/http1/cache_http1_proto.c
> @@ -185,6 +185,18 @@ http1_dissect_hdrs(struct http *hp, char *p, struct http_conn *htc,
>                             (int)(q - p > 20 ? 20 : q - p), p);
>                         return (400);
>                 }
> +
> +               for (; p < q; p++) {
> +                       if (vct_islws(*p)) {
> +                               VSLb(hp->vsl, SLT_BogoHeader,
> +                                   "Space in header '%.*s'",
> +                                   (int)Tlen(hp->hd[hp->nhd - 1]),
> +                                   hp->hd[hp->nhd - 1].b);
> +                               return (400);
> +                       }
> +                       if (*p == ':')
> +                               break;
> +               }

The grammar for a token (3.2.6) is very straightforward and doesn't
require any kind of jumping/backtracking in the text. I can be
effectively checked in a single loop and that would take care of
spaces too.

Should I send a patch that performs the grammar check and fails with
an "Invalid field-name in header ..." message instead?

Cheers



From phk at phk.freebsd.dk  Fri Jul  1 10:35:54 2016
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Fri, 01 Jul 2016 10:35:54 +0000
Subject: [master] 0577f3f RFC7230/3.2.4 compliance.
In-Reply-To: <CABoVN9BGw0SuVWj_kA9fym6wszoDr8+7W2J08iTfZXgRMznbXQ@mail.gmail.com>
References: <E1bIXnV-0007Sx-En@project.varnish-software.com>
 <CABoVN9BGw0SuVWj_kA9fym6wszoDr8+7W2J08iTfZXgRMznbXQ@mail.gmail.com>
Message-ID: <6507.1467369354@critter.freebsd.dk>

--------
In message <CABoVN9BGw0SuVWj_kA9fym6wszoDr8+7W2J08iTfZXgRMznbXQ at mail.gmail.com>, Dridi Boukelmoune writes:

>Should I send a patch that performs the grammar check and fails with
>an "Invalid field-name in header ..." message instead?

Improvements are always welcome :-)

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



From dridi at varni.sh  Mon Jul  4 12:22:36 2016
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 4 Jul 2016 14:22:36 +0200
Subject: Named listen addresses in VCL
Message-ID: <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q@mail.gmail.com>

Hi,

Inspired by stevedore names that (if I understood correctly) are now
properly checked at vcc time, I'd like to add names to -a options too
and introduce a new field in server too.

On the command line: -a [name=]address[:port][,proto]

In VCL: server.listen_address

In varnish-cli: listing listen addresses no longer a debug command

In varnishtest: s1_addr for the first one, s1_addr_$NAME for all

The point is to decouple IP/port addressing from the purpose, and for
example being able to distinguish secure traffic:

    if (server.listen_address == "hitch") {
        set req.http.X-Forwarded-Proto = "https";
    }

The listen address name could be safely used on different environments
(prod, qa, dev...) without requiring a single change in the VCL code.

It would also be an alternative to ACLs when dealing with
administrative requests:

    if (req.method == "PURGE") {
        if (server.listen_address != "admin") {
            return (synth(405));
        }
        return (purge);
    }

Those snippets wouldn't compile on a varnishd instance not started
with named listen addresses "https" and "admin".

So far, all the work I've done on this feature is writing this email and
a bit of thinking, should I proceed further?

Best,
Dridi



From phk at phk.freebsd.dk  Mon Jul  4 15:21:01 2016
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 04 Jul 2016 15:21:01 +0000
Subject: Named listen addresses in VCL
In-Reply-To: <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q@mail.gmail.com>
References: <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q@mail.gmail.com>
Message-ID: <55627.1467645661@critter.freebsd.dk>

--------
In message <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q at mail.gmail.com>
, Dridi Boukelmoune writes:

>Inspired by stevedore names that (if I understood correctly) are now
>properly checked at vcc time, I'd like to add names to -a options too
>and introduce a new field in server too.

TCP/IP doesn't really work that way, in particular people forget that
packets may take different routes forth and back.

As best as I can tell, all your proposed uses would open you up to
rather trivial attacks, given a single compromised machine anywhere
in your DMZ.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



From dridi at varni.sh  Mon Jul  4 15:31:25 2016
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 4 Jul 2016 17:31:25 +0200
Subject: Named listen addresses in VCL
In-Reply-To: <55627.1467645661@critter.freebsd.dk>
References: <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q@mail.gmail.com>
 <55627.1467645661@critter.freebsd.dk>
Message-ID: <CABoVN9BRpGPUoQxO3k1s7FKWQNT0hwHe5ez9nSFNpj0o14+pcg@mail.gmail.com>

> TCP/IP doesn't really work that way, in particular people forget that
> packets may take different routes forth and back.
>
> As best as I can tell, all your proposed uses would open you up to
> rather trivial attacks, given a single compromised machine anywhere
> in your DMZ.

I don't understand, the use cases I'm suggesting are as "unsafe" as
relying on ACLs with either client.ip or server.ip.

I'm suggesting making the alternative to ACLs more convenient, by not
having to match addresses or extract the port number with std.port()
and relying on an abstract name instead.

You have the same problem if anything matching one of your ACLs
trusted address is compromised.

Dridi



From phk at phk.freebsd.dk  Mon Jul  4 15:39:13 2016
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Mon, 04 Jul 2016 15:39:13 +0000
Subject: Named listen addresses in VCL
In-Reply-To: <CABoVN9BRpGPUoQxO3k1s7FKWQNT0hwHe5ez9nSFNpj0o14+pcg@mail.gmail.com>
References: <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q@mail.gmail.com>
 <55627.1467645661@critter.freebsd.dk>
 <CABoVN9BRpGPUoQxO3k1s7FKWQNT0hwHe5ez9nSFNpj0o14+pcg@mail.gmail.com>
Message-ID: <55710.1467646753@critter.freebsd.dk>

--------
In message <CABoVN9BRpGPUoQxO3k1s7FKWQNT0hwHe5ez9nSFNpj0o14+pcg at mail.gmail.com>
, Dridi Boukelmoune writes:

>I don't understand, the use cases I'm suggesting are as "unsafe" as
>relying on ACLs with either client.ip or server.ip.

With your suggestion, any traffic coming through a particular
listen address would be trusted, even if that traffic does not
have anything to do on that particular subnet.

>You have the same problem if anything matching one of your ACLs
>trusted address is compromised.

There is a big difference between hijacking the IP of a server in
use, which is likely to trigger alarms, and being able to attack
using any IP going in through a particular interface.

Neither is watertight, but I don't see "convenience" as a valid argument
for increasing the sizes of the holes.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



From dridi at varni.sh  Mon Jul  4 16:01:11 2016
From: dridi at varni.sh (Dridi Boukelmoune)
Date: Mon, 4 Jul 2016 18:01:11 +0200
Subject: Named listen addresses in VCL
In-Reply-To: <55710.1467646753@critter.freebsd.dk>
References: <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q@mail.gmail.com>
 <55627.1467645661@critter.freebsd.dk>
 <CABoVN9BRpGPUoQxO3k1s7FKWQNT0hwHe5ez9nSFNpj0o14+pcg@mail.gmail.com>
 <55710.1467646753@critter.freebsd.dk>
Message-ID: <CABoVN9DYKZ7gm0X-5zsEOjCCTenCf5_mS4Zk1=owoFr83oFhkA@mail.gmail.com>

>>I don't understand, the use cases I'm suggesting are as "unsafe" as
>>relying on ACLs with either client.ip or server.ip.
>
> With your suggestion, any traffic coming through a particular
> listen address would be trusted, even if that traffic does not
> have anything to do on that particular subnet.

That's the point of providing the mechanism. If you trust your network
because you happen to have a trustworthy and competent team of network
engineers, why turn a networking problem into an application problem?

>>You have the same problem if anything matching one of your ACLs
>>trusted address is compromised.
>
> There is a big difference between hijacking the IP of a server in
> use, which is likely to trigger alarms, and being able to attack
> using any IP going in through a particular interface.

I don't see any difference between dealing with clunky VCL constructs
and using a label to achieve the same.

> Neither is watertight, but I don't see "convenience" as a valid argument
> for increasing the sizes of the holes.

The main goal is not *mere* convenience but actual decoupling between
the application layer and the networking nitty gritty. On my dev box
the "hitch" listen address might mean localhost:8888 while in
production the hitch server may be on a different host in front of a
Varnish cluster.

With named listen addresses I can write my VCL policy once and not
require changes between environments (dev, qa, prod...) instead of
using platform-dependent server.ip.

Dridi