Protecting non-HTTP and TCP / UDP applications in ZTNA / WEBVPN environments

Abstract

Techniques and architectures are described for protecting non-http and TCP / UDP applications in a zero trusted network access (ZTNA) / web virtual private network (VPN) environment by establishing a secure communication channel between a native application and an application server that provides application services. More specifically, this disclosure describes techniques and architectures that utilize a firewall in which a thin client on a client device enables a client desktop, establishes a secure channel from a native application (e.g., a client desktop) to the firewall, and acts as a proxy.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to U.S. patent application No. 17 / 866,871, filed on July 18, 2022, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to protecting non-http and TCP / UDP applications in a Zero Trust Network Access (ZTNA) / web Virtual Private Network (VPN) environment, and more particularly to establishing a secure communication channel between a native application and an application server providing application services. Background Art

[0004] There are two main types of web (e.g., Internet) access: Hypertext Transfer Protocol (HTTP) and non-HTTP. All web content using HTTP is usually direct. Other web content access can use the Transmission Control Protocol (TCP). The challenge of ZTNA / webVPN is to try to continuously ensure that access is authenticated because access needs to be authenticated at each step. The previous web access process on a web browser (such as remote desktop applications) placed a heavy burden on the network gateway.

[0005] Specifically, a typical ZTNA / webVPN setup usually caters to HTTPs (Hypertext Transfer Protocol Security) applications, where HTTP traffic carries authentication cookies / tokens, each access request is first verified at the gateway, and then the authenticated traffic is allowed to go to the end application server. Typically, for non-HTTP / regular TCP or User Datagram Protocol (UDP) applications, access is first authenticated via HTTP using a web browser, and then a tunnel is created over HTTPs for transmitting such application traffic. This setup requires an HTTPs server on the gateway, which needs to decapsulate the HTTP traffic, verify the cookie for authentication, and then route the traffic to the end application server. On the reverse path, the HTTPs server on the gateway needs to encapsulate the traffic and then route it to the client. This process is expensive due to the decapsulation of HTTP, verification of cookies, and routing of traffic. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] The detailed description is set forth below with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of a reference number identifies 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] Figures 1A to 1D An example network arrangement of a portion of a network for establishing a secure communication channel between a native application and an application server providing application services according to aspects of the present disclosure is schematically illustrated.

[0008] Figure 2 An example workflow for establishing a secure communication channel between a native application and an application server providing application services according to aspects of the present disclosure is schematically illustrated.

[0009] Figure 3 A flow chart illustrating an example method for establishing a secure communication channel between a native application and an application server providing application services.

[0010] Figure 4 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

[0011] Overview

[0012] 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 the other aspects.

[0013] The present disclosure describes techniques and architectures for protecting non-http and TCP / UDP applications in a zero-trust network access (ZTNA) / web virtual private network (VPN) environment by establishing a secure communication channel between a native application and an application server providing application services. More specifically, the present disclosure describes techniques and architectures for utilizing a firewall, wherein a thin client on a client device enables a client desktop, establishes a secure channel from a native application (e.g., a client desktop) to the firewall, and acts as a proxy.

[0014] Specifically, in response to the browser on the client device using an application to access a non-HTTP-based service, the technology and architecture described herein provide a certificate and key pair generated by an authentication server or service. The authentication server can be used as a certificate authority (CA) / sub-CA, generate a private key, and sign a certificate. The authentication server also generates a cookie, and uses the cookie to encrypt the certificate and key pair. The certificate and key pair are provided to the browser together with the cookie. The authentication server can also provide a profile with the details of the endpoint application server after the network gateway to the browser. In the configuration, the certificate, key, cookie and profile are provided to the browser using Security Assertion Markup Language (SAML) redirection, but these technologies and architectures are not limited to SAML redirection, and other mechanisms can be used in other configurations. Therefore, the network gateway is before the endpoint device (e.g., application server) that provides the service.

[0015] In a configuration, a certificate and key pair are provided (e.g., pushed) along with a cookie to a network gateway (e.g., a firewall service at the network gateway (hereinafter referred to as a "firewall")). The firewall has a trust relationship with an authentication server and accepts a certificate generated by the authentication server. The authentication server may also provide the firewall with a profile with details of the endpoint service, and certificate details and a user identification (ID) related to an authenticated user associated with a client device. In a configuration, the certificate details may include a certificate number (e.g., a certificate ID) and a time limit for the certificate. Because the certificate may be stolen, in a configuration, the certificate can only be used once and is only valid for a predetermined or configurable amount of time.

[0016] In the configuration, as an example, a user wishes to access Remote Desktop Protocol (RDP) as a non-HTTP based service. The user uses a browser including a plug-in / extension on a client device to access RDP. Alternatively, the user can also invoke an RDP client application, which attempts to connect to the RDP service, and the traffic is intercepted by a thin client that launches a browser to initiate a connection to the RDP service.

