[AndroidCrypto] Any TargetHost input is set as SNI hostname

[simonrozsival]

On Android, we put any TargetHost passed to a client SslStream into the SNI hostname:

• SafeDeleteSslContext:252
• pal_sslstream.c:500-540

This is a problem when the hostname doesn't conform to the STD 3 ASCII rules (see SNIHostName docs). In this case, the code throws an exception and we can't establish communication with the server.

One particular case, that also shows in our functional tests, are IPv6 addresses. The colon symbol is not allowed and an exception is thrown. The Android crypto PAL tracking issue (#45741) also mentions underscores in hostnames.

The RFC 6066 that defines SNI states:

Literal IPv4 and IPv6 addresses are not permitted in "HostName".

I think that our Android PAL shouldn't throw exceptions when SNIHostName rejects an IPv6 address and it should proceed with the handshake.

/cc @wfurt
Ref #77386 (comment)

[ghost]

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

On Android, we put any TargetHost passed to a client SslStream into the SNI hostname:

• SafeDeleteSslContext:252
• pal_sslstream.c:500-540

This is a problem when the hostname doesn't conform to the STD 3 ASCII rules (see SNIHostName docs). In this case, the code throws an exception and we can't establish communication with the server.

One particular case, that also shows in our functional tests, are IPv6 addresses. The colon symbol is not allowed and an exception is thrown. The Android crypto PAL tracking issue (#45741) also mentions underscores in hostnames.

The RFC 6066 that defines SNI states:

Literal IPv4 and IPv6 addresses are not permitted in "HostName".

I think that our Android PAL shouldn't throw exceptions when SNIHostName rejects an IPv6 address and it should proceed with the handshake.

/cc @wfurt
Ref #77386 (comment)

Author:	simonrozsival
Assignees:	-
Labels:	area-System.Net.Security, os-android
Milestone:	-

[wfurt]

The IPv6 LLA should be fixed by #81631. It seems like the RFC forbids us to pass in IP literals.
For weird names, it may perhaps be acceptable to either swallow the error and don't set the SNI or throw PNSE.

Now there has been some chatter about allowing SslStream to connect to sites that do not conform to the spec.
www-.volal.cz is one the examples where .NET fails but some other tools are able to connect.

[steveisok]

@simonrozsival @wfurt is this still an issue?

[simonrozsival]

@steveisok I think the issue has been sufficiently resolved with #81631. There are still three tests that we currently skip and need re-enabling. I opened #89232 to re-enable those tests and I think we can close this issue once that PR is merged.