Re: svn commit: r1569108 - /httpd/httpd/branches/2.4.x/STATUS
On Feb 17, 2014, at 4:11 PM, Mike Rumph mike.ru...@oracle.com wrote: Hello Jim, I voted for this change for backport to 2.4.8. The fix looks solid to me at this time. But I do have a couple of questions/ideas for the future. 1) proxy_schemes_t in modules/proxy/proxy_util.c and schemes_t in apr-util/uri/apr_uri.c are identical in structure and field names. Could this be pulled to apr-util/include/apr_util.h in future releases of apr-util? Yep. And doing so would require no changes to the httpd-side. 2) Could mod_proxy_wstunnel.c benefit from a similar change as this fix does for mod_proxy_http.c? Ooo... let me look. Thanks, Mike Rumph On 2/17/2014 12:42 PM, mru...@apache.org wrote: Author: mrumph Date: Mon Feb 17 20:42:15 2014 New Revision: 1569108 URL: http://svn.apache.org/r1569108 Log: Vote for mod_proxy fix. Modified: httpd/httpd/branches/2.4.x/STATUS Modified: httpd/httpd/branches/2.4.x/STATUS URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1569108r1=1569107r2=1569108view=diff == --- httpd/httpd/branches/2.4.x/STATUS (original) +++ httpd/httpd/branches/2.4.x/STATUS Mon Feb 17 20:42:15 2014 @@ -98,6 +98,14 @@ RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] + * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided +port is the default port, don't add to canon URI). Ensures that ajp and +fcgi uses the defined workers and not the default generic reverse proxy +worker. +trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1542562 +2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch ++1: jim, druggeri, mrumph + PATCHES PROPOSED TO BACKPORT FROM TRUNK: [ New proposals should be added at the end of the list ] @@ -114,20 +122,11 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK: without mod_request and mod_session present would cause the very same failure. Would a warning in the release notes be good enough? - * mod_proxy: Use consistent canon formats for http, ajp and fcgi (if provided -port is the default port, don't add to canon URI). Ensures that ajp and -fcgi uses the defined workers and not the default generic reverse proxy -worker. -trunk patch: https://svn.apache.org/viewvc?view=revisionrevision=1542562 -2.4.x patch: http://people.apache.org/~jim/patches/proxy-port-scheme.patch -+1: jim, druggeri - * prefork: PR: 54852. Only use a dummy_connection for idle processes trunk patch: http://svn.apache.org/viewvc?view=revisionrevision=1542379 2.4.x patch: trunk patch works mod CHANGES +1: jim, covener - * FreeBSD: Disable IPv4-mapped listening sockets by default for versions 5+ instead of just for FreeBSD 5. PR 53824. trunk patch: http://svn.apache.org/r1551685
Re: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Dne Út 17. prosince 2013 18:35:50, Kaspar Brand napsal(a):
On 26.11.2013 06:31, Kaspar Brand wrote:
As far as PR 55782 is concerned, the problem might be that
proxy_util.c:ap_proxy_determine_connection() does not take Host: header
differences into account when checking if an existing connection can be
reused (not sure). With SNI this would have the effect that the hostname
from the TLS handshake is causing the mismatch with the Host: header.
To clear this up: the above guess was a red herring. mod_proxy's current
behavior is fine in this aspect and does not conflict with any IP resolution
coincidence when reverse proxying SNI-based URLs (I'm aware that this
thread is supposed to deal with forward proxying only, but am adding this
for posterity, in case someone is sifting through archives).
It's not ap_proxy_determine_connection() which is really relevant, but
proxy_util.c:ap_proxy_get_worker() instead. mod_proxy (only) reuses workers
for reverse proxying based on the target URL; looking at
proxy_util.c:ap_proxy_get_worker() in 2.4 e.g we see:
/*
* Do a longest match on the worker name to find the worker that
* fits best to the URL, but keep in mind that we must have at least
* a minimum matching of length min_match such that
* scheme://hostname[:port] matches between worker and url.
*/
if (balancer) {
proxy_worker **workers = (proxy_worker **)balancer-workers-elts;
for (i = 0; i balancer-workers-nelts; i++, workers++) {
worker = *workers;
if ( ((worker_name_length = strlen(worker-s-name)) =
url_length) (worker_name_length = min_match)
(worker_name_length max_match)
(strncmp(url_copy, worker-s-name, worker_name_length)
== 0) ) { max_worker = worker;
max_match = worker_name_length;
}
}
} else {
worker = (proxy_worker *)conf-workers-elts;
for (i = 0; i conf-workers-nelts; i++, worker++) {
if ( ((worker_name_length = strlen(worker-s-name)) =
url_length) (worker_name_length = min_match)
(worker_name_length max_match)
(strncmp(url_copy, worker-s-name, worker_name_length)
== 0) ) { max_worker = worker;
max_match = worker_name_length;
}
}
}
I.e., there's no risk of two workers for reverse proxying, say,
https://foo.example.net and https://bar.example.net, ever being reused for
each other, irrespective of whether foo.example.net and bar.example.net
resolve to the same IP address.
Kaspar
Hi,
sorry for late follow-up but you are wrong.
There is one big risk when someone uses reverse HTTPS proxy with ServerAlias.
Let say you have on both - backend and proxy servers options:
ServerName www.example.com
ServerAlias example.com
In old non-SNI days everything was working just fine.
Now when one client connects to proxy and requires www.example.com, connection
is established to backend server with SNI hostname set to www.example.com.
Second client connects to proxy and requires example.com. Worker is matched
because there is just one. Connection is reused but you will get 4xx Bad
Request because there is mismatch between old and current SNI hostname.
It's kind of heisenbug because even tons of request to example.com only or to
www.example.com only are just fine. You have to request both sites at the same
time to realize what's going on.
--
Pavel Mateja
Re: Welcome to Mike Rumph and Yann Ylavic!
w00t! On Feb 17, 2014, at 12:26 PM, Eric Covener cove...@gmail.com wrote: Mike Rumph and Yann Ylavic have recently joined us as committers. Welcome! (We don't usually send this welcome e-mail to dev@, but I think it's a good thing to do).
Re: asynch websocket, how to timeout?
I think this needs to be handled as 1 API within event, taking the existing API and adding a timeout, rather than having the caller register separate timed callbacks. This way, event can mark the timeout as no longer needed before pushing the first event to the worker. This way there's no question about the timers and callbacks running in different orders. When we are pulling timer events off the timer list, we can just ignore ones that are no longer needed. The ignore flag can be set w/o the lock rather than trying to fish it out of the list. On Sat, Feb 15, 2014 at 1:45 PM, Eric Covener cove...@gmail.com wrote: There is a deficiency in the asynch websocket stuff in trunk. For background, the websockets proxy acts like mod_proxy_connect after the initial setup. It can ask event to watch both sockets for it and return SUSPENDED. But there is no separate timeout if neither end sees activity, so the request can stretch out a long time. My only idea here is: Fire off some separate timer event at a relatively long interval to see if the pair of sockets has been idle for a very long time (it would have the same baton as the other callback) Optionally, the timer event could be cancelled when the socket callback fires -- we would need to add a way to cancel those events. Otherwise, it would just try to grab the invoke mutex then check to see when the last socket activity was. Anybody have better ideas? -- Eric Covener cove...@gmail.com -- Eric Covener cove...@gmail.com
Re: Adding AddHandler support for mod_proxy
AddHandler might be tricky from security point of view, eg. most of cms
software
usually checks only for last extension before writing uploaded files,
but this AddHandler will also
pass test.php.jpeg to php which might execute this
Yes, It would be probably safer to use something like:
FilesMatch \.php$
SetHandler proxy:unix:/path/to/app.sock|fcgi://localhost/
/FilesMatch
2014-02-17 0:11 GMT+01:00 Lazy lazy...@gmail.com:
2014-02-06 ryo takatsuki ryotakats...@gmail.com:
Hi,
I have an improvement request to suggest but I would like to first provide
some background to justify it, I apologise for the long email :).
I'm actively using mod_proxy to forward PHP files requests to PHP-FPM. My
current approach is to use a RewriteRule with the 'P' flag because (in most
of the cases) it plays nicely with other rules configured by the
applications I'm configuring, as well as allowing per-Directory
configurations.
To make it properly work I must assure the proxy RewriteRule must be the
latest one to be evaluated. The problem is that from time to time I
encounter corner cases in which the rules previously executed include a [L]
option that abort the next rules evaluation, skipping the proxy one, making
Apache serve the PHP text as plain text. This can be solved by tweaking the
rules but it is a tedious process and is hard to determine all the scenarios
in which the rewrites could go wrong.
IMHO this is a good idea, a handler is more compatible with .htacess
files created for
mod_php and it fits shared hosting env
Thinking about my goal with all of this was at the beginning, I realised I
only wanted a way of configuring a handler for all my PHP files, that in
this case is PHP-FPM, without having to worry about what happens before the
resource is going to be served. This made my think about the possibility of
adding this functionality to mod_proxy itself, allowing defining a proxy
worker as a handler for certain types of files. Something like:
AddHandler proxy:unix:/path/to/app.sock|fcgi://localhost/ .php
AddHandler might be tricky from security point of view, eg. most of cms
software
usually checks only for last extension before writing uploaded files,
but this AddHandler will also
pass test.php.jpeg to php which might execute this
I made a quick POC, it is a really small change and for those in my
situation it could really simplify the configuration of their apps. Of
course, I'm open to criticisms and alternative solutions :).
The code that adds the new functionality is inserted at the beginning of
mod_proxy's proxy_handler. The conditions are a little weird because I only
wanted to check the handler if it is not a proxy request already.
diff --git a/modules/proxy/mod_proxy.c b/modules/proxy/mod_proxy.c
index 9d7c92f..49f3bdc 100644
--- a/modules/proxy/mod_proxy.c
+++ b/modules/proxy/mod_proxy.c
@@ -927,8 +927,20 @@ static int proxy_handler(request_rec *r)
struct dirconn_entry *list = (struct dirconn_entry
*)conf-dirconn-elts;
/* is this for us? */
-if (!r-proxyreq || !r-filename || strncmp(r-filename, proxy:, 6)
!= 0)
+if (!r-filename)
+ return DECLINED;
+
+if (!r-proxyreq) {
+ if (r-handler strncmp(r-handler, proxy:, 6) == 0
strncmp(r-filename, proxy:, 6) != 0) {
+r-proxyreq = PROXYREQ_REVERSE;
+r-filename = apr_pstrcat(r-pool, r-handler, r-filename, NULL);
+apr_table_setn(r-notes, rewrite-proxy, 1);
+ } else {
return DECLINED;
+ }
+} else if (strncmp(r-filename, proxy:, 6) != 0) {
+ return DECLINED;
+}
/* handle max-forwards / OPTIONS / TRACE */
if ((str = apr_table_get(r-headers_in, Max-Forwards))) {
--
I've seen things you people wouldn't believe.
Attack ships on fire off the shoulder of Orion.
I watched C-beams glitter in the dark near Tannhauser Gate.
All those moments will be lost in time like tears in rain.
Time to die.
Segmentation faults when SSLProxyCheckPeerName On
Hi, since we've enabled SSLProxyCheckPeerName our reverserse proxy I can see AH00052: child pid 5711 exit signal Segmentation fault (11) in our logs during Nessus scans. Backend server has several X509v3 Subject Alternative Names and Nessus sends just IP as Host header. We are running: Apache/2.4.7 (Unix) OpenSSL/1.0.1f Mod_backtrace says: Crash at 2014-02-18 14:24:22 Process id: 5912 Fatal signal: 11 /apache/modules/mod_backtrace.so:0xb709bede /apache/modules/mod_whatkilledus.so:0xb709668b /apache/modules/mod_whatkilledus.so:0xb709686b /apache/bin/httpd:ap_run_fatal_exception+0x48 0x807b51f /apache/bin/httpd:0x80a75e7 /apache/bin/httpd:0x80a7622 [0xb774b400] /lib/libaprutil-1.so.0:apr_brigade_cleanup+0x22 0xb7578535 /lib/libaprutil-1.so.0:0xb757850d /lib/libapr-1.so.0:0xb75308db /lib/libapr-1.so.0:apr_pool_destroy+0x52 0xb752fb10 /apache/bin/httpd:0x8092603 /apache/modules/mod_ssl.so:0xb72e0c4f /apache/bin/httpd:ap_pass_brigade+0x94 0x807d9d1 /apache/modules/mod_ssl.so:0xb72e099f /apache/bin/httpd:ap_pass_brigade+0x94 0x807d9d1 /apache/bin/httpd:ap_process_request_after_handler+0x9a 0x8104c52 /apache/bin/httpd:ap_process_async_request+0x674 0x8105308 /apache/bin/httpd:ap_process_request+0x1a 0x8105328 /apache/bin/httpd:0x81014c0 /apache/bin/httpd:0x81015c9 /apache/bin/httpd:ap_run_process_connection+0x48 0x80a3ccb /apache/bin/httpd:ap_process_connection+0x51 0x80a4100 /apache/bin/httpd:0x818d3e9 Anobody seen something similar? -- Pavel Matěja
Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
On 02/18/2014 08:14 AM, Pavel Matěja wrote: There is one big risk when someone uses reverse HTTPS proxy with ServerAlias. Let say you have on both - backend and proxy servers options: ServerName www.example.com ServerAlias example.com In old non-SNI days everything was working just fine. Now when one client connects to proxy and requires www.example.com, connection is established to backend server with SNI hostname set to www.example.com. Second client connects to proxy and requires example.com. Worker is matched because there is just one. Connection is reused but you will get 4xx Bad Request because there is mismatch between old and current SNI hostname. It seems like an administrator could avoid this risk by doing hostname canonicalization via external redirect at the proxy itself. This probably isn't a currently common practice, but for sites who should canonicalize their hostnames, i don't see it as particularly onerous. The main concern would be for non-canonicalized hostnames. e.g. *.example.com, where each user of a service gets to set up https://$USERNAME.example.com/. A proxy would need to pass this information through to the origin server -- so in the scenario you describe, a reverse proxy could run into serious trouble. --dkg signature.asc Description: OpenPGP digital signature
Re: asynch websocket, how to timeout?
+1... On Feb 18, 2014, at 9:29 AM, Eric Covener cove...@gmail.com wrote: I think this needs to be handled as 1 API within event, taking the existing API and adding a timeout, rather than having the caller register separate timed callbacks. This way, event can mark the timeout as no longer needed before pushing the first event to the worker. This way there's no question about the timers and callbacks running in different orders. When we are pulling timer events off the timer list, we can just ignore ones that are no longer needed. The ignore flag can be set w/o the lock rather than trying to fish it out of the list. On Sat, Feb 15, 2014 at 1:45 PM, Eric Covener cove...@gmail.com wrote: There is a deficiency in the asynch websocket stuff in trunk. For background, the websockets proxy acts like mod_proxy_connect after the initial setup. It can ask event to watch both sockets for it and return SUSPENDED. But there is no separate timeout if neither end sees activity, so the request can stretch out a long time. My only idea here is: Fire off some separate timer event at a relatively long interval to see if the pair of sockets has been idle for a very long time (it would have the same baton as the other callback) Optionally, the timer event could be cancelled when the socket callback fires -- we would need to add a way to cancel those events. Otherwise, it would just try to grab the invoke mutex then check to see when the last socket activity was. Anybody have better ideas? -- Eric Covener cove...@gmail.com -- Eric Covener cove...@gmail.com
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson
shen...@opensslfoundation.com wrote:
On 02/02/2014 13:45, Kaspar Brand wrote:
On 01.02.2014 14:37, Dr Stephen Henson wrote:
I'm wondering how that could be avoided. Would a way to enumerate all
certificates in an SSL_CTX structure in OpenSSL help? Something like
SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate().
That would
also set the current certificate at the same time in case applications
wanted to
inspect the private key or chain.
Yes, this sounds like a useful extension - not only for the issue at
hand (i.e. SSL_CONF and stapling initialisation), but as a general
mechanism for retrieving all certificates of an SSL_CTX.
Added now. The API is slightly different, but easy enough to use.
To iterate over all certificates in an SSL_CTX something like this will do
the
trick:
X509 *x;
int rv;
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
while (rv)
{
X509 *x = SSL_CTX_get0_certificate(ctx);
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
}
Steve.
Is the leaf certificate always first? (And/or maybe it is up to how the
admin configures it and it only works if the leaf is first?)
The APIs work this way with the OpenSSL 1.0.2 branch now?
TIA!
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
--
Born in Roswell... married an alien...
http://emptyhammock.com/
[PATCH 55467] - Updates to mod_ssl to support TLS hello extensions and TLS supplemental data
Hi folks, I was wondering if someone would be willing/interested in reviewing the patch I've attached to issue 55467. https://issues.apache.org/bugzilla/show_bug.cgi?id=55467 The patch adds hooks to mod_ssl which give third-party modules the ability to send and receive custom TLS hello extensions TLS supplemental data. It also gives third-party modules the ability to trigger renegotiation. It leverages APIs recently added to OpenSSL master and 1.0.2 stable branches. Any feedback is appreciated! Thanks much, Scott On Feb 6, 2014, at 2:20 PM, Scott Deboy sde...@secondstryke.com wrote: Support for sending and receiving TLS hello extensions and TLS supplemental data messages has recently been added to the OpenSSL GitHub master branch. I’ve submitted a patch to mod_ssl which allows third-party modules to send and receive TLS hello extensions and TLS supplemental data via optional hooks and functions. The patch can be found here: https://issues.apache.org/bugzilla/show_bug.cgi?id=55467 I’m happy to update the patch based on feedback. Thanks much, Scott Deboy
Re: SSL_CTX_get_{first,next}_certificate (Re: svn commit: r1562500 - /httpd/httpd/branches/2.4.x/STATUS)
On 18/02/2014 20:06, Jeff Trawick wrote:
On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson
shen...@opensslfoundation.com
mailto:shen...@opensslfoundation.com wrote:
On 02/02/2014 13:45, Kaspar Brand wrote:
On 01.02.2014 14:37, Dr Stephen Henson wrote:
I'm wondering how that could be avoided. Would a way to enumerate all
certificates in an SSL_CTX structure in OpenSSL help? Something like
SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate().
That would
also set the current certificate at the same time in case applications
wanted to
inspect the private key or chain.
Yes, this sounds like a useful extension - not only for the issue at
hand (i.e. SSL_CONF and stapling initialisation), but as a general
mechanism for retrieving all certificates of an SSL_CTX.
Added now. The API is slightly different, but easy enough to use.
To iterate over all certificates in an SSL_CTX something like this will
do the
trick:
X509 *x;
int rv;
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_FIRST);
while (rv)
{
X509 *x = SSL_CTX_get0_certificate(ctx);
rv = SSL_CTX_set_current_cert(ctx, SSL_CERT_SET_NEXT);
}
Steve.
Is the leaf certificate always first? (And/or maybe it is up to how the admin
configures it and it only works if the leaf is first?)
The APIs work this way with the OpenSSL 1.0.2 branch now?
TIA!
An SSL_CTX can have multiple server certificates associated with it
and the one used depends on the ciphersuite negotiated by the client.
The certificate you get from SSL_CTX_get0_certificate is the server certificate
which will always be a leaf certificate. You need different APIs to get the rest
of the chain (assuming one has been configured).
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
