classification
Title: ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)
Type: security Stage: resolved
Components: Versions: Python 3.5, Python 3.4, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, Lukasa, alex, christian.heimes, donmez, dstufft, federico3, giampaolo.rodola, haypo, janssen, martius, pitrou, python-dev, rkuska
Priority: normal Keywords: needs review, patch

Created on 2014-10-14 23:11 by haypo, last changed 2015-01-06 13:38 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
issue22638.diff alex, 2014-10-14 23:12
Messages (46)
msg229368 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2014-10-14 23:11
Copy of Donald Stuff email sent to python-dev:

A big security breach of SSL 3.0 just dropped a little while ago (named POODLE).
With this there is now no ability to securely connect via SSL 3.0. I believe
that we should disable SSL 3.0 in Python similarly to how SSL 2.0 is disabled,
where it is disabled by default unless the user has explicitly re-enabled it.

The new attack essentially allows reading the sensitive data from within a SSL
3.0 connection stream. It takes roughly 256 requests to break a single byte so
the attack is very practical. You can read more about the attack here at the
google announcement [1] or the whitepaper [2].

[1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
[2] https://www.openssl.org/~bodo/ssl-poodle.pdf
msg229369 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2014-10-14 23:12
This patch disables SSLv3 by default for Python. Uesrs can get it back by specifiying SSL_PROTOCOLv3 explicitly.
msg229370 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-14 23:13
"""Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today. Therefore our recommended response is to support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks."""
msg229371 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-14 23:15
IOW, I think it may be ok to disable SSLv3 in create_default_context(), but not necessarily in other contexts.
msg229372 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2014-10-14 23:16
create_default_context already disables SSLv3! (Good work everybody :-))

FWIW many vendors are already moving to disable SSLv3, e.g. cloudflare already did.
msg229373 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-14 23:17
I think it's fine to disable it all together. Google is planning/hoping to kill SSL 3.0 completely from their clients in the next couple of months. They just don't want to release a patch that disables SSL 3.0 right today.
msg229374 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-14 23:17
How many times will it have to be repeated that SSL is used for other things than HTTPS-on-the-Web?
msg229375 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-14 23:21
I don't know, how many times will it have to be repeated that secure defaults matter?

SSL 3.0 can be turned back on easily enough, it isn't a hard shut off. It changes the default just like what was done with SSLv2.0.
msg229376 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-14 23:22
The difference is that SSLv2 had been dead for long already. We don't have any statistic about SSLv3 servers in the wild, but I'd be surprised if they had turned entirely negligible.
msg229377 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2014-10-14 23:23
CloudFlare published some statistics: https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
msg229378 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-14 23:23
There's also https://www.trustworthyinternet.org/ssl-pulse/
msg229379 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2014-10-14 23:24
Debian is also considering this, and link some statistics on IE6 specifically (one of the, if not the single, largest SSLv3 users): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765347
msg229380 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-14 23:25
On the Web, there is indeed a good reaction time to security issues (especially in large providers). That may not be the case for all the other SSL services out there.

Since TLS_FALLBACK_SCSV is the recommended solution (not to mention it will work against other attacks), do you know if it's being implemented in OpenSSL? I would be surprised if nobody did it.
msg229381 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-14 23:26
Note the Debian issue is specifically for Apache, not the OpenSSL package.
If Debian decides to disable SSLv3 in its OpenSSL package, then it will be a pretty good hint that we can do so as well :-)
msg229382 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2014-10-14 23:26
It's been implemented in boringssl: https://boringssl.googlesource.com/boringssl/+/2970779684c6f164a0e261e96a3d59f331123320

I don't believe it's in OpenSSL though.
msg229383 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-14 23:30
OpenSSL generally doesn't have bad options disabled until they are years old. OpenSSL takes the stance that it's up to the consumers of the OpenSSL API to properly configure themselves.

