Robert Segall wrote:[...]
Thanks, good to have a fix for the production server.

I think poundctl is still missing a dependency on pound.h in the makefile.

Cheers,
John

Robert,

I would like to see MAXBUF replaced with a dynamic buffer (no compile-time
options), limited only by a runtime configuration option very similar to (or
just use?) MaxRequest.

I am not sure if this presents or prevents a security issue, but having dynamic
buffers would greatly increase compatibility with existing web applications
which use large URL.  One of my peers is adamant that long URLs are bad design,
but this is something I cannot change in legacy applications.  I assume that
pound could check the configuration file and limit the dynamic buffer size to
MaxRequest for something like a DoS attack?

Overly large buffers (static or dynamic) aren't really an issue for me, since I
run pound on it's own server with more than enough RAM to eat through, but I
imagine that limits would be very welcome for those who run pound with other
processes on the same server, or servers without so much resources available
all to pound.

-Miles Raymond

Robert Segall wrote:[...][...][...][...][...]

On Sat, 2008-05-31 at 10:15 -0400, Albert wrote:[...]

Agreed - this goes on the wish list for 2.5.[...]

On Sat, 2008-05-31 at 23:38 +0200, Alessio wrote:[...]

"Separation of responsibilities" is a valuable principle, and I wish
more programmers would adhere to it. Its applicability is however
limited: it really means that each application should be secure in
itself.

Once you look at a complex system though, you have to take another view:
it would be good if a potential attacker would have to jump several
hurdles before doing real damage. This is known as the "defence in
depth" principle, is no less important, and does not contradict the idea
of "separation of responsibilities".

So perhaps we could agree that sticking to principles is good, but
understanding when a principle applies is not bad either.[...]

> "Separation of responsibilities" is a valuable principle, and I wish[...]

It is also important to realize that some folks are using Open Source
soultions to defend the closed source products which are running
internally and the security of said closed source products is an unknown
quantity.

Robert Segall wrote:
[...]

you should also agree that the hurdle you are using to stop potential 
attackers is breaking the functionalities pound is made for (as many 
users reported this MAXBUF limit caused popular applications to not work 
anymore when balanced by pound) and this does not make much sense to me: 
to implement something which is not a core functionality of pound 
(security) you are damaging a core functionality (load balancing).
if you really think pound should enforce this kind of "security policy", 
then it must be a user-customizable parameter at runtime and not at 
build time.

> you should also agree that the hurdle you are using to stop potential
[...]

I was under the impression that security IS one of the core functions of
Pound.  That is the purpose for which I am using it.  We have no need
for load balancing.

Michael St. Laurent wrote:
[...]

well, this is what is pound (as reported on the website):
1.  a reverse-proxy: it passes requests from client browsers to one or 
more back-end servers.
2. a load balancer: it will distribute the requests from the client 
browsers among several back-end servers, while keeping session information.
3. an SSL wrapper: Pound will decrypt HTTPS requests from client 
browsers and pass them as plain HTTP to the back-end servers.
4. an HTTP/HTTPS sanitizer: Pound will verify requests for correctness 
and accept only well-formed ones.
5. a fail over-server: should a back-end server fail, Pound will take 
note of the fact and stop passing requests to it until it recovers.
6. a request redirector: requests may be distributed among servers 
according to the requested URL.

The only thing vaguely concerning security is point 4: though defining a 
request greater than 1024k as not "well-formed" can be debated for long 
i think.

From what I can find, the size limit of cookies is:

4K of data 	Per cookie (both the name and value of the cookie count
towards this limit)

Since the cookies are part of the request, I have seen applications
break with large cookies.  I know I had to recompile Pound with the
modified MAXBUF.  Everything I've ever read has the 4K limit on cookies,
so that's why I didn't know why the MAXBUF had been lowered to 1K.

--Alfonso

 

-----Original Message-----
From: Alessio [mailto:a.cervellin(at)acm.org] 
Sent: Tuesday, June 03, 2008 3:40 PM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Pound changes in v2.4.x

Michael St. Laurent wrote:
[...]

