* The `lua_ssl_trusted_certificate` directive does not work currently.
It requires at least nginx 1.7.0. Tengine supports nginx 1.6.2 currently.
* Some test cases in modules/ngx_http_lua_module/t cannot pass because these
cases are customized for nginx. But it does not affect the functionality.
(Later commit will add more details about test cases to document.)
* move this module from src/http/modules/lua to modules/ngx_http_lua_module
At this stage, there are few user agents in the wild which do not support
anything better than SSLv3. Even in China, the usual place cited for wide
deployments of Windows XP and Internet Explorer 6, the number of SSLv3-only
clients is rapidly diminishing since Windows XP is no longer receiving updates
and web designers around the world are now actively desupporting Internet
Explorer 6.
In light of the POODLE attack, and its recommended mitigation of RC4 for
client/server pairs which do not support TLS_FALLBACK_SCSV, it feels somewhat
irresponsible for a web server to default to known-vulnerable behavior. This
is especially true when enabling SSLv3 is as simple as specifying it in the
server's config file.
Besides Internet Explorer 6, embedded and mobile devices are generally the
only widely-deployed user agents which will be affected by the disabling of
SSLv3 from the default suite. In the case of embedded and mobile use, the
status quo seems to be that developers and administrators are explicit about
which options they set so that future changes in behavior will not affect
their deployments. However, it may be worth a documentation note.
Originally reported by Thomas Ward in nginx ticket 653:
http://trac.nginx.org/nginx/ticket/653
This patch has been tested against OpenSSL 0.9.7l 28 Sep 2006 as well as
OpenSSL 0.9.7d 17 Mar 2004 (+ security patches to 2006-09-29). These versions
will only speak TLSv1 (not 1.1 or 1.2) with this change. I do not have any
older OpenSSL versions available to me readily, and newer OpenSSL is
unlikely to have any issues whatsoever with disabling SSLv3.
Only the HTTP module has had its bitmask altered. While SSLv3 is historic
and should be disabled by default for everything, there are no known attacks
against the other modules at this time. Therefore, those changes are out of
scope for this issue.
* Directives proxy_request_buffering and fastcgi_request_buffering is enabled
by default, in which case r->request_buffering should be 1.
If r->request_buffering is 1 by default, we should patch all subrequest
creating functions to set this field of sub request structure.
* This commit also fixes segfault if sub requset has input body.
If uri '/lua' is requested, tengine will segfault with following configure:
```
location /memc {
set $memc_key $echo_request_uri;
set $memc_exptime 600;
memc_pass 127.0.0.1:11211;
}
location /lua {
content_by_lua '
res = ngx.location.capture("/memc",
{ method = ngx.HTTP_PUT, body = "hello" });
';
}
```
* If ngx_http_spdy_finalize_connection() was called,
ngx_http_spdy_body_filter(r, in) should return NGX_ERROR.
* The write timer of spdy connection may be deleted.