Also it's important to note that TLS_FALLBACK_SCSV isn't actually a work around for the SSL 3.0 problem. There is no work around for that, you can only disable SSL 3.0. TLS_FALLBACK_SCSV is completely unrelated to Python because it's a work around for the fact that browsers will re-attempt a TLS connection if the first one fails with a lower protocol verison which means a MITM can force your connection back to SSL 3.0 even if both the client and the server support TLS 1.2. I'm not 100% sure but I don't believe Python has such a dance so TLS_FALLBACK_SCSV does nothing for us.
msg229385 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-14 23:33
> OpenSSL generally doesn't have bad options disabled until they are years old. OpenSSL takes the stance that it's up to the consumers of the OpenSSL API to properly configure themselves.

The point is, if they start exposing it, we can enable it ourselves.

> I'm not 100% sure but I don't believe Python has such a dance so TLS_FALLBACK_SCSV does nothing for us.

Well, the ssl module can also be used in server mode.
msg229403 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-15 05:56
Firefox is planning to disable SSL 3.0 as well - https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

"SSLv3 will be disabled by default in Firefox 34, which will be released on Nov 25. "
msg229408 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-15 08:12
Matthew Green posted a nice explanation of the attack:
http://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html

In short, currently it requires injection of code into the "browser" (i.e. SSL client) to be exploitable. While that's easy on the WWW, it's not necessarily possible with other protocols.

I think we could strengthen all stdlib *servers* because third-party clients are generally more up-to-date than third-party servers, so we risk less disruption. That may involve a separate _create_stdlib_server_context() function.

Besides, I think that, independently of this, we could strengthen _create_stdlib_context() in 3.5.
msg229410 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-15 08:23
Hmm... of course, stdlib servers don't use create_stdlib_context() in 2.7. We'll have to do it by hand :)
msg229411 - (view) Author: Cory Benfield (Lukasa) * Date: 2014-10-15 08:30
> I don't believe it's in OpenSSL though.

There's an outstanding OpenSSL patch: http://marc.info/?l=openssl-dev&m=141333049205629&w=2

However, as Donald has pointed out, this is really only meaningful for servers and co-operating clients. It's not a useful panacea.
msg229417 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-15 08:50
Update on 2.7:
- there are no SSL servers in the stdlib (ha)
- SSL clients don't do any auto-downgrading

so it's not obvious we should patch something (if people choose to pass PROTOCOL_SSLv3, it's their problem).

Update on 3.4:
- the only SSL server in the stdlib is in asyncio, but it forces the user to pass their own SSL context (good!)
- SSL clients don't do any auto-downgrading

(3.5 should be similar)
msg229423 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2014-10-15 09:37
There is no need for a "_create_stdlib_server_context()" function. _create_stdlib_context() takes a purpose argument, too.
msg229432 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-15 11:07
I really don't think it's unreasonable to say "SSL 3.0 is insecure, if you rely on it then you need to pass this flag to use it". Passing a flag to do something insecure is hardly onerous.
msg229437 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2014-10-15 12:03
I read the table explaining how SSL/TLS is negociated between the client and the server:
https://docs.python.org/2.7/library/ssl.html#ssl.wrap_socket

I don't understand how I can ask to "use TLS, prefer the most recent version, but don't use SSL"? Should I use TLSv1 which only works with TLS version 1.0? Or TLSv12 and bet that the server implements this newer TLS version?

create_default_context() uses PROTOCOL_SSLv23 with OP_NO_SSLv2 and OP_NO_SSLv3. I don't understand: we ask to use "SSL version 2 or 3" but we disable SSLv2 and SSLv3?

