On Sun, Jan 19, 2014 at 1:42 PM, mex wrote:
> hi coderman,
>
> icreasing the headerr_size is not a solution, since i look for a generic
> solution to circumvent
> the outcome of those malicious request.
>
> a possible way to handle this is a lighweight WAF-solution,
&
On Sun, Jan 19, 2014 at 8:35 AM, coderman wrote:
>
> i'd love to know of more elegant ways to handle this, with header
> specific handling - especially cookies, if possible...
the less better way to change this is:
http://nginx.org/en/docs/http/ngx_http_co
On Sun, Jan 19, 2014 at 8:06 AM, mex wrote:
> very interesting read:
> http://homakov.blogspot.de/2014/01/cookie-bomb-or-lets-break-internet.html
>
>
> my question: is there a generic way to check the size of such headers like
> cookies etc and to cut them off, or should we live with such mal
On Tue, Jan 7, 2014 at 9:35 AM, coderman wrote:
>...
> in any case, end result: use 1.0.1f and be happy
and if concerned that your OS distribution or upstream OpenSSL lacks this fix,
confirm yourself via openssl-1.0.1f/crypto/engine/eng_rdrand.c in patched src
if you see !ENGINE_set_f
On Mon, Jan 6, 2014 at 2:04 PM, Lukas Tribus wrote:
> Hi,
>
>
>> It does not look like 1.0.1f changed the default behavior of
>> ENGINE_rdrand (coderman's been following it).
>
> Yes it did, rdrand is no longer enabled by default. Here [1] is
> the backport in the OpenSSL_1_0_1-stable head [2].
>
On Mon, Dec 16, 2013 at 4:12 PM, Jeffrey Walton wrote:
>
> checking for OpenSSL library ... not found
> ... with nginx by using --with-openssl= option.
>
--with-openssl=/some/path/to/ssl/root
works for me. try --with-openssl=/usr/local/ssl ?
___
ng
On Thu, Dec 12, 2013 at 6:30 AM, Jeffrey Walton wrote:
> I'm reading through the nginx architecture document at
> http://www.aosabook.org/en/nginx.html.
>...
> What is the location configuration, and why is it significant?
e.g.: (assuming some web root set)
...
# location configuration for di
