Jump to content

Management protocol + reverse proxy


Recommended Posts

From what I understand the management protocol between ESMC agent and ESMC server (port 2222) is https based and as such proxy aware (at least if no authentication is used).

The default design for our customers is to never have connections being directly established from untrusted networks (like internet) to trusted networks (like LAN) but to be instead going thru a reverse proxy located in DMZ.

As we use this design pattern also for mobile workers successfully for different services based on http and https so we intend to go a similar route with ESMC.

In theory this should not be a big deal, but I want to ask if there is a showstopper I don't see at the moment.

Link to post
Share on other sites

Just re-read all documentation I could find about the topic and now I'm not entirely sure if the protocol on port 2222 is indeed based on https and as such is proxy aware. Maybe someone can confirm or deny.

 

Link to post
Share on other sites
  • ESET Staff
13 hours ago, offbyone said:

Just re-read all documentation I could find about the topic and now I'm not entirely sure if the protocol on port 2222 is indeed based on https and as such is proxy aware. Maybe someone can confirm or deny.

 

ESMC Agent are using mutually authenticated TLS (both endpoints do have to present with it's certificate), which is protecting underlying HTTP2 requests, so technically it is HTTP2 over TLS.

Link to post
Share on other sites

Thanks for confirmation.

So let communication go thru reverse proxy (Squid on Linux) should be doable. When finished I will post my findings.

Link to post
Share on other sites

My first tests show that Squid does not seem to be an option here, as currently HTTP/2 support is not fully implemented. Seems that ESET agent refuses to connect with HTTP/1.1

SC.PNG.23c18ba1f6dc3693b6b1c07b13792b31.PNG

 

Link to post
Share on other sites
  • ESET Staff
14 hours ago, offbyone said:

My first tests show that Squid does not seem to be an option here, as currently HTTP/2 support is not fully implemented. Seems that ESET agent refuses to connect with HTTP/1.1

SC.PNG.23c18ba1f6dc3693b6b1c07b13792b31.PNG

 

Yes, communication protocol is HTTP2-only, so it has to be supported also by proxy in case of TLS introspection and possibly other analysis. I do not think it is used in this way, but maybe HAProxy might helps, as it seems to support HTTP2.

Do you actually require TLS introspection? In case no, standard proxy with support for TLS connections and "CONNECT" method should be sufficient -> this can be handled also by Apache HTTP proxy in configuration we do provide, but obviously analysis of protocol content is not visible, but it is faster and does not involve security issues, as in case of introspection, proxy will have acces to all date transferred between AGENT and ESMC, which might include sensitive information, which should be ideally protected end-to-end as is done by default.

Link to post
Share on other sites

Hi Martin,

thanks for you response.

No TLS introspection is not necessary. Our first attempt was Squid as we use it anyway at the perimeter network for other HTTP over TLS services, and if this would have worked it would have been the most simple approach.

The nice side effect with introspection would be that as ESET uses a client certificate for authentication we could stop any connection attempt from outside at the perimeter if no valid client certificate is in place.

Next thing we will try would be NGHTTPX which is a reverse proxy with HTTP/2 support.

On TCP level it would also be possible to use SOCAT for connection replication which we also use for similar things, but it does not have connection pooling and creates a process for every connection and as such may not be a first choice performance wise on larger scales.

Link to post
Share on other sites
  • ESET Staff

As AGENT->ESMC protocol currently used gRPC on application layer (not guaranteed to the future), there are many small projects and proxies that can be used to routing, but in case of security, most reliable solution might be standard TLS termination and forwarding of requests on TCP layer, i.e. without interpreting data and requests itself. This is supported by most of the commonly used proxies ad mentioned previously. It would just require some basic "magic" with certificates. In this configuration, proxy should be just "repacking" TCP traffic from one TLS channel to another, instead of interpreting it + it is possible to configure proxies to be transparent for AGENTs. This kind of configuration is very often used for load balancing.

Your case would be probably best matched by something like TLS pass-through with additional client certificate checks, but it is probably not supported by common proxies, I think it not possible to validate client certificate before connection to backend service (ESMC in this case) is opened, so it would somehow reduce security benefits.

Link to post
Share on other sites
Quote

It would just require some basic "magic" with certificates. In this configuration, proxy should be just "repacking" TCP traffic from one TLS channel to another, instead of interpreting it

Fully agree that this would be the most robust way. That is what we are already doing with SOCAT for another usecase.

I will post results here, what we have found.

Thanks again for taking the time.

Link to post
Share on other sites

Hi Martin,

I just picked up your recommendation of HAProxy and had a look at the docs. Indeed it does exactly what we need (TLS bridging mode), has a very clean design, good docs, and is proven to be secure and stable in large scales.

I think we will give it a try.

THX again.

Link to post
Share on other sites
  • 1 month later...

We have successfully implemented haproxy in front of ESMC in a test environment.

Our first attempt to run in http mode failed, as we found that ESMC agent does not seem to send back valid HTTP responses which comply to http standards.

But we further found that this is not a problem with what we want to achieve (checking validity of the client cert on the reverse proxy side), as TLS bridging with haproxy also works in TCP mode.

Following is the relevant part of the haproxy config:

frontend esmcAgentFE
   mode tcp
   option tcplog
   bind *:2222 ssl crt /etc/haproxy/ssl/crt/esmcServer.pem verify required ca-file /etc/haproxy/ssl/ca/esmcCA.pem
   default_backend esmcAgentBE

backend esmcAgentBE
   mode tcp
   default-server ssl
   default-server ca-file /etc/haproxy/ssl/ca/esmcCA.pem
   default-server crt /etc/haproxy/ssl/crt/esmcAgent.pem
   server default esmc.mydomain.com:2222

Cheers

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...