Eliminating dual encryption in zero trust network access authenticated sessions

Abstract

Techniques and architectures are described for eliminating dual encryption in zero-trust network access authenticated sessions. Technologies include an endpoint client-based proxy of a network receiving a request from a browser to request access to a protected private service. The endpoint client-based proxy suspends access of the browser to the protected private service and establishes a transport layer security protocol (TLS) connection between the endpoint client-based proxy and a zero trusted network access (ZTNA) gateway. The ZTNA gateway determines whether the protected private service uses a secure transport mechanism and establishes a tunnel encrypted based at least on a null password between the proxy of the endpoint client and the ZTNA gateway, or a tunnel encrypted based at least on a non-null password between the proxy of the endpoint client and the ZTNA. The proxy based on the endpoint client continues the browser's access to the protected private service.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to U.S. patent application No. 18 / 220,057, filed on July 10, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure generally relates to eliminating double encryption in Zero Trust Network Access (ZTNA) authenticated sessions, and more specifically, to eliminating double encryption in Zero Trust Network Access authenticated sessions by overloading the Subject Name and Issuer (SNI) in the Transport Layer Security (TLS) protocol and using NULL encryption. Background Art

[0004] In a networking environment, there are typically multiple proxies running at the L4, L5, and L7 layers of the Open Systems Interconnection (OSI) stack. At the L4 layer, the protocol does not support any way to authenticate the connection. The Transport Layer Security (TLS) proxy runs at the L5 layer, while the Hypertext Transfer Protocol (HTTP) or other application proxies run at the L7 layer. Much of the session context and authentication is typically implemented at the L7 layer by leveraging HTTP cookies (or other application-specific authentication mechanisms) in the case of HTTP connections. In the case of application traffic protected by TLS, the TLS layer must first process the connection, including cryptographic operations, and then pass the plaintext to the application layer. The TLS operations involved are computationally intensive, and in the event of an attack, the server may be overwhelmed by such computation, resulting in denial of service to legitimate clients.

[0005] Furthermore, in devices such as firewalls, it may be necessary to inspect traffic whose contents need to be decrypted. However, there are some services that do not require decryption to be performed and are not expected to be inspected. Generally, most approaches involve creating an encrypted tunnel to the firewall, carrying traffic that is therefore additionally encrypted. After decrypting the outer layer, the firewall or gateway decides whether to inspect the internal traffic. In the case where the internal service (such as a browser) has been protected using the secure hypertext transfer protocol (HTTPs) and needs to be inspected, two levels of decryption are performed. A first or outer layer of decryption is required to access the internal traffic, and a second or outer layer of decryption is required for the internal traffic. After inspection, before passing on, the traffic must be encrypted again. On devices such as firewalls, especially in hardware, this double encryption is costly and generally does not bring security benefits. Generally, the decryption operation is also costly and affects the cost-effectiveness of the device used to decrypt and inspect the traffic. The client-based ZTNA model further exacerbates this situation by introducing another level of encryption and decryption of the outer tunnel. This is a well-known problem in the industry. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The following detailed description is made with reference to the accompanying drawings. In the drawings, the leftmost digit of a reference number indicates the drawing in which the reference number first appears. The use of the same reference number in different drawings indicates similar or identical items. The systems depicted in the drawings are not drawn to scale, and the components in the drawings may not be drawn to scale with respect to each other.

[0007] Figure 1 According to the techniques and architectures described herein, an example layout of a network and a protected private service or application accessed by a browser of the network is schematically shown.

[0008] Figure 2 According to the techniques and architectures described herein, an example process for eliminating double encryption in a ZTNA authenticated session by overloading SNI in TLS and using null encryption is schematically illustrated.

[0009] Figure 3 Another example process for eliminating double encryption in a ZTNA authenticated session by overloading SNI in TLS and using null encryption is schematically illustrated according to the techniques and architectures described herein.

[0010] Figure 4 According to the techniques and architectures described herein, an example process for eliminating double encryption in a ZTNA authenticated session by overloading SNI in TLS and using non-NULL encryption is schematically illustrated.

[0011] Figure 5 In accordance with the techniques and architectures described herein, a flow chart of an example method for abstracting an actual physical twin network is shown, wherein security policies are mapped as an overlay of a graphical representation of the network topology.

[0012] Figure 6 is a computer architecture diagram illustrating an example computer hardware architecture for implementing devices that can be used to implement aspects of the various techniques presented herein. DETAILED DESCRIPTION

[0013] Overview

[0014] Various aspects of the invention are set out in the independent claims, preferred features are set out in the dependent claims. Features of one aspect may be applicable to each aspect alone or in combination with other features.

[0015] The present disclosure provides techniques and architectures for eliminating double encryption in a Zero Trust Network Access authenticated session. Specifically, techniques and architectures are provided for eliminating double encryption in a ZTNA authenticated session by overloading the subject name and issuer (SNI) in the Transport Layer Security (TLS) protocol and using null encryption. For example, when an application protected by a gateway is accessed, the gateway can determine whether a null cipher can be used for an outer tunnel from an unprotected network to a protected private service (e.g., a service or application) based on a security policy (e.g., whether the traffic needs to be inspected).

[0016] As an example, a method may include: receiving, by an endpoint client-based agent of a network, a request to access a protected private service from a browser. The method may also include: pausing, by the endpoint client-based agent, the browser's access to the protected private service, and authenticating, by the endpoint client-based agent, a user of the browser. The method may also include: creating, by the endpoint client-based agent, a Transport Layer Security (TLS) connection between the endpoint client-based agent and a Zero Trust Network Service (ZTNA) gateway, and determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected. The method may also include one of: (i) establishing, by the ZTNA gateway, a null cipher-encrypted tunnel between at least the endpoint client-based agent and the ZTNA gateway, based at least in part on a determination by the ZTNA gateway that the protected private service uses a secure transport mechanism, or (ii) establishing, by the ZTNA gateway, a non-null cipher-encrypted tunnel between at least the endpoint client-based agent and the ZTNA gateway, based at least in part on a determination by the ZTNA gateway that the protected private service uses a non-secure transport mechanism. The method may also include continuing, by the endpoint client-based proxy, the browser's access to the protected private service.

[0017] Example Embodiments

