KNOWN_BUGS: Secure Transport disabling hostname validation also disables SNI

That behavior is a limitation of Apple's Secure Transport.

Reported-by: Cory Benfield
Reported-by: Ian Spence
Confirmed-by: Nick Zitzmann

Ref: https://github.com/curl/curl/issues/998

Closes https://github.com/curl/curl/issues/6347
Closes https://github.com/curl/curl/pull/6348
This commit is contained in:
Jay Satiro 2020-12-19 17:40:03 -05:00
parent ccbdbe13c4
commit 4cc115a85b
1 changed files with 15 additions and 0 deletions

View File

@ -36,6 +36,7 @@ problems may have been fixed or changed somewhat since this was written!
2.11 Schannel TLS 1.2 handshake bug in old Windows versions
2.12 FTPS with Schannel times out file list operation
2.13 curl with wolfSSL lacks support for renegotiation
2.14 Secure Transport disabling hostname validation also disables SNI
3. Email protocols
3.1 IMAP SEARCH ALL truncated response
@ -322,6 +323,20 @@ problems may have been fixed or changed somewhat since this was written!
See https://github.com/curl/curl/issues/5839
2.14 Secure Transport disabling hostname validation also disables SNI
SNI is the hostname that is sent by the TLS library to the server as part of
the TLS handshake. Secure Transport does not send SNI when hostname validation
is disabled. Servers that host multiple websites may not know which
certificate to serve without SNI or which backend server to connect to. The
server may serve the certificate of a default server or abort.
If a server aborts a handshake then curl shows error "SSL peer handshake
failed, the server most likely requires a client certificate to connect".
In this case the error may also have been caused by lack of SNI.
https://github.com/curl/curl/issues/6347
3. Email protocols
3.1 IMAP SEARCH ALL truncated response