Disable SSL compression for security reasons.

After the recent discussion about SSL compression both in shazow/urllib3#109
and kennethreitz/requests#1583 (this issue was about performance reason, it got me to look at other projects, performance is _not_ the reason for this issue) I looked at the behaviour of other popular open source projects. It turned out that the following projects disable the compression by default for [security reasons](https://en.wikipedia.org/wiki/CRIME_(security_exploit\)):
- Nginx, July 2012 ([version 1.2.2](http://nginx.org/en/CHANGES-1.2), [version 1.3.2, the development version to 1.4](http://nginx.org/en/CHANGES-1.4)
- Apache2, ([version 2.2.25](https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcompression), [version 2.4.4](https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcompression))
- The upcoming version 2.7 of the Pound reverse proxy (the `CHANGELOG` file in the source archive: http://www.apsis.ch/pound/Pound-2.7b.tgz)
- [Curl 7.28.1](http://curl.haxx.se/changes.html#7_28_1) July 2012
- CPython >= 3.4 (http://hg.python.org/cpython/rev/98eb88d3d94e)

This are the only projects I have looked at. I am sure we can find more if necessary.
As the stdlib `ssl` module does not allow us to change this parameter before 3.3
I propose to raise the issue on the CPython bug tracker, so that SSL
compression will be disabled by default (with the possibility to manually
enable it on 3.3 and later).

The current handlich of CPython 3.4 and up only disables compression on openssl
1.0 and up, as the relevant constant has not introduced before. However the
nginx changelog claims to also disable compression on earlier versions. I will
look into this.

This issue is meant to gather feedback and momentum before raising the issue with CPython (and maybe also the other implementations)

/cc @lukasa @sigmavirus24 @shazow @alex @jmhodges


Fwiw, urllib3 _just_ merged a PR which disables this by default in Py32+ and PyOpenSSL, big thanks to @dbrgn for bringing it up and writing the patch. https://github.com/shazow/urllib3/pull/309


Ah, I linked the wrong urllib3 issue. This should of course have been issue 309.


I'm 100% in favour of this. 2.7 is clearly accepting some SSL related changes in the next version (see [20207](http://bugs.python.org/issue20207) from @alex), so it doesn't seem unreasonable to make a push for this as well.

Unfortunately, it doesn't save requests/urllib3 _entirely_, because both projects support 2.6 and 2.6 is deader-than-dead.


If the enterprise distributions still supporting 2.6 see that the (security) changes are applied to the still maintained versions of Python they know they should backport those patches.


I've resolved to letting 2.6 get whatever subset of functionality we're able to reasonably provide, until it becomes too much of a hassle and we have to drop it.


Fine then. So we just need to work out how to do it. It's clear that @t-8ch has some plans to investigate nginx, so I'm open to doing that for now.


+1 on disabling TLS compression.

On Fri, Jan 10, 2014 at 10:54 AM, Cory Benfield notifications@github.comwrote:

> Fine then. So we just need to work out how to do it. It's clear that
> @t-8ch https://github.com/t-8ch has some plans to investigate nginx, so
> I'm open to doing that for now.
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/1857#issuecomment-32054215
> .

## 

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084


Here is [what nginx is doing](http://trac.nginx.org/nginx/browser/nginx/src/event/ngx_event_openssl.c?rev=4aa64f6950313311e0d322a2af1788edeb7f036c#L106):
(if `SSL_OP_NO_COMPRESSION` is not available, openssl < 1.0.0)

``` c
int                  n;
STACK_OF(SSL_COMP)  *ssl_comp_methods;

ssl_comp_methods = SSL_COMP_get_compression_methods();
n = sk_SSL_COMP_num(ssl_comp_methods);

while (n--) {
    (void) sk_SSL_COMP_pop(ssl_comp_methods);
}
```

(Nginx is 2-clause BSD licensed, so we should be fine)


Yeah, that looks reasonable to me. Any idea when the relevant functions were introduced to OpenSSL?


Nginx gates this code behind

```
#if OPENSSL_VERSION_NUMBER >= 0x0090800fL
```

It seems compression itself has been implemented some versions earlier but openssl >= 0.9.8 should cover most installations.


Am I right to understand that a CPython 2.7 ticket needs to be made to disable TLS compression?


From OS X 10.9 with Python HEAD I get:

u'tls_compression_supported': False

On Fri, Jan 10, 2014 at 2:32 PM, Jeff Hodges notifications@github.comwrote:

> Am I right to understand that a CPython 2.7 ticket needs to be made to
> disable TLS compression?
> 
> —
> Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/1857#issuecomment-32073294
> .

## 

"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084


@jmhodges This is the plan.
@alex I guess your are running it with openssl > 1.0.0. If yes, the last point of my initial list applies.


What's the state of this?


Closed for massive inactivity. =D