On Mon, May 19, 2025 at 6:54 AM Tom Beecher via NANOG <nanog@lists.nanog.org> wrote:
Most things , especially in a browser, are going to be doing 'normal' ( 1-way ) TLS, meaning only the server identity is verified. It is also possible to implement mutual TLS (mTLS) which the client and server must both verify their identities. This is where TLS client authentication certs
Yes. And Mutual TLS is also common. For example: A Web farm's frontend load balancer consists of a Reverse proxy server that perform only ServerAuth for traffic between end users' web browser and the reverse proxy server. For each HTTPS request: the reverse proxy server accepts the user's HTTPS connection and opens an outgoing HTTPS connection to the true web server in parallel in order to service the end user's request. The outgoing HTTPS connections made from the reverse proxy server towards the pool of true web servers should be mutual TLS-required HTTPS connections. The load balancer/reverse proxy has the TLS certificate signed by LetsEncrypt which is used for Server authentication when accepting an incoming HTTPS connection from a browser, and the same certificate is used for ClientAuth when the reverse proxy server connects to the True web server at the backend. The "true" web servers which the reverse proxy forwards to contain a configuration which specifies that Client authentication is required to connect; the Client certificate must be signed by a trusted CA derived from the Public trusted CA roots list, and the CN on that certificate must match the Proxy server's CN. This allows the web servers to confirm that the HTTPS requests comes from the legitimate load balancer IP. This prevents attempts to probe or attempt to crawl backend servers directly; in case nefarious actors discover the true web servers' IP address in attempt to bypass the load balancer's controls or filtering policies - they will be unable to negotiate a HTTPS connection. This also confirms at a protocol level some phisher or other adversary in the middle has not inserted themselves into the transaction as an unauthorized reverse proxy. ClientAuth and ServerAuth in this regard is about validating the identity of network endpoints; clients and servers which have a FQDN. TLS validation is unrelated to user authentication or authorization. -- -JA