The ClientHello TLS handshake contains the port number in the SNI extension:
Code: Select all
extensions" : [
...
,
"server_name (0)": {
type=host_name (0), value=foo.bar.com:12345
},
...
]
This causes multiple issues:
1) SNI fails. Due to the fact that the port number should *not* be part of the handshake, but is, the server won't be able to chose the appropriate virtual host "foo.bar.com" and the server might fail to present the appropriate certificate.
2) A java-based server with the TLS session ticket extension enabled even refuses to accept the connection completely, because the SNI host contains invalid characters:
Code: Select all
java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.base/java.net.IDN.toASCIIInternal(IDN.java:296)
at java.base/java.net.IDN.toASCII(IDN.java:122)
at java.base/javax.net.ssl.SNIHostName.<init>(SNIHostName.java:99)
at java.base/sun.security.ssl.SSLSessionImpl.<init>(SSLSessionImpl.java:417)
...
When using OpenSSL to connect, the ClientHello only contains the correct
Code: Select all
extensions" : [
...
,
"server_name (0)": {
type=host_name (0), value=foo.bar.com
},
...
]
Is this a problem within SChannel?
Or is this something that can be fixed in Total Commander? (By setting the correct SCH_CRED_SNI_CREDENTIAL in InitializeSecurityContext?)
The TC log contains
Code: Select all
Connect to: (03.04.2021 15:34:19)
hostname=foo.bar.com:12345
username=user
startdir=/