> From: Chethan Kumar [mailto:[email protected]]
> 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
