question about basics of creating a PROXY to MONITOR network activity

Paul Bryan pbryan at anode.ca
Sat Apr 10 12:17:33 EDT 2021


There is absolutely nothing wrong with building your own reverse proxy
in front of your own service, as long as you control both. This
constitutes a tiered network/application architecture, and it's a
common practice. There's no man in the middle; there's no imposter; its
all "you". 

If your proxy becomes the endpoint that clients now must connect to
(i.e. nothing "in front" of your new proxy), you will have to deal with
TLS (aka SSL). Having the TLS certificate match the DNS address of your
new endpoint is a central tenet of security, and allows clients to
trust that they are connecting to the intended endpoint (there is
not a man in the middle).

How you secure the network traffic between your proxy and the service
it fronts becomes an important factor. If you claim that data is always
encrypted in transit, then either:

a) your reverse proxy must be colocated with the service it fronts on
the same machine;
b) your network infrastructure transparently encrypts traffic between
your proxy and the service; or 
c) your proxy must negotiate its own TLS connection(s) with the
service.

Negotiating TLS connections independently for each hop through a
network will add overhead, and degrade the performance of your service.
This can be major pain point when composing an application of
microservices, where each service must be able to securely connect to
another over a network. This is where a service mesh proxy (e.g. Envoy)
comes into play, or even full blown service mesh with service
discovery, certificate management, access policies (e.g. Istio). 


On Sat, 2021-04-10 at 07:52 -0700, cseb... at gmail.com wrote:
> 
> > Is it even possible to be secure in that way? This is, by
> > definition, 
> > a MITM, and in order to be useful, it *will* have to decrypt 
> > everything. So if someone compromises the monitor, they get 
> > everything. 
> 
> Chris
> 
> I hear all your security concerns and I'm aware of them.  I *really*
> don't want to have to
> fight SSL.  Encryption was the biggest concern and I'd rather not
> mess with it to do something 
> useful.
> 
> I've never used CloudFlare but if I'm not mistaken, it can be
> considered a useful "MITM" service?
> Do they have to decrypt traffic and increase the attack surface to be
> useful?
> 
> I just want to create a "safe" MITM service so to speak.
> 
> cs



More information about the Python-list mailing list