On Tue, Jun 17, 2014 at 7:10 PM, Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: > ... > >> Worse, this does NOT conform to RFC 6066: >> >> >> The ServerNameList MUST NOT contain more than one name of the same >> name_type. If the server understood the ClientHello extension but >> does not recognize the server name, the server SHOULD take one of two >> actions: either abort the handshake by sending a fatal-level >> unrecognized_name(112) alert or continue the handshake. It is NOT >> RECOMMENDED to send a warning-level unrecognized_name(112) alert, >> because the client's behavior in response to warning-level alerts is >> unpredictable. If there is a mismatch between the server name used >> by the client application and the server name of the credential >> chosen by the server, this mismatch will become apparent when the >> client application performs the server endpoint identification, at >> which point the client application will have to decide whether to >> proceed with the communication. TLS implementations are encouraged >> to make information available to application callers about warning- >> level alerts that were received or sent during a TLS handshake. Such >> information can be useful for diagnostic purposes. > > Apache should not be requesting the alert, and should return > SSL_TLSEXT_ERR_NOACK. > Well, in fairness to the Apache folks.... It appears the return values from the callback function are pretty much undocumented. Questions to the list about appropriate return codes went unanswered too. See "Meanings of servername_cb (SNI callback) return codes?", http://openssl.6102.n7.nabble.com/Meanings-of-servername-cb-SNI-callback-return-codes-td48418.html
Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