[0018] According to the configuration described herein, as previously described, techniques and architectures are provided for eliminating double encryption in zero-trust network access authenticated sessions. Specifically, techniques and architectures are provided for eliminating double encryption in zero-trust network access authenticated sessions by overloading the subject name and issuer (SNI) in the transport layer security protocol (TLS) and using null encryption. For example, when an application protected by a gateway is accessed, the gateway can decide whether a null password can be used for an outer tunnel connecting from an unprotected network to a protected private service or application based on a security policy (e.g., whether the traffic needs to be inspected).

[0019] For the description of the example configurations in this article, protected private services (e.g., services external to the enterprise network) refer to applications behind the enterprise gateway. Gateway refers to a firewall or other proxy that can authenticate users. Endpoint clients refer to proxy-based clients that establish a tunnel from each application to the gateway. A browser (or any other application) can be used to access protected private services. An identity provider (IdP) authenticates the user, such as a user of an unprotected network. In addition, for the description of the example configurations in this article, it is assumed that the endpoint client has been configured for access for Zero Trust Network Access (ZTNA) and that the client software has been installed on the endpoint client. In addition, it is assumed that the client has a certificate for authenticating the endpoint client and that the client software understands which services are protected private services.

[0020] According to the techniques and architecture described in this article, in a configuration, a browser attempts to access a protected private service. The client software on the endpoint client intercepts the access and pretends to be the protected private service. The client software completes the Transmission Control Protocol (TCP) three-way handshake (3WHS) and suspends or blocks the connection between the browser and the protected private service.

[0021] The client software on the endpoint client initiates a connection to the gateway to authenticate the browser's user against the protected private service. The gateway redirects the client to the identity provider for authentication (AuthN). When AuthN is complete, the client returns an AuthN token to the gateway.

[0022] The gateway validates the AuthN token and determines whether the protected private service is protected by a secure transport mechanism (such as HTTPs or other encrypted protocols). The gateway also determines whether the service needs to be inspected by an intrusion detection system or prevention system (IDS / IPS) service. The gateway creates a unique subject name and issuer (SNI) token and returns the unique SNI token to the endpoint client.

[0023] The endpoint client creates another TLS connection to the gateway, but this time uses the unique SNI token in the SNI field. The gateway determines the security policy that needs to be applied to the traffic between the browser and the protected private service based on the SNI field. The gateway authenticates the endpoint client using the client certificate to avoid replay and forgery of packets.

[0024] If the traffic is going to an application that is already encrypted and does not need to be inspected, the gateway chooses to use a null cipher for TLS encryption. Once this tunnel is established, the endpoint client resumes the browser traffic and encapsulates the TLS client hello packet from the browser in the null cipher tunnel. Before encapsulating the client hello packet, the initial SNI token sent by the browser for the protected private service is replaced with the unique SNI token described above. The rest of the client hello field remains unchanged.

[0025] The gateway receives this data over an authenticated channel (with the unique SNI token and cross-validated with the client certificate). The gateway decrypts the null-encrypted data and replaces the unique SNI token with the actual SNI token associated with the protected private service in the client hello packet and sends it to the protected private service. The protected private service responds with a server hello. The gateway encapsulates this packet over a null-encrypted tunnel and sends it to the endpoint client. The endpoint client decrypts the null-encrypted packet and sends it to the browser.

[0026] If the backend application, such as a protected private service, does not use a secure transport mechanism such as HTTPs or Secure Shell (SSH) between the gateway and the protected private service, and a service (such as IPS) needs to inspect the traffic, the outer tunnel (such as the tunnel between the endpoint client and the gateway) uses a non-blank password and the inner network traffic is clear text traffic.

[0027] If a service (such as IPS) needs to inspect traffic between the gateway and the protected private service, the inner layer of encryption can be between the browser and the IPS engine, and the traffic in the outer tunnel is null encrypted if the protected private service is using HTTPs. If the protected private service is using HTTP, then the traffic between the endpoint client and the gateway is encrypted with a non-null cipher, and the traffic outside the tunnel is clear text traffic.

[0028] Thus, in a configuration, a method includes: receiving, by an endpoint client-based proxy of a network, a request to access a protected private service from a browser. The method also includes: pausing, by the endpoint client-based proxy, the browser's access to the protected private service, and authenticating, by the endpoint client-based proxy, the user of the browser. The method also includes: establishing, by the endpoint client-based proxy, a Transport Layer Security (TLS) connection between the endpoint client-based proxy and a Zero Trust Network Access (ZTNA) gateway, and determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected. The method also includes one of: (i) establishing, by the ZTNA gateway, a tunnel encrypted with a null password between at least the endpoint client-based proxy and the ZTNA gateway, based at least in part on a determination by the ZTNA gateway that the protected private service uses a secure transport mechanism, or (ii) establishing, by the ZTNA gateway, a tunnel encrypted with a non-null password between at least the endpoint client-based proxy and the ZTNA gateway, based at least in part on a determination by the ZTNA gateway that the protected private service uses a non-secure transport mechanism. The method also includes: continuing, by the endpoint client-based proxy, the browser's access to the protected private service.

[0029] In the configuration, the ZTNA gateway determines that traffic between the browser and the protected private service needs to be inspected, and the method further includes inspecting, by an intrusion prevention service (IPS) engine, the traffic between the browser and the protected private service.

[0030] In a further configuration, the ZTNA gateway determines that the protected private service uses a secure transport mechanism, and the method further includes establishing, by the ZTNA gateway, a tunnel encrypted with a null password between the endpoint client-based proxy and the ZTNA gateway. In a further configuration, the ZTNA gateway determines that the protected private service uses a non-secure transport mechanism, and the method further includes establishing, by the ZTNA gateway, a tunnel encrypted with a non-null password between the endpoint client-based proxy and the ZTNA gateway.

[0031] In additional configurations, the ZTNA gateway determines that traffic between the browser and the protected private service does not need to be inspected, and the method further includes establishing, by the ZTNA gateway, a null-password encrypted tunnel between the endpoint client-based proxy and the ZTNA.

