Re: httpd and letsencrypt

[William A Rowe Jr]

I think this is great, in concept.

My experience with letsencrypt (which was quite good, FWIW) is that
the project delivered a contained and trusted environment to sync and
deliver new keys and retrieve signed certificates. I'll be interested to see
what simplification is presented, I don't think we want to get into the
business of delivering container-style distributions of httpd.



On Fri, Aug 26, 2016 at 9:47 AM, Rich Bowen  wrote:

> At LinuxCon I spoke with the director of the LetsEncrypt project - whose
> business card I haven't yet found in unpacking - and he asked whether
> the httpd project would be interested in LetsEncrypt being "in" httpd.
> That is, when one installs httpd, letsencrypt would just be a config
> option. (I have no idea how this would actually work, but that's beside
> the point really.)
>
> Is this something that we'd be interested in, if it were contributed? I
> note that their software is under the Apache License, so there shouldn't
> be any difficulty on that front.
>
> Naturally, I told him that the next step was to get on this mailing list
> and talk about implementation details, and he said he'd do that. So that
> should be coming in the next week, as soon as I find his business card
> and send him the subscribe info and so on.
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>

Re: httpd and letsencrypt

[Jacob Perkins]

That’s an interesting idea. Having a native client for Lets Encrypt would be 
super useful. However, I will say my first thought was a worry that it might be 
disruptive, and causes users of httpd to change any current implementations of 
integrations with Lets Encrypt downstream.

/me stays tuned
—
Jacob Perkins
Product Owner
cPanel Inc.

jacob.perk...@cpanel.net 
Office:  713-529-0800 x 4046
Cell:  713-560-8655

Get WEIRED | cPanel Conference 2016
http://go.cpanel.net/WEIRED 
> On Aug 26, 2016, at 11:44 AM, Jacob Champion  wrote:
> 
> On 08/26/2016 07:47 AM, Rich Bowen wrote:
>> At LinuxCon I spoke with the director of the LetsEncrypt project - whose
>> business card I haven't yet found in unpacking - and he asked whether
>> the httpd project would be interested in LetsEncrypt being "in" httpd.
>> That is, when one installs httpd, letsencrypt would just be a config
>> option. (I have no idea how this would actually work, but that's beside
>> the point really.)
>> 
>> Is this something that we'd be interested in, if it were contributed? I
>> note that their software is under the Apache License, so there shouldn't
>> be any difficulty on that front.
> 
> I assume you mean that they would donate a Let's Encrypt *client* for us to 
> ship? I think that would be neat.
> 
> --Jacob



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: httpd and letsencrypt

[Jim Jagielski]

+1

I am guessing someone from:

  https://letsencrypt.org/about/
or
  https://letsencrypt.org/isrg/

most likely Josh Aas?

> On Aug 26, 2016, at 12:44 PM, Jacob Champion  wrote:
> 
> On 08/26/2016 07:47 AM, Rich Bowen wrote:
>> At LinuxCon I spoke with the director of the LetsEncrypt project - whose
>> business card I haven't yet found in unpacking - and he asked whether
>> the httpd project would be interested in LetsEncrypt being "in" httpd.
>> That is, when one installs httpd, letsencrypt would just be a config
>> option. (I have no idea how this would actually work, but that's beside
>> the point really.)
>> 
>> Is this something that we'd be interested in, if it were contributed? I
>> note that their software is under the Apache License, so there shouldn't
>> be any difficulty on that front.
> 
> I assume you mean that they would donate a Let's Encrypt *client* for us to 
> ship? I think that would be neat.
> 
> --Jacob

Re: mod_http2 - h2_session(): connections get's closed on graceful restart

[Stefan Priebe - Profihost AG]

Hi Stefan

tested today and works fine.

I just discovered another problem when using http2. Sadly i've no idea
what the problem is. May be you have an idea on how to debug.

I've a CGI Script written in perl which crashes with an internal server
error every 5-15 calls while running under http/2 details below.

What i've tested so far:
- works 100% with http/1.1

- works 100% with http2 if i close STDERR at the beginning this makes me
think it might be a http2 bug and not a perl bug or may be both.

- it happens only if i reload / or click fast enough it does not if i
leave 2-4s between each click

