Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

2016-09-12 Thread Eric Covener 
On Mon, Sep 12, 2016 at 5:38 PM, William A Rowe Jr  wrote:
> It really seems that if a major client is not handling "|" correctly, we
> need to carve out an exception,

+1 to allow it.

For others who might hit a maze of closed/duped bug reports this one
is active this year:
https://bugzilla.mozilla.org/show_bug.cgi?id=1064700

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

2016-09-12 Thread William A Rowe Jr 
On Mon, Sep 12, 2016 at 3:06 PM, William A Rowe Jr 
wrote:

> On Mon, Sep 12, 2016 at 10:49 AM, William A Rowe Jr 
> wrote:
>
>> On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem 
>> wrote:
>>
>>>
>>> On 08/29/2016 06:25 PM, William A Rowe Jr wrote:
>>> > Thanks all for the feedback. Status and follow-up questions inline
>>> >
>>> > On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr <
>>> wr...@rowe-clan.net > wrote:
>>> >
>>> > 4. Should the next 2.4/2.2 releases default to Strict[URI] at all?
>>> >
>>> > Real world direct observation especially appreciated from actual
>>> deployments.
>>> >
>>> > Strict (and StrictURI) remain the default.
>>>
>>> StrictURI as a default only makes sense if we have our own house in
>>> order (see above), otherwise it should be opt in.
>>
>>
>> So it's not only our house [our %3B encoding in httpd isn't a showstopper
>> here]... but also whether widely used user-agent browsers and tooling
>> have
>> their houses in order, so I started to study the current browser
>> behaviors.
>> The applicable spec is https://tools.ietf.org/html/rfc3986#section-3.3
>>
>
> The character '|' is also invalid. However, Firefox fails to follow the
>> spec
>> again here (although Chrome gets it right).
>>
>> With respect to these characters, recall this 18 year old document,
>> last paragraph describes the rational;
>> https://tools.ietf.org/html/rfc2396.html#section-2.4.3
>>
>>unwise  = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
>>
>>Data corresponding to excluded characters must be escaped in order to
>>be properly represented within a URI.
>>
>>
>> While it was labeled 'unsafe', 'unwise', and now disallowed-by-omission
>> from RFC3986, the 'must' designation couldn't have been any clearer.
>> We've had this right for 2 decades at httpd.
>>
>> Second paragraph of https://tools.ietf.org/html/rfc3986#appendix-D.1
>> goes into some detail about this change, and while it is hard to parse,
>> the paragraph is stating that '[' ']' were once invalid, now are reserved,
>> and remain disallowed in all other path segments and use cases.
>>
>> The upshot, right now StrictURI will accept '[' and ']', but this won't 
>> survive
>> a rewrite of the apr parser operating with a 'strict' toggle. StrictURI does
>> not accept '|'. The remaining question is what to do, if anything, about
>> carving a specific exception here due to modern Firefox issues.
>>
>> Thoughts/Comments/Additional test data?  TIA!
>>
>>
It really seems that if a major client is not handling "|" correctly, we
need to
carve out an exception, as well as disallow the "#" fragment gen-delim which
is not allowed to be presented. e.g.;

--- server/gen_test_char.c (revision 1760444)
+++ server/gen_test_char.c (working copy)
@@ -143,10 +143,11 @@
  * and unreserved (2.3) that are possible somewhere within a URI.
  * Spec requires all others to be %XX encoded, including obs-text.
  */