[0017] The authentication server verifies the user's credentials and returns three items to the endpoint browser via HTTPs: a cookie; an RDP profile with details of the endpoint service (application server) behind the firewall; and a new certificate and key pair signed by the authentication server. The generated cookie is used to protect the private key. The certificate has limited validity (perhaps minutes or hours) and may only be used once. The certificate may also have details of which application the user will access in that session.

[0018] The browser extension detects the certificate and key pair and calls or passes the certificate and key pair along with the cookie to the thin client on the client device. The thin client is configured to tunnel traffic from the application on the client device to the firewall. Typically, a VPN is used and a corporate IP address is used whenever the client device connects to corporate resources. The thin client does not do this. Instead, the thin client establishes a secure session, e.g., a secure channel or tunnel, for a specific application. Only traffic from that specific application can use the secure channel created by the thin client. Therefore, other applications will use the thin client to create their own secure sessions, e.g., secure channels or tunnels using their own certificates and keys.

[0019] The thin client decrypts the certificate and key pair using the cookie and connects to the firewall along with the certificate via a secure session (e.g., via mutual transport layer security (mTLS)). The firewall checks the validity of the certificate and, if valid, establishes a secure session, such as an mTLS channel, between the thin client and the firewall. For example, the firewall can use the certificate serial number, identification, etc. to verify and track the certificate and whether it has been used. For example, the firewall can maintain a database of certificates and once a certificate has been used, the firewall can remove the certificate from the database.

[0020] After mTLS is established, the browser extension calls the native client application (e.g., in this example, the RDP viewer) on the client device that needs to connect to the endpoint application server behind the firewall. The call is completed in a way that the RDP client connects to the local port served by the thin client on the client device. For example, the thin client opens a local proxy channel. The RDP application traffic received by the thin client through the local proxy channel is then placed on a tunnel (e.g., an mTLS channel) and securely transmitted to the firewall, where it is decapsulated and routed directly to the RDP server (endpoint application server) after appropriate inspection on the firewall. In an alternative scenario where the RDP application is first started and the browser authentication sequence is triggered, the extension can transmit details of the local port to which the RDP application on the client device should connect to the RDP application.

[0021] When the user quits using the service (RDP service in this example), the secure channel between the thin client and the firewall is terminated. If the user wishes to use the service again, a new certificate and key pair are obtained, and the process described in this article is repeated.

[0022] Although the use of cookies has been described, there are other ways to generate an mTLS session between a thin client and a firewall. For example, a pre-shared mechanism, such as a key, may be used.

[0023] As an example, a method may include: authenticating a client device by an authentication server for accessing a network to obtain a network service. The method may also include: generating a certificate and a key by the authentication server at least in part based on the authentication. The method may also include: providing the certificate and the key by the authentication server to the client device. The method may additionally include: providing the certificate and the key by the authentication server to a gateway located before the endpoint device providing the network service. The method may also include: initiating a secure session by a thin client on the client device by providing at least the certificate and the key to the gateway. The method may also include: verifying the certificate and the key provided by the thin client by the gateway. The method may also include: establishing a secure session between the thin client on the client device and the gateway based at least in part on the certificate and the key. The method may also include: launching a native application on the client device. The method may also include: providing a local proxy channel between the thin client and the native application. The method may additionally include: routing traffic between the native application and the endpoint device via the thin client through the secure session and the local proxy channel.

[0024] In a configuration, the method may further include: generating a cookie by the authentication server. In such a configuration, the method may further include: encrypting the certificate and key by the authentication server with the cookie before providing the certificate and key to the client device, and providing the certificate and key together with the cookie to the client device by the authentication server. In such a configuration, the method may additionally include: decrypting the certificate and key by the thin client using the cookie before initiating a secure session between the thin client on the client device and the gateway.

[0025] In the configuration, the method may further include: providing, by the authentication server, the certificate and the key together with the cookie to the gateway, and decrypting, by the gateway, the certificate and the key using the cookie.

[0026] In an arrangement, the certificate has a limited validity based at least in part on an amount of time.

[0027] In an arrangement, providing the certificate and key to the gateway further comprises providing certificate details to the gateway, and the method may further comprise determining the validity of the certificate based at least in part on the certificate details.

[0028] In an arrangement, the certificate details include a certificate identification (ID), and determining the validity of the certificate includes determining, based at least in part on the certificate ID, whether the certificate has been previously provided to the gateway by an entity other than the authentication server.

[0029] In an arrangement, determining whether the certificate has been previously provided to the gateway by an entity other than the authentication server comprises searching a database for the certificate ID.

[0030] In a configuration, the method may further include storing, by the gateway, the certificate ID in a database upon receiving the certificate from the authentication server, and removing the certificate ID from the database based at least in part on verifying, by the gateway, the certificate and key provided by the thin client.

[0031] In a configuration, the method may further include establishing a trusted relationship between the thin client and the gateway via a pre-sharing mechanism before initiating a secure session by the thin client by providing at least a certificate and a key to the gateway.