well, this is what is pound (as reported on the website):
1.  a reverse-proxy: it passes requests from client browsers to one or
more back-end servers.
2. a load balancer: it will distribute the requests from the client
browsers among several back-end servers, while keeping session
information.
3. an SSL wrapper: Pound will decrypt HTTPS requests from client
browsers and pass them as plain HTTP to the back-end servers.
4. an HTTP/HTTPS sanitizer: Pound will verify requests for correctness
and accept only well-formed ones.
5. a fail over-server: should a back-end server fail, Pound will take
note of the fact and stop passing requests to it until it recovers.
6. a request redirector: requests may be distributed among servers
according to the requested URL.

The only thing vaguely concerning security is point 4: though defining a
request greater than 1024k as not "well-formed" can be debated for long
i think.

--
To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.

--
This message has been scanned for viruses and dangerous content by
SecureMail, and is believed to be clean.

> well, this is what is pound (as reported on the website):[...]

Okay, but *one* of the main reasons that folks will go looking for
reverse proxy server software is security:
http://en.wikipedia.org/wiki/Reverse_proxy

I think there is little basis for claiming that security is not a core
function.  That's my opinion anyway.  YMMV.

> Okay, but *one* of the main reasons that folks will go looking for[...]

Let me add, however, that I agree with you that the MAXBUF should be a
configuration parameter and not a hard coded limit.

Michael St. Laurent wrote:
[...]

because it brings architectural - rather than functional - benefits 
(network segregation/separation, single point of entrance, server 
masquerading, and so on) not because it implements checks to legitimate 
or not a request.
anyway, if those checks should be really included (author's choice), as 
i said they must not in any way affect other core - and by my side more 
important - functionalities.

as i'm distributing pound as solaris binary package, i've to build it 
with maxbuf at 16K to guarantee that it works fine for any 
user/application... so this check about the max size of a request 
becomes useless.

On Tue, 2008-06-03 at 16:22 -0400, Alfonso Espitia wrote:[...]

I doubt these are actually cookies, as they are sent as headers, which
allow continuation lines, and most clients limit the length of a header.
Perhaps you mean session identifiers in the URI?

As to the URI length: from RFC 2616

   The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs. A server
   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
   than the server can handle (see section 10.4.15).

      Note: Servers ought to be cautious about depending on URI lengths
      above 255 bytes, because some older client or proxy
      implementations might not properly support these lengths.

and also

   10.4.15 414 Request-URI Too Long

   The server is refusing to service the request because the Request-URI
   is longer than the server is willing to interpret. This rare
   condition is only likely to occur when a client has improperly
   converted a POST request to a GET request with long query
   information, when the client has descended into a URI "black hole" of
   redirection (e.g., a redirected URI prefix that points to a suffix of
   itself), or when the server is under attack by a client attempting to
   exploit security holes present in some servers using fixed-length
   buffers for reading or manipulating the Request-URI.

You may also want to look at various servers - you almost always have an
arbitrary upper bound, as well as the possibility for the user to define
limits on URI and header sizes.[...]

I believe the problem I had originally run into was Pound related and
not the server that was returning the "URI too long" error.  If I went
to the BE server directly (bypassing Pound) it worked fine, but when I
went to the same URL through Pound it didn't work.

Increasing the MAXBUF fixed the problem with the large cookies.

--Alfonso 

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Wednesday, June 04, 2008 12:52 PM
To: pound(at)apsis.ch
Subject: RE: [Pound Mailing List] Pound changes in v2.4.x

On Tue, 2008-06-03 at 16:22 -0400, Alfonso Espitia wrote:[...]
to 1K.[...]

I doubt these are actually cookies, as they are sent as headers, which
allow continuation lines, and most clients limit the length of a header.
Perhaps you mean session identifiers in the URI?

As to the URI length: from RFC 2616

   The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs. A server
   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
   than the server can handle (see section 10.4.15).

      Note: Servers ought to be cautious about depending on URI lengths
      above 255 bytes, because some older client or proxy
      implementations might not properly support these lengths.

and also

   10.4.15 414 Request-URI Too Long

   The server is refusing to service the request because the Request-URI
   is longer than the server is willing to interpret. This rare
   condition is only likely to occur when a client has improperly
   converted a POST request to a GET request with long query
   information, when the client has descended into a URI "black hole" of
   redirection (e.g., a redirected URI prefix that points to a suffix of
   itself), or when the server is under attack by a client attempting to
   exploit security holes present in some servers using fixed-length
   buffers for reading or manipulating the Request-URI.

You may also want to look at various servers - you almost always have an
arbitrary upper bound, as well as the possibility for the user to define
limits on URI and header sizes.
--
?Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


--
To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
[...]