offbyone 10 Posted July 17, 2020 Share Posted July 17, 2020 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 comment Share on other sites More sharing options...
offbyone 10 Posted July 17, 2020 Author Share Posted July 17, 2020 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 comment Share on other sites More sharing options...
ESET Staff MartinK 383 Posted July 18, 2020 ESET Staff Share Posted July 18, 2020 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. offbyone 1 Link to comment Share on other sites More sharing options...
offbyone 10 Posted July 18, 2020 Author Share Posted July 18, 2020 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 comment Share on other sites More sharing options...
offbyone 10 Posted July 19, 2020 Author Share Posted July 19, 2020 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 Link to comment Share on other sites More sharing options...
ESET Staff MartinK 383 Posted July 20, 2020 ESET Staff Share Posted July 20, 2020 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 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 comment Share on other sites More sharing options...
offbyone 10 Posted July 20, 2020 Author Share Posted July 20, 2020 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 comment Share on other sites More sharing options...
ESET Staff MartinK 383 Posted July 20, 2020 ESET Staff Share Posted July 20, 2020 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. offbyone 1 Link to comment Share on other sites More sharing options...
offbyone 10 Posted July 20, 2020 Author Share Posted July 20, 2020 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 comment Share on other sites More sharing options...
offbyone 10 Posted July 20, 2020 Author Share Posted July 20, 2020 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 comment Share on other sites More sharing options...
offbyone 10 Posted September 6, 2020 Author Share Posted September 6, 2020 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 Mirek S. 1 Link to comment Share on other sites More sharing options...
Recommended Posts