Convergence of various kinds of proxies for SASE

Why Proxies in SASE?

Gone are the days when the packet level security was considered sufficient. Due to the sophistication of attacks, it is becoming imperative to do deep content inspection for various kinds of protections. Identity aware access is a key requirement due to distributed workforce and distributed applications. This blog post delves into the requirements related to identity-aware access in detail. Deep content inspection and identity-aware access at the API/application-resource level necessitates the termination of client connections, content inspection for threat detection and access control and origination of connections through proxies. Hence, many SASE solution implement security through proxies.

Proxy types

You might have heard about various types of proxies – Forward, Reverse and Transparent. The main functionality of all types of proxies is same. High level functionality is listed here.

• Get hold of traffic
• Terminate client connections.
• Authenticate clients.
• Get user identity.
• Originate connections towards servers.
• TLS decryption and encryption
• Check for IP and domain reputation.
• Perform identity-based access controls.
• Perform CASB functions.
• Check for Data loss and prevent loss.
• Perform intrusion detection/prevention function.
• Perform web application firewall function.
• Look for malware and exploit indicators in the traffic and act.

How they differ from one another is based on the following factors:

• Obtaining traffic for threat inspection and access control
• Authenticating users and identifying the users

Transparent Proxy type

In this type, clients and servers don’t know about the presence of proxies. These proxies capture traffic from the network routers on which traffic is passing through. It is the responsibility of network administrators to ensure that traffic from office users and traffic from WFH users is directed through enterprise routing entities. To ensure the traffic from WFH users go through Enterprise routers, it is normal practice to leverage VPN clients to connect to Enterprise networks. In the case of SD-WAN, VPN tunnels terminate at VPN concentrators at the nearest PoP location.

User authentication and corresponding user identification happens via

• Explicit Portal
• On Demand Portal
• VPN Tunnel establishment
• TLS client certificate

In case of “Explicit Portal”, users proactively log into the portal. Portal service authenticates the user with the help of enterprise authentication systems. Upon successful validation of user credentials, it notes down the IP address of the user (from source IP of the connection) and informs the proxies of user ID and IP address mapping information. Once proxy know these mappings, proxy identify the user from the IP address of the traffic and perform identity aware policy enforcement.

If user initiates session without proactively authenticating with the portal, then proxy can redirect the user to the portal. Since the portal access is on-demand, this method of authentication is also called on-demand portal authentication. One thing to note is that redirection of user to portal is only possible if the connection is HTTP/HTTPS based. In case of HTTPS, redirection is only possible after TLS decryption. In case of access to non-enterprise services/sites, it is required to mimic the server certificate with enterprise owned CA certificate. Moreover, if the user is not human user using the browser, then redirection does not help. Even with this caveats, it is still powerful way for proxy to get the user authenticated and identified.

As briefly discussed, to be part of the enterprise networks, WFH (Work From Home) users need to connect to the enterprise networks via VPN tunnel. VPN tunnel establishment already performs user authentication. VPN concentrators assign the unique private IP address to each client. Clients can be configured to use VPN tunnel and hence this IP address as source for majority of connections (including split tunnelling disabled). VPN concentrators have ability to advertise IP address assigned to the client, user ID (initiator ID) mapping to external parties. Proxies use this mapping to identify the sessions to a user at later time when the clients initiate sessions.

If the TLS session established client programs has TLS client certificate, it can be used to authenticate and identify the user. This is used very rarely today in SASE, but it is one of the options available.

One major benefit of transparent proxy type is that it can capture all protocol traffic, not just HTTP/HTTPS. Another major benefit is that there is no special configuration at the enterprise client machines or server machines.

There are few drawbacks with this type of proxies. Since it identifies the user based on the IP address observed in traffic, all the applications in that user machine get the same security treatment. If it is multi-user machine, all users of that machine gets the same security treatment/privilege. If this IP address is NATing multiple machines, then all the machine behind that NAT IP address get the same access and security treatment. Think of a case where user laptop is infected with malware. Malware gets the same access as defined for that user as malware is part of the same machine from where user logs in to the portal. Due to this, transparent proxy types should be used with care, at least for HTTP/HTTPS sessions.

Another drawback is that this type of proxies requires VPN client to be present in the devices. Though it is not a problem for managed devices, it can be a challenge to convince employees to install VPN client on employee-owned devices.

Forward Proxy type

Forward proxies are meant for client devices that communicate with external services/sites. Client applications are configured to go via forward proxy to communicate with external services. Client applications are configured with proxy FQDN/IP and Port on which proxies are listening on. In case of transparent proxy, source and destination IP address of the session never has proxy IP address. In case of forward proxy, connections from the client are to proxy IP address and connection to server would be from the proxy IP address.