[0032] Thus, the techniques and architectures described herein enable secure remote access to non-HTTP and legacy applications on non-managed clients (as well as access to other network services) over mTLS connections based on single-use certificates and key pairs. The techniques and architectures described herein leverage existing firewalls as gateways to terminate mTLS connections and forward traffic to backend application servers. The techniques and architectures described herein provide a unique way to authenticate non-HTTP client connections. The techniques and architectures described herein provide low performance overhead because the gateway (firewall) does not need to verify cookies when creating and protecting connections using mTLS.

[0033] The techniques described herein may be performed by a system and / or device having a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors, perform the methods described above.

[0034] Example Embodiments

[0035] Certain implementations and embodiments of the present disclosure will now be described more fully below with reference to the accompanying drawings, in which various aspects are shown. However, various aspects may be implemented in many different forms and should not be construed as being limited to the implementations set forth herein. As described herein, the present disclosure encompasses variations of the embodiments. Similar reference numerals refer to similar elements throughout.

[0036] Figure 1AA portion of a network 100 is schematically shown. The network 100 includes a user 102, who uses a client device 104 to access and / or obtain network services or applications from one or more servers 106 at a data center 108. The data center 108 is located behind a gateway 110, which includes a firewall service 112 (hereinafter referred to as "firewall" 112). The user 102 and / or the client device 104 can be authenticated by an authentication service or server 114, which can be located, for example, in the cloud, or can be part of an enterprise's locally deployed network. The client device 104 includes a thin client 116, which can be used to interact with the firewall 112 via a secure session, as will be further described herein. The network 100 can represent a structured network, an extended network, or an external network.

[0037] refer to Figure 1B , user 102 wants to access a network service or application, such as a remote desktop protocol (RDP) service. The RDP service may be provided by one or more servers 106 at a data center 108. User 102 utilizes a client device 104 including, for example, a browser 118 thereon. User 102 utilizes client device 104 to initiate and / or request authentication from authentication service 114, which may be in the form of one or more servers. When authenticating user 102 and / or client device 104, authentication service 114 generates a certificate and key pair 120. In a configuration, authentication service 114 also generates a cookie 122, which is used to encrypt certificate and key pair 120. Authentication service 114 provides encrypted certificate and key pair 120 to client device 102 together with cookie 122. In a configuration, encrypted certificate and key pair 120 together with cookie 122 are sent from authentication service 114 to client device 104 using Security Assertion Markup Language (SAML) redirection.

[0038] In the configuration, the authentication service 114 pushes the encrypted certificate and key pair 120 along with the cookie 122 to the firewall 112 at the gateway 110. In the configuration, the authentication service 114 also pushes the user identification (ID), the ID of the network service or application, and the certificate details (e.g., certificate ID (serial number), time validity of the certificate, etc.) to the firewall. In the configuration, the authentication service 114 can push the encrypted certificate and key pair 120 along with the cookie 122 to the firewall 112 at the gateway 110, and the authentication service 114 provides the encrypted certificate and key pair 120 along with the cookie 122 to the client device 102. The gateway 110 and the firewall 112 are in front of the data center 108, which includes one or more servers 106 (e.g., endpoint application servers) that provide network services (e.g., RDP services).

[0039] refer to Figure 1C , the browser 118 on the client device 104 includes a plug-in or extension 124. The extension 124 detects the encrypted certificate and key 120 and the cookie 122. The extension 124 provides the encrypted certificate and key pair 120 along with the cookie 122 to the thin client 116. The thin client 116 decrypts the certificate and key pair 120 using the cookie 122. The thin client 116 operates as a background service on the desktop of the client device 104 itself and is able to establish a secure channel or session with the firewall 112 while also acting as a local proxy on the desktop of the client device 104. Thus, the plug-in or extension 124 on the browser 118 interacts with and launches the thin client 116.

[0040] The thin client 116 initiates a secure session with the firewall 112 using the certificate and key pair 120. The firewall 112 verifies (eg, validates) the certificate and then establishes a secure session with the thin client 116. In a configuration, the secure session is a mutual transport layer security (mTLS) channel.

[0041] refer to Figure 1D, after the mTLS channel is established, the extension 124 calls a native client application 126 (e.g., an RDP viewer) on the client device 104 that needs to connect to the endpoint application server(s) 106 in the data center 108 to obtain a network service or application (e.g., an RDP service). The thin client 116 then opens a local proxy channel 128 and instructs the native application 126 (e.g., the RDP viewer) to connect to the proxy channel 128. The native application 126 now provides traffic from the client device 104 to the thin client 116 that is destined for the endpoint application server(s) 106. The thin client 116 places the traffic on the mTLS channel and forwards it to the firewall 112. The firewall 112 decrypts the traffic and provides it to the endpoint application server(s) 106. The endpoint application server(s) may also provide return traffic to the firewall 112, which encrypts the traffic and places it on the mTLS channel to provide it to the thin client 116. The thin client 116 may decrypt the traffic and provide it over the proxy channel 128 to the native application 126 (eg, an RDP viewer).

