Re: svn commit: r1714742 - /httpd/httpd/branches/2.4.x/STATUS

[Yann Ylavic]

On Tue, Nov 17, 2015 at 3:50 PM, Yann Ylavic  wrote:
> On Tue, Nov 17, 2015 at 10:48 AM,   wrote:
>>
>> Modified: httpd/httpd/branches/2.4.x/STATUS
>> URL: 
>> http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1714742=1714741=1714742=diff
>> ==
>> --- httpd/httpd/branches/2.4.x/STATUS (original)
>> +++ httpd/httpd/branches/2.4.x/STATUS Tue Nov 17 09:48:54 2015
>> @@ -161,6 +161,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
>>   2.4.x patch: 
>> http://people.apache.org/~ylavic/httpd-2.4.x-check_pipeline_blank_lines.patch
>>(trunk works, meant to ease review)
>>   +1: ylavic, minfrin
>> + icing: test 3 fails for me in t/security/CVE-2005-3357.t
>
> I can't reproduce this (with 2.4.x and this patch only)...

Finally got it.

The problem was about "HTTP spoken on HTTPS port" handling in
ssl_io_filter_input() not prepared to AP_MODE_INIT from
process_connection() and AP_MODE_SPECULATIVE read for H2Direct.

I fixed it in r1715023 by extending the NON_SSL_* state machine,
please review...

Re: 2.4.18?

[Graham Leggett]

On 18 Nov 2015, at 9:11 AM, Noel Butler  wrote:

> absolutely not! I personally only update  phpmyadmin once, on initial major 
> release, because I (like many others) were so of updating it every few days .

We’re catering for everybody here, not just your unique use case.

Regards,
Graham
—

Re: 2.4.18?

[Jim Jagielski]

If you don't need the stuff in 2.4.18 and 2.4.17 is fine
for you then there is no need to upgrade...

> On Nov 18, 2015, at 2:16 AM, Noel Butler  wrote:
> 
> On 17/11/2015 22:33, Reindl Harald wrote:
> 
>> 5 or 6 bloody weeks is a month - so what's the problem?
>> any other software but httpd is allowed to have monthly updates?
>> "I can accept" - seriously - you can just ignore a release when you
>> think it's not important for you but i don't get why anybody else
>> should wait for available non-security bugfixes just because you feel
>> like someone enforces you to update your server
> 
> your problem harry as usual is you dont comprehend whats said, because i 
> never once said it was OK for that other software, in fact its made clear 
> otherwise, but I'll grant you your comments based only on the fact you have 
> little comprehension of english and rely on translators.
> 
> 
> 
> -- 
> If you have the urge to reply to all rather than reply to list, you best
> read  http://members.ausics.net/qwerty/

CentOS 7 and test framework

[Jim Jagielski]

Anyone else having troubles convincing the test framework
in centOS 7 to recreate the various SSL certs and stuff???

usually a 'make realclean' will delete them and a t/TEST -clean
followed by t/TEST will recreate them. No luck. Nothing
removes 'em :/

Re: CentOS 7 and test framework

[Graham Leggett]

On 18 Nov 2015, at 5:45 PM, Jim Jagielski  wrote:

> Anyone else having troubles convincing the test framework
> in centOS 7 to recreate the various SSL certs and stuff???
> 
> usually a 'make realclean' will delete them and a t/TEST -clean
> followed by t/TEST will recreate them. No luck. Nothing
> removes 'em :/

