If the given ssl context has check_hostname set to False, then the server_hostname shouldn't be required.

Where is it required?

(To clarify: I haven't used the ssl interface enough for it to be obvious to me where the bug is.)

It's not bug, it's a misfeature, IMO.

If you pass an SSL context and either don't pass a hostname or pass an empty string, then server_hostname is required, even if check_hostname is false for the context.

The fix is trivial. I'd be happy to provide a PR.

You still haven't told me what you are passing the context to that objects to not having server_hostname.  I suppose the asyncio experts would know immediately, so I should probably just leave it to them...or wait for your PR.

I'm not sure I understand your question.

The documentation for create_connection, https://docs.python.org/3/library/asyncio-eventloop.html#creating-connections states that server_hostname is required if the host is empty. (I'm generalizing "empty" to include None.)

SSL contexts, https://docs.python.org/3/library/ssl.html#ssl-contexts,
have an attribute, check_hostname, which controls whether hostname checking is required. If set to false in a context passed to create_connection, then it makes no sense to require server_hostname under any circumstances.

Note that this is easy to work around by passing an empty string, it just seems pointless to make people do that if you're already controlling this via the SSL context.

Consider this a suggestion. Do with it what you will. I'm closing this as I don't want to spend more time on it other than creating a PR if requested.

Sorry, I've been having trouble communicating on this ticket.  I thought I'd posetd an apology but I don't see it...I wonder where I did post it?  Bad morning :(.

Anyway, create_connection was what I was asking for.

Reading the docs, I, at least, agree with you, and if it weren't for backward compatibility I'd suggest making the only way to disable host checking be by passing a context with it disabled.  But failing that I don't see any reason to force you to specify a hostname if you've already said you don't want to check hostnames.

> SSL contexts, https://docs.python.org/3/library/ssl.html#ssl-contexts,
have an attribute, check_hostname, which controls whether hostname checking is required. If set to false in a context passed to create_connection, then it makes no sense to require server_hostname under any circumstances.

This makes sense.  I'm reopening this issue.  Jim, would you be able to submit a PR to github/python/asyncio?

No need to apologize!  My capitulation was just due to the fact that this isn't a big deal. (My tone probably came across as cranky; sorry)

WRT backward compatibility, I suspect that there's a bit of wiggle here between loop implementations and I doubt this would be noticed. For example, uvloop errors if you pass None for both server_hostname and ssl. <shug>

OK, sure, I'll make a PR.

server_hostname is also required for SNI (server name indicator). Virtual hosting depends on the feature. Without SNI TLS extension you'll end up on the wrong vhost or the web server sends you the wrong certificate.

The feature is pretty much required these days.

> The feature is pretty much required these days.

We have the feature. What Jim was asking is to make server_hostname argument optional when check_hostname is False in the ssl context

It's a bad idea. An increasing amount of web servers require a TLS SNI extension. I'd rather make server_hostname a required argument for all client-side SSL sockets -- no matter how check_hostname is configured.

> It's a bad idea.

I thought so too :)  I was actually going to ask you to review this request.  In any case, feel free to close this issue.

SSL is used for more than just HTTP.  The are applications in which clients have server public keys that they use to authenticate servers rather than using certificate authorities.  For these applications, server host names are irrelevant.  This is why it makes sense to have an option on the SSL context to disable host name checking.  Removing this ability would break some applications.

If the option to check host names is provided as false on the SSL context, it makes no sense to check whether the host name, which isn't going to be used, is not None.  It's just silly, but not a huge deal one way or the other, because there are actually *two* ways to disable host name checking; you can also pass '' as the hostname, which is why this isn't a big deal and why I haven't gotten around to making a PR yet.

You are still ignoring my remarks about TLS SNI. :)

Python uses server_hostname for two different but related parts of the TLS/SSL.

1) When server_hostname is set, the client sends the hostname to the server during the TLS handshake in the ClientHello message. [1] Without a TLS SNI extension your client may talk to the wrong service. TLS SNI not limited to HTTPS, although HTTPS virtual hosting is the biggest user of SNI. You should only omit the argument if you directly connect to an IP address.

2) Python uses server_hostname to verify that the certificate matches the hostname. Hostname matching can be disabled with a custom SSLContext that has check hostname disabled.
[1] https://en.wikipedia.org/wiki/Server_Name_Indication

server_hostname='' should not bypass hostname verification. That's a bug.

I'm not ignoring anything AFAICT.

There are applications where server hostname isn't useful (no virtual hosts, client has server's public key).

I'm not positive we're disagreeing, so let me put this another way.

1. If the given SSL context has check_hostname set to False,
   then ``create_connection`` should not not require a value for
   ``server_hostname``, regardless of the value of ``host``.

   Do you agree?

2. If the given SSL context has check_hostname set to True,
   then ``create_connection`` should not accept an empty string
   to disable hostname checks.

   Do you agree? I'm wondering is this is what you're referring to
   as a bug.

   Personally, this only bothers me from a TOOWTDI perspective.
   I can imagine (always a dangerous word :)) people wanting to 
   reuse an SSL context but disable host name checking. In any case,
   "fixing" this would likely be a breaking change.

Jim, yes I agree. In a matter of fact, the ssl module also agrees with you and behaves like that for a while. I cannot reproduce the problem with either 2.7, 3.5, or 3.6. I have attached an demo script.


check_hostname = True
* server_hostname='www.python.org' OK
* server_hostname='': Exception: check_hostname requires server_hostname
* no server_hostname: Exception: check_hostname requires server_hostname

check_hostname = False
* server_hostname='www.python.org' OK
* server_hostname='' OK
* no server_hostname OK

The case appears in asyncio's create_connection. Actually it's known thing https://github.com/python/cpython/blob/3.6/Lib/asyncio/base_events.py#L699, a workaround mentioned (same as Jim has pointed) is used widely. It seems reasonably at first sight to "fix it", but I consider this requirement (pass '') as a safety check.

So it's not a problem with the SSL module but rather in asyncio. From the initial report it was not clear to me that it only affects asyncio.

I'm not sure this issue should be fixed at all. As I explained earlier, a hostname is required for both hostname verification and SNI TLS extension. We may allow to omit the parameter with verify_mode=CERT_NONE and check_hostname=False only. In all other cases the server may return a wrong cert or refuse to establish a connection.

OMG, >1year. :)

This was always a minor issue.  I still think the current asyncio behavior is dumb, but whatever.

FWIW, I tripped on this when adding SSL support to ZEO, which is a client-server *database* protocol used by ZODB, having nothing to do with the Web. In this context, the client and server are well known to each other and share certs.