[0042] Once the session is terminated, in order to connect again with the (one or more) endpoint application servers 106, the client device 106 repeats the steps described herein (e.g., being authenticated by the authentication service 114 and obtaining a new certificate and key, and a cookie that encrypts the new certificate and key pair). In a configuration, each certificate may be valid only for a predetermined amount of time (e.g., one to three minutes). A longer period of time or a shorter period of time may also be used for the validity of the certificate. In addition, in a configuration, a certificate can only be used once. Therefore, in a configuration, the firewall 112 may maintain a database 130 of certificates received from the authentication service 114. Once a certificate has been used, the firewall 112 may delete the certificate from the database 130. Therefore, in order to verify the certificate received from the thin client 116, the firewall 112 may search the database 130. If the certificate exists in the database 130, the firewall 112 (assuming that the certificate has not expired due to a time limit) realizes that the certificate is valid and establishes an mTLS session with the thin client 116. The firewall 112 may then delete the certificate from the database 130. However, if the certificate does not exist within database 130, firewall 112 recognizes that the certificate has been used and does not establish the mTLS session.

[0043] refer to Figure 2, a workflow diagram 200 for establishing a secure communication channel between a native application and an application server providing an application service according to aspects of the present disclosure begins at 202, where a user (e.g., user 102) wishes to establish a session with an endpoint application server (s) 106 behind a firewall 112 using a browser (e.g., browser 118). At 204, the user 102 and / or client device 104 is authenticated by an authentication service 114 over an HTTP stream. The authentication may be via, for example, a multi-step authentication.

[0044] At 206, the authentication service 114 generates a certificate and key pair 120 and a cookie 122. At 208, the authentication service 114 encrypts the certificate and key pair 120 using the cookie 122. At 210, the authentication service 114 sends the encrypted certificate and key pair 120 along with the cookie 122 from the authentication service 114 to the browser 118 on the client device 104 using Security Assertion Markup Language (SAML) redirection, and at 212, the authentication service 114 pushes the encrypted certificate and key pair 120 along with the cookie 122 to the firewall 112 at the gateway 110. The authentication service 114 also pushes the user identification (ID), the ID of the network service or application, and the certificate details (e.g., certificate ID (serial number), time validity of the certificate, etc.) to the firewall. In a configuration, the authentication service 114 can push the encrypted certificate and key pair 120 along with the cookie 122 to the firewall 112 at the gateway 110 , while the authentication service 114 provides the encrypted certificate and key pair 120 along with the cookie 122 to the client device 102 .

[0045] At 214, the thin client uses the cookie 118 to decrypt the certificate and key pair 120. At 216, the thin client 116 uses the certificate and key pair 120 to initiate a secure session with the firewall 112. At 218, the firewall 112 verifies the certificate and key pair 120 and then establishes a secure session with the thin client 116, e.g., to verify that the certificate was previously used, to expire the certificate, etc. In a configuration, the secure session is a mutual transport layer security (mTLS) channel. Typically, the firewall 112 trusts the certificate and key pair 120 because the certificate and key pair 120 are generated by the authentication service 114.

[0046] At 220, the extension 124 calls a native client application 126 (e.g., RDP or Secure Shell (SSH) protocol on the client device 104) that needs to connect to the endpoint application server(s) 106 in the data center 108 to obtain a network service or application (e.g., an RDP service). Then, at 222, the thin client 116 opens a local proxy channel 128 and instructs the native application 126 to connect to the proxy channel 128. At 224, the native application 126 now provides traffic from the client device 104 to the thin client 116 that is destined for the endpoint application server(s) 106. At 226, the thin client 116 places the traffic on the mTLS channel and forwards it to the firewall 112. At 228, the firewall 112 decrypts the traffic and provides it to the endpoint application server(s) 106. At 230, the endpoint application server(s) may also provide return traffic to the firewall 112, which encrypts the traffic and places it on the mTLS channel to provide it to the thin client 116 at 232. At 234 , the thin client 116 may decrypt the traffic and provide it to the native application 126 (eg, an RDP viewer) over the proxy channel 128 .

[0047] Therefore, in response to the browser 118 on the client device 104 using the application to access the non-HTTP based service, the technology and architecture described herein provide a certificate and key pair 120 generated by the authentication service 114. The authentication service 114 can act as a certificate authority (CA) / sub-CA, generate private keys, and sign certificates. The authentication service 114 also generates a cookie 122 and uses the cookie 122 to encrypt the certificate and key pair 120.

[0048] The certificate and key pair 120 is provided to the browser 118 along with the cookie 122. The authentication service 114 may also provide a profile with details of the endpoint application server(s) 106 behind the firewall 112 to the browser 118. In the configuration, the certificate, key, cookie, and profile are provided to the browser using Security Assertion Markup Language (SAML) redirection. Thus, the firewall is in front of the endpoint device (e.g., endpoint application server(s) 106) that provides the desired network service.