[0032] In the configuration, determining whether traffic between the browser and the protected private service needs to be inspected includes: determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected based at least in part on a subject name and issuer (SNI) token associated with the protected private service. In such a configuration, the method further includes generating, by the ZTNA gateway, a unique SNI token, and providing, by the ZTNA gateway, the unique SNI token to an endpoint client-based proxy, wherein continuing the browser's access to the protected private service includes replacing the SNI token associated with the protected private service in a client hello packet with the unique SNI token. In addition, in the configuration, the method further includes replacing, by the ZTNA gateway, the unique SNI token in the client hello packet with the SNI token associated with the protected private service, and forwarding, by the ZTNA gateway, the client hello packet with the SNI token associated with the protected private service to the protected private service.

[0033] Therefore, only one level of encryption is involved at any given moment. Unique SNI tokens are generated on a per-app per-user per-session basis. This ensures that an observer cannot see which services behind the gateway are being accessed, or which services are protected by the gateway. Because only one level of encryption is used at any given moment, computing requirements are reduced. Compared to double encryption mechanisms, latency and throughput are also improved and can be scaled to higher levels. In addition, the cost of null encryption and decryption is close to zero, thus saving valuable computing resources.

[0034] Some implementations and embodiments of the present disclosure will be described more fully below with reference to the accompanying drawings showing various aspects. However, various aspects can be implemented in different forms and should not be understood as being limited to the implementations set forth herein. As described herein, the present disclosure encompasses variations of the embodiments. Similar reference numerals always represent similar elements.

[0035] Figure 1A layout 100 of a network 102 and a protected private service or application 104 accessed by a browser 106 is schematically shown. In the configuration, the browser 106 may be located in an unprotected network (not shown in the figure). The protected private service 104 refers to an application behind an enterprise gateway (e.g., a zero trust network access (ZTNA) gateway 108) and is protected by the enterprise gateway. The ZTNA gateway 108 refers to a firewall or other agent that can authenticate a user, such as a user 110 of the browser 106. An endpoint client 112 is included in the network 102 and refers to a proxy-based client that establishes a tunnel for each application to the ZTNA gateway 108. The browser 106 (or any other application) can be used to access the protected private service 104. An identity provider (IdP) 114 authenticates the user (e.g., a user of the network 102). In addition, for the description of the example configuration herein, it is assumed that the endpoint client has completed access configuration for the zero trust network gateway 108 and the client software has been installed on the endpoint client 112. Furthermore, it is assumed that the client has a certificate for authenticating the endpoint client 112 and that the client software understands which services are protected private services.

[0036] According to the techniques and architectures described herein, in a configuration, a browser 106 attempts to access a protected private service 104. The client software on the endpoint client 112 intercepts the access and masquerades as the protected private service 104. The client software completes a Transport Layer Control Protocol (TCP) three-way handshake (3WHS) and suspends or blocks the connection between the browser 106 and the protected private service 104.

[0037] The client software on the endpoint client 112 initiates a connection with the ZTNA gateway 108 to authenticate the user 110 of the browser 106 to the protected private service 104. The ZTNA gateway 108 redirects the endpoint client 112 to the IdP 102 for authentication (AuthN). When AuthN is completed, the endpoint client 112 returns an AuthN token to the ZTNA gateway 108.

[0038] The ZTNA gateway 108 validates the AuthN token and determines whether the protected private service 104 is protected using a secure transport mechanism (e.g., using HTTPs or other encrypted protocols). The ZTNA gateway 108 also determines whether the protected private service 104 needs to be inspected by an intrusion detection system or prevention system (IDS / IPS) service (e.g., IPS service 116). The ZTNA gateway 108 creates a unique subject name and issuer (SNI) token and returns the unique SNI token to the endpoint client 112.

[0039] The endpoint client 112 creates another TLS connection to the ZTNA gateway 108, but this time uses the unique SNI token in the SNI field. The ZTNA gateway 108 determines the security policy that needs to be applied to the traffic between the browser 106 and the protected private service 104 based on the SNI field. The ZTNA gateway 108 authenticates the endpoint client 112 with the client certificate to prevent replay and forgery of data packets.

[0040] If the traffic is going to an application that is already encrypted and does not need to be inspected, such as protected private service 104, then ZTNA gateway 108 selects to use a null cipher for TLS encryption. Once this tunnel is established, endpoint client 112 continues or unblocks the browser traffic and encapsulates the TLS client hello packet from browser 106 in the null cipher tunnel. Prior to encapsulating the client hello packet, the initial SNI token sent by browser 106 for protected private service 104 is replaced with a unique SNI token. The rest of the client hello fields remain unchanged.

[0041] The ZTNA gateway 108 receives this data over an authenticated channel (with the unique SNI token and cross-validated with the client certificate). The ZTNA gateway 108 decrypts the null encrypted data and replaces the unique SNI token with the actual SNI token associated with the protected private service 104 in a client hello packet and sends it to the protected private service 104. The protected private service 104 responds with a server hello. The ZTNA gateway 108 encapsulates this packet over a null cipher tunnel and sends it to the endpoint client 112. The endpoint client 112 decrypts the null encrypted packet and sends it to the browser 106.

[0042] If a backend application, such as protected private service 104, does not use a secure transport mechanism, such as HTTPs or Secure Shell (SSH), between ZTNA gateway 108 and protected private service 104, and a service (such as IPS 116) needs to inspect the traffic, then the outer tunnel (e.g., the tunnel between endpoint client 112 and ZTNA gateway 108) uses a non-blank password and the inner network traffic is clear text traffic.

[0043] If a service (e.g., IPS 116) needs to inspect traffic between the ZTNA gateway 108 and the protected private service 104, then the inner layer of encryption can be between the browser 106 and the IPS engine 116, and the outer tunnel can be null encrypted if the protected private service 104 is using HTTPs. If the protected private service 104 is using HTTP, then the traffic between the endpoint client 112 and the ZTNA gateway 108 is encrypted with a non-null cipher, and the traffic in the outer tunnel is clear text traffic.

[0044] Figure 2 An example process 102 is schematically shown for eliminating double encryption in a ZTNA authenticated session by overriding the subject name and issuer (SNI) in the Transport Layer Security (TLS) protocol and using null encryption. The example process 200 includes an IdP 202, a browser 204 (which, in a configuration, may be located in an unprotected network), an endpoint client (proxy) 206, a ZTNA gateway 208, and a protected private service 210 using HTTPs.