PAC files are used to configure the client applications such as browsers with proxy settings. PAC file allows selecting routing of traffic to various proxies based on the destination service domains. PAC files are distributed to the client browsers via system management solutions or via WPAD (Web Proxy Auto Discovery) service.

Client applications with the proxy settings always communicate with the proxy. That is how, forward proxies capture the traffic. In case of TLS connections such as HTTPS, every TCP connection starts with “HTTP CONNECT” transaction. This transaction is only between client and the proxy. After that HTTP CONNECT transaction, the data between client and server is mediated by the proxy. “HTTP CONNECT” transaction has host header field whose value used by the proxy to determine the ultimate destination FQDN and port. In case of HTTP2.0, every stream connection starts with “HTTP CONNECT” transaction. As you might have observed, there is no need for traffic being sent to Enterprise routers for the proxy to capture the traffic. That is, traffic directly goes to the proxy. In that way, it is network agnostic.

Forward proxies also can authenticate and identify the users via proxy-authenticate and proxy-authorization headers. In case of TLS connections, these headers are sent in response and request respectively in HTTP CONNECT transactions. A point to note is that there is no need for decrypting TLS connections for the purposes of authenticating and identifying the user. There is no portal authentication required. There is one added advantage is that many browsers and client applications support Kerberos as part of proxy authentication. With that, any user that login to one’s device can automatically authenticate themselves with the proxy with no additional login popups (also known as SSO).

There are several advantages of using forward proxy type for clients that communicate with external services. Some of them are listed below.

• User authentication and identification is deterministic. In case of transparent proxy type, if user forgets to proactively authenticate to the portal, on-demand portal or captive portal redirection for user authentication is only possible after TLS decryption. Some enterprises don’t allow TLS decryption to sites that collect PII. If sites adopt certificate pinning, transparent proxies are not expected to mimic the certificate and hence TLS decryption is not possible. In these cases, user can’t be determined to provide identity aware policy enforcement. In forward proxy type, since proxy authentication phase occurs before any TLS exchange, user authentication and identification is deterministic.
• As discussed before, forward proxy is network agnostic and can work with any network as long as client applications are configured with proxy settings. There is no need for VPN client being there in the devices even if the users are working from home.
• Since many client applications support Kerberos, user gets SSO experience.
• Encrypted Client Hello (ECH) in TLS 1.3+ is getting traction in the industry. When ECH is adopted, SNI is not visible and hence transparent proxy type will not be able to do even basic URL filtering and access control. In forward proxy type, due to HTTP CONNECT transaction, proxy knows the destination FQDN even if ECH is adopted. That is, forward proxy type is ECH safe.
• There is no IP whitelisting. Every client application needs to authenticate separately with the proxy and hence very secure.

There are few drawbacks too. It only works for HTTP/HTTPS traffic. Though majority of client applications support proxy settings, some don’t.

Reverse Proxy type

Reverse proxies are used to frontend server applications. Reverse proxies are used to protect services from threats, to provide RBAC, to terminate TLS sessions and also to load balance the traffic sessions among multiple instances of services.

Reverse proxy capture traffic via DNS methods. FQDN of each enterprise service that is exposed to employees or public users is configured in enterprise DNS servers to point to the IP addresses of reverse proxy instances. Due to this, every time any user tries to make connection to the enterprise services, the corresponding traffic lands in the reverse proxies.

Reverse proxies also terminate HTTPS/HTTP sessions. As part of this process, they also authenticate users and then identify users of the sessions via OIDC, SAMLv2 and SPENGO/Kerberos methods. In case of App-to-App communication, users are identified from TLS certificates too.

SASE Proxy

For a primer on SASE, please read the blog post on Deciphering SASE. As you might have observed, SASE solutions are expected to provide comprehensive security – Securing clients, Securing SaaS data and Securing enterprise applications. As described in Identity-aware-SASE blog post, identity based access controls is the key feature of SASE. Though many enterprises can live with HTTP/HTTPS access alone, some may also require access controls on other protocols too. Due to these needs, we believe that SASE proxy shall act as transparent for non-HTTP traffic and for client applications that don’t support proxy settings. The SASE proxy shall acts as forward proxy for client applications that access Internet and SaaS services to provide deterministic identity based access control and also to future proof when ECH is adopted. The SASE proxy shall also act as reverse proxy to protect enterprise applications. This convergence of multiple proxy types is required for successful SASE solution.

• CTO Insights blog

  The Aryaka CTO Insights blog series provides thought leadership for network, security, and SASE topics. For Aryaka product specifications refer to Aryaka Datasheets.