Problem with SNI support

[ppatierno]

I'm trying to use the SSLContext support from the "develop" branch for SNI support.

What I see is that the "host" specified in the connect() method is also used as server_hostname during socket wrapping :

self._ssl_context.wrap_socket(sock, server_hostname=self._host)

it means that it's impossible with this implementation opening a socket versus an hostname (i.e. "localhost") but providing a different SNI (i.e. "myservice") during TLS handshake.

[PierreF]

Hi,

I fear that adding another "host" argument to connection and/or TLS setup might confuse user.
I've quickly looked to some API (Python urllib, Python requests, paho.c and paho-java) and none seem to provide a way to specify the "SNI hostname".

Before supporting this feature, is it really needed to be supported by the paho library ? In your example why don't you connect to "myservice", probably adding "myservice" to your /etc/hosts ?

[ppatierno]

Hi,
some other implementations related to a different protocol (see Qpid Proton for AMQP) provide the virtual_host parameter.
The current Paho implementation is useless because the SNI has exactly the objective to connect a server who can provide different certificates. It means that client connect to server_host_name via TCP but then specify the "virtual" host via SNI so that the TLS handshake can go forward using the specific certificate for that "virtual" host.
It's exactly what happens with HTTPS virtual hosting.

[PierreF]

I don't see where in production it could be useful, since in production you should have a DNS name matching your certificate name. It seems to be useful only during development if your don't have a correct DNS name.

Having different handling during development and production should be avoided, and this one could be avoided by added the DNS name in your /etc/hosts.

Why can't you update your /etc/hosts in your case ?

[ppatierno]

@PierreF you are absolutely right ... it's only a problem on developing side ;)

[PierreF]

I believe this issue is fixed. Feel free to reopen if the issue persist.