[Python-Dev] Enable Hostname and Certificate Chain Validation (original) (raw)

Wes Turner wes.turner at gmail.com
Wed Jan 22 19:53:37 CET 2014

If I could summarize this discussion (please correct me if I am wrong):

  1. Status Quo

    All existing versions of Python are unsecure by default because by not doing SSL hostname verification, libraries which wrap sockets with SSLContext allow SSL MITM (man-in-the-middle) with no warning.

    Christian Heimes has introduced ss.create_default_context for 3.4

    Donald Stuft is proposing that hostname verification should be the default behavior in future versions of Python; such as Python 3.4, ideally as soon as possible.

    python-dev has been resistant to preventing SSL MITM by default because humans, pypi:keyring, and pypi:certifi

  2. Generalizations about end-users:

    • corporate users aren't susceptible to MITM because perimeter

      • fallacious on all accounts
      • mismatched metaphors abound

    • nobody knows how to add self-signed CA certs to their chains

      • Agreed.

    • most people haven't / aren't going to read the docs: http://docs.python.org/3/library/ssl.html#verifying-certificates

      A warning:: would probably be appropriate

      (and a big red warning box has been added to the 3.3 docs)

      It could also say "PYTHON DOES NOT VALIDATE SSL CERTIFICATES BY

DEFAULT"

  1. Compatibility

    There could be a PYTHONSSLNOVALIDATE environment variable:

    • +1 : This would allow workarounds for applications which cannot be updated
    • -1 : This is not preferable because PYTHONHASHSEED

  2. Chain management

    • It should be possible to update the cert chain
    • It could be easier to specify a different cert chain (?)
    • Python 3.4 now supports using the Windows cert chain
    • Pip does not yet support using the Windows cert chain
    • pypi:certifi adds the Mozilla Firefox keychain for Python 2 and 3 (like requests and pip)

  3. Deprecation

    • Should deprecate slowly (2017) because people would complain about having been secured against MITM (in their upgrade to Python 3.4)
    • Should not deprecate slowly because the status quo (insecure by default) is risky
    • Should add pending deprecation now (see CERT_NOVALIDATE NOP below)

  4. Testing Responses

    • It's probably good to start testing downstream patches to Python 3.4 packages
    • The error message may be primed

My two cents:

Please feel free to add any, all, or none of this to the forthcoming PEP.

Thank you for addressing this issue.

(This is buried here because the mailman archive gzip hasn't yet updated with the latest Message-Id to specify for In-Reply-To)

-- Wes Turner

On Wed, Jan 22, 2014 at 12:46 PM, Brian Curtin <brian at python.org> wrote:

On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong <gokoproject at gmail.com> wrote: > On 1/22/14 8:16 AM, Nick Coghlan wrote: >> >> Which is exactly the way most non-web-specialists working inside the >> comfort of corporate and academic firewalls will react to a change that >> breaks their access to internal applications, where self-signed certs and >> improperly configured internal CAs are endemic (of course, that's assuming >> they're using HTTPS at all, which I admit is an optimistic assumption). > > The number of people who are using 3.4+ in these environments is probably > very very low to be honest. I don't have a number to prove, but in that > environment people are more likely to still be using 2.6+. I think a > deprecation in 2.7+ would be nice, but forward we should just enable it by > default. > > When requests changed property calls (e.g. requests.json) to callable > instead of an attribute(from requests.json to requests.json()), I was > shocked. I had to figure out by Googling it. I found out from github > issue.... > > I think a hard fail is somehow necessary. > > Also, a lot of people overlook at deprecation warnings. They either don't > care or don't see it. I see a lot of deprecation warnings in the older > applications I write, but I can careless until it breaks. So as we moving > forward, we can break it. For those stuck behind, deprecation is the right > approach.

They're disabled by default, so a lot of people simply don't know they exist because they also don't read the documentation.

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140122/96d47036/attachment-0001.html>

More information about the Python-Dev mailing list