This might be the log (it's difficult to isolate the request):
[Fri Aug 26 19:54:05.303242 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(1461): [client 1.2.3.4:38822] AH03073:
h2_stream(212-43): submit response 200, REMOTE_WINDOW_SIZE=6291456
[Fri Aug 26 19:54:05.303388 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(652): [client 1.2.3.4:38822] AH03068:
h2_session(212): sent FRAME[HEADERS[length=34, hend=1, stream=43,
eos=0]], frames=25/45 (r/s)
[Fri Aug 26 19:54:05.303412 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(652): [client 1.2.3.4:38822] AH03068:
h2_session(212): sent FRAME[DATA[length=3, flags=1, stream=43,
padlen=0]], frames=25/46 (r/s)
[Fri Aug 26 19:54:05.303789 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(1707): [client 1.2.3.4:38822] AH03078:
h2_session(212): transit [BUSY] -- no io (keepalive) --> [IDLE]
[Fri Aug 26 19:54:05.321979 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_stream.c(205): [client 1.2.3.4:38822] AH03082:
h2_stream(212-45): opened
[Fri Aug 26 19:54:05.322017 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(432): [client 1.2.3.4:38822] AH03066:
h2_session(212): recv FRAME[HEADERS[length=126, hend=1, stream=45,
eos=1]], frames=25/47 (r/s)
[Fri Aug 26 19:54:05.322051 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(1707): [client 1.2.3.4:38822] AH03078:
h2_session(212): transit [IDLE] -- data read --> [BUSY]
[Fri Aug 26 19:54:05.651654 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(432): [client 1.2.3.4:38822] AH03066:
h2_session(212): recv FRAME[RST_STREAM[length=4, flags=0, stream=45]],
frames=26/47 (r/s)
[Fri Aug 26 19:54:05.651673 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(501): [client 1.2.3.4:38822] AH03067:
h2_session(212-45): RST_STREAM by client, errror=8
[Fri Aug 26 19:54:05.651678 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(340): [client 1.2.3.4:38822] AH03065:
h2_stream(212-45): closing with err=8 cancel
[Fri Aug 26 19:54:05.651697 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_stream.c(205): [client 1.2.3.4:38822] AH03082:
h2_stream(212-47): opened
[Fri Aug 26 19:54:05.651720 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(432): [client 1.2.3.4:38822] AH03066:
h2_session(212): recv FRAME[HEADERS[length=126, hend=1, stream=47,
eos=1]], frames=27/47 (r/s)
[Fri Aug 26 19:54:06.119019 2016] [http2:debug] [pid 13222:tid
139700772161280] h2_task.c(357): [client 1.2.3.4:38822] AH03348:
h2_task(212-45): open response to GET X.de /admin/admin.cgi?todo=admin
[Fri Aug 26 19:54:06.421545 2016] [cgid:error] [pid 13222:tid
139700755375872] [client 1.2.3.4:38822] End of script output before
headers: admin.cgi, referer: https://X.de/admin/admin.cgi?todo=admin
[Fri Aug 26 19:54:06.422195 2016] [http2:debug] [pid 13222:tid
139700755375872] h2_task.c(357): [client 1.2.3.4:38822] AH03348:
h2_task(212-47): open response to GET X.de /admin/admin.cgi?todo=admin
[Fri Aug 26 19:54:06.422276 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(1461): [client 1.2.3.4:38822] AH03073:
h2_stream(212-47): submit response 500, REMOTE_WINDOW_SIZE=6291456
[Fri Aug 26 19:54:06.422302 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(652): [client 1.2.3.4:38822] AH03068:
h2_session(212): sent FRAME[HEADERS[length=73, hend=1, stream=47,
eos=0]], frames=28/47 (r/s)
[Fri Aug 26 19:54:06.422319 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(652): [client 1.2.3.4:38822] AH03068:
h2_session(212): sent FRAME[DATA[length=1751, flags=1, stream=47,
padlen=0]], frames=28/48 (r/s)
[Fri Aug 26 19:54:06.422615 2016] [http2:debug] [pid 13222:tid
139700320794368] h2_session.c(1707): [client 1.2.3.4:38822] AH03078:
h2_session(212): transit [BUSY] -- no io (keepalive) --> [IDLE]

Greets,
Stefan
Am 25.08.2016 um 10:26 schrieb Stefan Eissing:
> So, the fix is in both trunk and 2.4.x and the github repo has a new release. 
> Can you verify that it works for you also? Thanks!
> 
> 
>> Am 24.08.2016 um 10:18 schrieb Stefan Priebe - Profihost AG 
>> :
>>
>> Hi Stefan,
>>
>> were you able to reproduce? Did you need any help?
>>
>> Greets,
>> Stefan
>> Am 22.08.2016 um 18:07 schrieb Stefan Eissing:
>>> Hi Stefan,
>>>
>>> I am looking into this. It is definitely a 

Re: Backporting HttpProtocolOptions survey

[Jacob Champion]

On 08/25/2016 08: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...

1. Does it make sense to emit these parsing failures at the info level?
Or debug level (or in trunk/2.4, only at the trace level?) Granted some
legitimate internal diagnostics may be required, so it needs to have
some potential visibility, but the vast majority of such traffic is
abusive and doesn't need a place in most error logs.


Debug.


2. Should we ban \r\n\v\f unequivocally from request and request header
fields altogether, or is there a legitimate need to support these? Or
should these follow the UnsafeWhitespace toggle and be permitted?


No opinion.


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?


Multiple, at the very least to separate discouraged-but-conformant 
behavior from nonconformant behavior. (I know having multiple options is 
messy, and having too many knobs is already a problem. But I think that 
exposing only one, loosely defined, "allow a bunch of stuff" setting 
will just mean it becomes the next cargo-cult directive in everyone's 
configurations.)



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)?


Strict by default.

--Jacob

Re: httpd and letsencrypt

[Jacob Champion]

On 08/26/2016 07:47 AM, Rich Bowen wrote:

At LinuxCon I spoke with the director of the LetsEncrypt project - whose
business card I haven't yet found in unpacking - and he asked whether
the httpd project would be interested in LetsEncrypt being "in" httpd.
That is, when one installs httpd, letsencrypt would just be a config
option. (I have no idea how this would actually work, but that's beside
the point really.)

Is this something that we'd be interested in, if it were contributed? I
note that their software is under the Apache License, so there shouldn't
be any difficulty on that front.


I assume you mean that they would donate a Let's Encrypt *client* for us 
to ship? I think that would be neat.


--Jacob

httpd and letsencrypt

[Rich Bowen]

At LinuxCon I spoke with the director of the LetsEncrypt project - whose
business card I haven't yet found in unpacking - and he asked whether
the httpd project would be interested in LetsEncrypt being "in" httpd.
That is, when one installs httpd, letsencrypt would just be a config
option. (I have no idea how this would actually work, but that's beside
the point really.)

Is this something that we'd be interested in, if it were contributed? I
note that their software is under the Apache License, so there shouldn't
be any difficulty on that front.

Naturally, I told him that the next step was to get on this mailing list
and talk about implementation details, and he said he'd do that. So that
should be coming in the next week, as soon as I find his business card
and send him the subscribe info and so on.

-- 
Rich Bowen - rbo...@rcbowen.com - @rbowen
http://apachecon.com/ - @apachecon

Re: Backporting HttpProtocolOptions survey

[William A Rowe Jr]

On Aug 25, 2016 22:02, "William A Rowe Jr"  wrote:

> 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?

My thoughts on three toggles ran like this...

Unsafe allows things httpd has offered which run counter to the current
RFC723x series of specs. Admins supporting errant user-agents would unlock
this alone.

UnsafeWhitespace allows unusual whitespace defined in RFC7230 section 3.5
that httpd has permitted. It is cautioned against but doesn't fit that
first pattern. If this is the only error encountered in a necessary
user-agents, This is all the admin should permit. This is the easiest to
fold into a general Unsafe flag.

UnsafeURI might be the single most common error encountered, and flows from
RFC3986's precise grammar. I expect more admins will have to permit this
exception than either of the two above.

Anyways, just wanted to share my thoughts on why two or three flags may be
appropriate.

Re: Backporting HttpProtocolOptions survey

[Eric Covener]

On Fri, Aug 26, 2016 at 7:10 AM, Ruediger Pluem  wrote:
>
>
> On 08/26/2016 05:02 AM, 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...
>>
>> 1. Does it make sense to emit these parsing failures at the info level? Or 
>> debug level (or in trunk/2.4, only at the
>> trace level?) Granted some legitimate internal diagnostics may be required, 
>> so it needs to have some potential
>> visibility, but the vast majority of such traffic is abusive and doesn't 
>> need a place in most error logs.
>
> Debug
>
>>
>> 2. Should we ban \r\n\v\f unequivocally from request and request header 
>> fields altogether, or is there a legitimate need
>> to support these? Or should these follow the UnsafeWhitespace toggle and be 
>> permitted?
>
> We should ban it unequivocally.
>
>>
>> 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?
>
> Only a single toggle.
>
>>
>> 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)?
>
> Default should be strict.
>

+1

Re: Backporting HttpProtocolOptions survey

[Ruediger Pluem]

On 08/26/2016 05:02 AM, 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...
> 
> 1. Does it make sense to emit these parsing failures at the info level? Or 
> debug level (or in trunk/2.4, only at the
> trace level?) Granted some legitimate internal diagnostics may be required, 
> so it needs to have some potential
> visibility, but the vast majority of such traffic is abusive and doesn't need 
> a place in most error logs.

Debug

> 
> 2. Should we ban \r\n\v\f unequivocally from request and request header 
> fields altogether, or is there a legitimate need
> to support these? Or should these follow the UnsafeWhitespace toggle and be 
> permitted?

We should ban it unequivocally.

> 
> 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?

Only a single toggle.

> 
> 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)?

Default should be strict.

> 
> Real world direct observation especially appreciated from actual deployments.
> 
> 
> 

Regards

Rüdiger