If the client uses PROTOCOL_SSLv23, does it mean that TLS will never be tried?
msg229439 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-10-15 12:08
The naming of SSLv23 is sort of unfortunate, that will negotiate the highest version of SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 that both the client and the server support. You can modify the list of what protocols are supported using the ssl.OP_NO_* flags. By default SSL 2.0 has been disabled in Python 2.7 (in <2.7.9 you can't even turn it back on afaik) and SSL 3.0 is already disabled by create_default_context() (but can be renabled by negating ssl.OP_NO_SSLv3).
msg229440 - (view) Author: Ismail Donmez (donmez) * Date: 2014-10-15 12:25
FWIW OpenSSL patch is now upstream

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=cf6da05304d554aaa885151451aa4ecaa977e601

https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fb0e87fb67a358b40a1d56d2df3a611a09899780
msg229444 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-15 13:33
Le 15/10/2014 14:03, STINNER Victor a écrit :
> 
> create_default_context() uses PROTOCOL_SSLv23 with OP_NO_SSLv2 and
OP_NO_SSLv3. I don't understand: we ask to use "SSL version 2 or 3" but
we disable SSLv2 and SSLv3?

PROTOCOL_SSLv23 is badly named (blame OpenSSL). It really means "any
protocol version, the highest if possible".
msg229445 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-15 13:41
Le 15/10/2014 13:07, Donald Stufft a écrit :
> 
> I really don't think it's unreasonable to say "SSL 3.0 is insecure,
> if you rely on it then you need to pass this flag to use it". Passing a
flag to do something insecure is hardly onerous.

Your position is well-known, Donald, there is no need to rehash it.
msg229586 - (view) Author: Roundup Robot (python-dev) Date: 2014-10-17 17:28
New changeset e971f3c57502 by Antoine Pitrou in branch 'default':
Issue #22638: SSLv3 is now disabled throughout the standard library.
https://hg.python.org/cpython/rev/e971f3c57502
msg229587 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-17 17:33
So, I've disabled SSLv3 in _create_stdlib_context() for the next feature release (3.5). By the time it is released, we can consider SSLv3 will be dead.

Related news:
- Opera doesn't disable SSLv3 yet, but implements custom countermeasures:
http://blogs.opera.com/security/2014/10/security-changes-opera-25-poodle-attacks/
- Mozilla doesn't disable SSLv3 yet (it will be disabled in 3 months):
https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
msg229588 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-17 17:48
As for bugfix releases, I think we should take the time and consider what other software packages will decide.
msg229650 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2014-10-18 18:25
Benjamin, do you have an opinion on backporting this to 2.7?
msg231517 - (view) Author: Federico Ceratto (federico3) Date: 2014-11-22 11:39
FYI Debian dropped ssl.PROTOCOL_SSLv3 from Python 2.7 in the upcoming Jessie release:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611
msg231518 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-22 12:50
> FYI Debian dropped ssl.PROTOCOL_SSLv3 from Python 2.7 in the upcoming 
> Jessie release:

This is not really what the Debian patch does. What it does is allow the ssl module to compile if SSLv3 is disabled in the OpenSSL build.
msg231522 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-22 18:30
Right, they did that because Debian has disabled SSLv3 in OpenSSL in Jessie.
msg231523 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-22 18:47
If that's the case, then I agree we can backport e971f3c57502 to the bugfix branches.
msg231524 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-22 18:50
Yea see: http://sources.debian.net/src/openssl/1.0.2~beta3-1/debian/rules/#L29

The configure options they are running with are: no-idea no-mdc2 no-rc5 no-zlib  enable-tlsext no-ssl2 no-ssl3 no-ssl3-method enable-unit-test
msg231558 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-23 14:46
I was looking into a 2.7 backport but it turns out _create_stdlib_context() isn't used anywhere in 2.7 (yet?), so the backport wouldn't achieve anything. I will backport to 3.4 at least.
msg231559 - (view) Author: Roundup Robot (python-dev) Date: 2014-11-23 14:50
New changeset 653dfb1240d5 by Antoine Pitrou in branch '3.4':
Issue #22638: SSLv3 is now disabled throughout the standard library.
https://hg.python.org/cpython/rev/653dfb1240d5
msg231560 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2014-11-23 14:55
In a post-pep476 world, this method will be used on Python2.7, so it would be good to backport now.
msg231563 - (view) Author: Roundup Robot (python-dev) Date: 2014-11-23 15:26
New changeset f762cbb712de by Antoine Pitrou in branch '2.7':
Backport disabling of SSLv3 in ssl._create_stdlib_context() (issue #22638).
https://hg.python.org/cpython/rev/f762cbb712de
msg231564 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-23 15:26
Ok, this is done. Is there anything left in this issue?
msg231658 - (view) Author: Robert Kuska (rkuska) * Date: 2014-11-25 13:40
FYI fedora (rawhide) has SSLv3 disabled in SSLv23 method of openssl package.
http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=80b5477597e9f0d9fababd854adfb4988b37efd5

This looks like the same approach as in attached issue22638.diff.
msg233538 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2015-01-06 13:06
Can we close this issue?
msg233542 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-01-06 13:38
I think so, thank you.
History
Date User Action Args
2015-01-06 13:38:18pitrousetstatus: open -> closed
resolution: fixed
messages: + msg233542

stage: resolved
2015-01-06 13:06:33hayposetmessages: + msg233538
2014-11-25 13:40:12rkuskasetnosy: + rkuska
messages: + msg231658
2014-11-23 15:26:52pitrousetmessages: + msg231564
versions: + Python 3.5
2014-11-23 15:26:31python-devsetmessages: + msg231563
2014-11-23 14:55:26alexsetmessages: + msg231560
2014-11-23 14:50:41python-devsetmessages: + msg231559
2014-11-23 14:46:45pitrousetmessages: + msg231558
versions: - Python 3.3
2014-11-22 18:50:58dstufftsetmessages: + msg231524
2014-11-22 18:47:10pitrousetmessages: + msg231523
2014-11-22 18:30:53dstufftsetmessages: + msg231522
2014-11-22 12:50:43pitrousetmessages: + msg231518
2014-11-22 11:39:46federico3setnosy: + federico3
messages: + msg231517
2014-10-18 18:25:23alexsetmessages: + msg229650
2014-10-17 17:48:35pitrousetmessages: + msg229588
versions: - Python 3.1, Python 3.2, Python 3.5
2014-10-17 17:33:53pitrousetmessages: + msg229587
2014-10-17 17:28:52python-devsetnosy: + python-dev
messages: + msg229586
2014-10-15 13:41:45pitrousetmessages: + msg229445
2014-10-15 13:33:22pitrousetmessages: + msg229444
2014-10-15 12:25:07donmezsetnosy: + donmez
messages: + msg229440
2014-10-15 12:08:35dstufftsetmessages: + msg229439
2014-10-15 12:03:12hayposetmessages: + msg229437
2014-10-15 11:07:13dstufftsetmessages: + msg229432
2014-10-15 09:37:54christian.heimessetmessages: + msg229423
2014-10-15 08:55:23martiussetnosy: + martius
2014-10-15 08:50:13pitrousetmessages: + msg229417
2014-10-15 08:30:18Lukasasetnosy: + Lukasa
messages: + msg229411
2014-10-15 08:23:59pitrousetmessages: + msg229410
2014-10-15 08:12:13pitrousetmessages: + msg229408
2014-10-15 05:56:23dstufftsetmessages: + msg229403
2014-10-14 23:42:17Arfreversetnosy: + Arfrever
2014-10-14 23:33:05pitrousetmessages: + msg229385
2014-10-14 23:30:21dstufftsetmessages: + msg229383
2014-10-14 23:26:39alexsetmessages: + msg229382
2014-10-14 23:26:33pitrousetmessages: + msg229381
2014-10-14 23:25:20pitrousetmessages: + msg229380
2014-10-14 23:24:55alexsetmessages: + msg229379
2014-10-14 23:23:48dstufftsetmessages: + msg229378
2014-10-14 23:23:16alexsetmessages: + msg229377
2014-10-14 23:22:17pitrousetmessages: + msg229376
2014-10-14 23:21:01dstufftsetmessages: + msg229375
2014-10-14 23:17:46pitrousetmessages: + msg229374
2014-10-14 23:17:05dstufftsetmessages: + msg229373
2014-10-14 23:16:37alexsetmessages: + msg229372
2014-10-14 23:15:00pitrousetmessages: + msg229371
2014-10-14 23:13:54pitrousetmessages: + msg229370
2014-10-14 23:12:34alexsetnosy: + janssen, pitrou, giampaolo.rodola, christian.heimes, dstufft
2014-10-14 23:12:27alexsetfiles: + issue22638.diff

nosy: + alex
messages: + msg229369

keywords: + patch, needs review
2014-10-14 23:11:15haypocreate