To get end point's IP address

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

To get end point's IP address

Chethan Kumar

Dear all,

 

I wanted to log end point’s IP address during some errors in communication using openssl.

What is the best way to know end point’s IP address in openssl as many applications use openssl and its not feasible to change in all of them.

Initially when I tried getpeername() on SSL context, its giving proxy server’s IP and not destination IP.

Let me know how can achieve the same.

 

Thanks in advance,

Chethan Kumar

 

The information contained in this e-mail message and in any attachments/annexure/appendices is confidential to the
recipient and may contain privileged information. If you are not the intended recipient, please notify the
sender and delete the message along with any attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.
Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by Toshiba Software India Pvt. Ltd, for any loss or damage arising in any way from its use.

Reply | Threaded
Open this post in threaded view
|

RE: To get end point's IP address

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Chethan Kumar
> Sent: Monday, May 20, 2019 04:22

> I wanted to log end point’s IP address during some errors in communication
> using openssl.
> Initially when I tried getpeername() on SSL context, its giving proxy
> server’s IP and not destination IP.

The proxy server address *is* the peer address. Proxies terminate TLS conversations. The client has a TLS conversation with the proxy, and the proxy may have a separate TLS conversation with the origin server. (Or with whatever the next application-level node in the chain is; there can be multiple proxies, gateways, etc.)

If it didn't do TLS termination, it wouldn't be a proxy, but a router.

If you have a node that's doing routing at level 4 (copying data between two TCP connections) but not doing TLS termination, there's no way to get the IP addresses of the endpoints of the other connection from the stack. That information has to be provided at the application level.

(Techincal quibble: "Level 4 routing" is a somewhat dubious concept in TCP/IP, since TCP straddles OSI levels 4 and 5. But applications which forward data between TCP conversations are traditionally connsidered level-4 routers. Also, note some level-4 routing packages do TLS termination - stunnel in its base mode is an example. A level-4 router may or may not do TLS termination.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus


Reply | Threaded
Open this post in threaded view
|

RE: To get end point's IP address

Chethan Kumar
Thanks for the information.

I researched more and found that tlsext_hostname member variable in SSL structure can be used to to get host name.
If applications set this using SSL_set_tlsext_host_name(), is it correct to print hostname/IP in  tlsext_hostname.
Can I use this one to set hostname/Ip address.?
Can applications acting as both server and client set this?

Thanks in advance,
Chethan Kumar

-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of Michael Wojcik
Sent: Monday, May 20, 2019 7:35 PM
To: [hidden email]
Subject: RE: To get end point's IP address

> From: openssl-users [mailto:[hidden email]] On
> Behalf Of Chethan Kumar
> Sent: Monday, May 20, 2019 04:22

> I wanted to log end point's IP address during some errors in
> communication using openssl.
> Initially when I tried getpeername() on SSL context, its giving proxy
> server's IP and not destination IP.

The proxy server address *is* the peer address. Proxies terminate TLS conversations. The client has a TLS conversation with the proxy, and the proxy may have a separate TLS conversation with the origin server. (Or with whatever the next application-level node in the chain is; there can be multiple proxies, gateways, etc.)

If it didn't do TLS termination, it wouldn't be a proxy, but a router.

If you have a node that's doing routing at level 4 (copying data between two TCP connections) but not doing TLS termination, there's no way to get the IP addresses of the endpoints of the other connection from the stack. That information has to be provided at the application level.

(Techincal quibble: "Level 4 routing" is a somewhat dubious concept in TCP/IP, since TCP straddles OSI levels 4 and 5. But applications which forward data between TCP conversations are traditionally connsidered level-4 routers. Also, note some level-4 routing packages do TLS termination - stunnel in its base mode is an example. A level-4 router may or may not do TLS termination.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus


The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

Reply | Threaded
Open this post in threaded view
|

Re: To get end point's IP address

Karl Denninger
On 5/21/2019 4:53 AM, Chethan Kumar wrote:
Thanks for the information.

I researched more and found that tlsext_hostname member variable in SSL structure can be used to to get host name.
If applications set this using SSL_set_tlsext_host_name(), is it correct to print hostname/IP in  tlsext_hostname.
Can I use this one to set hostname/Ip address.?
Can applications acting as both server and client set this?

Thanks in advance,
Chethan Kumar

Why do you want the specific IP address?  If the other end is behind a NAT device or similar (or a full-blown proxy) then that address is not meaningful in the context of actual identification as to the source of the communication.

Better, if it is necessary to know who you're talking to, is for the client to present a certificate which the server can then verify as to validity and provenance; the client, of course, by definition has same capability against the server so it can verify that the server it thinks it is talking to is actually the one it's communicating with.

--
-- Karl Denninger
The Market-Ticker
S/MIME Email accepted and preferred

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: To get end point's IP address

Michael Wojcik
In reply to this post by Chethan Kumar
> From: Chethan Kumar [mailto:[hidden email]]
> Sent: Tuesday, May 21, 2019 03:53
>
> I researched more and found that tlsext_hostname member variable in SSL
> structure can be used to to get host name.

That's the SNI hostname, which is set by the client to the hostname (or possibly some other string identifier, such as the text representation of an IP address) that it thinks it wants to connect to. It's used by the server to determine what certificate to send to the client. It's not a reliable indicator of the server's hostname, and has nothing to do with the client's hostname.

> If applications set this using SSL_set_tlsext_host_name(), is it correct to
> print hostname/IP in  tlsext_hostname.

"correct" in what sense? "print" where?

Forget OpenSSL APIs and details of OpenSSL data structures. What problem are you trying to solve?

> Can I use this one to set hostname/Ip address.?

Maybe. You haven't explained what you're trying to do.

> Can applications acting as both server and client set this?

It's set by a client. It doesn't matter what else that client is doing.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

RE: To get end point's IP address

Chethan Kumar
Thanks for the input.

>> If applications set this using SSL_set_tlsext_host_name(), is it
>> correct to print hostname/IP in  tlsext_hostname.
>"correct" in what sense? "print" where?
> Maybe. You haven't explained what you're trying to do.
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.
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.?

Thanks in advance,
Chethan Kumar

-----Original Message-----
From: openssl-users [mailto:[hidden email]] On Behalf Of Michael Wojcik
Sent: Tuesday, May 21, 2019 8:30 PM
To: [hidden email]
Subject: RE: To get end point's IP address

> From: Chethan Kumar [mailto:[hidden email]]
> Sent: Tuesday, May 21, 2019 03:53
>
> I researched more and found that tlsext_hostname member variable in
> SSL structure can be used to to get host name.

That's the SNI hostname, which is set by the client to the hostname (or possibly some other string identifier, such as the text representation of an IP address) that it thinks it wants to connect to. It's used by the server to determine what certificate to send to the client. It's not a reliable indicator of the server's hostname, and has nothing to do with the client's hostname.

> If applications set this using SSL_set_tlsext_host_name(), is it
> correct to print hostname/IP in  tlsext_hostname.

"correct" in what sense? "print" where?

Forget OpenSSL APIs and details of OpenSSL data structures. What problem are you trying to solve?

> Can I use this one to set hostname/Ip address.?

Maybe. You haven't explained what you're trying to do.

> Can applications acting as both server and client set this?

It's set by a client. It doesn't matter what else that client is doing.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the
recipient and may contain privileged information.
If you are not the intended recipient, please notify the
sender and delete the message along with any
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail
are those of the individual sender except where the sender
specifically states them to be the views of
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.

Reply | Threaded
Open this post in threaded view
|

RE: To get end point's IP address

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