[0045] At 212, the browser 204 attempts to access the protected private service 210. The client software on the endpoint client 206 intercepts the access and, at 214, masquerades as the protected private service 210. At 216, the client software completes a Transport Layer Control Protocol (TCP) three-way handshake (3WHS) with the browser 204 and, at 218, suspends or blocks the connection between the browser 204 and the protected private service 210.

[0046] At 220, the client software on the endpoint client 206 initiates a connection with the ZTNA gateway 208 to authenticate the user of the browser 204 to the protected private service 210. At 222, the ZTNA gateway 208 redirects the endpoint client 206 to the IdP 202 for authentication (AuthN). When AuthN is completed, at 224, the endpoint client 206 returns an AuthN token to the ZTNA gateway 208.

[0047] At 226, the ZTNA gateway 208 verifies the AuthN token and determines whether the protected private service 210 is protected using a secure transport mechanism (e.g., HTTPs or other encrypted protocols). Specifically, the ZTNA gateway 208 determines the security policy that needs to be applied to the traffic between the browser 204 and the protected private service 210 based on the SNI field. The ZTNA gateway 208 authenticates the endpoint client 206 using the client certificate to prevent replay and forgery of data packets. The ZTNA gateway 208 also determines whether the traffic of the protected private service 210 needs to be inspected by an intrusion detection system or prevention system (IDS / IPS) service (not shown). Figure 2 In the example flow 200 shown, protected private service 210 traffic does not need to be inspected by an intrusion detection system or prevention system (IDS / IPS) service. The ZTNA gateway 208 also creates a unique SNI token and returns the unique SNI token to the endpoint client 206 at 228 .

[0048] At 230 , the endpoint client 206 creates another TLS connection to the ZTNA gateway 208 , but this time uses the unique SNI token in the SNI field. At 232 , the endpoint client 206 sends the ZTNA gateway 208 a client hello and the unique SNI token.

[0049] Because in Figure 2 In the example flow, traffic flows to a protected private service 210 that is encrypted, for example, the protected private service 210 uses HTTPs or other encrypted protocols and does not require inspection, and at 234, the ZTNA gateway selects to use a null cipher for TLS encryption. Once the tunnel is established, at 236, the endpoint client 206 continues the browser traffic or unblocks the browser traffic and encapsulates the TLS client hello packet from the browser in the null cipher tunnel. Before encapsulating the client hello packet, the initial SNI token sent by the browser 204 for the protected private service is replaced with the unique SNI token. The rest of the client hello field remains unchanged.

[0050] At 238, a TLS client hello packet and a unique SNI token are sent from the endpoint client 206 to the ZTNA gateway 208 over the authenticated channel (with the unique SNI token and cross-validated with the client certificate). At 240, the ZTNA gateway decrypts the null-encrypted data and replaces the unique SNI token with the actual SNI token associated with the protected private service 210 in the TLS client hello packet and sends the client hello with the original SNI token attached to the protected private service 210 at 242. The protected private service 210 responds with a TLS server hello at 244. The ZTNA gateway 208 encapsulates this packet over a null-encrypted tunnel and sends it to the endpoint client 206 at 246. The endpoint client 206 decrypts the null-encrypted packet and sends it to the browser 204 at 248. At 250, traffic can now be sent end-to-end encrypted, including the null-encrypted tunnel between the browser 204 and the protected private service 210.

[0051] Figure 3Another example process 300 for eliminating double encryption in a Zero Trust Network Access (ZTNA) authenticated session by overloading the subject name and issuer (SNI) in the Transport Layer Security (TLS) protocol and using null encryption is schematically illustrated. The example process 300 includes an IdP 302, a browser 304 (which, in a configuration, may be located in an unprotected network), an endpoint client (agent) 306, a ZTNA gateway 308, a protected private service 310 using HTTPs, and an intrusion detection system or prevention system (IPS) engine 312.

[0052] At 314, the browser 304 attempts to access the protected private service 310. The client software on the endpoint client 306 intercepts the access and masquerades as the protected private service 310 at 316. At 318, the client software completes a Transport Layer Control Protocol (TCP) three-way handshake (3WHS) with the browser 304 and suspends or blocks the connection between the browser 304 and the protected private service 310 at 320.

[0053] At 322, the client software on the endpoint client 306 initiates a connection with the ZTNA gateway 308 to authenticate the user of the browser 304 to the protected private service 310. At 324, the ZTNA gateway 308 redirects the endpoint client 306 to the IdP 302 for authentication (AuthN). When AuthN is completed, at 326, the endpoint client 306 returns an AuthN token to the ZTNA gateway 308.

[0054] At 328, the ZTNA gateway 308 verifies the AuthN token and determines whether the protected private service 310 is protected by a secure transport mechanism (e.g., HTTPs or other encrypted protocols). Specifically, the ZTNA gateway 308 determines the security policy that needs to be applied to the traffic between the browser 304 and the protected private service 310 based on the SNI field. The ZTNA gateway 308 authenticates the endpoint client 306 using the client certificate to prevent replay and forgery of data packets. The ZTNA gateway 308 also determines whether the traffic of the protected private service 310 needs to be inspected by the IPS engine 312. Figure 3 In the example flow 300 shown, protected private service 310 traffic does need to be inspected by IPS engine 312. ZTNA gateway 308 also creates a unique SNI token and returns the unique SNI token to endpoint client 306 at 330.

[0055] At 332 , the endpoint client 306 creates another TLS connection to the ZTNA gateway 308 , but this time uses the unique SNI token in the SNI field. At 334 , the endpoint client 306 sends the ZTNA gateway 308 a client hello and the unique SNI token.

[0056] Because in Figure 3 In the example flow of FIG. 3 , traffic flows to a protected private service 310 that is encrypted, for example, the protected private service 310 uses HTTPs or other encrypted protocols, but requires inspection, and at 336, the ZTNA gateway 308 selects to use a null cipher for TLS encryption. Once the tunnel is established, at 338, the endpoint client 306 continues the browser traffic or unmasks the browser traffic and encapsulates the TLS client hello packet from the browser 304 in the null cipher tunnel. Prior to encapsulating the client hello packet, the initial SNI token sent by the browser 304 for the protected private service is replaced with the unique SNI token. The rest of the client hello fields remain unchanged.

