Re: [PATCH] SSL: don't enable SSLv3 by default
On Oct 31, 2014, at 7:24 AM, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Oct 30, 2014 at 04:33:09PM -0700, Piotr Sikora wrote: Hey Maxim, - SSLv3 is still important from compatibility point of view, there are various clients which doesn't support (or enable by default) anything better; But is it, really? All major browsers (Chrome [1], Firefox [2], IE [3], Opera [4]) either already disabled SSLv3 or are about to do it. AFAIK, the only browser already disabled SSLv3 for now is Opera 12, an obsolete Presto-based branch. The links provided suggests the same. (This is mostly unrelated though, as from nginx point of view it's the number of clients without anything better than SSLv3 is important.) Huge chunk of websites (42% of Alexa's top 10.000 [5]) requires at least TLSv1.0, including major properties like Facebook, Twitter [6], Wikipedia [7] and websites that are using one of the popular CDNs (CloudFlare [8], Akamai [9], MaxCDN [10], Fastly [11]). The 42% here means, on the other hand, that 58% are still available via SSLv3, including Google, Youtube, Amazon, Microsoft and so on. While 42% is a good number, I'm pretty sure the question is different. As a minor comment, some interesting stats here http://news.netcraft.com/archives/2014/10/15/googles-poodle-affects-oodles.html OpenBSD and LibreSSL disabled SSLv3 by default [12]. Furthermore, when we disabled SSLv3 across our network [8] and gave website owners the ability to opt-in back to it... less than 0.001% did re-enable it. And the comments there suggests people have problems with at least libcurl. On the other hand, I'm pretty sure that php scripts using libcurl with SSLv3 aren't vulnerable to POODLE. Hopefully that list is long enough to convince you that SSLv3 is not really important... Definitely not important enough to be enabled by default, because that's what the commit changes, people can still enable SSLv3 in the conf if they really need to. As previously said, this was alrady discussed excessively and we decided to preserve the default for now. We'll likely reconsider the change later. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Gzip Gunzip: always flush busy bufs when the incoming chain is NULL.
# HG changeset patch
# User Yichun Zhang agen...@gmail.com
# Date 1414804249 25200
# Fri Oct 31 18:10:49 2014 -0700
# Node ID 38a74e59f199edafad0a8caae5cfc921ab3302e8
# Parent dff86e2246a53b0f4a61935cd5c8c0a0f66d0ca2
Gzip Gunzip: always flush busy bufs when the incoming chain is NULL.
After the system send buffer is full, NULL incoming chains are used to
flush pending output upon new write events. The current gzip and gunzip
filters may intercept NULL chains and keep the data stalling in
nginx's own send buffers, leading to request hanging (until send
timeout).
This regression had appeared in nginx 1.7.7.
diff -r dff86e2246a5 -r 38a74e59f199
src/http/modules/ngx_http_gunzip_filter_module.c
--- a/src/http/modules/ngx_http_gunzip_filter_module.c Mon Aug 25
13:41:31 2014 +0400
+++ b/src/http/modules/ngx_http_gunzip_filter_module.c Fri Oct 31
18:10:49 2014 -0700
@@ -200,7 +200,7 @@ ngx_http_gunzip_body_filter(ngx_http_req
}
}
-if (ctx-nomem) {
+if (ctx-nomem || in == NULL) {
/* flush busy buffers */
diff -r dff86e2246a5 -r 38a74e59f199
src/http/modules/ngx_http_gzip_filter_module.c
--- a/src/http/modules/ngx_http_gzip_filter_module.c Mon Aug 25
13:41:31 2014 +0400
+++ b/src/http/modules/ngx_http_gzip_filter_module.c Fri Oct 31
18:10:49 2014 -0700
@@ -373,7 +373,7 @@ ngx_http_gzip_body_filter(ngx_http_reque
r-connection-buffered |= NGX_HTTP_GZIP_BUFFERED;
}
-if (ctx-nomem) {
+if (ctx-nomem || in == NULL) {
/* flush busy buffers */
# HG changeset patch
# User Yichun Zhang agen...@gmail.com
# Date 1414804249 25200
# Fri Oct 31 18:10:49 2014 -0700
# Node ID 38a74e59f199edafad0a8caae5cfc921ab3302e8
# Parent dff86e2246a53b0f4a61935cd5c8c0a0f66d0ca2
Gzip Gunzip: always flush busy bufs when the incoming chain is NULL.
After the system send buffer is full, NULL incoming chains are used to
flush pending output upon new write events. The current gzip and gunzip
filters may intercept NULL chains and keep the data stalling in
nginx's own send buffers, leading to request hanging (until send
timeout).
This regression had appeared in nginx 1.7.7.
diff -r dff86e2246a5 -r 38a74e59f199 src/http/modules/ngx_http_gunzip_filter_module.c
--- a/src/http/modules/ngx_http_gunzip_filter_module.c Mon Aug 25 13:41:31 2014 +0400
+++ b/src/http/modules/ngx_http_gunzip_filter_module.c Fri Oct 31 18:10:49 2014 -0700
@@ -200,7 +200,7 @@ ngx_http_gunzip_body_filter(ngx_http_req
}
}
-if (ctx-nomem) {
+if (ctx-nomem || in == NULL) {
/* flush busy buffers */
diff -r dff86e2246a5 -r 38a74e59f199 src/http/modules/ngx_http_gzip_filter_module.c
--- a/src/http/modules/ngx_http_gzip_filter_module.c Mon Aug 25 13:41:31 2014 +0400
+++ b/src/http/modules/ngx_http_gzip_filter_module.c Fri Oct 31 18:10:49 2014 -0700
@@ -373,7 +373,7 @@ ngx_http_gzip_body_filter(ngx_http_reque
r-connection-buffered |= NGX_HTTP_GZIP_BUFFERED;
}
-if (ctx-nomem) {
+if (ctx-nomem || in == NULL) {
/* flush busy buffers */
___
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