[0049] In the configuration, the certificate and key pair 120 is provided (e.g., pushed) to the firewall 112 at the network gateway 110 along with the cookie 122. The firewall 112 has a trust relationship with the authentication service 114 and accepts the certificate generated by the authentication service 114. The authentication service 114 may also provide the firewall 112 with a profile with details of the endpoint service, and certificate details and a user identification (ID) related to the authenticated user 102 associated with the client device 104. In the configuration, the certificate details may include a certificate number (e.g., certificate ID) and a time limit for the certificate. Because the certificate may be stolen, in the configuration, the certificate can only be used once and is only valid for a predetermined amount of time.

[0050] In the configuration, as an example, user 102 wishes to access Remote Desktop Protocol (RDP) as a non-HTTP based service at endpoint application server(s) 106. The user uses browser 118 including plug-in / extension 124 on client device 104 to access the RDP service.

[0051] The authentication service 114 verifies the credentials of the user 102 and returns the following three items to the endpoint browser via HTTPs: a cookie 122; an RDP profile with details of the endpoint service (application server(s) 106) behind the firewall 112; and a new certificate and key pair 120 signed by the authentication server. The generated cookie 122 is used to protect the private key. The certificate has a limited validity (perhaps a few minutes or hours) and can only be used once. The certificate may also have details of which application the user 102 will access in this session.

[0052] The browser extension 124 detects the certificate and key pair 120 and calls or passes the certificate and key pair 120 along with the cookie 122 to the thin client 116 on the client device 104. The thin client 116 is configured to tunnel traffic from applications on the client device 104 to the firewall 112. Typically, whenever the client device 104 connects to corporate resources, a VPN is used and a corporate IP address is used. The thin client 116 does not do this. Instead, the thin client 116 establishes a secure session, e.g., a secure channel or tunnel, for a specific application. Only traffic from that specific application can use the secure channel created by the thin client 116. Therefore, other applications will use the thin client 116 to create their own secure sessions, e.g., secure channels or tunnels, using their own certificates and keys.

[0053] The thin client 116 decrypts the certificate and key pair 120 using the cookie 122 and connects to the firewall 112 along with the certificate via a secure session (e.g., via mutual transport layer security (mTLS)). The firewall 112 checks the validity of the certificate and, if valid, establishes a secure session, such as an mTLS channel, between the thin client 116 and the firewall 112. For example, the firewall 112 can use the certificate serial number, identification, etc. to verify and track the certificate and whether it has been used. For example, the firewall 112 can maintain a database 130 of certificates and once a certificate has been used, the firewall 112 can remove the certificate from the database 130.

[0054] After mTLS is established, the browser extension 124 calls a native client application 126 (e.g., in this example, an RDP viewer) on the client device 104 that needs to connect to the (one or more) endpoint application servers 106 behind the firewall 112. The call is completed in the manner that the RDP client (viewer) connects to the local port served by the thin client 116 on the client device 104. For example, the thin client 116 opens a local proxy channel 128. Then, the RDP application traffic received by the thin client 116 through the local proxy channel 128 is placed on the tunnel (e.g., the mTLS channel) and is securely transmitted to the firewall 112, where it is decapsulated and routed directly to the RDP server ((one or more) endpoint application servers 106) after appropriate inspection on the firewall 112. The return traffic from the RDP server ((one or more) endpoint application servers 106) is forwarded to the firewall 112, which encrypts the return traffic and places the encrypted traffic on the tunnel (e.g., the mTLS channel destined for the thin client 116). The thin client 116 decrypts the return traffic and places the return traffic on the proxy channel 128 destined for the native application 126 (eg, RDP viewer).

[0055] When user 102 quits using the service (RDP service in this example), the secure channel between thin client 116 and firewall 112 is terminated. If user 102 wishes to use the service again, a new certificate and key pair is obtained and the process described herein is repeated.

[0056] Although the use of cookies 122 has been described, there are other ways to generate an mTLS session between the thin client 116 and the firewall 112. For example, a pre-shared mechanism, such as a key, may be used.

[0057] Figure 3 A flowchart of an example method 300 is shown and is provided at least in part by reference to Figures 1A to 1D as well as Figure 2 The network devices of the described network perform various aspects of the functions. Figure 4 The logical operations described 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.

[0058] 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 3 , 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.

[0059] Figure 3 A flowchart of an example method 300 for establishing a secure communication channel between a native application and an application server providing application services is shown. In some examples, the method 300 can be performed by a system including one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions, which, when executed by the one or more processors, cause the one or more processors to perform the method 300.

[0060] At 302, a client device is authenticated by an authentication service for accessing a network to obtain network services. For example, user 102 utilizes client device 104 to initiate and / or request authentication from authentication service 114, which may be in the form of one or more servers.

[0061] At 304, a certificate and key are generated by the authentication server based at least in part on the authentication. For example, upon authenticating the user 102 and / or the client device 104, the authentication service 114 generates a certificate and key pair 120. In a configuration, the authentication service 114 also generates a cookie 122 that is used to encrypt the certificate and key pair 120.