[0057] At 340, a TLS client hello packet and a unique SNI token are sent from the endpoint client 306 to the ZTNA gateway 308 over the authenticated tunnel (with the unique SNI token and cross-validated with the client certificate). At 342, the ZTNA gateway decrypts the null encrypted data and replaces the unique SNI token with the actual SNI token associated with the protected private service 310 in the TLS client hello packet and sends it to the IPS engine 312 at 344. At 346, the IPS engine 312 sends the TLS client hello to the protected private service 310. At 348, the protected private service 310 responds to the IPS engine 312 with a TLS server hello, which is sent to the ZTNA gateway 308 at 348. The ZTNA gateway 308 encapsulates this packet over a null cipher tunnel and sends it to the endpoint client 306 at 350. The endpoint client 306 decrypts the null encrypted packet and sends it to the browser 304 at 352. At 354, traffic can now be sent between the browser 304 and the IPS engine 312. Thus, since the IPS engine needs to inspect the traffic between the ZTNA gateway 308 and the protected private service 310, the inner encryption is between the browser 304 and the IPS engine 312, and the outer layer is null encrypted in the case where the protected private service 310 is using HTTPs, SSH, etc.

[0058] If the backend application, such as the protected private service 310, does not use a secure transport mechanism, such as HTTPs or Secure Shell (SSH), between the ZTNA gateway 308 and the protected private service 310, and the IPS engine 312 needs to inspect the traffic, then the outer tunnel (e.g., the tunnel between the endpoint client 306 and the ZTNA gateway 308) uses a non-blank cipher for encryption, and the inner network traffic is clear text traffic. Figure 4 An example flow 400 is schematically shown for eliminating double encryption in a Zero Trust Network Access (ZTNA) authenticated session by overriding the subject name and issuer (SNI) in the Transport Layer Security (TLS) protocol and using non-null encryption in such a scenario. The example flow 400 includes an IdP 402, a browser 404 (which may be located in an unprotected network in a configuration), an endpoint client (agent) 406, a ZTNA gateway 408, a protected private service 410 using HTTP, and an intrusion detection system or prevention system (IPS) engine 412.

[0059] At 414, the browser 404 attempts to access the protected private service 410. The client software on the endpoint client 406 intercepts the access and masquerades as the protected private service 410 at 416. At 418, the client software completes a Transport Layer Control Protocol (TCP) three-way handshake (3WHS) with the browser 404 and suspends or blocks the connection between the browser 404 and the protected private service 410 at 420.

[0060] At 422, the client software on the endpoint client 406 initiates a connection with the ZTNA gateway 408 to authenticate the user of the browser 404 to the protected private service 410. At 424, the ZTNA gateway 408 redirects the endpoint client 406 to the IdP 402 for authentication (AuthN). When AuthN is completed, at 426, the endpoint client 406 returns an AuthN token to the ZTNA gateway 408.

[0061] At 428, the ZTNA gateway 408 verifies the AuthN token and determines whether the protected private service 410 is protected with a secure transport mechanism (e.g., with HTTPs or other encrypted protocols). Specifically, the ZTNA gateway 408 determines the security policy that needs to be applied to the traffic between the browser 404 and the protected private service 410 based on the SNI field. The ZTNA gateway 408 authenticates the endpoint client 406 using the client certificate to prevent replay and forgery of data packets. The ZTNA gateway 408 also determines whether the protected private service 410 traffic needs to be inspected by the IPS engine 412. Figure 4In the example flow 400 of FIG. 4 , the protected private service 410 traffic does need to be inspected by the IPS engine 412 . The ZTNA gateway 408 also creates a unique SNI token and returns the unique SNI token to the endpoint client 406 at 430 .

[0062] At 432 , the endpoint client 406 creates another TLS connection to the ZTNA gateway 408 , but this time uses the unique SNI token in the SNI field. At 434 , the endpoint client 406 sends the ZTNA gateway 408 a client hello and the unique SNI token.

[0063] Because in Figure 4 In the example flow, traffic flows to unencrypted protected private service 410, for example, protected private service 410 uses HTTP or other similar protocol and needs to be inspected, at 436, during TLS negotiation and TLS tunnel creation, ZTNA gateway 408 selects to use a non-null cipher for TLS encryption. Once the tunnel is established, at 438, endpoint client 406 continues browser traffic or unmasks browser traffic and at 440, sends an HTTP GET message with the unique SNI token to ZTNA gateway 408 in the non-null encrypted tunnel.

[0064] At 442, the HTTP GET message and the unique SNI token are sent from the ZTNA gateway 408 to the IPS engine 412. At 444, the IPS engine 412 sends the HPPT GET message and the unique SNI token to the IPS engine 412. At 446, the protected private service 410 responds to the IPS engine 412 with an HTTP RESP message, which is sent to the browser 404 at 448. At 450, traffic can now be sent between the browser 404 and the IPS engine 412. Therefore, since the protected private service 410 is using HTTP, the traffic between the endpoint client 406 and the ZTNA gateway 408 is encrypted with a non-null cipher, and the outer layer traffic is clear text traffic.

[0065] Figure 5 A flowchart of an example method 500 is shown and described with reference to Figures 1 to 4 Various aspects of the functions described, at least in part, performed by devices in the network. Figure 5 The described logical operations may be implemented as: (1) a sequence of computer-implemented acts or program modules running on a computing system, and / or (2) interconnected machine logic circuits or circuit modules within a computing system.

[0066] The implementation of the various components described herein is selected based on the performance and other requirements of the computing system. Therefore, the logical operations described herein are variously referred to as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more than one operation can be performed. Figure 5 , and more or less operations as shown in and described in this article. These operations may also be performed in parallel, or in an order different from that described herein. Some or all of these operations may also be performed by components other than those specifically identified. Although the techniques described in this disclosure refer to specific components, in other examples, these techniques may be implemented by fewer components, more components, different components, or any configuration of components.

[0067] Figure 5 A flowchart of an example method 500 for abstracting an actual physical twin network is shown, where security policies are mapped as an overlay of a graphical representation of a network topology. In some examples, the method 500 can be performed by a system including one or more processors and one or more non-transitory computer-readable media, the one or more non-transitory computer-readable storage media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method 500.

[0068] At 502, the endpoint client-based proxy of the network receives a request from a browser to access a protected private service. For example, browser 204 attempts to access protected private service 210. Client software on endpoint client 206 intercepts the access and masquerades as protected private service 210 at 216. The client software completes a Transport Layer Control Protocol (TCP) three-way handshake (3WHS) with browser 2024.

