Re: Massive change in Public Cert behaviour coming soon

[Jay Acuna via NANOG <nanog () lists nanog org>]

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
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/JR3YW7LJAEHMMSZO4EAWRUUPGW7I2X7J/