> From: Chethan Kumar [mailto:Chethan.Kumar@xxxxxxxxxxxxxxxx] > Sent: Wednesday, May 22, 2019 02:41 > > What we are trying to achieve is, if there is failure in connection between > host and destination, then at the host side, log messages saying to which > destination it got failed. So if the connection fails, you want the client program to be able to log some identifier for the server it's trying to connect to. > That's why, need to know the hostname/IP address of the destination. > Since many applications use openssl, we want to log messages from openssl > side. > Is it ok if application set IP/hostname using SSL_set_tlsext_host_name() and > at openssl side, we refer tlsext_hostname to log the message.? Issues with that: - It assumes the client passes the correct hostname[1] to SSL_set_tlsext_host_name(). - It assumes name resolution (usually DNS) is correct and uncompromised. The client may think it's connecting to foo.bar.baz, and call SSL_set_tlsext_host_name("foo.bar.baz"), but actually get the address for some other system from DNS. Then the connection-failure message will report an error connecting to foo.bar.baz when the problem is on some other system. - Following from the previous item, ideally you want the message to report both the desired host and the address you were trying to connect to. - I don't believe there's an accessor function for SSL_set_tlsext_host_name (i.e. SSL_get0_tlsext_host_name or similar), and accessing fields of the OpenSSL structs directly is a Bad Idea. It may cause build-time issues with later OpenSSL releases, and if you load OpenSSL dynamically (i.e. build as a shared object / DLL), you could even break existing applications by dropping in a build of a later OpenSSL release. Accessing struct fields is excessive coupling. The right way to do this is at the application level. The application knows which host it wanted to contact, and what address it found for that host, and precisely what failure it experienced. [1] There are cases where a client would pass an IP address (as a string) to SSL_set_tlsext_host_name(). Specifically, if a user specifies an IP address when telling a client to connect to a server, the client *should not* attempt reverse name resolution on that address; it should use the address literally for SNI and when comparing against SANs in the server entity certificate. (In theory it should look for IP SANs in that case, though I've seen clients that will also accept the string form of the address in a DNS SAN.) This usage is rare. -- Michael Wojcik Distinguished Engineer, Micro Focus