[0069] At 504, the endpoint client-based proxy suspends the browser's access to the protected private service. For example, at 218, the client software on the endpoint client 206 suspends or blocks the connection between the browser 204 and the protected private service 210.

[0070] At 506, the user of the browser is authenticated based on the proxy of the endpoint client. For example, at 222, the client software on the endpoint client 206 initiates a connection with the ZTNA gateway 208 to authenticate the user of the browser 204 to the protected private service 210. At 224, the ZTNA gateway 208 redirects the endpoint client 206 to the IdP 202 for authentication (AuthN). When AuthN is completed, at 226, the endpoint client 206 returns an authentication token to the ZTNA gateway 208.

[0071] At 508, the endpoint client-based proxy establishes a Transport Layer Security (TLS) connection between the endpoint client-based proxy and the Zero Trust Network Access (ZTNA) gateway. For example, at 232, the endpoint client 206 creates another TLS connection to the ZTNA gateway 208, but this time uses a unique SNI token in the SNI field. At 234, the endpoint client 206 sends a client hello and the unique SNI token to the ZTNA gateway 208.

[0072] At 510, the ZTNA gateway determines whether to inspect traffic between the browser and the protected private service. At 512, one of the following operations is performed: (i) at 514, based at least in part on the determination by the ZTNA gateway that the protected private service uses a secure transport mechanism, the ZTNA gateway establishes a tunnel encrypted with a null password between at least the endpoint client-based proxy and the ZTNA gateway, or (ii) at 516, based at least in part on the determination by the ZTNA gateway that the protected private service uses a non-null password, the ZTNA gateway establishes a tunnel encrypted with a non-null password between at least the endpoint client-based proxy and the ZTNA gateway. For example, at 228, the ZTNA gateway 208 verifies the AuthN token and determines whether the protected private service 210 is protected with a secure transport mechanism (e.g., with HTTPs or other encrypted protocols). Specifically, the ZTNA gateway 208 determines the security policy that needs to be applied to the traffic between the browser 204 and the protected private service 210 based on the SNI field. The ZTNA gateway 208 authenticates the endpoint client 206 with the client certificate to prevent replay and forgery of packets. The ZTNA gateway 208 also determines whether protected private service 210 traffic needs to be inspected by the IPS engine 212. The ZTNA gateway 208 also creates a unique SNI token and returns the unique SNI token to the endpoint client 206 at 230.

[0073] At 518, the endpoint client-based proxy continues the browser's access to the protected private service. For example, once the tunnel is established, at 238, the endpoint client 206 continues or unmasks the browser traffic and encapsulates the TLS client hello packet from the browser 204.

[0074] Therefore, according to the configuration described in this article, only one level of encryption is involved at any time. Unique SNI tokens are generated on a per-app per-user per-session basis. This ensures that an observer cannot see which services are being accessed behind the gateway or which services are protected by the gateway. Because only one level of encryption is used at any time, the computational requirements are reduced. Compared to double encryption mechanisms, latency and throughput are also improved and can be scaled to higher levels. In addition, the cost of null encryption and decryption is close to zero, thus saving precious computing resources.

[0075] Figure 6 An example computer architecture of a computing device 600 capable of executing program components for implementing the above-described functions is shown. In a configuration, one or more computing devices 600 may be used to implement Figures 1 to 5 One or more components in the components. Figure 6 The computer architecture shown shows a traditional server computer, router, switch, workstation, desktop computer, laptop computer, tablet computer, network equipment, e-reader, smart phone or other computing device, and can be used to execute any software components presented herein.In some examples, computing device 600 can correspond to a physical device or resource described herein.

[0076] The computing device 600 includes a baseboard (or "motherboard") 602, which is a printed circuit board to which many components or devices may be connected via a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") 604 operate in conjunction with a chipset 606. The CPUs 604 may be standard programmable processors that perform the arithmetic and logic operations necessary for the operation of the computing device 600.

[0077] The CPU 604 performs operations by transitioning from one discrete physical state to the next, where the state transitions are achieved by manipulating switching elements that distinguish and change these states. Switching elements generally include electronic circuits that maintain one of two binary states, such as flip-flops, and electronic circuits that provide output states based on logical combinations of the states of one or more other switching elements, such as logic gates. These basic switching elements can be combined to create more complex logic circuits, including registers, adders and subtractors, arithmetic logic units, floating point units, and the like.

[0078] Chipset 606 provides an interface between CPU 604 and the remaining components and devices on substrate 602. Chipset 606 may provide an interface to RAM 608, which is used as main memory in computing device 600. Chipset 606 may also provide an interface to a computer-readable storage medium, such as read-only memory ("ROM") 610 or non-volatile RAM ("NVRAM"), for storing basic routines that help boot computing device 600 and transfer information between various components and devices. ROM 610 or NVRAM may also store other software components necessary for the operation of computing device 600 according to the configuration described herein.

[0079] The computing device 600 can operate in a networked environment using logical connections to remote computing devices and computer systems through a network. The chipset 606 can include functionality to provide network connectivity through a NIC 612 (e.g., a Gigabit Ethernet adapter). In a configuration, the NIC 612 is a smart NIC (based on a data processing unit (DPU)) that can be inserted into a data center server to provide networking capabilities. The NIC 612 is capable of connecting the computing device 600 to other computing devices through a network. It should be understood that multiple NICs 612 can be present in the computing device 600, connecting the computer to other types of networks and remote computer systems.

[0080] The computing device 600 may include a storage device 618 that provides non-volatile storage for the computer. The storage device 618 may store an operating system 620, programs 622, and data, which have been described in detail herein. The storage device 618 may be connected to the computing device 600 via a storage controller 614 connected to the chipset 606. The storage device 618 may be composed of one or more physical storage units. The storage controller 614 may be connected to the physical storage unit via a serial attached SCSI ("SAS") interface, a serial advanced technology attachment ("SATA") interface, a fiber channel ("FC") interface, or other types of interfaces for physically connecting and transmitting data between a computer and a physical storage unit.

