-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack) #66828
Comments
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). The new attack essentially allows reading the sensitive data from within a SSL [1] http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html |
This patch disables SSLv3 by default for Python. Uesrs can get it back by specifiying SSL_PROTOCOLv3 explicitly. |
"""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.""" |
IOW, I think it may be ok to disable SSLv3 in create_default_context(), but not necessarily in other contexts. |
create_default_context already disables SSLv3! (Good work everybody :-)) FWIW many vendors are already moving to disable SSLv3, e.g. cloudflare already did. |
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. |
How many times will it have to be repeated that SSL is used for other things than HTTPS-on-the-Web? |
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. |
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. |
CloudFlare published some statistics: https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/ |
There's also https://www.trustworthyinternet.org/ssl-pulse/ |
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 |
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. |
Note the Debian issue is specifically for Apache, not the OpenSSL package. |
It's been implemented in boringssl: https://boringssl.googlesource.com/boringssl/+/2970779684c6f164a0e261e96a3d59f331123320 I don't believe it's in OpenSSL though. |
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. |
The point is, if they start exposing it, we can enable it ourselves.
Well, the ssl module can also be used in server mode. |
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. " |
Matthew Green posted a nice explanation of the attack: 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. |
Hmm... of course, stdlib servers don't use create_stdlib_context() in 2.7. We'll have to do it by hand :) |
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. |
Update on 2.7:
so it's not obvious we should patch something (if people choose to pass PROTOCOL_SSLv3, it's their problem). Update on 3.4:
(3.5 should be similar) |
There is no need for a "_create_stdlib_server_context()" function. _create_stdlib_context() takes a purpose argument, too. |
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. |
I read the table explaining how SSL/TLS is negociated between the client and the server: 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? |
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). |
Le 15/10/2014 14:03, STINNER Victor a écrit :
PROTOCOL_SSLv23 is badly named (blame OpenSSL). It really means "any |
Le 15/10/2014 13:07, Donald Stufft a écrit :
Your position is well-known, Donald, there is no need to rehash it. |
New changeset e971f3c57502 by Antoine Pitrou in branch 'default': |
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:
|
As for bugfix releases, I think we should take the time and consider what other software packages will decide. |
Benjamin, do you have an opinion on backporting this to 2.7? |
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. |
Right, they did that because Debian has disabled SSLv3 in OpenSSL in Jessie. |
If that's the case, then I agree we can backport e971f3c57502 to the bugfix branches. |
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 |
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. |
New changeset 653dfb1240d5 by Antoine Pitrou in branch '3.4': |
In a post-pep476 world, this method will be used on Python2.7, so it would be good to backport now. |
New changeset f762cbb712de by Antoine Pitrou in branch '2.7': |
Ok, this is done. Is there anything left in this issue? |
FYI fedora (rawhide) has SSLv3 disabled in SSLv23 method of openssl package. This looks like the same approach as in attached bpo-22638.diff. |
Can we close this issue? |
I think so, thank you. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: