Skip to content
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

Closed
vstinner opened this issue Oct 14, 2014 · 46 comments
Closed

ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack) #66828

vstinner opened this issue Oct 14, 2014 · 46 comments
Labels
type-security A security issue

Comments

@vstinner
Copy link
Member

vstinner commented Oct 14, 2014

BPO 22638
Nosy @pitrou, @vstinner, @giampaolo, @tiran, @alex, @dstufft, @Lukasa, @rkuska, @Martiusweb
Files
  • issue22638.diff
  • 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:

    assignee = None
    closed_at = <Date 2015-01-06.13:38:18.903>
    created_at = <Date 2014-10-14.23:11:15.855>
    labels = ['type-security']
    title = 'ssl module: the SSLv3 protocol is vulnerable ("POODLE" attack)'
    updated_at = <Date 2015-01-06.13:38:18.902>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2015-01-06.13:38:18.902>
    actor = 'pitrou'
    assignee = 'none'
    closed = True
    closed_date = <Date 2015-01-06.13:38:18.903>
    closer = 'pitrou'
    components = []
    creation = <Date 2014-10-14.23:11:15.855>
    creator = 'vstinner'
    dependencies = []
    files = ['36926']
    hgrepos = []
    issue_num = 22638
    keywords = ['patch', 'needs review']
    message_count = 46.0
    messages = ['229368', '229369', '229370', '229371', '229372', '229373', '229374', '229375', '229376', '229377', '229378', '229379', '229380', '229381', '229382', '229383', '229385', '229403', '229408', '229410', '229411', '229417', '229423', '229432', '229437', '229439', '229440', '229444', '229445', '229586', '229587', '229588', '229650', '231517', '231518', '231522', '231523', '231524', '231558', '231559', '231560', '231563', '231564', '231658', '233538', '233542']
    nosy_count = 14.0
    nosy_names = ['janssen', 'pitrou', 'vstinner', 'giampaolo.rodola', 'christian.heimes', 'donmez', 'Arfrever', 'alex', 'python-dev', 'dstufft', 'Lukasa', 'rkuska', 'martius', 'federico3']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'security'
    url = 'https://bugs.python.org/issue22638'
    versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

    @vstinner
    Copy link
    Member Author

    vstinner commented Oct 14, 2014

    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

    @vstinner vstinner added the type-security A security issue label Oct 14, 2014
    @alex
    Copy link
    Member

    alex commented Oct 14, 2014

    This patch disables SSLv3 by default for Python. Uesrs can get it back by specifiying SSL_PROTOCOLv3 explicitly.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 14, 2014

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

    @pitrou
    Copy link
    Member

    pitrou commented Oct 14, 2014

    IOW, I think it may be ok to disable SSLv3 in create_default_context(), but not necessarily in other contexts.

    @alex
    Copy link
    Member

    alex commented Oct 14, 2014

    create_default_context already disables SSLv3! (Good work everybody :-))

    FWIW many vendors are already moving to disable SSLv3, e.g. cloudflare already did.

    @dstufft
    Copy link
    Member

    dstufft commented Oct 14, 2014

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 14, 2014

    How many times will it have to be repeated that SSL is used for other things than HTTPS-on-the-Web?

    @dstufft
    Copy link
    Member

    dstufft commented Oct 14, 2014

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 14, 2014

    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.

    @alex
    Copy link
    Member

    alex commented Oct 14, 2014

    @dstufft
    Copy link
    Member

    dstufft commented Oct 14, 2014

    @alex
    Copy link
    Member

    alex commented Oct 14, 2014

    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

    @pitrou
    Copy link
    Member

    pitrou commented Oct 14, 2014

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 14, 2014

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

    @alex
    Copy link
    Member

    alex commented Oct 14, 2014

    It's been implemented in boringssl: https://boringssl.googlesource.com/boringssl/+/2970779684c6f164a0e261e96a3d59f331123320

    I don't believe it's in OpenSSL though.

    @dstufft
    Copy link
    Member

    dstufft commented Oct 14, 2014

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 14, 2014

    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.

    @dstufft
    Copy link
    Member

    dstufft commented Oct 15, 2014

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

    @pitrou
    Copy link
    Member

    pitrou commented Oct 15, 2014

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 15, 2014

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

    @Lukasa
    Copy link
    Mannequin

    Lukasa mannequin commented Oct 15, 2014

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Oct 15, 2014

    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)

    @tiran
    Copy link
    Member

    tiran commented Oct 15, 2014

    There is no need for a "_create_stdlib_server_context()" function. _create_stdlib_context() takes a purpose argument, too.

    @dstufft
    Copy link
    Member

    dstufft commented Oct 15, 2014

    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.

    @vstinner
    Copy link
    Member Author

    vstinner commented Oct 15, 2014

    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?

    @dstufft
    Copy link
    Member

    dstufft commented Oct 15, 2014

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

    @pitrou
    Copy link
    Member

    pitrou commented Oct 15, 2014

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

    @pitrou
    Copy link
    Member

    pitrou commented Oct 15, 2014

    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.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Oct 17, 2014

    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

    @pitrou
    Copy link
    Member

    pitrou commented Oct 17, 2014

    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:

    @pitrou
    Copy link
    Member

    pitrou commented Oct 17, 2014

    As for bugfix releases, I think we should take the time and consider what other software packages will decide.

    @alex
    Copy link
    Member

    alex commented Oct 18, 2014

    Benjamin, do you have an opinion on backporting this to 2.7?

    @federico3
    Copy link
    Mannequin

    federico3 mannequin commented Nov 22, 2014

    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

    @pitrou
    Copy link
    Member

    pitrou commented Nov 22, 2014

    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.

    @dstufft
    Copy link
    Member

    dstufft commented Nov 22, 2014

    Right, they did that because Debian has disabled SSLv3 in OpenSSL in Jessie.

    @pitrou
    Copy link
    Member

    pitrou commented Nov 22, 2014

    If that's the case, then I agree we can backport e971f3c57502 to the bugfix branches.

    @dstufft
    Copy link
    Member

    dstufft commented Nov 22, 2014

    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

    @pitrou
    Copy link
    Member

    pitrou commented Nov 23, 2014

    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.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Nov 23, 2014

    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

    @alex
    Copy link
    Member

    alex commented Nov 23, 2014

    In a post-pep476 world, this method will be used on Python2.7, so it would be good to backport now.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Nov 23, 2014

    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

    @pitrou
    Copy link
    Member

    pitrou commented Nov 23, 2014

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

    @rkuska
    Copy link
    Mannequin

    rkuska mannequin commented Nov 25, 2014

    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.

    @vstinner
    Copy link
    Member Author

    vstinner commented Jan 6, 2015

    Can we close this issue?

    @pitrou
    Copy link
    Member

    pitrou commented Jan 6, 2015

    I think so, thank you.

    @pitrou pitrou closed this as completed Jan 6, 2015
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    type-security A security issue
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants