[netty] Refuse connections from certain clients (based on IP)

[romm1of]

Hello there. I have a need to block certain clients from establishing a connection to the server (i.e. at the moment of tls handshake, based on their ip address)
I know a ServerInterceptor would work here, but I don't really want to make redundant checks every time a client executes a rpc

So far I've managed to proceed with proxy X509ExtendedTrustManager - I am able to close any inbound/outbound traffic during tls handshake.
But I am unable to retrieve ip address of the client from SSLEngine (peerhost/peerport is set to null there).
A little bit of debugging and I see that io.grpc.netty.shaded.io.grpc.netty.ProtocolNegotiators.ServerTlsHandler.handlerAdded() instantiates a new SSLEngine without setting peerhost/peerport, though it has access to channel (which contains remoteAddress) from ChannelHandlerContext (curious whether it was done intentionally, if not and this is the only option I have left then I'm more than willing to make contribution to address it)

So, at this point I'm out of ideas what to do. Could anyone please guide me what my options are?
Thanks

[ejona86]

Copying my response from Gitter:

It doesn't have access to the peerhost. That is used on client-side for server hostname verification. I expect that such a feature shouldn't use the TLS stack, as it is not part of TLS.

[ejona86]

See the continued discussion on Gitter. Points to call out:

This is to handle clients with broken retry logic. All such clients can be identified by their subnet (looked up in-memory; no I/O). It seems best to close the connection pre-TLS, but they are interested in post-tls, potentially for other uses. The clients have reasonable reconnect behavior, so killing the connection reduces load compared to killing RPCs.

This is related to DoS handling, but more static than may be useful there. That would also be longer term. We may need a shorter-term solution like a callback "should we accept this connection."

---

ServerTransportFilter is called around this time, although post-TLS. It doesn't handle exceptions. For post-TLS, it'd probably be better to do it as part of the handshake (not strictly post/"after").