[issue5639] Support TLS SNI extension in ssl module
report at bugs.python.org
Tue Sep 1 04:59:45 CEST 2009
Phil Pennock <python-dev at spodhuis.org> added the comment:
(Sorry for dropping this, lost available time)
I see your point. OTOH, use of SNI needs to be something that can be
disabled and people need to be able to connect to host A while supplying
host B, not necessarily using IP addresses for the specificity. Use-
case example: someone has a service "www" hosted on ["www-1", "www-2",
"www-3"]. They have an SSL certificate for "www" and they want to have
a health-checker which probes for "working service, all certs valid and
not about to expire".
Unless s.connect() gains a keep_original_hostname=False option (?), this
is hard to do.
Then there's the principle of least surprise -- while it would be nice
to get SNI working automatically for everyone, it's still plausible that
amongst the various TLS servers out there are some which break horribly
for SNI and upgrading Python shouldn't break the tools in use.
So I tend towards favouring "make use of the newer, less well tested,
protocol feature something that has to be explicitly enabled", even if
it adds a line to boilerplate -- if SNI ever takes over the world (as
Host: headers in HTTP have) then it can be defaulted on in future
In which case, if the default is to change, the API should be sorted
now, so perhaps connect() should take an override_server_hostname=False
flag, which will make it pass the connect() hostname parameter instead
of self.server_hostname in the call to _ssl.sslwrap()? With checking
for an IP address?
Python tracker <report at bugs.python.org>
More information about the Python-bugs-list