-if (c && (strchr("%"  /* pct-encode */
- ":/?#[]@"/* gen-delims */
- "!$&'()*+,;="/* sub-delims */
- "-._~", c) || apr_isalnum(c))) { /* unreserved */
+if (c && (strchr("%"   /* pct-encode */
+ ":/?[]@"  /* gen-delims - "#"
*/
+ "!$&'()*+,;=" /* sub-delims */
+ "-._~"/* unreserved */
+ "|", c) || apr_isalnum(c))) { /* permit firefox
bug */
 flags |= T_URI_RFC3986;
 }


so my only remaining question is what of the others in the not-mentioned,
entirely invalid set? <"> | "<" | ">" | "\" | "^" | "`" | "{" | "}" ... so
far the modern
browsers reviewed handle these correctly, but if anyone has old browsers
still
installed for testing/validation, double checking the test queries would be
a big
help still, as well as confirming on Safari, Dolphin, etc.

Are we ok with adding one invalid exception for firefox to StrictURI (and
later,
two more "[" "]" when we code segment-by-segment validation into apr) while
still disallowing the rest of this list?

Re: StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

2016-09-12 Thread William A Rowe Jr 
On Mon, Sep 12, 2016 at 10:49 AM, William A Rowe Jr 
wrote:

> On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem  wrote:
>
>>
>> On 08/29/2016 06:25 PM, William A Rowe Jr wrote:
>> > Thanks all for the feedback. Status and follow-up questions inline
>> >
>> > On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr <
>> wr...@rowe-clan.net > wrote:
>> >
>> > 4. Should the next 2.4/2.2 releases default to Strict[URI] at all?
>> >
>> > Real world direct observation especially appreciated from actual
>> deployments.
>> >
>> > Strict (and StrictURI) remain the default.
>>
>> StrictURI as a default only makes sense if we have our own house in order
>> (see above), otherwise it should be opt in.
>
>
> So it's not only our house [our %3B encoding in httpd isn't a showstopper
> here]... but also whether widely used user-agent browsers and tooling have
> their houses in order, so I started to study the current browser
> behaviors.
> The applicable spec is https://tools.ietf.org/html/rfc3986#section-3.3
>

The second test below has been updated with 2 and 3 byte utf-8 sequences,
and see no new surprises showed up.

Checked the unreserved set with '?' and '/' observing special meanings.
Nothing here should become escaped when given as a URI;
http://localhost:8080/unreserved-._~/sub-delims-!$&;'
()*+,;=/gen-delims-:@?query

Checked the invalid set of characters all of which must be encoded
per the spec, and verify that #frag is not passed to the server;
http://localhost:8080/gen-delims-[]/invalid- "<>\^`{|}§‡#frag

Checked the reserved set including '#' '%' '?' by their encoded value
to determine if there are any unpleasant reverse surprises lurking;
http://localhost:8080/encoded-%23%25%2F%3A%3B%3D%3F%40%5B%5C%5D%7B%7C%7D

Checked a list of unreserved/unassigned gen-delims and sub-delims
to determine if the user agent normalizes while composing the request;
http://localhost:8080/plain-%21%24%26%27%28%29%2A%2B%2C%2D%
2E%31%32%33%41%42%43%5F%61%62%63%7E

Using the simplistic $ nc -kl localhost 8080 here are the results
I obtained from a couple of current browsers. More observations and
feedback
of other user-agents to this list would be appreciated.

Chrome 53:
GET /unreserved-._~/sub-delims-!$&'()*+,;=/gen-delims-:@?query HTTP/1.1
GET /gen-delims-[]/invalid-%20%22%3C%3E/%5E%60%7B%7C%7D%C2%A7%E2%80%A1
 HTTP/1.1
odd>^^ ^
GET /encoded-%23%25%2F%3A%3B%3D%3F%40%5B%5C%5D%7B%7C%7D HTTP/1.1
GET /plain-%21%24%26%27%28%29%2A%2B%2C-.123ABC_abc~ HTTP/1.1
odd>^  ^  ^  ^  ^  ^  ^  ^  ^

Firefox 48:
GET /unreserved-._~/sub-delims-!$&'()*+,;=/gen-delims-:@?query HTTP/1.1
GET /gen-delims-[]/invalid-%20%22%3C%3E/%5E%60%7B|%7D HTTP/1.1
odd>^^ ^ ^
GET /encoded-%23%25%2F%3A%3B%3D%3F%40%5B%5C%5D%7B%7C%7D%C2%A7%E2%80%A1
 HTTP/1.1
GET /plain-%21%24%26%27%28%29%2A%2B%2C%2D%2E%31%32%33%41%42%43%5F%61%62%63%7E
HTTP/1.1
odd>^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^
 ^

IE 11:
GET /unreserved-._~/sub-delims-!$&'()*+,;=/gen-delims-:@?query HTTP/1.1
GET /gen-delims-[]/invalid-%20%22%3C%3E/%5E%60%7B%7C%7D%C2%A7%E2%80%A1
HTTP/1.1
odd>^^ ^
GET /encoded-%23%25%2F%3A%3B%3D%3F%40%5B%5C%5D%7B%7C%7D HTTP/1.1
GET /plain-%21%24%26%27%28%29%2A%2B%2C-.123ABC_abc~ HTTP/1.1
odd>^  ^  ^  ^  ^  ^  ^  ^  ^



> The character '\' is converted to a '/' by both browsers, in a nod either
> to Microsoft insanity, or a less-accessible '/' key. (Which suggests that
> the yen sign might be treated similarly in some jp locales.) Invalid as a
> literal '\' character, both browsers support an explicit %5C for those who
> really want to use that in a URI. No actual issue here.
>

Ditto for Microsoft IE.


> Interestingly, gen-delims '@' and ':' are explicitly allowed by 3.3
> grammer
> (as I've tested above), while '[' and ']' are omitted and therefore not
> allowed
> according to spec. (On this, StrictURI won't care yet, because we are
> simply correcting for any valid URI character, not by section, and '[' ']'
> are
> obviously allowed for the IPv6 port specification - so we don't reject
> yet.)
> When we add strict parsing to the apr uri parsing function, we will trip
> over this, from all browsers, in spite of these being prohibited and
> declared
> unwise for the past 18 years or more.
>

IE also suffers the '[' ']' defect above, and does not share the
Firefox-specific
defect of '|' below. In short Chrome and IE behavior appears to be
identical
over the wire.


> The character '|' is also invalid. However, Firefox fails to follow the
> spec
> again here (although Chrome gets it right).
>
> With respect to these characters, recall this 18 year old document,
> last paragraph describes the rational;
> https://tools.ietf.org/html/rfc2396.html#section-2.4.3
>
>unwise  = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
>
>Data corresponding to excluded characters must be escaped in order to
>

Re: Random AH01842 errors in mod_session_crypto

2016-09-12 Thread Yann Ylavic 
On Mon, Sep 12, 2016 at 10:31 AM, Ewald Dieterich  wrote:
> On 06/13/2016 09:38 AM, Ewald Dieterich wrote:
>
> Looks like the problem is this:

Thanks for invertigating!

>
> * In session_crypto_init() a crypto context is created from a global pool
> (server->pconf).
> * In encrypt_string() and decrypt_string() a key is created from the context
> via apr_crypto_passphrase() using the global pool for allocating memory for
> the key.

True, this is because we give apr_crypto_passphrase() a NULL key.

> * Multiple threads might access the global pool at the same time.

Correct, hence the data corruption (possibly crash).

>
> I changed mod_session_crypto to use the request pool instead and it seems
> that this fixed my problem.
>
> I think this also fixes a memory consumption problem: Keys are only created,
> but never explicitly destroyed (or reused). So for every request memory is
> allocated from the global pool, but this memory is never freed during the
> lifetime of mod_session_crypto. Using the request pool fixes this problem
> because it is destroyed when the request is done.
>
> See the attached patch session-crypto.patch that I created for 2.4.20.

Thanks for the patch, possibly a simpler way to fix it would be:

Index: modules/session/mod_session_crypto.c
===
--- modules/session/mod_session_crypto.c(revision 1760149)
+++ modules/session/mod_session_crypto.c(working copy)
@@ -246,6 +246,8 @@ static apr_status_t decrypt_string(request_rec * r
 return res;
 }

+key = apr_pcalloc(r->pool, sizeof *key);
+
 /* try each passphrase in turn */
 for (; i < dconf->passphrases->nelts; i++) {
 const char *passphrase = APR_ARRAY_IDX(dconf->passphrases, i, char *);
_

so that crypto_passphrase() will use the given key instead of
allocating a new one.

Regards,
Yann.

Re: httpd track in Seville

2016-09-12 Thread jean-frederic clere 
On 09/12/2016 04:26 PM, Stefan Eissing wrote:
> Unfortunately, I will not be able to make it to Seville. If I can
> help in regard to presenting what is new in Apache HTTP/2 by
> answering questions or creating slides, pls let me know.

Sure I will... Basically I need to add what is new since last time I
presented the topic (AKA in Vancover in May).

Cheers

Jean-Frederic

> 
> Cheers, Stefan
> 
>> Am 12.09.2016 um 14:28 schrieb jean-frederic clere
>> :
>> 
>> On 08/30/2016 03:34 PM, Rich Bowen wrote:
>>> As you know, the CFP for ApacheCon closes in less than 2 weeks.
>>> It would be awesome if we could pull together an httpd track,
>>> highlighting that httpd is still the flagship of the ASF, and is
>>> still exciting, relevant, and alive. The last few ApacheCons, we
>>> haven't managed to muster a track, or even a half day.
>> 
>> my classical talk: "HTTP/2 and SSL/TLS state of art in our
>> servers" could also ajusted to cover more httpd if not used
>> somewhere else.
>> 
>> Cheers
>> 
>> Jean-Frederic
>> 
>>> 
>>> To this end, we've started to put together a proposed list of
>>> talks that we'd like to see people submit, in the hopes that we
>>> end up with 2 days - a user track, and a developer track - of
>>> httpd content.
>>> 
>>> https://public.etherpad-mozilla.org/p/httpd-apachecon-seville
>>> 
>>> Please claim (and submit!) talks that appear on this list, and
>>> suggest others that we haven't thought of. Also, please plan to
>>> attend. The venue is beautiful and cheap, and it would be awesome
>>> to have a bunch of us there to do an old-school squash-the-bugs
>>> write-the-code meet-the-devs hackathon.
>>> 
>>> (Disclaimer: talks put on this etherpad are not automatically
>>> accepted. There's still the actual talk selection process, which
>>> is done by committee, and is subject to what other stuff is
>>> submitted to the event, and available space.)
>>> 
>> 
> 
>

StrictURI in the wild [Was: Backporting HttpProtocolOptions survey]

2016-09-12 Thread William A Rowe Jr 
On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem  wrote:

>
> On 08/29/2016 06:25 PM, William A Rowe Jr wrote:
> > Thanks all for the feedback. Status and follow-up questions inline
> >
> > On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr  > wrote:
> >
> > 4. Should the next 2.4/2.2 releases default to Strict[URI] at all?
> >
> > Real world direct observation especially appreciated from actual
> deployments.
> >
> > Strict (and StrictURI) remain the default.
>
> StrictURI as a default only makes sense if we have our own house in order
> (see above), otherwise it should be opt in.


So it's not only our house [our %3B encoding in httpd isn't a showstopper
here]... but also whether widely used user-agent browsers and tooling have
their houses in order, so I started to study the current browser behaviors.
The applicable spec is https://tools.ietf.org/html/rfc3986#section-3.3

Checked the unreserved set with '?' and '/' observing special meanings.
Nothing here should become escaped when given as a URI;
http://localhost:8080/unreserved-._~/sub-delims-!$&;'()*+,;=/gen-delims-:@?query

Checked the invalid set of characters all of which must be encoded
per the spec, and verify that #frag is not passed to the server;
http://localhost:8080/gen-delims-[]/invalid- "<>\^`{|}#frag

Checked the reserved set including '#' '%' '?' by their encoded value
to determine if there are any unpleasant reverse surprises lurking;
http://localhost:8080/encoded-%23%25%2F%3A%3B%3D%3F%40%5B%5C%5D%7B%7C%7D

Checked a list of unreserved/unassigned gen-delims and sub-delims
to determine if the user agent normalizes while composing the request;
http://localhost:8080/plain-%21%24%26%27%28%29%2A%2B%2C%2D%2E%31%32%33%41%42%43%5F%61%62%63%7E

Using the simplistic $ nc -kl localhost 8080 here are the results
I obtained from a couple of current browsers, more observations and
feedback
of other user-agents to this list would be appreciated.

Chrome 53:
GET /unreserved-._~/sub-delims-!$&'()*+,;=/gen-delims-:@?query HTTP/1.1
GET /gen-delims-[]/invalid-%20%22%3C%3E/%5E%60%7B%7C%7D HTTP/1.1
odd>^^ ^
GET /encoded-%23%25%2F%3A%3B%3D%3F%40%5B%5C%5D%7B%7C%7D HTTP/1.1
GET /plain-%21%24%26%27%28%29%2A%2B%2C-.123ABC_abc~ HTTP/1.1
odd>^  ^  ^  ^  ^  ^  ^  ^  ^

Firefox 48:
GET /unreserved-._~/sub-delims-!$&'()*+,;=/gen-delims-:@?query HTTP/1.1
GET /gen-delims-[]/invalid-%20%22%3C%3E/%5E%60%7B|%7D HTTP/1.1
odd>^^ ^ ^
GET /encoded-%23%25%2F%3A%3B%3D%3F%40%5B%5C%5D%7B%7C%7D HTTP/1.1
GET
/plain-%21%24%26%27%28%29%2A%2B%2C%2D%2E%31%32%33%41%42%43%5F%61%62%63%7E
HTTP/1.1
odd>^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^  ^
 ^

The character '\' is converted to a '/' by both browsers, in a nod either
to Microsoft insanity, or a less-accessible '/' key. (Which suggests that
the yen sign might be treated similarly in some jp locales.) Invalid as a
literal '\' character, both browsers support an explicit %5C for those who
really want to use that in a URI. No actual issue here.

Interestingly, gen-delims '@' and ':' are explicitly allowed by 3.3 grammer
(as I've tested above), while '[' and ']' are omitted and therefore not
allowed
according to spec. (On this, StrictURI won't care yet, because we are
simply correcting for any valid URI character, not by section, and '[' ']'
are
obviously allowed for the IPv6 port specification - so we don't reject yet.)
When we add strict parsing to the apr uri parsing function, we will trip
over this, from all browsers, in spite of these being prohibited and
declared
unwise for the past 18 years or more.

The character '|' is also invalid. However, Firefox fails to follow the spec
again here (although Chrome gets it right).

With respect to these characters, recall this 18 year old document,
last paragraph describes the rational;
https://tools.ietf.org/html/rfc2396.html#section-2.4.3

   unwise  = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"

   Data corresponding to excluded characters must be escaped in order to
   be properly represented within a URI.


Which replaced https://tools.ietf.org/html/rfc1738#section-2.2 now
almost 22 years old, without changing the rules;

   Unsafe:

   Characters can be unsafe for a number of reasons.  The space
   character is unsafe because significant spaces may disappear and
   insignificant spaces may be introduced when URLs are transcribed or
   typeset or subjected to the treatment of word-processing programs.
   The characters "<" and ">" are unsafe because they are used as the
   delimiters around URLs in free text; the quote mark (""") is used to
   delimit URLs in some systems.  The character "#" is unsafe and should
   always be encoded because it is used in World Wide Web and in other
   systems to delimit a URL from a fragment/anchor identifier that might
   follow it.  The character "%" is unsafe because it is used for
   encodings of other chara

Re: Backporting HttpProtocolOptions survey

2016-09-12 Thread William A Rowe Jr 
On Mon, Aug 29, 2016 at 1:04 PM, Ruediger Pluem  wrote:

>
> On 08/29/2016 06:25 PM, William A Rowe Jr wrote:
> > Thanks all for the feedback. Status and follow-up questions inline
> >
> > On Thu, Aug 25, 2016 at 10:02 PM, William A Rowe Jr  > wrote:
> >
> > A couple key questions now that the full refactoring of legacy vs.
> strict is mostly complete (there remain potential
> > issues with some of the 3-4 yr old changes on trunk which I'll raise
> in other posts.) But speaking only to the
> > request line and request header parsing...
> >
> > 3. Do we need multiple
> > layers of 'Strict'ness, or should there be a single toggle, or no
> toggle, no tolerant input at all in the next
> > 2.2/2.4 releases?
> >
> > Discussion item:
> >
> > I am not sold that StrictURI can be collapsed into this flag. Right now,
> not even
> > httpd itself promises to correctly encode resulting URI's, AIUI. Until
> we have our
> > own house in order, it seems we need to remain flexible about this. The
> \t\v\r\f\0
> > characters are always now prohibited, so it's considerably more safe.
> Strict further
> > bans all unencoded ctrl's in the URL. So StrictURI takes this one step
> further, and
> > bans all unencoded obs-text along with SP / '"' / '<' / '>' / '\' / '^'
> / '`' / '{' / '|' / '}'
> >
> > Since it's expected that a number of sites will have to relax UnsafeURI
> due to
> > these encoding issues, even with the resulting URI's generated by httpd
> servers,
> > and will have to do so for *public facing* interfaces, I strongly
> believe that this
> > flag  needs to remain distinct, or we will have lots of servers with
> entirely unsafe
> > parsing, not with only limited exposure by accepting bad URIs. Thoughts?
>
> Given the situation you describe it sounds sensible to keep this distinct.



> >
> > 4. Should the next 2.4/2.2 releases default to Strict at all? Or
> remain permissive (Unsafe) and allow the user to
> > toggle these to Strict(... Whitespace... URI)?
> >
> > Real world direct observation especially appreciated from actual
> deployments.
> >
> > Strict (and StrictURI) remain the default. The Allow0.9 and
> LenientMethods
>
> StrictURI as a default only makes sense if we have our own house in order
> (see above), otherwise it should be opt in.
>

Relative to our own house, I discovered that ';' is currently in the list
of those characters we insist on encoding. According to RFC3986,
while ';' has a special meaning, and as a sub-delim there is a potentially
distinct value of %3B... our own behavior seems entirely broken.

When we receive either ';' or %3B it is decoded to ';' in our r->uri, as we
decode all of the pct-escaped chars.  Take this example;

http://example.com/foo;enc=en%3Bus/test.html

(Ignore the fact that my example has a much more logical way to choose
the language variant of a foo path segment).

r->uri becomes /foo;enc=en;us/test.html - this is part of the path to the
file system we will look for. The httpd server has no special logic to
handle
such args or properties as described in the last paragraph of section 3.3,
they aren't an httpd consideration at all.

But worse, if the character ';' is distinct from %3B at the origin server,
we
are passing a proxied path of /foo%3Benc=en%3Bus/test.html - and also
returning redirects in that form. The character ';' is smashed and cannot
be recovered, although it's allowed by section 3.3, and it's plain-text
meaning is both more prevalent and more often correct.

Seems we are better off handing back or handing off /foo;enc=en;us/test.html
than the current /foo%3Benc=en%3Bus/test.html - the current behavior
is a much more pervasive error than the second case of embedded %3B
within a ';' section.

This appears to be our only mis-encoding from path to a composed URI.
The rest of this logic reflects section 3.3 rules, so I'll commit this
addition
shortly to this allowed (don't-escape) list, and we will still accept either
form on input;

if (!apr_isalnum(c) && !strchr("$-_.+!*'(),:@&=/~", c)) {
flags |= T_OS_ESCAPE_PATH;
}

Re: httpd track in Seville

2016-09-12 Thread Stefan Eissing 
Unfortunately, I will not be able to make it to Seville. If I can help in 
regard to presenting what is new in Apache HTTP/2 by answering questions or 
creating slides, pls let me know.

Cheers, Stefan

> Am 12.09.2016 um 14:28 schrieb jean-frederic clere :
> 
> On 08/30/2016 03:34 PM, Rich Bowen wrote:
>> As you know, the CFP for ApacheCon closes in less than 2 weeks. It would
>> be awesome if we could pull together an httpd track, highlighting that
>> httpd is still the flagship of the ASF, and is still exciting, relevant,
>> and alive. The last few ApacheCons, we haven't managed to muster a
>> track, or even a half day.
> 
> my classical talk: "HTTP/2 and SSL/TLS state of art in our servers"
> could also ajusted to cover more httpd if not used somewhere else.
> 
> Cheers
> 
> Jean-Frederic
> 
>> 
>> To this end, we've started to put together a proposed list of talks that
>> we'd like to see people submit, in the hopes that we end up with 2 days
>> - a user track, and a developer track - of httpd content.
>> 
>> https://public.etherpad-mozilla.org/p/httpd-apachecon-seville
>> 
>> Please claim (and submit!) talks that appear on this list, and suggest
>> others that we haven't thought of. Also, please plan to attend. The
>> venue is beautiful and cheap, and it would be awesome to have a bunch of
>> us there to do an old-school squash-the-bugs write-the-code
>> meet-the-devs hackathon.
>> 
>> (Disclaimer: talks put on this etherpad are not automatically accepted.
>> There's still the actual talk selection process, which is done by
>> committee, and is subject to what other stuff is submitted to the event,
>> and available space.)
>> 
>

Re: httpd track in Seville

2016-09-12 Thread William A Rowe Jr 
On Sep 12, 2016 7:28 AM, "jean-frederic clere"  wrote:
>
> On 08/30/2016 03:34 PM, Rich Bowen wrote:
> > As you know, the CFP for ApacheCon closes in less than 2 weeks. It would
> > be awesome if we could pull together an httpd track, highlighting that
> > httpd is still the flagship of the ASF, and is still exciting, relevant,
> > and alive. The last few ApacheCons, we haven't managed to muster a
> > track, or even a half day.
>
> my classical talk: "HTTP/2 and SSL/TLS state of art in our servers"
> could also ajusted to cover more httpd if not used somewhere else.

That would fit nicely and cover 2 holes in one session, unless we wanted to
dedicate more time to one or both.

Re: httpd track in Seville

2016-09-12 Thread jean-frederic clere 
On 08/30/2016 03:34 PM, Rich Bowen wrote:
> As you know, the CFP for ApacheCon closes in less than 2 weeks. It would
> be awesome if we could pull together an httpd track, highlighting that
> httpd is still the flagship of the ASF, and is still exciting, relevant,
> and alive. The last few ApacheCons, we haven't managed to muster a
> track, or even a half day.

my classical talk: "HTTP/2 and SSL/TLS state of art in our servers"
could also ajusted to cover more httpd if not used somewhere else.

Cheers

Jean-Frederic

> 
> To this end, we've started to put together a proposed list of talks that
> we'd like to see people submit, in the hopes that we end up with 2 days
> - a user track, and a developer track - of httpd content.
> 
> https://public.etherpad-mozilla.org/p/httpd-apachecon-seville
> 
> Please claim (and submit!) talks that appear on this list, and suggest
> others that we haven't thought of. Also, please plan to attend. The
> venue is beautiful and cheap, and it would be awesome to have a bunch of
> us there to do an old-school squash-the-bugs write-the-code
> meet-the-devs hackathon.
> 
> (Disclaimer: talks put on this etherpad are not automatically accepted.
> There's still the actual talk selection process, which is done by
> committee, and is subject to what other stuff is submitted to the event,
> and available space.)
>

Re: Random AH01842 errors in mod_session_crypto

2016-09-12 Thread Ewald Dieterich 

On 06/13/2016 09:38 AM, Ewald Dieterich wrote:

I configured form authentication with mod_auth_form, mod_session_cookie
and mod_session_crypto in Apache 2.4.20 on Debian unstable and get
random AH01842 errors ("decrypt session failed, wrong passphrase"). The
passphrase was not changed when this happens.

It looks like the error occurs when the following conditions are met:

* mpm_worker enabled (never experienced the error with mpm_prefork)
* Same user doing multiple requests in parallel using the same session
(don't see the error when the user is doing only sequential requests)


Looks like the problem is this:

* In session_crypto_init() a crypto context is created from a global 
pool (server->pconf).
* In encrypt_string() and decrypt_string() a key is created from the 
context via apr_crypto_passphrase() using the global pool for allocating 
memory for the key.

* Multiple threads might access the global pool at the same time.
* APR documentation about pool thread-safety: "Note that most operations 
on pools are not thread-safe: a single pool should only be accessed by a 
single thread at any given time."


I changed mod_session_crypto to use the request pool instead and it 
seems that this fixed my problem.


I think this also fixes a memory consumption problem: Keys are only 
created, but never explicitly destroyed (or reused). So for every 
request memory is allocated from the global pool, but this memory is 
never freed during the lifetime of mod_session_crypto. Using the request 
pool fixes this problem because it is destroyed when the request is done.


See the attached patch session-crypto.patch that I created for 2.4.20.
--- a/modules/session/mod_session_crypto.c
+++ b/modules/session/mod_session_crypto.c
@@ -34,7 +34,7 @@
 
 #include "apr_crypto.h"/* for apr_*_crypt et al */
 
-#define CRYPTO_KEY "session_crypto_context"
+#define DRIVER_KEY "session_crypto_driver"
 
 module AP_MODULE_DECLARE_DATA session_crypto_module;
 
@@ -333,6 +333,35 @@
 
 }
 
+static int session_crypto_init_per_request(request_rec *r, const apr_crypto_t **ff)
+{
+apr_crypto_t *f = NULL;
+
+session_crypto_conf *conf = ap_get_module_config(r->server->module_config,
+&session_crypto_module);
+
+if (conf->library) {
+const apr_crypto_driver_t *driver = NULL;
+apr_pool_t *p = r->pool;
+apr_status_t rv;
+
+apr_pool_userdata_get((void **)&driver, DRIVER_KEY,
+  r->server->process->pconf);
+
+rv = apr_crypto_make(&f, driver, conf->params, p);
+if (APR_SUCCESS != rv) {
+ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r, APLOGNO(01848)
+  "The crypto context could not be initialised");
+return rv;
+}
+}
+
+*ff = f;
+
+return OK;
+}
+
+
 /**
  * Crypto encoding for the session.
  *
@@ -349,7 +378,13 @@
 &session_crypto_module);
 
 if (dconf->passphrases_set && z->encoded && *z->encoded) {
-apr_pool_userdata_get((void **)&f, CRYPTO_KEY, r->server->process->pconf);
+res = session_crypto_init_per_request(r, &f);
+if (res != OK) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, res, r,
+  "session_crypto_encode: session_crypto_init_per_request failed");
+return res;
+}
+
 res = encrypt_string(r, f, dconf, z->encoded, &encoded);
 if (res != OK) {
 ap_log_rerror(APLOG_MARK, APLOG_DEBUG, res, r, APLOGNO(01841)
@@ -380,8 +415,13 @@
 &session_crypto_module);
 
 if ((dconf->passphrases_set) && z->encoded && *z->encoded) {
-apr_pool_userdata_get((void **)&f, CRYPTO_KEY,
-r->server->process->pconf);
+res = session_crypto_init_per_request(r, &f);
+if (res != OK) {
+ap_log_rerror(APLOG_MARK, APLOG_DEBUG, res, r,
+  "session_crypto_decode: session_crypto_init_per_request failed");
+return res;
+}
+
 res = decrypt_string(r, f, dconf, z->encoded, &encoded);
 if (res != APR_SUCCESS) {
 ap_log_rerror(APLOG_MARK, APLOG_ERR, res, r, APLOGNO(01842)
@@ -402,7 +442,6 @@
 apr_pool_t *ptemp, server_rec *s)
 {
 const apr_crypto_driver_t *driver = NULL;
-apr_crypto_t *f = NULL;
 
 session_crypto_conf *conf = ap_get_module_config(s->module_config,
 &session_crypto_module);
@@ -451,19 +490,11 @@
 return rv;
 }
 
-rv = apr_crypto_make(&f, driver, conf->params, p);
-if (APR_SUCCESS != rv) {
-ap_log_error(APLOG_MARK, APLOG_ERR, rv, s, APLOGNO(01848)
-"The crypto library '%s' could not be initialised",
-conf->library);
-return rv;
-}
-
 ap_log_error(APLOG_MARK, APLOG_INFO, rv, s, APLOGNO(01849)
 "The crypto library '%s' was loaded successfully",
 conf->library);