[0062] At 306, the certificate and key are provided by the authentication service to the client device. For example, the authentication service 114 provides the encrypted certificate and key pair 120 along with the cookie 122 to the client device 102. In a configuration, the encrypted certificate and key pair 120 along with the cookie 122 are sent from the authentication service 114 to the client device 104 using Security Assertion Markup Language (SAML) redirection.

[0063] At 308, the certificate and key are provided by the authentication service to a gateway located in front of the endpoint device providing the network service. For example, the authentication service 114 pushes the encrypted certificate and key pair 120 along with the cookie 122 to the firewall 112 at the gateway 110. In a configuration, the authentication service 114 also pushes the user identification (ID), the ID of the network service or application, and the certificate details (e.g., the certificate ID (serial number), the time validity of the certificate, etc.) to the firewall. In a configuration, the authentication service 114 can push the encrypted certificate and key pair 120 along with the cookie 122 to the firewall 112 at the gateway 110, and the authentication service 114 provides the encrypted certificate and key pair 120 together with the cookie 122 to the client device 102. The gateway 110 and the firewall 112 are in front of the data center 108, which includes one or more servers 106 (e.g., endpoint application servers) that provide network services.

[0064] At 310, a secure session is initiated by a thin client on a client device by providing at least a certificate and a key to a gateway. For example, a browser 118 on a client device 104 includes a plug-in or extension 124. The extension 124 detects the encrypted certificate and key 120 and the cookie 122. The extension 124 provides the encrypted certificate and key pair 120 along with the cookie 122 to the thin client 116. The thin client 116 decrypts the certificate and key pair 120 using the cookie 122. The thin client 116 operates as a background service on the desktop of the client device 104 itself and is able to establish a secure channel or session with the firewall 112 while also acting as a local proxy on the desktop of the client device 104. Thus, the plug-in or extension 124 on the browser 118 interacts with the thin client 116 and launches the thin client 116. The thin client 116 uses the certificate and key pair 120 to initiate a secure session with the firewall 112.

[0065] At 312, the certificate and key provided by the thin client are verified by the gateway. At 314, a secure session is established between the thin client on the client device and the gateway based at least in part on the certificate and key. For example, the firewall 112 verifies the certificate and then establishes a secure session with the thin client 116. In a configuration, the secure session is a mutual transport layer security (mTLS) channel.

[0066] A native application is launched on the client device at 316. For example, after the mTLS channel is established, the extension 124 invokes a native client application 126 on the client device 104 that needs to connect to the endpoint application server(s) 106 in the data center 108 to obtain a network service or application.

[0067] At 318, a local proxy channel is provided between the thin client and the native application. Then, for example, the thin client 116 opens the local proxy channel 128 and instructs the native application 126 to connect to the proxy channel 128.

[0068] At 320, traffic is routed between the native application and the endpoint device via the thin client through the secure session and the local proxy channel. For example, the native application 126 provides traffic from the client device 104 to the thin client 116 destined for the endpoint application server(s) 106. The thin client 116 places the traffic on the mTLS channel and forwards it to the firewall 112. The firewall 112 decrypts the traffic and provides it to the endpoint application server(s) 106. The endpoint application server(s) may also provide return traffic to the firewall 112, which encrypts the traffic and places it on the mTLS channel to provide it to the thin client 116. The thin client 116 may decrypt the traffic and provide it to the native application 126 on the proxy channel 128.

[0069] Thus, the techniques and architectures described herein enable secure remote access to non-HTTP and legacy applications on non-managed clients (as well as access to other network services) over mTLS connections based on single-use certificates and key pairs. The techniques and architectures described herein leverage existing firewalls as gateways to terminate mTLS connections and forward traffic to backend application servers. The techniques and architectures described herein provide a unique way to authenticate non-HTTP client connections. The techniques and architectures described herein provide low performance overhead because the gateway (firewall) does not need to verify cookies when creating and protecting connections using mTLS.

[0070] Figure 4FIG. 4 shows an example computer architecture of a computing device 400 capable of executing program components for implementing the above functions. In one configuration, one or more computing devices 400 may be used to implement the computer program components of FIG. 1 to FIG. Figure 3 One or more components in the components. Figure 4 The computer architecture shown shows a traditional server computer, workstation, desktop computer, laptop computer, tablet computer, web appliance, e-reader, smart phone and / or other computing device, and can be used to execute any software components presented herein.In some examples, computing device 400 can correspond to a physical device or resource described herein.

[0071] The computing device 400 includes a baseboard (or "motherboard") 402, which is a printed circuit board to which many components or devices may be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units ("CPUs") 404 operate in conjunction with a chipset 406. The CPU 404 may be a standard programmable processor that performs the arithmetic and logic operations necessary for the operation of the computing device 400.

[0072] The CPU 404 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.