I’ve had this before, but never found what caused it :(

Regards,
Graham
—

Re: 2.4.18?

[David Zuelke]

On 18.11.2015, at 08:11, Noel Butler  wrote:

> absolutely not! I personally only update  phpmyadmin once, on initial major 
> release, because I (like many others) were so of updating it every few days .

> You obviously dont manage very many public facing servers then, I have that 
> advantage of looking at it from both sides, when I do testing - I test based 
> on what sys admins want.

Please don't make your inability to quickly roll out updated versions my 
problem.

I want SO_REUSEPORT for my users, but with the REDIRECT_URL regression, I am 
stuck on 2.4.16.

You're always free to skip a release, so what's the issue?

Re: 2.4.18 backporting

[Stefan Eissing]

OK, test framework fixed in r1714972

http2 vhost test cases will not run unless openssl >= 1.0.0
http2 tests will work on a 2.4.17 and 2.5-DEV
http2 test 52 will fail on a 2.4.18-DEV without the proposed core protocols 
changes
http2 tests will work on a 2.4.18-DEV with changes applied

Hope this works for everyone. Sorry for the initial confusion.

//Stefan

> Am 17.11.2015 um 18:08 schrieb Jim Jagielski :
> 
> No issues under CentOS...
> 
>> On Nov 17, 2015, at 11:28 AM, Stefan Eissing  
>> wrote:
>> 
>> That's cheating...
>> 
>> I'll let you know when it works for me in such a configuration.
>> 
>>> Am 17.11.2015 um 16:51 schrieb Jim Jagielski :
>>> 
>>> My perl is built against openssl 1.0.2...
>>> 
 On Nov 17, 2015, at 10:43 AM, Stefan Eissing 
  wrote:
 
 OK, the problem on OS X is that the default openssl is 0.98 which does not 
 do SNI.
 
 I try to detect this in lines 14-17 by:
 my $alpn_available = exists ::SSLeay::CTX_set_alpn_protos;
 if ($alpn_available) {
 $total_tests += $vhost_suite;
 }
 
 and change the test case expectations accordingly. That seems to fail on 
 your system. The test case thinks ALPN+SNI are available and wants to see 
 "localhost" in the response, but it is not used.
 
 Unnecessary to say that the detection (and therefore the tests) work on my 
 OS X installation - also before 10.11.
 
 Hmmmare there SNI test cases for mod_ssl where I could see how it 
 detects it?
 
 
> Am 17.11.2015 um 16:30 schrieb Jim Jagielski :
> 
> Still:
> 
> t/modules/http2.t .. 26/51
> # Failed test 34 in t/modules/http2.t at line 242 fail #4
> # testing : content comparision
> # expected: '
> # Hello World!
> # TLS_SNI="localhost"
> # 
> # '
> # received: '
> # Hello World!
> # TLS_SNI=""
> # 
> # '
> not ok 34
> 
> # Failed test 50 in t/modules/http2.t at line 194 fail #6
> test case: VHOST001, expect 404 or 421 (using Host:): GET 
> https://localhost:8544/misdirected
> # testing : GET https://localhost:8544/misdirected
> # expected: 421
> # received: '404'
> not ok 50
> 
> # Failed test 51 in t/modules/http2.t at line 194 fail #7
> test case: VHOST002, expect 404 or 421 (using :authority): GET 
> https://localhost:8544/misdirected
> # Failed test 50 in t/modules/http2.t at line 194 fail #6
> # testing : GET https://localhost:8544/misdirected
> # expected: 421
> # received: '404'
> not ok 51
> 
> t/modules/http2.t .. Failed 3/51 subtests
> 
> 
>> On Nov 17, 2015, at 10:17 AM, Stefan Eissing 
>>  wrote:
>> 
>> OK, the change is from October 19th by me. I changed the test suite to 
>> have
>> the test run in deterministic order. $r is a references to an array of 
>> tests
>> and, depending on module availability, I push more elements to $r.
>> 
>> I just changed it to push @$r, { ... }
>> 
>> Please give it a try.
>> 
>>> Am 17.11.2015 um 16:06 schrieb Jim Jagielski :
>>> 
>>> I am still 10.10 but w/ Xcode 7.1.1
>>> 
>>> 
>>>  % perl -V
>>> Summary of my perl5 (revision 5 version 20 subversion 2) configuration:
>>> 
>>> Platform:
>>> osname=darwin, osvers=14.4.0, archname=darwin-thread-multi-2level
>>> uname='darwin jimsys.local 14.4.0 darwin kernel version 14.4.0: thu may 
>>> 28 11:35:04 pdt 2015; root:xnu-2782.30.5~1release_x86_64 x86_64 '
>>> config_args='-des -Duseithreads -Dusemultiplicity=y -Duseshrplib 
>>> -Dprefix=/usr/local2 -Dvendorprefix=/usr/local2'
>>> hint=recommended, useposix=true, d_sigaction=define
>>> useithreads=define, usemultiplicity=define
>>> use64bitint=define, use64bitall=define, uselongdouble=undef
>>> usemymalloc=n, bincompat5005=undef
>>> Compiler:
>>> cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe 
>>> -fstack-protector -I/usr/local/include -I/opt/local/include',
>>> optimize='-O3',
>>> cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe 
>>> -fstack-protector -I/usr/local/include -I/opt/local/include'
>>> ccversion='', gccversion='4.2.1 Compatible Apple LLVM 6.1.0 
>>> (clang-602.0.53)', gccosandvers=''
>>> intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
>>> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>>> ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', 
>>> lseeksize=8
>>> alignbytes=8, prototype=define
>>> Linker and Libraries:
>>> ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector 
>>> -L/usr/local/lib -L/opt/local/lib'
>>> libpth=/usr/local/lib 

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

[Michal Karm]

On 11/17/2015 02:28 PM, Jim Jagielski wrote:

Agreed... if we should optimize, then focusing on ap_proxy_port_of_scheme(),
which is part of the actual API, is likely best.


On Nov 17, 2015, at 8:20 AM, Yann Ylavic  wrote:

On Tue, Nov 17, 2015 at 2:12 PM, Jim Jagielski  wrote:

I would propose that if the below is NOT the cause, then the
old version remain. There is a lot to be said for simplicity
and clarity.

There is still a (per request) call to ap_proxy_port_of_scheme() in
ap_proxy_determine_connection() we can't avoid (AFAICT), so it is
worth optimize it anyway IMO.


Plus, the whole reason for ap_proxy_port_of_scheme() was
to avoid the sorts of special numbers the below "hides"
in various locations.

Agreed, the optimization in ap_proxy_port_of_scheme() only is probably better.




Hi guys, FYI,
the patch suggested by Yenn [1][2] did not help the performance
results in any substantial capacity. The difference between having and not 
having

 if (uri.port && uri.port == ap_proxy_port_of_scheme(uri.scheme)) {
 uri.port = 0;
 }

in proxy_util.c is still at least 30% performance loss, gain respectively.

The test case is having hundreds of different application contexts
being accessed by hundreds of concurrent clients.

Thanks for comments.

Cheers

[1] 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201511.mbox/%3CCAKQ1sVP-ZO%3DC8kUt_%2BtW7%2Bh5A%3DyjDuKhEE9ah9shF1xRQVciRw%40mail.gmail.com%3E
[2] 
http://mail-archives.apache.org/mod_mbox/httpd-dev/201511.mbox/%3CCAKQ1sVO_-Shud7EXrCBn-KhjdPdNVk96Npwxeeb6Lk5n0TE1KA%40mail.gmail.com%3E


Michal Karm Babacek

--
Sent from my Hosaka Ono-Sendai Cyberspace 7

RE: svn commit: r1714219 - in /httpd/httpd/trunk: docs/manual/mod/ modules/http2/

[Bert Huijben]

> -Original Message-
> From: ic...@apache.org [mailto:ic...@apache.org]
> Sent: vrijdag 13 november 2015 15:54
> To: c...@httpd.apache.org
> Subject: svn commit: r1714219 - in /httpd/httpd/trunk: docs/manual/mod/
> modules/http2/
> 
> Author: icing
> Date: Fri Nov 13 14:54:15 2015
> New Revision: 1714219
> 
> URL: http://svn.apache.org/viewvc?rev=1714219=rev
> Log:
> new directive H2Push on/off to en-/disable HTTP/2 server pushes. Server
> pushes are recognized by Link: headers in responses that carry the
> rel=preload parameter
> 


> Modified: httpd/httpd/trunk/modules/http2/h2_request.c
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/http2/h2_reque
> st.c?rev=1714219=1714218=1714219=diff
> ==
> 
> --- httpd/httpd/trunk/modules/http2/h2_request.c (original)
> +++ httpd/httpd/trunk/modules/http2/h2_request.c Fri Nov 13 14:54:15
> 2015
> @@ -31,11 +31,22 @@
> 
>  h2_request *h2_request_create(int id, apr_pool_t *pool)
>  {
> +return h2_request_createn(id, pool, NULL, NULL, NULL, NULL, NULL);
> +}
> +
> +h2_request *h2_request_createn(int id, apr_pool_t *pool,
> +   const char *method, const char *scheme,
> +   const char *authority, const char *path,
> +   apr_table_t *header)
> +{
>  h2_request *req = apr_pcalloc(pool, sizeof(h2_request));
> 
> -req->id = id;
> -req->headers = apr_table_make(pool, 10);
> -req->content_length = -1;
> +req->id = id;
> +req->method = method;
> +req->scheme = scheme;
> +req->authority  = authority;
> +req->path   = path;
> +req->headers= header? header : apr_table_make(pool, 10);
> 
>  return req;
>  }
> @@ -44,45 +55,26 @@ void h2_request_destroy(h2_request *req)
>  {
>  }
> 
> +static apr_status_t inspect_clen(h2_request *req, const char *s)
> +{
> +char *end;
> +req->content_length = apr_strtoi64(s, , 10);
> +return (s == end)? APR_EINVAL : APR_SUCCESS;
> +}
> +
>  static apr_status_t add_h1_header(h2_request *req, apr_pool_t *pool,
>const char *name, size_t nlen,
>const char *value, size_t vlen)
>  {
>  char *hname, *hvalue;
> 
> -if (H2_HD_MATCH_LIT("transfer-encoding", name, nlen)) {
> -if (!apr_strnatcasecmp("chunked", value)) {
> -/* This should never arrive here in a HTTP/2 request */
> -ap_log_perror(APLOG_MARK, APLOG_ERR, APR_BADARG, pool,
> -  APLOGNO(02945)
> -  "h2_request: 'transfer-encoding: chunked' 
> received");
> -return APR_BADARG;
> -}
> -}
> -else if (H2_HD_MATCH_LIT("content-length", name, nlen)) {
> -char *end;
> -req->content_length = apr_strtoi64(value, , 10);
> -if (value == end) {
> -ap_log_perror(APLOG_MARK, APLOG_WARNING, APR_EINVAL, pool,
> -  APLOGNO(02959)
> -  "h2_request(%d): content-length value not parsed: 
> %s",
> -  req->id, value);
> -return APR_EINVAL;
> -}
> -req->chunked = 0;
> -}
> -else if (H2_HD_MATCH_LIT("content-type", name, nlen)) {
> -/* If we see a content-type and have no length (yet),
> - * we need to chunk. */
> -req->chunked = (req->content_length == -1);
> -}
> -else if ((req->seen_host && H2_HD_MATCH_LIT("host", name, nlen))
> - || H2_HD_MATCH_LIT("expect", name, nlen)
> - || H2_HD_MATCH_LIT("upgrade", name, nlen)
> - || H2_HD_MATCH_LIT("connection", name, nlen)
> - || H2_HD_MATCH_LIT("proxy-connection", name, nlen)
> - || H2_HD_MATCH_LIT("keep-alive", name, nlen)
> - || H2_HD_MATCH_LIT("http2-settings", name, nlen)) {
> +if (H2_HD_MATCH_LIT("expect", name, nlen)
> +|| H2_HD_MATCH_LIT("upgrade", name, nlen)
> +|| H2_HD_MATCH_LIT("connection", name, nlen)
> +|| H2_HD_MATCH_LIT("proxy-connection", name, nlen)
> +|| H2_HD_MATCH_LIT("transfer-encoding", name, nlen)
> +|| H2_HD_MATCH_LIT("keep-alive", name, nlen)
> +|| H2_HD_MATCH_LIT("http2-settings", name, nlen)) {
>  /* ignore these. */
>  return APR_SUCCESS;


Not added in this revision, but this is not 100% to the spec:

http2-settings is only special if it is referenced in the upgrade header, so 
dropping "connection" would be enough.

Expect is still 100% valid in http/2; as are trailing headers, which used 
transfer-encoding in http/1. So that header shouldn't be dropped.

Not sure about keep-alive. But if I remember correctly the spec says that it 
needs to be referenced from connection too, to be applied at the connection 
layer. (But I wouldn't be surprised if actual 

Re: 2.4.18 backporting

[Jim Jagielski]

Perfect! Runs clean as a whistle!

I am ++1 for merging /httpd/httpd/branches/2.4.17-protocols-changes

> On Nov 18, 2015, at 6:17 AM, Stefan Eissing  
> wrote:
> 
> OK, test framework fixed in r1714972
> 
> http2 vhost test cases will not run unless openssl >= 1.0.0
> http2 tests will work on a 2.4.17 and 2.5-DEV
> http2 test 52 will fail on a 2.4.18-DEV without the proposed core protocols 
> changes
> http2 tests will work on a 2.4.18-DEV with changes applied
> 
> Hope this works for everyone. Sorry for the initial confusion.
> 
> //Stefan
> 
>> Am 17.11.2015 um 18:08 schrieb Jim Jagielski :
>> 
>> No issues under CentOS...
>> 
>>> On Nov 17, 2015, at 11:28 AM, Stefan Eissing  
>>> wrote:
>>> 
>>> That's cheating...
>>> 
>>> I'll let you know when it works for me in such a configuration.
>>> 
 Am 17.11.2015 um 16:51 schrieb Jim Jagielski :
 
 My perl is built against openssl 1.0.2...
 
> On Nov 17, 2015, at 10:43 AM, Stefan Eissing 
>  wrote:
> 
> OK, the problem on OS X is that the default openssl is 0.98 which does 
> not do SNI.
> 
> I try to detect this in lines 14-17 by:
> my $alpn_available = exists ::SSLeay::CTX_set_alpn_protos;
> if ($alpn_available) {
> $total_tests += $vhost_suite;
> }
> 
> and change the test case expectations accordingly. That seems to fail on 
> your system. The test case thinks ALPN+SNI are available and wants to see 
> "localhost" in the response, but it is not used.
> 
> Unnecessary to say that the detection (and therefore the tests) work on 
> my OS X installation - also before 10.11.
> 
> Hmmmare there SNI test cases for mod_ssl where I could see how it 
> detects it?
> 
> 
>> Am 17.11.2015 um 16:30 schrieb Jim Jagielski :
>> 
>> Still:
>> 
>> t/modules/http2.t .. 26/51
>> # Failed test 34 in t/modules/http2.t at line 242 fail #4
>> # testing : content comparision
>> # expected: '
>> # Hello World!
>> # TLS_SNI="localhost"
>> # 
>> # '
>> # received: '
>> # Hello World!
>> # TLS_SNI=""
>> # 
>> # '
>> not ok 34
>> 
>> # Failed test 50 in t/modules/http2.t at line 194 fail #6
>> test case: VHOST001, expect 404 or 421 (using Host:): GET 
>> https://localhost:8544/misdirected
>> # testing : GET https://localhost:8544/misdirected
>> # expected: 421
>> # received: '404'
>> not ok 50
>> 
>> # Failed test 51 in t/modules/http2.t at line 194 fail #7
>> test case: VHOST002, expect 404 or 421 (using :authority): GET 
>> https://localhost:8544/misdirected
>> # Failed test 50 in t/modules/http2.t at line 194 fail #6
>> # testing : GET https://localhost:8544/misdirected
>> # expected: 421
>> # received: '404'
>> not ok 51
>> 
>> t/modules/http2.t .. Failed 3/51 subtests
>> 
>> 
>>> On Nov 17, 2015, at 10:17 AM, Stefan Eissing 
>>>  wrote:
>>> 
>>> OK, the change is from October 19th by me. I changed the test suite to 
>>> have
>>> the test run in deterministic order. $r is a references to an array of 
>>> tests
>>> and, depending on module availability, I push more elements to $r.
>>> 
>>> I just changed it to push @$r, { ... }
>>> 
>>> Please give it a try.
>>> 
 Am 17.11.2015 um 16:06 schrieb Jim Jagielski :
 
 I am still 10.10 but w/ Xcode 7.1.1
 
 
  % perl -V
 Summary of my perl5 (revision 5 version 20 subversion 2) configuration:
 
 Platform:
 osname=darwin, osvers=14.4.0, archname=darwin-thread-multi-2level
 uname='darwin jimsys.local 14.4.0 darwin kernel version 14.4.0: thu 
 may 28 11:35:04 pdt 2015; root:xnu-2782.30.5~1release_x86_64 x86_64 '
 config_args='-des -Duseithreads -Dusemultiplicity=y -Duseshrplib 
 -Dprefix=/usr/local2 -Dvendorprefix=/usr/local2'
 hint=recommended, useposix=true, d_sigaction=define
 useithreads=define, usemultiplicity=define
 use64bitint=define, use64bitall=define, uselongdouble=undef
 usemymalloc=n, bincompat5005=undef
 Compiler:
 cc='cc', ccflags ='-fno-common -DPERL_DARWIN -fno-strict-aliasing 
 -pipe -fstack-protector -I/usr/local/include -I/opt/local/include',
 optimize='-O3',
 cppflags='-fno-common -DPERL_DARWIN -fno-strict-aliasing -pipe 
 -fstack-protector -I/usr/local/include -I/opt/local/include'
 ccversion='', gccversion='4.2.1 Compatible Apple LLVM 6.1.0 
 (clang-602.0.53)', gccosandvers=''
 intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
 d_longlong=define, longlongsize=8, d_longdbl=define, 

RE: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

[Bert Huijben]

Hi William,

 

Is any commonly used client actually implementing this spec in a way that makes 
this RFC relevant for httpd?

 

Sure we could implement this… Perhaps we already did but once you switch to TLS 
there are so many security related things to account for.

 

Ignoring the server certificate case, what about SNI and ALPN?

 

Is there really a specific upgrade to tls/1.0, 1.1 and 1.2. Or is one upgrade 
enough as the handshake does the rest.

 

Does this also allow switching to http/2 in one step via ALPN?

 

Or is that explicitly forbidden?

 

Bert

 

From: William A Rowe Jr [mailto:wr...@rowe-clan.net] 
Sent: woensdag 18 november 2015 01:10
To: httpd 
Subject: Fwd: [openssl-dev] [openssl.org #4145] Enhancement: patch to support 
s_client -starttls http

 

I'm fairly certain this will be applied to 1.1.0 and not necessarily

backported to 1.0.2, so this hack might be useful to some of you 

who want to test for the preservation of the SSLEngine optional 

Upgrade: TLS/1.0 behavior on trunk and 2.4.x branch...

 

 

 

-- Forwarded message --
From: William A. Rowe Jr. via RT  >
Date: Tue, Nov 17, 2015 at 5:26 PM
Subject: [openssl-dev] [openssl.org   #4145] Enhancement: 
patch to support s_client -starttls http
To: 
Cc: openssl-...@openssl.org  



RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL).

Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've
gone ahead and instrumented s_client to support this behavior (and noted a
small optimization in the same logic stream for starttls support).

Attached is the patch to introduce this behavior.  It is a bit crufty, but
lacking a CUPS client that did connection upgrade to TLS, I needed
something for testing and experimentation.

I don't know that there is a justification for implementing Upgrade: h2
since this is a binary protocol that is not conducive to terminal mode :)

Source licensed by me under the OpenSSL license at
https://www.openssl.org/source/license.txt - don't see a need for a CLA,
but email me privately if so.


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org  
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

 

Re: patch to mod_authz_dbd to handle query parameters

[Jose Kahan]

Hi,

Not having heard back since submitting this enhancement, I decided
to put it on github to share it with other people who may be 
interested by it [1]. I integrated the changes from [2] and used
2.4.17 as the "base version".

My original submission is [3].

Feel free to contact me if you are interested to integrate this
into apache and require further changes.

-jose

[1] https://github.com/jkbzh/apache2_mod_authz_dbd
[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=57868
[3] https://bz.apache.org/bugzilla/show_bug.cgi?id=58025

Re: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

[Yann Ylavic]

Hi Bill,

thanks, this will be quite useful.

A little note, probably some missing == here:
+else if (meth = TLSv1_2_client_method())
+BIO_printf(fbio, "Upgrade: TLS/1.2\r\n");
+else if (meth = TLSv1_1_client_method())
+BIO_printf(fbio, "Upgrade: TLS/1.1\r\n");
+else if (meth = TLSv1_client_method())
+BIO_printf(fbio, "Upgrade: TLS/1.0\r\n");
+

Cheers,
Yann.

On Wed, Nov 18, 2015 at 1:10 AM, William A Rowe Jr  wrote:
> I'm fairly certain this will be applied to 1.1.0 and not necessarily
> backported to 1.0.2, so this hack might be useful to some of you
> who want to test for the preservation of the SSLEngine optional
> Upgrade: TLS/1.0 behavior on trunk and 2.4.x branch...
>
>
>
> -- Forwarded message --
> From: William A. Rowe Jr. via RT 
> Date: Tue, Nov 17, 2015 at 5:26 PM
> Subject: [openssl-dev] [openssl.org #4145] Enhancement: patch to support
> s_client -starttls http
> To:
> Cc: openssl-...@openssl.org
>
>
> RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL).
>
> Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've
> gone ahead and instrumented s_client to support this behavior (and noted a
> small optimization in the same logic stream for starttls support).
>
> Attached is the patch to introduce this behavior.  It is a bit crufty, but
> lacking a CUPS client that did connection upgrade to TLS, I needed
> something for testing and experimentation.
>
> I don't know that there is a justification for implementing Upgrade: h2
> since this is a binary protocol that is not conducive to terminal mode :)
>
> Source licensed by me under the OpenSSL license at
> https://www.openssl.org/source/license.txt - don't see a need for a CLA,
> but email me privately if so.
>
>
> ___
> openssl-bugs-mod mailing list
> openssl-bugs-...@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
> ___
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>

Re: 2.4.18?

[Reindl Harald]

Am 18.11.2015 um 08:11 schrieb Noel Butler:

On 17/11/2015 22:31, Graham Leggett wrote:

We’ve just released HTTP/2 support for the very first time. People
want to use it, people want to see problems in it fixed. I don’t see
the number of releases as excessive at all.


You obviously dont manage very many public facing servers then, I have
that advantage of looking at it from both sides, when I do testing - I
test based on what sys admins want


not in my name!

i manage enough public facing servers, maintain enough RPM packages at 
my own and have no problem put a new release tarball below 
rpmbuild/SOURFCES, edit the version in the SPEC file and build a package 
followed by standard tests and automated deployment


not for MariaDB, not for PHP, not for anything else and as long as i can 
deploy weekly kernel updates for 35 machines (and yes for some times 
they are weekly) i can cope with monthly httpd updates pretty fine




signature.asc
Description: OpenPGP digital signature

Re: 2.4.18?

[Reindl Harald]

Am 18.11.2015 um 08:16 schrieb Noel Butler:

On 17/11/2015 22:33, Reindl Harald wrote:


5 or 6 bloody weeks is a month - so what's the problem?
any other software but httpd is allowed to have monthly updates?

"I can accept" - seriously - you can just ignore a release when you
think it's not important for you but i don't get why anybody else
should wait for available non-security bugfixes just because you feel
like someone enforces you to update your server


your problem harry as usual is you dont comprehend whats said, because i
never once said it was OK for that other software, in fact its made
clear otherwise, but I'll grant you your comments based only on the fact
you have little comprehension of english and rely on translators.


no i don't rely on a translator, i just read you other posts too before 
reply and one part of that was "take phpmyadmin as one example, most 
admins I know gave up updating it, because there were updates every 
week, sometimes  every few days, Marc has accepted this is a serious 
problem and unless a critical security bug is found, normal bug fixes 
releases will be only once per month if need be"


and here we talk about that *one month* - so what's the problem?

anyways, if you can't cope with monthly updates and in doubt decide if 
they are relevant at all hire somebody who can cope or just install a 
LTS distribution only delivering critical bugfixes




signature.asc
Description: OpenPGP digital signature

Re: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

[William A Rowe Jr]

On Wed, Nov 18, 2015 at 5:19 AM, Bert Huijben  wrote:

> Hi William,
>
>
>
> Is any commonly used client actually implementing this spec in a way that
> makes this RFC relevant for httpd?
>
>
Note httpd already implements this correctly, it's simply a matter of not
breaking it.  My quick checks indicate that 2.4.18-dev is working well.
Next check is the protocols patch in the queue.

My checks with -starttls ftp indicate we broke mod_ftp auth over explicit
tls connections some time back in 2.4.13-dev when we had fixed error
document response to speaking plain http over https.  Need to see how many
other ways mod_ftp tls has been corrupted recently, but will probably
leverage mod_ssl's internal upgrade handling for the mod_ftp use case.

The major peering for this upgrade logic has been CUPS printing.  Outside
of this case there has been fairly little traction.

SNI and ALPN both solve issues that this spec was designed to solve (host,
then tls handshake, upgrade to a specific protocol etc).

What it now solves is limited to consolidating on port 80, and very few
clients ever picked this up.


> Sure we could implement this… Perhaps we already did but once you switch
> to TLS there are so many security related things to account for.
>
>
>
> Ignoring the server certificate case, what about SNI and ALPN?
>
>
>
> Is there really a specific upgrade to tls/1.0, 1.1 and 1.2. Or is one
> upgrade enough as the handshake does the rest.
>

The spec suggests it is called out, but you are correct, in this tool we
begin at the appropriate -tls1_2 provided (fixing Yann's observation) but
perform a normal handshake.

Does this also allow switching to http/2 in one step via ALPN?
>
>
>
> Or is that explicitly forbidden?
>

There is an interesting thread
http://www.ietf.org/mail-archive/web/httpbisa/current/msg24147.html and
further discussion about ALPN vs Upgrade and the coexistence of the two
schemas.

Re: svn commit: r1650655 - in /httpd/httpd/branches/2.4.x: CHANGES STATUS modules/proxy/proxy_util.c

[Yann Ylavic]

On Wed, Nov 18, 2015 at 1:58 PM, Michal Karm  wrote:
>
> the patch suggested by Yenn [1][2] did not help the performance
> results in any substantial capacity. The difference between having and not
> having
>
>  if (uri.port && uri.port == ap_proxy_port_of_scheme(uri.scheme)) {
>  uri.port = 0;
>  }
>
> in proxy_util.c is still at least 30% performance loss, gain respectively.

The code above is load time only (i.e. not per request), so it's not
this particular ap_proxy_port_of_scheme() which eats cycles, but
rather the fact that the proxy worker URL (name) is now canonicalized
at startup (not including the port if it is well known) and thus when
that URL is parsed/used at runtime (per request) in
ap_proxy_determine_connection(), the backend's port needs to be
determined using ap_proxy_port_of_scheme().

I thought this latter call was the culprit for the increased cycles,
but it seems not (the new version should be quite more efficient than
the previous code to find a know port associated to a scheme).
So I'm a bit lost here...

Can you confirm that reverting this only commit (r1650655) from 2.4.17
fixes the performance loss?

Also, which proxy module(s) is(are) used, http/ajp/...?
How are the backends ports declared in ProxyPass/BalancerMember
directives, using the default port for the scheme (ie. 80/443 for
http/s, 8009 for ajp, ...) or with a custom port or else no port at
all?

Regards,
Yann.