Issue 22638: ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack) (original) (raw)
Created on 2014-10-14 23:11 by vstinner, last changed 2022-04-11 14:58 by admin. This issue is now closed.
Messages (46)
Author: STINNER Victor (vstinner) * 
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
Author: Alex Gaynor (alex) *
Date: 2014-10-14 23:12
This patch disables SSLv3 by default for Python. Uesrs can get it back by specifiying SSL_PROTOCOLv3 explicitly.
Author: Antoine Pitrou (pitrou) *
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."""
Author: Antoine Pitrou (pitrou) *
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.
Author: Alex Gaynor (alex) *
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.
Author: Donald Stufft (dstufft) *
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.
Author: Antoine Pitrou (pitrou) *
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?
Author: Donald Stufft (dstufft) *
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.
Author: Antoine Pitrou (pitrou) *
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.
Author: Alex Gaynor (alex) *
Date: 2014-10-14 23:23
CloudFlare published some statistics: https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
Author: Donald Stufft (dstufft) *
Date: 2014-10-14 23:23
There's also https://www.trustworthyinternet.org/ssl-pulse/
Author: Alex Gaynor (alex) *
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
Author: Antoine Pitrou (pitrou) *
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.
Author: Antoine Pitrou (pitrou) *
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 :-)
Author: Alex Gaynor (alex) *
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.
Author: Donald Stufft (dstufft) *
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.
Author: Antoine Pitrou (pitrou) *
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.
Author: Donald Stufft (dstufft) *
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. "
Author: Antoine Pitrou (pitrou) *
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.
Author: Antoine Pitrou (pitrou) *
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 :)
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.
Author: Antoine Pitrou (pitrou) *
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)
Author: Christian Heimes (christian.heimes) *
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.
Author: Donald Stufft (dstufft) *
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.
Author: STINNER Victor (vstinner) *
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?
Author: Donald Stufft (dstufft) *
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).
Author: Ismail Donmez (donmez) *
Date: 2014-10-15 12:25
FWIW OpenSSL patch is now upstream
Author: Antoine Pitrou (pitrou) *
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".
Author: Antoine Pitrou (pitrou) *
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.
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
Author: Antoine Pitrou (pitrou) *
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/
Author: Antoine Pitrou (pitrou) *
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.
Author: Alex Gaynor (alex) *
Date: 2014-10-18 18:25
Benjamin, do you have an opinion on backporting this to 2.7?
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
Author: Antoine Pitrou (pitrou) *
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.
Author: Donald Stufft (dstufft) *
Date: 2014-11-22 18:30
Right, they did that because Debian has disabled SSLv3 in OpenSSL in Jessie.
Author: Antoine Pitrou (pitrou) *
Date: 2014-11-22 18:47
If that's the case, then I agree we can backport e971f3c57502 to the bugfix branches.
Author: Donald Stufft (dstufft) *
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
Author: Antoine Pitrou (pitrou) *
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.
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
Author: Alex Gaynor (alex) *
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.
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
Author: Antoine Pitrou (pitrou) *
Date: 2014-11-23 15:26
Ok, this is done. Is there anything left in this issue?
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 .diff.
Author: STINNER Victor (vstinner) *
Date: 2015-01-06 13:06
Can we close this issue?
Author: Antoine Pitrou (pitrou) *
Date: 2015-01-06 13:38
I think so, thank you.
History
Date
User
Action
Args
2022-04-11 14:58:09
admin
set
github: 66828
2015-01-06 13:38:18
pitrou
set
status: open -> closed
resolution: fixed
messages: +
stage: resolved
2015-01-06 13:06:33
vstinner
set
messages: +
2014-11-25 13:40:12
rkuska
set
nosy: + rkuska
messages: +
2014-11-23 15:26:52
pitrou
set
messages: +
versions: + Python 3.5
2014-11-23 15:26:31
python-dev
set
messages: +
2014-11-23 14:55:26
alex
set
messages: +
2014-11-23 14:50:41
python-dev
set
messages: +
2014-11-23 14:46:45
pitrou
set
messages: +
versions: - Python 3.3
2014-11-22 18:50:58
dstufft
set
messages: +
2014-11-22 18:47:10
pitrou
set
messages: +
2014-11-22 18:30:53
dstufft
set
messages: +
2014-11-22 12:50:43
pitrou
set
messages: +
2014-11-22 11:39:46
federico3
set
nosy: + federico3
messages: +
2014-10-18 18:25:23
alex
set
messages: +
2014-10-17 17:48:35
pitrou
set
messages: +
versions: - Python 3.1, Python 3.2, Python 3.5
2014-10-17 17:33:53
pitrou
set
messages: +
2014-10-17 17:28:52
python-dev
set
nosy: + python-dev
messages: +
2014-10-15 13:41:45
pitrou
set
messages: +
2014-10-15 13:33:22
pitrou
set
messages: +
2014-10-15 12:25:07
donmez
set
nosy: + donmez
messages: +
2014-10-15 12:08:35
dstufft
set
messages: +
2014-10-15 12:03:12
vstinner
set
messages: +
2014-10-15 11:07:13
dstufft
set
messages: +
2014-10-15 09:37:54
christian.heimes
set
messages: +
2014-10-15 08:55:23
martius
set
nosy: + martius
2014-10-15 08:50:13
pitrou
set
messages: +
2014-10-15 08:30:18
Lukasa
set
nosy: + Lukasa
messages: +
2014-10-15 08:23:59
pitrou
set
messages: +
2014-10-15 08:12:13
pitrou
set
messages: +
2014-10-15 05:56:23
dstufft
set
messages: +
2014-10-14 23:42:17
Arfrever
set
nosy: + Arfrever
2014-10-14 23:33:05
pitrou
set
messages: +
2014-10-14 23:30:21
dstufft
set
messages: +
2014-10-14 23:26:39
alex
set
messages: +
2014-10-14 23:26:33
pitrou
set
messages: +
2014-10-14 23:25:20
pitrou
set
messages: +
2014-10-14 23:24:55
alex
set
messages: +
2014-10-14 23:23:48
dstufft
set
messages: +
2014-10-14 23:23:16
alex
set
messages: +
2014-10-14 23:22:17
pitrou
set
messages: +
2014-10-14 23:21:01
dstufft
set
messages: +
2014-10-14 23:17:46
pitrou
set
messages: +
2014-10-14 23:17:05
dstufft
set
messages: +
2014-10-14 23:16:37
alex
set
messages: +
2014-10-14 23:15:00
pitrou
set
messages: +
2014-10-14 23:13:54
pitrou
set
messages: +
2014-10-14 23:12:34
alex
set
nosy: + janssen, pitrou, giampaolo.rodola, christian.heimes, dstufft
2014-10-14 23:12:27
alex
set
files: + issue22638.diff
nosy: + alex
messages: +
keywords: + patch, needs review
2014-10-14 23:11:15
vstinner
create