[0081] The computing device 600 can store data on the storage device 618 by transforming the physical state of the physical storage unit to reflect the information being stored. In different embodiments of the present specification, the specific transformation of the physical state may depend on various factors. Examples of such factors may include, but are not limited to, the technology used to implement the physical storage unit, whether the storage device 618 is characterized as a primary storage or an auxiliary storage device, etc.

[0082] For example, the computing device 600 can store information to the storage device 618 by issuing instructions through the storage controller 614 to change the magnetic properties of a specific location in the disk drive unit, the reflective or refractive properties of a specific location in the optical storage unit, or the electrical properties of a specific capacitor, transistor, or other discrete component in the solid-state storage unit. Other transformations of the physical medium are possible without departing from the scope and spirit of the present specification, and the foregoing examples are provided only for convenience of illustration. The computing device 600 can also read information from the storage device 618 by detecting the physical state or properties of one or more specific locations in the physical storage unit.

[0083] In addition to the mass storage device 618 described above, the computing device 600 may also access other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be understood by those skilled in the art that a computer-readable storage medium is any available medium that provides non-transitory storage of data and can be accessed by the computing device 600. In some examples, the operations performed by the cloud network and / or any components included therein may be supported by one or more devices similar to the computing device 600. In other words, some or all of the operations described herein may be performed by one or more computing devices 600 running in a cloud-based arrangement.

[0084] As an example, and not a limitation, computer-readable storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology. Computer-readable storage media include, but are not limited to, RAM, ROM, erasable programmable ROM ("EPROM"), electrically erasable programmable ROM ("EEPROM"), flash memory or other solid-state memory technology, compact disk ROM ("CD-ROM"), digital versatile disk ("DVD"), high-definition DVD ("HD-DVD"), BLU-RAY or other optical storage devices, cassettes, magnetic tapes, disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.

[0085] As briefly mentioned above, the storage device 618 may store an operating system 620 that is used to control the operation of the computing device 600. According to one embodiment, the operating system comprises a LINUX operating system. According to another embodiment, the operating system comprises an LINUX operating system from MICROSOFT Corporation of Redmond, Washington. SERVER operating system. According to another embodiment, the operating system may include a UNIX operating system or one of its variants. It should be understood that other operating systems may also be utilized. Storage device 618 may store other systems or applications and data utilized by computing device 600.

[0086] In one embodiment, the storage device 618 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into the computing device 600, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. As described above, these computer-executable instructions transform the computing device 600 by specifying how the CPU 604 transitions between states. According to one embodiment, the computing device 600 is able to access a computer-readable storage medium storing computer-executable instructions that, when executed by the computing device 600, perform the above-described Figures 1 to 5 The computing device 600 may also include a computer-readable storage medium having stored thereon instructions for performing any other computer-implemented operations described herein.

[0087] The computing device 600 may also include one or more input / output controllers 616 for receiving and processing input from a number of input devices (e.g., a keyboard, a mouse, a touch pad, a touch screen, an electronic stylus, or other types of input devices). Similarly, the input / output controller 616 may provide output to a display, such as a computer monitor, a flat panel display, a digital projector, a printer, or other types of output devices. It will be appreciated that the computing device 600 may not include Figure 6 All components shown in the Figure 6 Other components not explicitly shown may be used in conjunction with Figure 6 A completely different architecture is shown in .

[0088] The computing device 600 may support a virtualization layer, such as one or more virtual resources executing on the computing device 600. In some examples, the virtualization layer may be supported by a hypervisor that provides one or more virtual machines running on the computing device 600 to perform the functions described herein. The virtualization layer may generally support virtual resources that perform at least a portion of the techniques described herein.

[0089] In summary, techniques and architectures for eliminating double encryption in a zero trust network access authenticated session are described. The techniques include an endpoint client-based agent of a network receiving a request from a browser to access a protected private service. The endpoint client-based agent suspends the browser's access to the protected private service and establishes a Transport Layer Security (TLS) connection between the endpoint client-based agent and a zero trust network access (ZTNA) gateway. The ZTNA gateway determines whether the protected private service uses a secure transport mechanism and establishes a null password encrypted tunnel between at least the endpoint client-based agent and the ZTNA gateway, or a non-null password encrypted tunnel between at least the endpoint client-based agent and the ZTNA. The endpoint client-based agent continues the browser's access to the protected private service.

[0090] Although the present invention has been described with respect to specific embodiments, it should be understood that the scope of the present invention is not limited to these specific examples. Since other modifications and changes made to adapt to specific operating requirements and environments are obvious to those skilled in the art, the present invention is not considered to be limited to the examples selected for the purpose of disclosure, and covers all changes and modifications that do not constitute a departure from the true spirit and scope of the present invention.

[0091] Although the present application describes embodiments with specific structural features and / or method actions, it is to be understood that the claims are not necessarily limited to the specific features or actions described. Instead, the specific features and actions are only some embodiments within the scope of the claims of the present application.

Claims

1. A method comprising: A request for accessing a protected private service is received by an endpoint client-based agent in the network from a browser; Suspending, by the endpoint client-based agent, access by the browser to the protected private service; authenticating the user of the browser by the endpoint client-based agent; Establishing, by the endpoint client-based agent, a Transport Layer Security (TLS) connection between the endpoint client-based agent and a Zero Trust Network Access (ZTNA) gateway; Determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected; One of the following: establishing, by the ZTNA gateway, a null-password encrypted tunnel between at least the endpoint client-based proxy and the ZTNA gateway based at least in part on a determination by the ZTNA gateway that the protected private service utilizes a secure transport mechanism, or establishing, by the ZTNA gateway, a non-null password encrypted tunnel between at least the endpoint client-based proxy and the ZTNA gateway based at least in part on a determination by the ZTNA gateway that the protected private service uses a non-secure transport mechanism; as well as Access to the protected private service by the browser is continued by the endpoint client-based proxy.

2. The method of claim 1, wherein the ZTNA gateway determines that traffic between the browser and the protected private service needs to be inspected, the method further comprising: Traffic between the browser and the protected private service is inspected by an intrusion prevention service (IPS) engine.

3. The method of claim 2, wherein the ZTNA gateway determines that the protected private service uses the secure transport mechanism, the method further comprising: A null-password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

4. The method of claim 2, wherein the ZTNA gateway determines that the protected private service uses the non-secure transport mechanism, the method further comprising: A non-null password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

