From 060cdc58cf40555bd3cbd4959496140e4e04cccb Mon Sep 17 00:00:00 2001 From: Stefan Fritsch Date: Tue, 3 Jul 2012 19:38:58 +0000 Subject: [PATCH] Merge r1327036, r1327080 from trunk: * server/mpm_unix.c (dummy_connection): Use a TLS 1.0 close_notify alert if the chosen listener is configured for https; not perfect but better than sending an HTTP request. Adjust comments. * server/mpm_unix.c (dummy_connection): Fix spello. Reviewed by: jorton, jim, covener git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1356884 13f79535-47bb-0310-9956-ffa450edef68 --- CHANGES | 3 +++ STATUS | 6 ------ server/mpm_unix.c | 55 +++++++++++++++++++++++++++++------------------ 3 files changed, 37 insertions(+), 27 deletions(-) diff --git a/CHANGES b/CHANGES index 4d784e7b4f..5ab3041efe 100644 --- a/CHANGES +++ b/CHANGES @@ -3,6 +3,9 @@ Changes with Apache 2.4.3 + *) core: Use a TLS 1.0 close_notify alert for internal dummy connection if + the chosen listener is configured for https. [Joe Orton] + *) mod_proxy: Use the the same hostname for SNI as for the HTTP request when forwarding to SSL backends. PR 53134. [Michael Weiser , Ruediger Pluem] diff --git a/STATUS b/STATUS index b0c33285d8..eb370cf944 100644 --- a/STATUS +++ b/STATUS @@ -88,12 +88,6 @@ RELEASE SHOWSTOPPERS: PATCHES ACCEPTED TO BACKPORT FROM TRUNK: [ start all new proposals below, under PATCHES PROPOSED. ] - * core: Use a TLS/10 close_notify for dummy connection to SSL listener. - trunk patches: http://svn.apache.org/viewvc?rev=1327036&view=rev - http://svn.apache.org/viewvc?rev=1327080&view=rev - 2.4 patch: trunk works => http://people.apache.org/~jorton/httpd-2.4.2-dummytls.patch - +1: jorton, jim, covener - * htdbm/htpasswd: fix handling of crypt() failures. trunk patch: http://svn.apache.org/viewvc?rev=1346905&view=rev 2.4.x patch: trunk patch (ex CHANGES) works diff --git a/server/mpm_unix.c b/server/mpm_unix.c index 87df8f57a9..65c0940753 100644 --- a/server/mpm_unix.c +++ b/server/mpm_unix.c @@ -501,14 +501,14 @@ static apr_status_t pod_signal_internal(ap_pod_t *pod) return rv; } -/* This function connects to the server, then immediately closes the connection. - * This permits the MPM to skip the poll when there is only one listening - * socket, because it provides a alternate way to unblock an accept() when - * the pod is used. - */ +/* This function connects to the server and sends enough data to + * ensure the child wakes up and processes a new connection. This + * permits the MPM to skip the poll when there is only one listening + * socket, because it provides a alternate way to unblock an accept() + * when the pod is used. */ static apr_status_t dummy_connection(ap_pod_t *pod) { - char *srequest; + const char *data; apr_status_t rv; apr_socket_t *sock; apr_pool_t *p; @@ -574,24 +574,37 @@ static apr_status_t dummy_connection(ap_pod_t *pod) return rv; } - /* Create the request string. We include a User-Agent so that - * adminstrators can track down the cause of the odd-looking - * requests in their logs. - */ - srequest = apr_pstrcat(p, "OPTIONS * HTTP/1.0\r\nUser-Agent: ", + if (lp->protocol && strcasecmp(lp->protocol, "https") == 0) { + /* Send a TLS 1.0 close_notify alert. This is perhaps the + * "least wrong" way to open and cleanly terminate an SSL + * connection. It should "work" without noisy error logs if + * the server actually expects SSLv3/TLSv1. With + * SSLv23_server_method() OpenSSL's SSL_accept() fails + * ungracefully on receipt of this message, since it requires + * an 11-byte ClientHello message and this is too short. */ + static const unsigned char tls10_close_notify[7] = { + '\x15', /* TLSPlainText.type = Alert (21) */ + '\x03', '\x01', /* TLSPlainText.version = {3, 1} */ + '\x00', '\x02', /* TLSPlainText.length = 2 */ + '\x01', /* Alert.level = warning (1) */ + '\x00' /* Alert.description = close_notify (0) */ + }; + data = (const char *)tls10_close_notify; + len = sizeof(tls10_close_notify); + } + else /* ... XXX other request types here? */ { + /* Create an HTTP request string. We include a User-Agent so + * that adminstrators can track down the cause of the + * odd-looking requests in their logs. A complete request is + * used since kernel-level filtering may require that much + * data before returning from accept(). */ + data = apr_pstrcat(p, "OPTIONS * HTTP/1.0\r\nUser-Agent: ", ap_get_server_description(), " (internal dummy connection)\r\n\r\n", NULL); + len = strlen(data); + } - /* Since some operating systems support buffering of data or entire - * requests in the kernel, we send a simple request, to make sure - * the server pops out of a blocking accept(). - */ - /* XXX: This is HTTP specific. We should look at the Protocol for each - * listener, and send the correct type of request to trigger any Accept - * Filters. - */ - len = strlen(srequest); - apr_socket_send(sock, srequest, &len); + apr_socket_send(sock, data, &len); apr_socket_close(sock); apr_pool_destroy(p); -- 2.40.0