Nio2Endpoint creates SSL engines without populating remote IP and port

[Giorgio Saviane <gs...@gmail.com>]

Hi all,
  when Tomcat is used with BouncyCastle as security provider, the audit
logs of TLS connection attempts do not report the remote IP:port where the
connection comes from:

[2024-10-25 00:26:51,328 INFO] [server #24 @23e488a9] accepting connection
from (Unknown):(Unknown)


I investigated why, and noticed that the SSLEngine objects in Nio2Endpoint
are created by using the default constructor, thus not populating the
remote IP:port that are being used by BouncyCastle to report them in the
audit log.
I made my own custom connector by extending a bunch of Http11Nio2Protocol
connector classes and populating the hostPeer, hostPort in SSLEngine with
values taken from socketWrapper.getRemoteAddr(), and
socketWrapper.getRemotePort(). It works pretty well, now the correct
IP:port are shown in the audit log.

I was thinking to open a PR with this change. Does it make sense or do you
see any counterindication?

Kind regards

Giorgio

Re: Nio2Endpoint creates SSL engines without populating remote IP and port

[Rémy Maucherat <re...@apache.org>]

On Wed, Oct 30, 2024 at 5:06 PM Giorgio Saviane <gs...@gmail.com> wrote:
>
> Hi all,
>   when Tomcat is used with BouncyCastle as security provider, the audit
> logs of TLS connection attempts do not report the remote IP:port where the
> connection comes from:
>
> [2024-10-25 00:26:51,328 INFO] [server #24 @23e488a9] accepting connection
> from (Unknown):(Unknown)
>
>
> I investigated why, and noticed that the SSLEngine objects in Nio2Endpoint
> are created by using the default constructor, thus not populating the
> remote IP:port that are being used by BouncyCastle to report them in the
> audit log.
> I made my own custom connector by extending a bunch of Http11Nio2Protocol
> connector classes and populating the hostPeer, hostPort in SSLEngine with
> values taken from socketWrapper.getRemoteAddr(), and
> socketWrapper.getRemotePort(). It works pretty well, now the correct
> IP:port are shown in the audit log.
>
> I was thinking to open a PR with this change. Does it make sense or do you
> see any counterindication?

This is normally not used, although I see why it is nice to have in
this situation. Also this would probably be a significant API change.
As a result, it seems unlikely the PR is going to be merged.

Rémy

> Kind regards
>
> Giorgio

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org