Hello!
Here are patches for OCSP stapling support. Testing and
review appreciated.
New directives:
ssl_trusted_certificate /path/to/file;
Specifies a file with CA certificates in the PEM format used for
certificate verification. In contrast to ssl_client_certificate, DNs
of these certificates aren't sent to a client in CertificateRequest.
ssl_stapling on|off;
Activates OCSP stapling.
ssl_stapling_file /path/to/file;
Use predefined OCSP response for stapling, do not query responder.
Assumes OCSP response in DER format as produced by "openssl ocsp".
ssl_stapling_responder URL;
Use specified OCSP responder instead of one found in AIA certificate
extension.
Example configuration:
server {
listen 443 ssl;
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
ssl_stapling on;
ssl_trusted_certificate /path/to/ca.pem;
resolver 8.8.8.8;
}
Known limitations:
- Unless externally set OCSP response is used (via the "ssl_stapling_file"
directive), stapled response won't be sent in a first connection. This
is due to the fact that OCSP responders are currently queried by nginx
once it receives connection with certificate_status extension in ClientHello,
and due to limitations in OpenSSL API (certificate status callback is
blocking).
- Cached OCSP responses are currently stored in local process memory (thus
each worker process will query OCSP responders independently). This
shouldn't be a problem as typical number of worker processes is low, usually
set match number of CPUs.
- Various timeouts are hardcoded (connect/read/write timeouts are 60s,
response is considered to be valid for 1h after loading). Adding
configuration directives to control these would be trivial, but it may
be a better idea to actually omit them for simplicity.
- Only "http://" OCSP responders are recognized.
Patch can be found here:
http://nginx.org/patches/ocsp-stapling/
Thanks to Comodo, DigiCert and GlobalSign for sponsoring this work.
Maxim Dounin
Hello,
I have written a module to implement sFlow in nginx (nginx-sflow-module.googlecode.com). I'm simulating a 1-second timer-tick by assuming that the request handler will be called at least once per second. That's probably a safe assumption for any server that would care about sFlow monitoring, but I expect there's a better way...
I tried asking for a timer callback like this:
ngx_event_t *ev = ngx_pcalloc(pool, sizeof(ngx_event_t));
ev->hander = ngx_http_sflow_tick_event_hander;
ngx_add_timer(ev, 1000);
but (like most russian girls) the event never called me back. It looks like I might have to hang this on a file-descriptor somehow, but that's where I'm getting lost. Any pointers would be most appreciated.
Neil
Hello!
According to the current implementation of ngx_http_upstream, there is
almost no way for 3rd-party output body filters and "post_subrequest"
handlers (in the subrequest context) to know if there's any errors
while ngx_http_upstream is processing the upstream response body after
the response header is sent out (in both the buffered and non-buffered
modes).
For example, if
1. a read-timeout happens in the middle of the process of reading the
upstream response body,
2. or the upstream connection is closed prematurely in the same situation,
then ngx_http_upstream will just happily finalize the current request
with the status code 0 (i.e., NGX_OK). This issue already affects at
least our ngx_srcache and ngx_lua modules (originally reported by
Bryan Alger).
Here attaches a patch that makes ngx_http_upstream set
r->headers_out.status to a new error status code to notify the outside
world if there is a problem. Comments will be highly appreciated as
always :)
Thanks!
-agentzh
--- nginx-1.2.3/src/http/ngx_http_upstream.c 2012-08-06 10:34:08.000000000 -0700
+++ nginx-1.2.3-patched/src/http/ngx_http_upstream.c 2012-09-09
21:58:04.727761891 -0700
@@ -2383,7 +2383,7 @@
if (c->read->timedout) {
ngx_connection_error(c, NGX_ETIMEDOUT, "upstream timed out");
- ngx_http_upstream_finalize_request(r, u, 0);
+ ngx_http_upstream_finalize_request(r, u, NGX_HTTP_GATEWAY_TIME_OUT);
return;
}
@@ -2430,13 +2430,17 @@
if (u->busy_bufs == NULL) {
if (u->length == 0
- || upstream->read->eof
- || upstream->read->error)
+ || (upstream->read->eof &&
u->headers_in.content_length_n == -1))
{
ngx_http_upstream_finalize_request(r, u, 0);
return;
}
+ if (upstream->read->eof || upstream->read->error) {
+ ngx_http_upstream_finalize_request(r, u,
NGX_HTTP_BAD_GATEWAY);
+ return;
+ }
+
b->pos = b->start;
b->last = b->start;
}
@@ -2710,7 +2714,16 @@
#if 0
ngx_http_busy_unlock(u->conf->busy_lock, &u->busy_lock);
#endif
- ngx_http_upstream_finalize_request(r, u, 0);
+
+ if (p->upstream_done
+ || (p->upstream_eof && u->headers_in.content_length_n == -1))
+ {
+ ngx_http_upstream_finalize_request(r, u, 0);
+
+ } else {
+ ngx_http_upstream_finalize_request(r, u, NGX_HTTP_BAD_GATEWAY);
+ }
+
return;
}
}
@@ -3073,6 +3086,13 @@
&& rc != NGX_HTTP_REQUEST_TIME_OUT
&& (rc == NGX_ERROR || rc >= NGX_HTTP_SPECIAL_RESPONSE))
{
+ if (rc == NGX_ERROR) {
+ r->headers_out.status = NGX_HTTP_INTERNAL_SERVER_ERROR;
+
+ } else {
+ r->headers_out.status = rc;
+ }
+
rc = 0;
}
# HG changeset patch
# User Piotr Sikora <piotr(a)cloudflare.com>
# Date 1369177319 25200
# Node ID 4b277448dfd56751c7c88477e78b2ba3cf6ae472
# Parent 1d68b502088c9d6e6603e9699354e36d03d77f9c
SNI: better server name handling.
Acknowledge acceptance of SNI server name to the OpenSSL library,
which in turn lets the client know that it was accepted (by sending
"server_name" TLS extension in the "ServerHello" handshake message,
as suggested by RFC4366).
Previously, this would happen only in case when requested server name
was on the "server_name" list and either: there were multiple virtual
servers defined for the same listening port or there was at least one
regular expression with captures in the "server_name" directive.
As a consequence, this change also:
1. Preserves requested SNI server name for future use.
2. Avoids unnecessary setting of SSL options if the virtual server
didn't change.
3. Avoids unnecessary lookup of virtual server later on if requested
HTTP server name is the same as requested SNI server name.
Signed-off-by: Piotr Sikora <piotr(a)cloudflare.com>
diff -r 1d68b502088c -r 4b277448dfd5 src/http/ngx_http_request.c
--- a/src/http/ngx_http_request.c Tue May 21 21:47:50 2013 +0400
+++ b/src/http/ngx_http_request.c Tue May 21 16:01:59 2013 -0700
@@ -773,6 +773,7 @@
ngx_http_ssl_srv_conf_t *sscf;
ngx_http_core_loc_conf_t *clcf;
ngx_http_core_srv_conf_t *cscf;
+ ngx_int_t rc;
servername = SSL_get_servername(ssl_conn, TLSEXT_NAMETYPE_host_name);
@@ -799,10 +800,10 @@
hc = c->data;
- if (ngx_http_find_virtual_server(c, hc->addr_conf->virtual_names, &host,
- NULL, &cscf)
- != NGX_OK)
- {
+ rc = ngx_http_find_virtual_server(c, hc->addr_conf->virtual_names, &host,
+ NULL, &cscf);
+
+ if (rc == NGX_ERROR) {
return SSL_TLSEXT_ERR_NOACK;
}
@@ -813,6 +814,10 @@
*hc->ssl_servername = host;
+ if (rc == NGX_DECLINED || hc->conf_ctx == cscf->ctx) {
+ return SSL_TLSEXT_ERR_OK;
+ }
+
hc->conf_ctx = cscf->ctx;
clcf = ngx_http_get_module_loc_conf(hc->conf_ctx, ngx_http_core_module);
Hi there,
I'm about to put some traffic stats code into the nginx core, as I'm going
to let the traffic go into specific user's "iptables" statistics by
setuid() rather than creating a filter counting bytes,for other toys are
already going thru iptables.
The problem is,that I can't figure out where's the point......Evan Miller's
articles?Read,but still not clear about how to go thru the chain.In
"ngx_http_write_handler" found the struct "connection" has a pointer to
function "send_chain" that might be,but can't find it anywhere.I'm not that
kind waiting for a LMGIFY link(although Google doesn't help either),but I
gracefully appreciate if you can tell it.Thanks a looooooooooooot!!
Yours,
Zorceta Moshak
details: http://hg.nginx.org/nginx/rev/c9fe549b127b
branches:
changeset: 5235:c9fe549b127b
user: Maxim Dounin <mdounin(a)mdounin.ru>
date: Fri May 31 14:59:26 2013 +0400
description:
Win32: accept_mutex now always disabled (ticket #362).
Use of accept mutex on win32 may result in a deadlock if there are multiple
worker_processes configured and the mutex is grabbed by a process which
can't accept connections.
diffstat:
src/event/ngx_event.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diffs (21 lines):
diff --git a/src/event/ngx_event.c b/src/event/ngx_event.c
--- a/src/event/ngx_event.c
+++ b/src/event/ngx_event.c
@@ -607,6 +607,17 @@ ngx_event_process_init(ngx_cycle_t *cycl
ngx_use_accept_mutex = 0;
}
+#if (NGX_WIN32)
+
+ /*
+ * disable accept mutex on win32 as it may cause deadlock if
+ * grabbed by a process which can't accept connections
+ */
+
+ ngx_use_accept_mutex = 0;
+
+#endif
+
#if (NGX_THREADS)
ngx_posted_events_mutex = ngx_mutex_init(cycle->log, 0);
if (ngx_posted_events_mutex == NULL) {