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

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.
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 :-)

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.

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.

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:
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.

Hmm... of course, stdlib servers don't use create_stdlib_context() in 2.7. We'll have to do it by hand :)

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.

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)

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:
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?

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).

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

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".

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.

New changeset e971f3c57502 by Antoine Pitrou in branch 'default':
Issue bpo-22638: SSLv3 is now disabled throughout the standard library.
https://hg.python.org/cpython/rev/e971f3c57502

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/

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:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768611

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':
Issue bpo-22638: SSLv3 is now disabled throughout the standard library.
https://hg.python.org/cpython/rev/653dfb1240d5

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':
Backport disabling of SSLv3 in ssl._create_stdlib_context() (issue bpo-22638).
https://hg.python.org/cpython/rev/f762cbb712de

Ok, this is done. Is there anything left in this issue?

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 bpo-22638.diff.

Can we close this issue?

I think so, thank you.