What is a Reverse proxy?
A reverse proxy sits in front of a server, intercepting requests to the applications hosted on the server. A reverse proxy is typically deployed in front of a pool of servers to help meet scalability, high availability and security against the incoming web traffic. It is used for providing services such as load balancing, web application security, content caching, etc. ands are an integral part of the Internet infrastructure in the form of ADCs, WAFs, CDNs, etc.
How Does a Reverse Proxy Server Work?
A reverse proxy example:
A reverse proxy is topologically deployed in the network such that the client traffic meant for the application server reaches the proxy. This is commonly achieved by exposing a single IP address for a pool of application servers, which is then assigned to a network interface on the proxy. The clients discover this IP address through services such as DNS.
The client TCP connection is terminated at the reverse proxy. It first performs TCP handshake with the client, acting as the application server itself, and once client data arrives it will open another TCP connection acting as a client to an available application server in the pool. For performance optimization, proxy might use an already established TCP connection to the application server saving one full round trip time (this technique is called connection pooling).
Reverse proxies that open two TCP connections, mediating connections to both the client and to the server are sometimes also called full proxies. A reverse full proxy may provide different services on the two connection legs and may even implement two different network stacks to achieve the same. An example of such a full proxy is when it acts as a gateway for protocol translation from the client side to the server side e.g. HTTP2 on client side and HTTP1.1 on the server side.
Benefits of a Reverse Proxy Server
Reverse proxies are deployed in front of application servers for several use cases, such as:
1. Anonymity
Provide anonymity to backend servers by hiding their address, topology, capability and characteristics so that these information cannot be exploited for security attacks by adversaries.
2. Load Balancing
To allow client traffic to scale, the application servers are generally deployed in a cluster so that different instances in the cluster can serve the traffic as the traffic load spikes. To achieve this load balancing, the proxy can distribute the traffic load to several servers using algorithms such as round robin, load-aware, least connections, hashing-based load balancing algorithms.
3. High Availability
It can monitor the health of the servers and prune out unreachable and dead servers from the list of load-balanced servers thereby making sure client traffic always gets served by a responsive server.
4. Security Offload
- It can terminate TLS sessions on behalf of the servers. This not only offloads TLS encryption and decryption from the server but also eases TLS deployment by centralizing key rotation, certification management, etc.
- It can implement client authentication integrating with modern technologies such as OAuth2.0 and OpenID Connect backends such as Github, Facebook, Okta, etc.
5. Content Acceleration
- It can cache content from the servers before sending to the clients and serve this content from the cache to future client requests saving round trips to the server
- It can cache static content like pictures, javascript files, etc.
- It can compress and optimize content to speed up content load time on the client side such as browsers, native apps, etc. It can detect the form factor of client devices (e.g. by using the user-agent header value in the http request) and serve appropriately compressed images.
Gateway Functionality
Provide gateway functionality to the servers by performing protocol translations such that server applications need not change with a change of the client side application protocol. Examples include:
- It can talk HTTP2 with clients and translate these requests into HTTP1.1 for the server.
- It can talk TLS 1.3 with clients and let the servers continue to use TLS 1.2 until the servers get a security upgrade.
Similar to deployment for application servers, reverse proxies have also been deployed in front of database servers for improving visibility and monitoring. Database activity monitoring (DAM) products, when used in inline network mode, are essentially reverse proxies that monitor all activity on a database including administrator activity and SQL transactions, providing reporting and audit logs, and alerting on any unauthorized activity and policy violations. Database Firewalls, similarly when used as an inline service are reverse proxies, protect databases from threats and are used to control access to the database.
Cloud Native
With the widespread adoption of microservices and containers monolithic applications are getting disaggregated into microservices, creating the desire to abstract out all infrastructure and networking state (load balancing, tls termination, resiliency, etc.) from the services itself.
Smaller, discrete services have made coding easier, but resulted in much more complex traffic patterns within the application because these microservices are inherently numerous and ephemeral. This led to challenges providing services such as reliable communication, observability, security, etc. for the dynamic mesh of microservices without complicating the lives of developers. To address these problems, service mesh architectures such as Linkerd and Istio emerged, to help easily network the microservices providing policy-based communication services to the workload running in the mesh. In a way, they have eliminated the need for a traditional bolt-on reverse proxy, providing proxy-like capabilities as a core component in the data plane of this service mesh architecture. In this new world, these embedded proxies and sidecars mediate all ingress and egress traffic for the services in the mesh, provide dynamic service discovery, load balancing, TLS termination, HTTP2 and gRPC Remote Procedure Call proxying, health checks, staged rollouts and metrics for unprecedented observability into the services by instrumenting network traffic.
In this new architecture, while the traditional DAM and database firewall products have become operationally infeasible, the service meshes aren’t designed to handle database protocols. This led Cyral to develop the Data Layer Sidecar, a stateless interception service for data endpoints, that can be deployed as part of typical modern cloud-native workflows.