[0073] Chipset 406 provides an interface between CPU 404 and the remaining components and devices on baseboard 402. Chipset 406 may provide an interface with RAM 408, which is used as main memory in computing device 400. Chipset 406 may also provide an interface with a computer-readable storage medium, such as read-only memory (ROM) 410 or non-volatile RAM (NVRAM), which is used to store basic routines that help start computing device 400 and transfer information between various components and devices. ROM 410 or NVRAM may also store other software components necessary for the operation of computing device 400 according to the configuration described herein.

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

[0075] The computing device 400 can be connected to a storage device 418 that provides non-volatile storage for the computer. The storage device 418 can store an operating system 420, programs 422, and data, which have been described in detail herein. The storage device 418 can be connected to the computing device 400 via a storage controller 414 connected to the chipset 406. The storage device 418 can be composed of one or more physical storage units. The storage controller 414 can 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.

[0076] The computing device 400 may store data on the storage device 418 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 418 is characterized as primary storage or secondary storage, etc.

[0077] For example, computing device 400 can store information to storage device 418 by issuing instructions through storage controller 414 to change the magnetic properties of specific locations in a disk drive unit, the reflective or refractive properties of specific locations in an optical storage unit, or the electrical properties of specific capacitors, transistors, or other discrete components in a solid-state storage unit. Other transformations of physical media are possible without departing from the scope and spirit of this specification, and the foregoing examples are provided only for the convenience of this specification. Computing device 400 can further read information from storage device 418 by detecting the physical state or properties of one or more specific locations in a physical storage unit.

[0078] In addition to the mass storage device 418 described above, the computing device 400 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 400. 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 400. In other words, some or all of the operations described herein may be performed by one or more computing devices 400 operating in a cloud-based arrangement.

[0079] By way of example, and not 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 disc ROM ("CD-ROM"), digital versatile disk ("DVD"), high definition DVD ("HD-DVD"), BLU-RAY or other optical storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information in a non-transitory manner.

[0080] As briefly mentioned above, the storage device 418 may store an operating system 420 that is used to control the operation of the computing device 400. 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 418 may store other systems or applications and data utilized by computing device 400.

[0081] In one embodiment, storage device 418 or other computer-readable storage medium is encoded with computer-executable instructions that, when loaded into computing device 400, 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 computing device 400 by specifying how CPU 404 transitions between states. According to one embodiment, computing device 400 is able to access a computer-readable storage medium storing computer-executable instructions that, when executed by computing device 400, perform the operations described above with respect to FIGS. 1 to 4. Figure 3 The computing device 400 may also include a computer-readable storage medium having stored thereon instructions for performing any other computer-implemented operations described herein.

[0082] The computing device 400 may also include one or more input / output controllers 416 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 416 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 400 may not include Figure 4 All components shown in the Figure 4 Other components not explicitly shown may be used in conjunction with Figure 4 A completely different architecture is shown in .

[0083] The computing device 400 may support a virtualization layer, such as one or more virtual resources executing on the computing device 400. In some examples, the virtualization layer may be supported by a hypervisor that provides one or more virtual machines running on the computing device 400 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.

[0084] 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 embodiments. 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 deviations from the true spirit and scope of the present invention.

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

Claims

1. A method comprising: authenticating the client device by the authentication service for accessing the network to obtain network services; generating, by the authentication service, a certificate and a key based at least in part on the authentication; providing, by the authentication service, the certificate and key to the client device; The authentication service provides the certificate and key to a gateway located before the endpoint device providing the network service; initiating, by a thin client on the client device, a secure session by providing at least the certificate and the key to the gateway; Verifying, by the gateway, the certificate and the key provided by the thin client; establishing the secure session between the thin client on the client device and the gateway based at least in part on the certificate and key; launching a native application on the client device; providing a local proxy channel between the thin client and the native application; as well as Traffic is routed between the native application and the endpoint device via the thin client through the secure session and the local proxy channel.

2. The method according to claim 1, further comprising: A cookie is generated by the authentication service; The authentication service encrypts the certificate and key with the cookie before providing the certificate and key to the client device; providing the certificate and key together with the cookie to the client device by the authentication service; as well as The certificate and the key are decrypted by the thin client using the cookie before initiating the secure session between the thin client on the client device and the gateway.

3. The method according to claim 2, further comprising: The authentication service provides the certificate and key together with the cookie to the gateway; as well as The cookie is used by the gateway to decrypt the certificate and the key.

4. The method according to any one of claims 1 to 3, wherein: The certificate has a limited validity based at least in part on an amount of time.

5. The method according to any one of claims 1 to 4, wherein: Providing the certificate and key to the gateway further comprises: providing certificate details to the gateway; and The method also includes determining a validity of the certificate based at least in part on the certificate details.

6. The method according to claim 5, wherein: The certificate details include a certificate identification (ID); and Determining the validity of the certificate includes determining, based at least in part on the certificate ID, whether the certificate has been previously provided to the gateway by an entity other than the authentication service.

