On 09/06/16 21:00, Rob Godfrey wrote:
Hi Olivier,
Speaking for the Java Broker, there is currently no mechanism to tie the
TLS client certificate to the host name or IP address corresponding to the
origin of the TCP/IP connection (I'd imagine this is also the case for
Dispatcher but I'll let someone more knowledgable on that codebase step in
there). Similarly to the C++ broker as described in the document Chester
provided, when using the SSL Client Certificates on a connection we simply
verify that the certificate has been signed by a trusted source, and then
(if the External Auth Provider is being used) take the identity from the
certificate itself.
It's certainly shouldn't be a big job to add the ability to verify that the
certificate provided by the client in the TLS negotiation has a DN or SAN
which corresponds to the IP address or reverse-looked-up DNS name of the
machine initiating the connection. Obviously in your use case as described
below this would be validating that the connection from a Dispatcher
instance is coming from the expected machine for the Dispatcher... it won't
be verifying anything about the client which connects to the Dispatcher.
Would you be interested in me implementing something to add this
functionality to the Java Broker?
My suggestion would be to restrict the authenticated client identity to
connect only from given IP addresses. That way your certificates just
identify the client (and are not tied to a given host or ip address) and
you can update the whitelisted/blacklisted ips for a given client
identity more easily.
The router can do this now, I believe.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
