Issue 22921: SSLContext's check_hostname needlessly intertwined with SNI (original) (raw)

Created on 2014-11-23 05:27 by dstufft, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
check-hostname-no-sni.patch dstufft,2014-11-23 18:55 review
check-hostname-no-sni-with-docs.patch dstufft,2014-11-23 20:46 review
check-hostname-no-sni-with-docs-2.patch dstufft,2014-11-23 21:36 review
check-hostname-no-sni-with-docs-3.patch dstufft,2014-11-23 22:48 review
check-hostname-no-sni-with-docs-py27.patch dstufft,2014-11-24 01:36 review
Messages (11)
msg231544 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-23 05:27
The SSLContext().wrap_socket() method allows you to pass in a server_hostname option which will be used for two purposes, it will be used as the server name for SNI and it will be used to verify the server name of the certificate. However currently if the OpenSSL you're using does not have SNI then sending the server_hostname option to wrap_socket() will raise a ValueError. I think that instead server_hostname should always be accepted by SSLContext().wrap_socket() regardless of if SNI is available or if check_hostname is available. It's just going to be stored and used later so we can conditonally use it for SNI or for checking the hostname depending on if SNI is available or checking if a hostname is available. The way it works right now is that unless you're happy not working when SNI is not available you have to check the hostname yourself. If we can fix this, I think it would be smart to do it ASAP and get it into Python 2.7.9 and backported to the various Python 3.x's so that in the near future it works with all recent versions of the various Pythons (though older micro releases it may not). This shouldn't break any code since it's changing what used to be an error into a saner working case.
msg231557 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-11-23 13:45
This sounds ok to me, but are there still SNI-less OpenSSLs around?
msg231575 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-23 18:55
I tested this patch on Python 3.5 compiled on CentOS 5.11 which does not have SNI enabled. The end result is that you can use server_hostname even when SNI isn't there to enable the SSL certificate checks. Of course the check will fail if the host your connecting to requires SNI to serve the expected certificate, but that's no different than it is today. The docs still need updated, I can do that a little bit later today, but figured I'd let people review this since it's done and working other than the docs. The basic gist of the patch is that we stash the hostname and use it for the validation checks, but we don't send it deeper into the stack if SNI is not available.
msg231576 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2014-11-23 20:02
Thanks a lot, Donald! Back then I didn't pursue the point because I wasn't sure about possible security implications.
msg231578 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-23 20:46
Added docs.
msg231580 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-23 21:36
A new patch that achieves the same thing in a simpler way at benjamin's suggestion.
msg231581 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-23 22:48
Uploaded a third patch, this is the same technique as in the -2 patch, except it fixes a missed spot in Lib/ssl.py where I needed a better error message. Additionally this goes through and unskips all of the tests that were marked as depending on HAS_SNI when what they really depended on was the ability to set SSLContext().check_hostname = True. This also fixes a number of tests that are currently failing whenever HAS_SNI = False that started to fail as fallout of PEP 476.
msg231582 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-11-23 23:06
New changeset f2d4beb90a5b by Benjamin Peterson in branch '3.4': don't require OpenSSL SNI to pass hostname to ssl functions (#22921) https://hg.python.org/cpython/rev/f2d4beb90a5b New changeset 24dfe7310cc1 by Benjamin Peterson in branch 'default': merge 3.4 (#22921) https://hg.python.org/cpython/rev/24dfe7310cc1
msg231585 - (view) Author: Donald Stufft (dstufft) * (Python committer) Date: 2014-11-24 01:36
Added a patch for Python 2.7
msg231586 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-11-24 02:13
New changeset ce4073afd992 by Benjamin Peterson in branch '2.7': allow hostname to be passed to SSLContext even if OpenSSL doesn't support SNI (closes #22921) https://hg.python.org/cpython/rev/ce4073afd992
msg231587 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-11-24 02:17
New changeset 40f9e91f3626 by Benjamin Peterson in branch '2.7': add NEWS note for #22921 https://hg.python.org/cpython/rev/40f9e91f3626 New changeset 060fd5d09063 by Benjamin Peterson in branch '3.4': add NEWS note for #22921 https://hg.python.org/cpython/rev/060fd5d09063
History
Date User Action Args
2022-04-11 14:58:10 admin set github: 67110
2014-11-24 02:17:25 python-dev set messages: +
2014-11-24 02:13:49 python-dev set status: open -> closedresolution: fixedmessages: + stage: needs patch -> resolved
2014-11-24 01:36:43 dstufft set files: + check-hostname-no-sni-with-docs-py27.patchmessages: +
2014-11-23 23:06:56 python-dev set nosy: + python-devmessages: +
2014-11-23 22:48:28 dstufft set files: + check-hostname-no-sni-with-docs-3.patchmessages: +
2014-11-23 21:36:35 dstufft set files: + check-hostname-no-sni-with-docs-2.patchmessages: +
2014-11-23 20:46:24 dstufft set files: + check-hostname-no-sni-with-docs.patchmessages: +
2014-11-23 20:02:52 christian.heimes set messages: +
2014-11-23 18:55:09 dstufft set files: + check-hostname-no-sni.patchkeywords: + patchmessages: +
2014-11-23 13:45:25 pitrou set stage: needs patchtype: enhancement -> behaviorcomponents: + Library (Lib)versions: + Python 2.7, Python 3.4, Python 3.5
2014-11-23 13:45:12 pitrou set nosy: + pitroumessages: +
2014-11-23 05:27:45 dstufft create