ssl: Handle ip-address as string correctly

[dgud]

If the host was specified as string ip-address, server_name_indication didn't work.

Convert "ip-address" to tuple form in default hostname and also fallback to check ip if dns_id doesn't work, as was done for upgraded sockets previously.

Also while at it cleanup handling when hostname is undefined.

Fixes #7968

[github-actions]

CT Test Results

    2 files     66 suites   47m 55s ⏱️
  773 tests   740 ✅  33 💤 0 ❌
3 672 runs  2 928 ✅ 744 💤 0 ❌

Results for commit 2da9c1e.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[JeromeDeBretagne]

@dgud @IngelaAndin shouldn't some type specs be updated also to describe this change?

[IngelaAndin]

Hostname already has the type string() which is wide enough to allow also "127.0.0.1" etc, this just a special handling of such strings that mostly was already possible. I guess the question is should we really use inet:hostname() instead of having ssl:hostname() ? This would allow the hostname also to be an atom. @dgud @u3s @RaimoNiskanen @bmk ?

[bmk]

Well:

inet:hostname() :: atom() | string()

ssl:hostname() :: string() | inet:ip_address()

So, not quite identical.

[JeromeDeBretagne]

Hostname already has the type string() which is wide enough to allow also "127.0.0.1" etc, this just a special handling of such strings that mostly was already possible. I guess the question is should we really use inet:hostname() instead of having ssl:hostname() ? This would allow the hostname also to be an atom. @dgud @u3s @RaimoNiskanen @bmk ?

My point was that when looking at the specs currently :

otp/lib/ssl/src/ssl.erl

Lines 163 to 165 in 40607cd

	-type host() :: hostname() | ip_address(). % exported
	-type hostname() :: string().
	-type ip_address() :: inet:ip_address().

it is not obvious (at all) that an IP address can be passed and accepted as a string since 1/ an IP address is not a hostname and 2/ the ip_address() type spec doesn't allow for a string. I got the impression that it was the point of your own comment here too: #7968 (comment)

If not the specs, maybe more a potentail documentation improvement?

[IngelaAndin]

Well, maybe it is a documentation improvement that is needed, even though we ought to use inet:hostname() and behave the same as gen_tcp, it was surprising to me that "127.0.0.1" etc would be parsed and interpreted as an ip-address.

[RaimoNiskanen]

@IngelaAndin wrote:

... it was surprising to me that "127.0.0.1" etc would be parsed and interpreted as an ip-address.

This behaviour is implemented, known and sometimes documented for basic OS resolver API functions such as gethostbyname(3) since the dawn of Unix networking.

[dgud]

Allowed atom() as well, i.e. used inet:hostname() as type.