5. The method according to any one of claims 1 to 4, wherein the ZTNA gateway determines that traffic between the browser and the protected private service does not need to be inspected, the method further comprising: A null-password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

6. The method according to any one of claims 1 to 5, wherein determining that traffic between the browser and the protected private service needs to be inspected comprises: A determination is made by the ZTNA gateway whether traffic between the browser and the protected private service needs to be inspected based at least in part on a subject name and issuer (SNI) token associated with the protected private service.

7. The method according to claim 6, further comprising: A unique SNI token is generated by the ZTNA gateway; as well as providing the unique SNI token by the ZTNA gateway to the endpoint client-based proxy, Continuing the browser's access to the protected private service includes: replacing the SNI token associated with the protected private service in the client hello data packet with the unique SNI token.

8. The method according to claim 7, further comprising: replacing, by the ZTNA gateway, the unique SNI token in the client hello packet with an SNI token associated with the protected private service; as well as The client hello packet with the SNI token associated with the protected private service is forwarded by the ZTNA gateway to the protected private service.

9. A system comprising: one or more processors; as well as One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform actions comprising: A request for accessing a protected private service is received by an endpoint client-based agent in the network from a browser; Suspending, by the endpoint client-based agent, access by the browser to the protected private service; authenticating the user of the browser by the endpoint client-based agent; Establishing, by the endpoint client-based agent, a Transport Layer Security (TLS) connection between the endpoint client-based agent and a Zero Trust Network Access (ZTNA) gateway; Determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected; One of the following: establishing, by the ZTNA gateway, a null-password encrypted tunnel between at least the endpoint client-based proxy and the ZTNA gateway based at least in part on a determination by the ZTNA gateway that the protected private service utilizes a secure transport mechanism, or Based at least in part on a determination by the ZTNA gateway that the protected private service uses a non-secure transport mechanism, establishing by the ZTNA gateway a non-null password encrypted tunnel between at least the endpoint client-based proxy and the ZTNA gateway; and Access to the protected private service by the browser is continued by the endpoint client-based proxy.

10. The system of claim 9, wherein the ZTNA gateway determines that traffic between the browser and the protected private service needs to be inspected, the actions further comprising: Traffic between the browser and the protected private service is inspected by an intrusion prevention service (IPS) engine.

11. The system of claim 10, wherein the ZTNA gateway determines that the protected private service uses the secure transport mechanism, the actions further comprising: A null-password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

12. The system of claim 10, wherein the ZTNA gateway determines that the protected private service uses the non-secure transport mechanism, the actions further comprising: A non-null password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

13. The system of any one of claims 9 to 12, wherein the ZTNA gateway determines that traffic between the browser and the protected private service does not need to be inspected, the actions further comprising: A null-password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

14. The system according to any one of claims 9 to 13, wherein determining whether traffic between the browser and the protected private service needs to be inspected comprises: Determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected based at least in part on a Subject Name and Issuer (SNI) token associated with the protected private service.

15. The system of claim 14, wherein the actions further comprise: A unique SNI token is generated by the ZTNA gateway; as well as providing the unique SNI token by the ZTNA gateway to the endpoint client-based proxy, Continuing the browser's access to the protected private service includes: replacing the SNI token associated with the protected private service in the client hello data packet with the unique SNI token.

16. The system of claim 15, wherein the actions further comprise: replacing, by the ZTNA gateway, the unique SNI token in the client hello packet with an SNI token associated with the protected private service; as well as The client hello packet with the SNI token associated with the protected private service is forwarded by the ZTNA gateway to the protected private service.

17. One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform actions comprising: A request for accessing a protected private service is received by an endpoint client-based agent in the network from a browser; Suspending, by the endpoint client-based agent, access by the browser to the protected private service; authenticating the user of the browser by the endpoint client-based agent; Establishing, by the endpoint client-based agent, a Transport Layer Security (TLS) connection between the endpoint client-based agent and a Zero Trust Network Access (ZTNA) gateway; Determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected; One of the following: establishing, by the ZTNA gateway, a null-password encrypted tunnel between at least the endpoint client-based proxy and the ZTNA gateway based at least in part on a determination by the ZTNA gateway that the protected private service utilizes a secure transport mechanism, or establishing, by the ZTNA gateway, a non-null password encrypted tunnel between at least the endpoint client-based proxy and the ZTNA gateway based at least in part on a determination by the ZTNA gateway that the protected private service uses a non-secure transport mechanism; as well as Access to the protected private service by the browser is continued by the endpoint client-based proxy.

18. The one or more non-transitory computer-readable media of claim 17, wherein the ZTNA gateway determines that traffic between the browser and the protected private service needs to be inspected, the actions further comprising: Traffic between the browser and the protected private service is inspected by an intrusion prevention service (IPS) engine.

19. The one or more non-transitory computer-readable media of claim 18, wherein the ZTNA gateway determines that the protected private service uses a secure transport mechanism, the actions further comprising: A null-password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

20. The one or more non-transitory computer-readable media of claim 18, wherein the ZTNA gateway determines that the protected private service uses a non-secure transport mechanism, the actions further comprising: A non-null password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway is established by the ZTNA gateway.

21. An apparatus comprising: Means for receiving, by an endpoint client-based proxy in a network, a request from a browser to access a protected private service; means for suspending, by the endpoint client-based agent, access by the browser to the protected private service; means for authenticating, by the endpoint client-based proxy, a user of the browser; means for establishing, by the endpoint client-based agent, a Transport Layer Security (TLS) connection between the endpoint client-based agent and a Zero Trust Network Access (ZTNA) gateway; module for determining, by the ZTNA gateway, whether traffic between the browser and the protected private service needs to be inspected; Module for establishing any of the following tunnels by the ZTNA gateway: Based at least in part on a determination by the ZTNA gateway that the protected private service uses a secure transport mechanism, at least a null password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway, or Based at least in part on a determination by the ZTNA gateway that the protected private service utilizes a non-secure transport mechanism, at least a non-null password encrypted tunnel between the endpoint client-based proxy and the ZTNA gateway; as well as Means for continuing, by the endpoint client-based proxy, access by the browser to the protected private service.

22. The apparatus of claim 21, further comprising a module for implementing the method of any one of claims 2 to 8.

23. A computer program, a computer program product or a computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 8.

Images