7. The method according to claim 6, wherein: Determining whether the certificate has been previously provided to the gateway by an entity other than the authentication service includes searching a database for the certificate ID.

8. The method according to claim 7, further comprising: Upon receiving the certificate from the authentication service, storing the certificate ID in the database by the gateway; as well as Based at least in part on verifying, by the gateway, the certificate and the key provided by the thin client, removing the certificate ID from the database.

9. The method according to any one of claims 1 to 8, further comprising: Prior to initiating the secure session by the thin client by providing at least the certificate and the key to the gateway, a trusted relationship is established between the thin client and the gateway via a pre-sharing mechanism.

10. 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: authenticating the client device by the authentication service for accessing the network to obtain network services; generating, by the authentication service, a certificate and a key based at least in part on the authentication; providing, by the authentication service, the certificate and key to the client device; The authentication service provides the certificate and key to a gateway located before the endpoint device providing the network service; initiating, by a thin client on the client device, a secure session by providing at least the certificate and the key to the gateway; Verifying, by the gateway, the certificate and the key provided by the thin client; establishing the secure session between the thin client on the client device and the gateway based at least in part on the certificate and key; launching a native application on the client device; providing a local proxy channel between the thin client and the native application; and Traffic is routed between the native application and the endpoint device via the thin client through the secure session and the local proxy channel.

11. The system according to claim 10, wherein: The actions also include: A cookie is generated by the authentication service; The authentication service encrypts the certificate and key with the cookie before providing the certificate and key to the client device; providing, by the authentication service, the certificate and key together with the cookie to the client device; and The certificate and the key are decrypted by the thin client using the cookie before initiating the secure session between the thin client on the client device and the gateway.

12. The system according to claim 11, wherein: The actions also include: providing the certificate and key together with the cookie to the gateway by the authentication service; and The cookie is used by the gateway to decrypt the certificate and the key.

13. A system according to any one of claims 10 to 12, wherein: The certificate has a limited validity based at least in part on an amount of time.

14. A system according to any one of claims 10 to 13, wherein: Providing the certificate and key to the gateway further comprises: providing certificate details to the gateway; and The actions also include determining a validity of the certificate based at least in part on the certificate details.

15. The system of claim 14, wherein: The certificate details include a certificate identification (ID); and Determining the validity of the certificate includes determining, based at least in part on the certificate ID, whether the certificate has been previously provided to the gateway by an entity other than the authentication service.

16. The system of claim 15, wherein: Determining whether the certificate has been previously provided to the gateway by an entity other than the authentication service includes searching a database for the certificate ID.

17. The system of claim 16, wherein: The actions also include: Upon receiving the certificate from the authentication service, storing, by the gateway, the certificate ID in the database; and Based at least in part on verifying, by the gateway, the certificate and the key provided by the thin client, removing the certificate ID from the database.

18. A system according to any one of claims 10 to 17, wherein: The actions also include: Prior to initiating the secure session by the thin client by providing at least the certificate and the key to the gateway, a trusted relationship is established between the thin client and the gateway via a pre-sharing mechanism.

19. 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: authenticating the client device by the authentication service for accessing the network to obtain network services; generating, by the authentication service, a certificate and a key based at least in part on the authentication; providing, by the authentication service, the certificate and key to the client device; The authentication service provides the certificate and key to a gateway located before the endpoint device providing the network service; initiating, by a thin client on the client device, a secure session by providing at least the certificate and the key to the gateway; Verifying, by the gateway, the certificate and the key provided by the thin client; establishing the secure session between the thin client on the client device and the gateway based at least in part on the certificate and key; launching a native application on the client device; providing a local proxy channel between the thin client and the native application; as well as Traffic is routed between the native application and the endpoint device via the thin client through the secure session and the local proxy channel.

20. The one or more non-transitory computer readable media of claim 19, wherein: The actions also include: A cookie is generated by the authentication service; The authentication service encrypts the certificate and key with the cookie before providing the certificate and key to the client device; providing, by the authentication service, the certificate and key together with the cookie to the client device; and The certificate and the key are decrypted by the thin client using the cookie before initiating the secure session between the thin client on the client device and the gateway.

21. An apparatus comprising: means for authenticating, by an authentication service, a client device for accessing a network to obtain network services; means for generating, by the authentication service, credentials and keys based at least in part on the authentication; means for providing, by the authentication service, the certificate and key to the client device; means for providing, by the authentication service, the certificate and key to a gateway located before an endpoint device providing the network service; means for initiating, by a thin client on the client device, a secure session by providing at least the certificate and the key to the gateway; means for verifying, by the gateway, the certificate and the key provided by the thin client; means for establishing the secure session between the thin client on the client device and the gateway based at least in part on the certificate and key; module for launching a native application on the client device; means for providing a local proxy channel between the thin client and the native application; as well as Means for routing traffic between the native application and the endpoint device via the thin client through the secure session and the local proxy channel.

22. The apparatus according to claim 21, further comprising: Module for implementing the method according to any one of claims 2 to 9.

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 9.

Images