[erlang-patches] SSL Server Name Indication (SNI) client support

[Julien Barbot]

Hi,

I added a new client-side option 'server_name_indication', this option
can be set to:
- a hostname, when upgrading a TCP socket to TLS,
- disable, to explicitly disable sni extension.

If nothing is specified, SNI hello extension is used.

Same branch.

Regards,

-- 
Julien Barbot

2013/11/1 Ingela Anderton Andin <ingela.anderton.andin@REDACTED>:
> On 10/31/2013 03:00 PM, Julien Barbot wrote:
>> Here is a new attempt to implement SNI (RFC 6066, section 3). This is
>> *only* the client side implementation.

>> git fetch git://github.com/klyr/otp.git r17_ssl_sni_client
>>
>> https://github.com/klyr/otp/compare/master...r17_ssl_sni_client
>> https://github.com/klyr/otp/compare/master...r17_ssl_sni_client.patch
>>
>> Pending questions are:
>> - how to do an ssl upgrade with sni ?
>> - is an aditional option to ssl:connect needed to explicitly choose an
>> ssl virtual host (like {virtual_host, string()}) ?
>
> I think that client  should not be concerned with the notion of virtual
> hosts, from
> its point of view there should not be a difference between real hosts and
> virtual ones.
> Virtual host is however a good option name on the server side when
> specifying a
> use of the server name indication extension.
> However  when  upgrading a tcp connection to TLS you can not  hide
> everything that
> you can doing the connection from scratch. So I think that when upgrading a
> tcp_socket
> there should be an sni-option available to specify the hostname and if it is
> not set
> the sni-extension should not be sent. The RFC says:
>
> "If an application negotiates a server name using an application
>    protocol and then upgrades to TLS, and if a server_name extension is
>    sent, then the extension SHOULD contain the same name that was
>    negotiated in the application protocol."

>> - is an aditional option to ssl:connect needed to explicitly disable sni ?
>
> Well in the ideal world I would say no, but it could be nice if other
> implementations off SSL/TLS don't handle
> extensions correctly.  I am thinking maybe there should be a general
> ssl:connection option like
> {server_name_indication,  Hostname} that defaults to the first argument of
> connect unless it is
> an upgrade when it defaults to undefined.  In this way you will get the
> server name indication by
> default without changing anything (unless it is an upgrade), but if it
> causes a problem you can work around it.