US20220337654A1 - Non-http layer 7 protocol applications running in the browser - Google Patents
Non-http layer 7 protocol applications running in the browser Download PDFInfo
- Publication number
- US20220337654A1 US20220337654A1 US17/559,994 US202117559994A US2022337654A1 US 20220337654 A1 US20220337654 A1 US 20220337654A1 US 202117559994 A US202117559994 A US 202117559994A US 2022337654 A1 US2022337654 A1 US 2022337654A1
- Authority
- US
- United States
- Prior art keywords
- protocol
- http
- client
- layer
- browser
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims description 18
- 230000004044 response Effects 0.000 claims description 10
- 238000012545 processing Methods 0.000 description 12
- 238000010586 diagram Methods 0.000 description 9
- 239000003795 chemical substances by application Substances 0.000 description 6
- 230000003287 optical effect Effects 0.000 description 5
- 230000008520 organization Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 4
- 235000014510 cooky Nutrition 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 238000013475 authorization Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000008859 change Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000000644 propagated effect Effects 0.000 description 2
- 230000005641 tunneling Effects 0.000 description 2
- KJLPSBMDOIVXSN-UHFFFAOYSA-N 4-[4-[2-[4-(3,4-dicarboxyphenoxy)phenyl]propan-2-yl]phenoxy]phthalic acid Chemical compound C=1C=C(OC=2C=C(C(C(O)=O)=CC=2)C(O)=O)C=CC=1C(C)(C)C(C=C1)=CC=C1OC1=CC=C(C(O)=O)C(C(O)=O)=C1 KJLPSBMDOIVXSN-UHFFFAOYSA-N 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H04L67/16—
-
- H04L67/2804—
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/561—Adding application-functional data or data for application control, e.g. adding metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
Definitions
- Embodiments of the invention relate to the field of network communications; and more specifically, to non-HTTP layer 7 protocol applications running in a browser.
- the internet has historically been open where content including services and applications provided by companies are exposed to the general internet. However, exposing these services and applications to the general internet may not be secure. Since any application on the internet can be a target for an attack, these companies often try to hide the origin server of their application. For example, they may use a proxy to try to mask the origin IP address and/or they may lock down ports to block unwanted traffic. In some cases, Generic Routing Encapsulation (GRE) tunnel or a Virtual Private Network (VPN) is used to secure the services and applications, and to keep their origin hidden. However, GRE tunneling and implementing a VPN is time consuming, requires cross-company coordination, and is not flexible to easily make changes.
- GRE Generic Routing Encapsulation
- VPN Virtual Private Network
- Non-web applications e.g., non-HTTP layer 7 protocol applications
- SSH secure shell protocol
- RDP remote desktop protocol
- VNC virtual network computing
- SSH secure shell protocol
- Many of these applications require a thick client and rely on private networks.
- the client software expects to reach a private IP over a specific protocol.
- Authentication to these applications relies on legacy approaches. For instance, developers often hold long-lived secure shell protocol (SSH) keys to reach machines and business users keep usernames and passwords on sticky notes.
- SSH secure shell protocol
- SSO single sign-on
- SSH clients executing on the browser.
- Web browsers cannot natively access Layer 4 sockets (e.g., TCP sockets, UDP sockets) so the SSH clients executing on the browser cannot directly access layer 4 sockets to communicate with an SSH server.
- Layer 4 sockets e.g., TCP sockets, UDP sockets
- the web browser application communicates to the agent using a proprietary or otherwise non-SSH protocol.
- the web browser application is not a true SSH client.
- Non-HTTP Layer 7 protocol
- the non-HTTP layer 7 protocol client application connects to a compute server that proxies layer 4 packets to the origin network that has the non-HTTP layer 7 protocol service.
- an SSH client a non-HTTP layer 7 protocol
- TCP packets layer 4 packets
- the non-HTTP layer 7 protocol client application allows users to run commands or otherwise interact with the client as if they were using a native application (one that is not executed within the browser) without any client-side configuration or agent.
- FIG. 1 is a block diagram that illustrates a system for executing non-HTTP layer 7 protocol client applications in the browser according to an embodiment.
- FIG. 2 is a sequence diagram that illustrates exemplary operations for executing non-HTTP layer 7 protocol applications in the browser according to an embodiment.
- FIG. 3 is a flow diagram that illustrates exemplary operations for executing non-HTTP layer 7 protocol applications in the browser according to an embodiment.
- FIG. 4 illustrates a block diagram for an exemplary data processing system that may be used in some embodiments.
- Non-HTTP Layer 7 protocol
- the non-HTTP layer 7 protocol client application connects to a compute server that proxies layer 4 packets to the origin network that has the non-HTTP layer 7 protocol service.
- an SSH client a non-HTTP layer 7 protocol
- the non-HTTP layer 7 protocol client application allows users to run commands or otherwise interact with the client as if they were using a native application (one that is not executed within the browser) without any client-side configuration or agent.
- the non-HTTP layer 7 protocol client application is compiled into a WebAssembly (Wasm) file that is executed by the browser.
- Wism WebAssembly
- the browser can render a fully functional non-HTTP layer 7 protocol client application that a user can launch with a single click or selection.
- a user can be authenticated with the single sign-on (SSO) of their organization and access policies for the resource may be checked.
- SSO single sign-on
- the compute server may apply one or more policies to the traffic of the non-HTTP layer 7 service.
- the one or more policies may be based on identity, device posture, location, and/or risk signals, for example.
- the one or more policies may be defined by the operator of the non-HTTP layer 7 service. For example, the operator may specify what user(s) (e.g., identified by email address, phone number, name, device name, identifier, group, country, etc.) are allowed and/or not allowed to access the non-HTTP layer 7 service. Additionally, or alternatively, the operator may specify device posture requirements for access to the non-HTTP layer 7 service.
- the device posture may be provided from third-party endpoint security providers.
- the one or more policies allow organizations to build rules that control who in the organization (or external users) can transfer data to or away from a machine over a particular non-HTTP layer 7 application (e.g., over an SSH connection or to a remote desktop over RDP). These rules could be based on machine, user and/or group identity, country, and/or device.
- the compute server may log, report, and/or record session data of the non-HTTP layer 7 service. For instance, each event of the session may be logged and/or recorded. The event(s) may be configured by the operator of the non-HTTP layer 7 service.
- the logged and/or recorded data can be sent to an external storage location (e.g., the data may be batched and sent in intervals).
- the user can use the non-HTTP layer 7 protocol client application in the browser as if they were using the native application without any client-side configuration or agent.
- the distributed edge compute and routing service may accelerate the connection, apply rules regarding what data transfers can take place, and/or record the session for administrators to audit as needed.
- FIG. 1 is a block diagram that illustrates a system for executing non-HTTP layer 7 protocol client applications in the browser according to an embodiment.
- the system includes the client device 110 that executes the browser 115 , the compute server 120 , and the private network 130 .
- the client device 110 is a computing device (e.g., laptop, workstation, smartphone, mobile phone, tablet, gaming system, set top box, wearable device, Internet of Things (IoT) device, etc.) that can transmit and/or receive network traffic through the web browser 115 .
- a computing device e.g., laptop, workstation, smartphone, mobile phone, tablet, gaming system, set top box, wearable device, Internet of Things (IoT) device, etc.
- IoT Internet of Things
- the compute server 120 is a computing device that may be part of a distributed edge compute and routing service provided by a distributed edge compute and routing network.
- a distributed edge compute and routing service may provide different services for customers (e.g., domain owners or operators) such as protecting against internet-based threats, performance services (e.g., acting as a content delivery network (CDN) and dynamically caching customer's files closer to visitors, page acceleration/optimization), TCP stack optimizations, and/or other services.
- the compute server 120 may be one of multiple compute servers within a datacenter and there may be similar compute servers located in multiple datacenters that are geographically distributed.
- Each datacenter may also include one or more control servers, one or more domain name system (DNS) servers, and/or one or more other pieces of network equipment such as router(s), switch(es), and/or hub(s).
- DNS domain name system
- each compute server within a datacenter may process internet traffic (e.g., transmission control protocol (TCP), user datagram protocol (UDP), HTTP/S, SPDY, file transfer protocol (FTP), IPSec, session initiation protocol (SIP), or other IP protocol traffic).
- TCP transmission control protocol
- UDP user datagram protocol
- HTTP/S HyperText Transfer Protocol
- SPDY file transfer protocol
- FTP file transfer protocol
- IPSec session initiation protocol
- SIP session initiation protocol
- the private network 130 includes a private application or service running on an origin network.
- the non-HTTP layer 7 protocol service 138 may be running on an origin server within the private network 130 .
- the operator of the private network 130 may have content (e.g., application, service, etc.) to secure without the content being exposed to the general internet.
- the content may be running locally on the origin server or behind a firewall/NAT.
- the L4 proxy client 135 connects to the L4 proxy service 128 and requests an L4 tunnel be established between the private network 130 and the distributed edge compute and routing service.
- the L4 proxy client 135 connects to a compute server that is closest to the private network 130 via an anycast protocol implementation.
- the L4 proxy client 135 connects to a compute server via a site-local address (a private address that is not globally routable) for the compute server 120 .
- the connection to the L4 proxy service 128 is over an encrypted L4 tunnel 152 .
- the connection may be secured with a pinned certificate embedded in the L4 proxy client 135 .
- the L4 proxy client 135 may be configured to send configuration information for the tunnel to the L4 proxy service 128 .
- the configuration information may include authentication information (e.g., username/password, an access token (e.g., an application programming interface (API) key), cryptographic identity (e.g., a certificate), and/or email address), transport layer security (TLS) configuration information (e.g., type of TLS supported), port, and/or hostname that traffic should be received on.
- the L4 proxy service 128 may forward the request to a tunnel control service for establishing the L4 tunnel or may establish the L4 tunnel itself. Establishing the tunnel may include authenticating the request and configuring a DNS zone and possibly a tunnel subdomain zone (used as a canonical name (CNAME) target and an alternative way of accessing the tunnel).
- CNAME canonical name
- a tunneled hostname may appear as a CNAME to a subdomain of a dedicated domain for the tunneling service.
- a unique IP address may be assigned to the tunnel.
- Multiple streams of data and control may be multiplexed over a single established tunnel.
- the L4 proxy client 135 connects over secure sessions to multiple L4 proxy services running on multiple compute servers of the distributed edge compute and routing service to request multiple tunnels be established respectively for the same hostname.
- the L4 proxy service 128 on the compute server 120 accepts tunnel connection requests such as from the L4 proxy client 135 .
- the L4 proxy service 128 sends the tunnel connection request to a tunnel control service of a control server.
- the tunnel connection request may include the configuration information for the tunnel.
- the control server may be a centralized server that is connected with multiple datacenters.
- the L4 proxy service 128 may also include a communication server (e.g., a Remote Procedure Call (RPC) server, HTTP REST server, etc.), that can be used by the tunnel control service to inspect, shutdown, and/or redirect tunnels.
- the L4 proxy service 128 may also communicate with the interface application/file server 122 of the compute server 120 to proxy requests for the tunnel hostname to the private network.
- RPC Remote Procedure Call
- a compute server of the distributed edge compute and routing service may receive an HTTP request for the tunneled hostname, identify the intended origin server, and transmit the HTTP request towards, or over, the established L4 tunnel. If the receiving compute server does not have a tunnel to the private network for the tunneled hostname, that compute server determines which compute server to transmit the HTTP request and routes the traffic accordingly.
- the routing between compute servers is performed intelligently based on traffic information (e.g., latency, packet loss data) gathered from other requests that traverse the distributed edge compute and routing service.
- the interface application/file server 122 retrieves the file(s) that the browser 115 requests including the files that execute the non-HTTP L7 protocol client 118 .
- the interface application/file server 122 may retrieve client-side script(s), cascading style sheets (CSS), HTML, and/or WASM file(s) as requested by the browser 115 .
- the files may be sent over a websocket between the browser 115 and the compute server 120 .
- the non-HTTP layer 7 protocol client allows users to run commands or otherwise interact with the client as if they were using a native application (one that is not executed within the browser) without any client-side configuration or agent.
- the compute server 120 includes the security service 125 according to an embodiment.
- the security service 125 applies one or more policies 126 to the traffic of the non-HTTP layer 7 service.
- the one or more policies may be based on identity, device posture, location, and/or risk signals, for example.
- the one or more policies may be defined by the operator of the non-HTTP layer 7 service. For example, the operator may specify what user(s) (e.g., identified by email address, phone number, name, device name, identifier, group, country, etc.) are allowed and/or not allowed to access the non-HTTP layer 7 service. Additionally, or alternatively, the operator may specify device posture requirements for access to the non-HTTP layer 7 service.
- the device posture may be provided from third-party endpoint security providers.
- the security service 125 may also perform log capture 127 and/or recording of session data of the non-HTTP layer 7 service. For instance, each event of the session may be logged and/or recorded. The event(s) may be configured by the operator of the non-HTTP layer 7 service.
- the logged and/or recorded data 154 can be sent to an external storage location 140 (e.g., the data may be batched and sent in intervals).
- the compute server 120 proxies the layer 4 packets received over the WebSocket to the non-HTTP layer 7 service 138 .
- the L4 proxy service 128 proxies the layer 4 packets received over the WebSocket over the L4 tunnel 152 to the L4 proxy client 135 at operation 232 .
- the L4 proxy client 135 receives the data and forwards the data to the non-HTTP L7 protocol service 138 at operation 234 .
- a non-HTTP L7 protocol session 150 is logically created between the non-HTTP L7 protocol client 118 and the non-HTTP L7 protocol service 138 . Since the server-side proxy happens at the L4 level only, the session may be end-to-end encrypted between the client executing on the web browser and the remote service.
- FIG. 2 is a sequence diagram that illustrates exemplary operations for executing non-HTTP layer 7 protocol applications in the browser according to an embodiment.
- the browser 115 executing on the client device 110 makes an HTTP(s) request for a domain, e.g., https://mytunnel.com.
- the compute server 120 may receive the request because it is the closest one of the compute servers to the client device 110 in terms of routing protocol configuration (e.g., border gateway protocol (BGP) configuration) according to an anycast implementation or due to a geographical load balancer.
- Border gateway protocol (BGP) configuration e.g., border gateway protocol (BGP) configuration
- the interface application/file server 122 may receive this request and forward the request to the security service 125 .
- the request may be triggered by a user navigating to a dashboard or other page that includes a listing of one or more non-HTTP layer 7 protocol applications and the user selecting one of the non-HTTP layer 7 protocol applications listed or by visiting the application directly.
- This dashboard or page may be tailored to the permissions of the users. For instance, an organization user may login to a page controlled by the organization that displays the non-HTTP layer 7 protocol applications that is available to that user. The user can select any of the displayed applications without leaving their browser to launch the application. This may cause the initial request that launches the initial login flow to authorize them for the session so that the user can begin doing work without modifying any configuration files or editing clients locally.
- the security service 125 may perform identity authentication. For instance, if a valid user session is not established, at operation 212 , the security service 125 redirects the browser 115 to perform a login flow.
- the browser may be presented with one or more identity providers for providing identity information.
- the one or more identity providers may be configured by the organization. Each identity provider may have its own requirements or rules that must be followed to prove identity. Regardless of the technique, in the example of FIG. 2 , the browser 115 performs the login flow at operation 214 .
- the security service 125 completes the login flow process at operation 216 and sets a cookie that specifies that the user is authorized for the request.
- the security service 125 may determine whether the user is allowed to access the non-HTTP layer 7 protocol application based on a set of one or more policies.
- the one or more policies may be based on identity, device posture, location, and/or risk signals, for example.
- the one or more policies may be defined by the operator of the non-HTTP layer 7 protocol service. For example, the operator may specify what user(s) (e.g., identified by email address, phone number, name, device name, identifier, group, country, etc.) are allowed and/or not allowed to access the non-HTTP layer 7 service. Additionally, or alternatively, the operator may specify device posture requirements for access to the non-HTTP layer 7 service.
- the device posture may be provided from third-party endpoint security providers.
- the browser 115 executing on the client device 110 makes an HTTP/S request for the domain, e.g., https://mytunnel.com, and includes the set authorization cookie.
- This request is like the request received at operation 210 with the addition of the authorization cookie.
- the security service 125 may apply the one or more policies to determine whether the HTTP/S request is allowed to be processed. Assuming that the request is allowed to be processed, the interface application/file server 122 processes the request. Processing the request may include retrieving the requested resource (e.g., index.html at mytunnel.com) from the origin or from a local storage. Assuming that the requested resource is available, the interface application/file server 122 transmits a response that includes the requested resource at operation 220 .
- the requested resource e.g., index.html at mytunnel.com
- the initial requested resource may include one or more additional resources used for the non-HTTP layer 7 protocol application.
- Example additional resources include a WebAssembly file, a client-side script, a stylesheet, and/or other HTML.
- the non-HTTP layer 7 protocol client application has been compiled into a WebAssembly file.
- the browser 115 transmits a request for the WebAssembly file that is received by the compute server 120 .
- the request includes the authorization cookie in some embodiments.
- the security service 125 may apply the one or more policies to determine whether the request is allowed to be processed.
- the interface application/file server 122 processes the request. Processing the request may include retrieving the requested resource (e.g., the WebAssembly file) from the origin or from a local storage. Assuming that the requested resource is available, the interface application/file server 122 transmits a response that includes the requested resource at operation 224 .
- the requested resource e.g., the WebAssembly file
- the browser 115 executes the WebAssembly file.
- the WebAssembly file is code that when executed by the browser 115 , executes a non-HTTP layer 7 protocol client at operation 226 .
- an SSH client may be compiled into the WebAssembly file and therefore an SSH client may be executed within the browser.
- the user may be required to authenticate with the non-HTTP layer 7 protocol service. For instance, if the client application is an SSH client, the user may need to authenticate with the remote SSH server.
- the available authentication methods vary based on server configuration but may include password authentication (e.g., through a prompt to the user), public key authentication (e.g., through a prompt to the user), or automatically through a certificate authentication.
- the non-HTTP layer 7 protocol client In a certificate authentication method, the non-HTTP layer 7 protocol client generates a keypair and sends a request with the public key to a signing endpoint (e.g., part of the distributed edge compute and routing service and may be executed on the compute server 120 ).
- the request may also include a token that is issued during login that proves the user has been authenticated.
- the signing endpoint generates a signed certificate and returns it to the non-HTTP layer 7 protocol client.
- the signed public key and the generated private key are used to authenticate with the remote SSH server.
- This certificate may be valid for a relatively short period (e.g., minutes).
- the non-HTTP L7 protocol client 118 executing within the browser 115 transmits data that is related to the non-HTTP layer 7 protocol service and that data is received at the compute server 120 .
- the data is transmitted using the protocol of the non-HTTP layer 7 protocol service.
- the client application is an SSH client
- the data is transmitted in accordance with the SSH protocol.
- the data may be transmitted over a WebSocket between the client device 110 and the compute server 120 .
- the transmission uses a layer 4 protocol such as TCP or UDP.
- the index page may cause a client-side script (e.g., JavaScript) to be downloaded that initiates the WebSocket connection and draws the page. This client-side script may send data from the WebSocket to and from the WebAssembly code that implements the majority of the logic for the non-HTTP L7 protocol client 118 .
- a client-side script e.g., JavaScript
- the compute server 120 receives the non-HTTP layer 7 protocol service data.
- the security service 125 may perform one or more actions after receiving the data.
- the security service 125 applies the set of one or more policies to determine whether the data or the requested connection is allowed.
- the security service 125 performs the log capture operation 230 where the security service 125 may log, record, and/or report the session data of the non-HTTP layer 7 service. For instance, each event of the session may be logged, recorded, and/or reported.
- the event(s) may be configured by the operator of the non-HTTP layer 7 service.
- the logged and/or recorded data can be sent to an external storage location (e.g., the data may be batched and sent in intervals).
- the compute server 120 proxies the layer 4 packets received over the WebSocket to the non-HTTP layer 7 service 138 .
- the L4 proxy service 128 proxies the layer 4 packets received over the WebSocket over the L4 tunnel 152 to the L4 proxy client 135 at operation 232 .
- the L4 proxy client 135 receives the data and forwards the data to the non-HTTP L7 protocol service 138 at operation 234 .
- the non-HTTP layer 7 protocol service 138 may transmit data to the non-HTTP layer 7 protocol client 118 .
- the non-HTTP layer 7 protocol service 138 transmits data related to the session.
- the data is received at the L4 proxy client 135 that forwards the data at operation 238 over the L4 tunnel 152 to the L4 proxy service 128 .
- the L4 proxy service 128 forwards the traffic to the security service 125 .
- the security service 125 may perform one or more actions after receiving the data such as performing the log capture operation 240 where the security service 125 may log, record, and/or report the session data of the non-HTTP layer 7 service.
- the data is transmitted to the non-HTTP layer 7 protocol client 118 at operation 242 over the WebSocket.
- FIG. 2 proxies the layer 4 packets over an existing L4 tunnel.
- embodiments are not so limited. If an L4 tunnel does not exist between the compute server 120 and the private network 130 , an L4 tunnel can be created.
- the compute server 120 that receives traffic from the client device 110 does not have a tunnel established with the non-HTTP L7 protocol service; instead, a different compute server of the distributed edge compute and routing service may have an established tunnel to the non-HTTP L7 protocol service. In such a case, the compute server 120 may route the traffic toward the computed server that is connected with an L4 tunnel to the non-HTTP L7 protocol service. There may be many compute servers (along with other network equipment) between the compute server that initially receives the traffic and a compute server with a tunnel for the non-HTTP L7 protocol service.
- an origin server is in London and a tunnel is created from a compute server in London to the origin server, and traffic is sent from a client device in California that is received at a compute server in California, the traffic may be routed over multiple compute servers between California and London.
- routing rules are installed in the compute servers of the distributed edge compute and routing service to reach the tunneled destination.
- the routing between compute server(s) is performed intelligently based on traffic information (e.g., latency, packet loss data) gathered from other requests that traverse the distributed edge compute and routing service. This allows the distributed edge compute and routing service to pick the best path to the non-HTTP L7 protocol service (e.g., the fastest, most reliable, etc.) depending on current network conditions.
- the routing between compute server(s) is based on carrier information. For example, some of the IP address(es) assigned to the tunnel may be from different carriers that may have different routes that can be taken through the distributed edge compute and routing service.
- the routing may find the optimal path to the non-HTTP L7 protocol service based on which carrier is selected for the routing, which may be based on factors such as speed, reliability, and/or cost. For instance, the prices of different cloud providers can be monitored (the prices can change relatively quickly depending on demand and sales) and the cheaper route can be taken.
- FIG. 3 is a flow diagram that illustrates exemplary operations for executing non-HTTP layer 7 protocol applications in the browser according to an embodiment.
- the compute server 120 receives a request from a browser 115 (e.g., an HTTP/S request) for a resource identified at a domain.
- the compute server 120 determines, based on a set of one or more policies configured for the domain, that the request is allowed to be processed.
- the one or more policies may be based on one or more of identity, device posture, location, and/or risk signals. If the request was not allowed to be processed, then the request would not be processed (e.g., the request would be dropped).
- the compute server 120 transmits to the browser 115 a response to the request, where the response includes code that when executed by the browser 115 , causes a non-HTTP layer 7 protocol client to be executed, where that client communicates with a non-HTTP layer 7 protocol service at an external network.
- the code is in a WebAssembly format.
- the non-HTTP layer 7 protocol client is an SSH client
- the non-HTTP layer 7 protocol service is an SSH server.
- the SSH client may execute in a tab of the browser 115 .
- the user may be required to authenticate to the non-HTTP layer 7 protocol service.
- the non-HTTP layer 7 protocol client may present a login prompt to the user and/or a public key prompt to the user for authentication.
- a certificate generation and authentication may also be performed automatically that allows the user to begin using the application without providing login details.
- the compute server 120 receives, from the non-HTTP layer 7 protocol executing in the browser 115 , data related to the non-HTTP layer 7 protocol service.
- the data is transmitted using the protocol of the non-HTTP layer 7 protocol service.
- the client application is an SSH client
- the data is transmitted in accordance with the SSH protocol.
- the data may be transmitted over a WebSocket between the client device 110 and the compute server 120 .
- the transmission uses a layer 4 protocol such as TCP or UDP.
- the compute server performs logging and/or recording of the data received from the non-HTTP layer 7 protocol client executing in the browser.
- the logged and/or recorded data may be transmitted to a storage location for later retrieval.
- the compute server 120 proxies the data related to the non-HTTP L7 protocol service over the L4 tunnel 152 that is interfaced with the non-HTTP L7 protocol service.
- the L4 proxy service 128 proxies the layer 4 packets received over the WebSocket over the L4 tunnel 152 to the L4 proxy client 135 .
- the L4 proxy client 135 receives the data and forwards the data to the non-HTTP L7 protocol service 138 .
- FIG. 4 illustrates a block diagram for an exemplary data processing system 400 that may be used in some embodiments.
- the data processing system 400 is a computing device that stores and transmits (internally and/or with other computing devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media 410 (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals—such as carrier waves, infrared signals), which is coupled to the processing system 420 (e.g., one or more processors and connected system components such as multiple connected chips).
- the depicted machine-readable storage media 410 e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices
- the data processing system 400 also includes one or more network interfaces 440 (e.g., a wired and/or wireless interfaces) that allows the data processing system 400 to transmit data and receive data from other computing devices, typically across one or more networks (e.g., Local Area Networks (LANs), the Internet, etc.).
- the data processing system 400 may also include one or more input or output (“I/O”) components 450 such as a mouse, keypad, keyboard, a touch panel or a multi-touch input panel, camera, frame grabber, optical scanner, an audio input/output subsystem (which may include a microphone and/or a speaker), other known I/O devices or a combination of such I/O devices. Additional components, not shown, may also be part of the system 400 , and, in certain embodiments, fewer components than that shown in one or more buses may be used to interconnect the various components shown in FIG. 4 .
- the techniques shown in the figures can be implemented using code and data stored and executed on one or more computing devices (e.g., a compute server, a client device, an origin server).
- computing devices store and communicate (internally and/or with other computing devices over a network) code and data using computer-readable media, such as non-transitory machine-readable storage media (e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; phase-change memory) and transitory machine-readable communication media (e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals, digital signals).
- non-transitory machine-readable storage media e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; phase-change memory
- transitory machine-readable communication media e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals, digital signals).
- such computing devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-transitory machine-readable storage media), user input/output devices (e.g., a keyboard, a touchscreen, and/or a display), and network connections.
- the coupling of the set of processors and other components is typically through one or more busses and bridges (also termed as bus controllers).
- bus controllers also termed as bus controllers.
- the storage device of a given computing device typically stores code and/or data for execution on the set of one or more processors of that computing device.
- one or more parts of an embodiment of the invention may be implemented using different combinations
- references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether explicitly described.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Library & Information Science (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
- This application claims the benefit of U.S. Provisional Application No. 63/175,525, filed Apr. 15, 2021, which is hereby incorporated by reference.
- Embodiments of the invention relate to the field of network communications; and more specifically, to non-HTTP
layer 7 protocol applications running in a browser. - The internet has historically been open where content including services and applications provided by companies are exposed to the general internet. However, exposing these services and applications to the general internet may not be secure. Since any application on the internet can be a target for an attack, these companies often try to hide the origin server of their application. For example, they may use a proxy to try to mask the origin IP address and/or they may lock down ports to block unwanted traffic. In some cases, Generic Routing Encapsulation (GRE) tunnel or a Virtual Private Network (VPN) is used to secure the services and applications, and to keep their origin hidden. However, GRE tunneling and implementing a VPN is time consuming, requires cross-company coordination, and is not flexible to easily make changes.
- Non-web applications (e.g., non-HTTP
layer 7 protocol applications), such as secure shell protocol (SSH) applications, remote desktop protocol (RDP) applications, virtual network computing (VNC) applications, introduce challenges. Many of these applications require a thick client and rely on private networks. The client software expects to reach a private IP over a specific protocol. Authentication to these applications relies on legacy approaches. For instance, developers often hold long-lived secure shell protocol (SSH) keys to reach machines and business users keep usernames and passwords on sticky notes. These applications are difficult to integrate with a single sign-on (SSO) provider and implement other controls like device posture. Further, these applications have little to no data control and logging capabilities. - There are some examples of SSH clients executing on the browser. Web browsers cannot natively access
Layer 4 sockets (e.g., TCP sockets, UDP sockets) so the SSH clients executing on the browser cannot directly accesslayer 4 sockets to communicate with an SSH server. To solve this problem, most of these implementations use an agent that is installed at an intermediary device that acts as the SSH client that is connected to the SSH server, where the web browser application communicates to the agent using a proprietary or otherwise non-SSH protocol. Thus, the web browser application is not a true SSH client. -
Layer 7 protocol (non-HTTP) client applications are executed in the browser. Thenon-HTTP layer 7 protocol client application connects to a compute server thatproxies layer 4 packets to the origin network that has thenon-HTTP layer 7 protocol service. As an example, an SSH client (anon-HTTP layer 7 protocol) can execute in the browser and the TCP packets (layer 4 packets) are proxied by a compute server to the origin network that has the appropriate SSH server. Thenon-HTTP layer 7 protocol client application allows users to run commands or otherwise interact with the client as if they were using a native application (one that is not executed within the browser) without any client-side configuration or agent. - The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
-
FIG. 1 is a block diagram that illustrates a system for executingnon-HTTP layer 7 protocol client applications in the browser according to an embodiment. -
FIG. 2 is a sequence diagram that illustrates exemplary operations for executingnon-HTTP layer 7 protocol applications in the browser according to an embodiment. -
FIG. 3 is a flow diagram that illustrates exemplary operations for executingnon-HTTP layer 7 protocol applications in the browser according to an embodiment. -
FIG. 4 illustrates a block diagram for an exemplary data processing system that may be used in some embodiments. -
Layer 7 protocol (non-HTTP) client applications are executed in the browser. Thenon-HTTP layer 7 protocol client application connects to a compute server thatproxies layer 4 packets to the origin network that has thenon-HTTP layer 7 protocol service. As an example, an SSH client (anon-HTTP layer 7 protocol) can execute in the browser and the TCP packets (layer 4 packets) are proxied by a compute server to the origin network that has the appropriate SSH server. Thenon-HTTP layer 7 protocol client application allows users to run commands or otherwise interact with the client as if they were using a native application (one that is not executed within the browser) without any client-side configuration or agent. In an embodiment, thenon-HTTP layer 7 protocol client application is compiled into a WebAssembly (Wasm) file that is executed by the browser. - In an embodiment, the browser can render a fully
functional non-HTTP layer 7 protocol client application that a user can launch with a single click or selection. A user can be authenticated with the single sign-on (SSO) of their organization and access policies for the resource may be checked. - In an embodiment, the compute server may apply one or more policies to the traffic of the
non-HTTP layer 7 service. The one or more policies may be based on identity, device posture, location, and/or risk signals, for example. The one or more policies may be defined by the operator of thenon-HTTP layer 7 service. For example, the operator may specify what user(s) (e.g., identified by email address, phone number, name, device name, identifier, group, country, etc.) are allowed and/or not allowed to access thenon-HTTP layer 7 service. Additionally, or alternatively, the operator may specify device posture requirements for access to thenon-HTTP layer 7 service. The device posture may be provided from third-party endpoint security providers. The one or more policies allow organizations to build rules that control who in the organization (or external users) can transfer data to or away from a machine over aparticular non-HTTP layer 7 application (e.g., over an SSH connection or to a remote desktop over RDP). These rules could be based on machine, user and/or group identity, country, and/or device. - In an embodiment, the compute server may log, report, and/or record session data of the
non-HTTP layer 7 service. For instance, each event of the session may be logged and/or recorded. The event(s) may be configured by the operator of thenon-HTTP layer 7 service. The logged and/or recorded data can be sent to an external storage location (e.g., the data may be batched and sent in intervals). - Thus, once a user has been approved, the user can use the
non-HTTP layer 7 protocol client application in the browser as if they were using the native application without any client-side configuration or agent. The distributed edge compute and routing service may accelerate the connection, apply rules regarding what data transfers can take place, and/or record the session for administrators to audit as needed. -
FIG. 1 is a block diagram that illustrates a system for executingnon-HTTP layer 7 protocol client applications in the browser according to an embodiment. The system includes theclient device 110 that executes thebrowser 115, thecompute server 120, and theprivate network 130. - The
client device 110 is a computing device (e.g., laptop, workstation, smartphone, mobile phone, tablet, gaming system, set top box, wearable device, Internet of Things (IoT) device, etc.) that can transmit and/or receive network traffic through theweb browser 115. - The
compute server 120 is a computing device that may be part of a distributed edge compute and routing service provided by a distributed edge compute and routing network. Such a distributed edge compute and routing service may provide different services for customers (e.g., domain owners or operators) such as protecting against internet-based threats, performance services (e.g., acting as a content delivery network (CDN) and dynamically caching customer's files closer to visitors, page acceleration/optimization), TCP stack optimizations, and/or other services. Thecompute server 120 may be one of multiple compute servers within a datacenter and there may be similar compute servers located in multiple datacenters that are geographically distributed. Each datacenter may also include one or more control servers, one or more domain name system (DNS) servers, and/or one or more other pieces of network equipment such as router(s), switch(es), and/or hub(s). In an embodiment, each compute server within a datacenter may process internet traffic (e.g., transmission control protocol (TCP), user datagram protocol (UDP), HTTP/S, SPDY, file transfer protocol (FTP), IPSec, session initiation protocol (SIP), or other IP protocol traffic). - The
private network 130 includes a private application or service running on an origin network. For instance, thenon-HTTP layer 7protocol service 138 may be running on an origin server within theprivate network 130. The operator of theprivate network 130 may have content (e.g., application, service, etc.) to secure without the content being exposed to the general internet. The content may be running locally on the origin server or behind a firewall/NAT. To connect thisprivate network 130 to the distributed edge compute and routing service, in an embodiment theL4 proxy client 135 connects to theL4 proxy service 128 and requests an L4 tunnel be established between theprivate network 130 and the distributed edge compute and routing service. In an embodiment, theL4 proxy client 135 connects to a compute server that is closest to theprivate network 130 via an anycast protocol implementation. In another embodiment, theL4 proxy client 135 connects to a compute server via a site-local address (a private address that is not globally routable) for thecompute server 120. The connection to theL4 proxy service 128 is over anencrypted L4 tunnel 152. The connection may be secured with a pinned certificate embedded in theL4 proxy client 135. TheL4 proxy client 135 may be configured to send configuration information for the tunnel to theL4 proxy service 128. The configuration information may include authentication information (e.g., username/password, an access token (e.g., an application programming interface (API) key), cryptographic identity (e.g., a certificate), and/or email address), transport layer security (TLS) configuration information (e.g., type of TLS supported), port, and/or hostname that traffic should be received on. TheL4 proxy service 128 may forward the request to a tunnel control service for establishing the L4 tunnel or may establish the L4 tunnel itself. Establishing the tunnel may include authenticating the request and configuring a DNS zone and possibly a tunnel subdomain zone (used as a canonical name (CNAME) target and an alternative way of accessing the tunnel). For example, a tunneled hostname may appear as a CNAME to a subdomain of a dedicated domain for the tunneling service. A unique IP address may be assigned to the tunnel. Multiple streams of data and control may be multiplexed over a single established tunnel. In an embodiment, theL4 proxy client 135 connects over secure sessions to multiple L4 proxy services running on multiple compute servers of the distributed edge compute and routing service to request multiple tunnels be established respectively for the same hostname. - The
L4 proxy service 128 on thecompute server 120 accepts tunnel connection requests such as from theL4 proxy client 135. TheL4 proxy service 128 sends the tunnel connection request to a tunnel control service of a control server. The tunnel connection request may include the configuration information for the tunnel. The control server may be a centralized server that is connected with multiple datacenters. TheL4 proxy service 128 may also include a communication server (e.g., a Remote Procedure Call (RPC) server, HTTP REST server, etc.), that can be used by the tunnel control service to inspect, shutdown, and/or redirect tunnels. TheL4 proxy service 128 may also communicate with the interface application/file server 122 of thecompute server 120 to proxy requests for the tunnel hostname to the private network. - After establishing the L4 tunnel(s), data can be transmitted over the established L4 tunnel(s). For instance, a compute server of the distributed edge compute and routing service may receive an HTTP request for the tunneled hostname, identify the intended origin server, and transmit the HTTP request towards, or over, the established L4 tunnel. If the receiving compute server does not have a tunnel to the private network for the tunneled hostname, that compute server determines which compute server to transmit the HTTP request and routes the traffic accordingly. In an embodiment, which will be described in greater detail later herein, the routing between compute servers is performed intelligently based on traffic information (e.g., latency, packet loss data) gathered from other requests that traverse the distributed edge compute and routing service.
- The interface application/
file server 122 retrieves the file(s) that thebrowser 115 requests including the files that execute the non-HTTPL7 protocol client 118. For instance, the interface application/file server 122 may retrieve client-side script(s), cascading style sheets (CSS), HTML, and/or WASM file(s) as requested by thebrowser 115. The files may be sent over a websocket between thebrowser 115 and thecompute server 120. Thenon-HTTP layer 7 protocol client allows users to run commands or otherwise interact with the client as if they were using a native application (one that is not executed within the browser) without any client-side configuration or agent. - The
compute server 120 includes thesecurity service 125 according to an embodiment. Thesecurity service 125 applies one ormore policies 126 to the traffic of thenon-HTTP layer 7 service. The one or more policies may be based on identity, device posture, location, and/or risk signals, for example. The one or more policies may be defined by the operator of thenon-HTTP layer 7 service. For example, the operator may specify what user(s) (e.g., identified by email address, phone number, name, device name, identifier, group, country, etc.) are allowed and/or not allowed to access thenon-HTTP layer 7 service. Additionally, or alternatively, the operator may specify device posture requirements for access to thenon-HTTP layer 7 service. The device posture may be provided from third-party endpoint security providers. Thesecurity service 125 may also performlog capture 127 and/or recording of session data of thenon-HTTP layer 7 service. For instance, each event of the session may be logged and/or recorded. The event(s) may be configured by the operator of thenon-HTTP layer 7 service. The logged and/or recordeddata 154 can be sent to an external storage location 140 (e.g., the data may be batched and sent in intervals). - The
compute server 120 proxies thelayer 4 packets received over the WebSocket to thenon-HTTP layer 7service 138. For instance, theL4 proxy service 128 proxies thelayer 4 packets received over the WebSocket over theL4 tunnel 152 to theL4 proxy client 135 atoperation 232. TheL4 proxy client 135 receives the data and forwards the data to the non-HTTPL7 protocol service 138 atoperation 234. Thus, a non-HTTPL7 protocol session 150 is logically created between the non-HTTPL7 protocol client 118 and the non-HTTPL7 protocol service 138. Since the server-side proxy happens at the L4 level only, the session may be end-to-end encrypted between the client executing on the web browser and the remote service. -
FIG. 2 is a sequence diagram that illustrates exemplary operations for executingnon-HTTP layer 7 protocol applications in the browser according to an embodiment. Atoperation 210, thebrowser 115 executing on theclient device 110 makes an HTTP(s) request for a domain, e.g., https://mytunnel.com. In embodiments where thecompute server 120 is one of multiple compute servers of a distributed edge compute and routing service, thecompute server 120 may receive the request because it is the closest one of the compute servers to theclient device 110 in terms of routing protocol configuration (e.g., border gateway protocol (BGP) configuration) according to an anycast implementation or due to a geographical load balancer. Although not shown inFIG. 2 , the interface application/file server 122 may receive this request and forward the request to thesecurity service 125. - In an embodiment, the request may be triggered by a user navigating to a dashboard or other page that includes a listing of one or more
non-HTTP layer 7 protocol applications and the user selecting one of thenon-HTTP layer 7 protocol applications listed or by visiting the application directly. This dashboard or page may be tailored to the permissions of the users. For instance, an organization user may login to a page controlled by the organization that displays thenon-HTTP layer 7 protocol applications that is available to that user. The user can select any of the displayed applications without leaving their browser to launch the application. This may cause the initial request that launches the initial login flow to authorize them for the session so that the user can begin doing work without modifying any configuration files or editing clients locally. - The
security service 125 may perform identity authentication. For instance, if a valid user session is not established, atoperation 212, thesecurity service 125 redirects thebrowser 115 to perform a login flow. The browser may be presented with one or more identity providers for providing identity information. The one or more identity providers may be configured by the organization. Each identity provider may have its own requirements or rules that must be followed to prove identity. Regardless of the technique, in the example ofFIG. 2 , thebrowser 115 performs the login flow atoperation 214. - The
security service 125 completes the login flow process at operation 216 and sets a cookie that specifies that the user is authorized for the request. As part of processing the login flow, thesecurity service 125 may determine whether the user is allowed to access thenon-HTTP layer 7 protocol application based on a set of one or more policies. The one or more policies may be based on identity, device posture, location, and/or risk signals, for example. The one or more policies may be defined by the operator of thenon-HTTP layer 7 protocol service. For example, the operator may specify what user(s) (e.g., identified by email address, phone number, name, device name, identifier, group, country, etc.) are allowed and/or not allowed to access thenon-HTTP layer 7 service. Additionally, or alternatively, the operator may specify device posture requirements for access to thenon-HTTP layer 7 service. The device posture may be provided from third-party endpoint security providers. - At operation 218, the
browser 115 executing on theclient device 110 makes an HTTP/S request for the domain, e.g., https://mytunnel.com, and includes the set authorization cookie. This request is like the request received atoperation 210 with the addition of the authorization cookie. Thesecurity service 125 may apply the one or more policies to determine whether the HTTP/S request is allowed to be processed. Assuming that the request is allowed to be processed, the interface application/file server 122 processes the request. Processing the request may include retrieving the requested resource (e.g., index.html at mytunnel.com) from the origin or from a local storage. Assuming that the requested resource is available, the interface application/file server 122 transmits a response that includes the requested resource atoperation 220. - The initial requested resource (e.g., index.html) may include one or more additional resources used for the
non-HTTP layer 7 protocol application. Example additional resources include a WebAssembly file, a client-side script, a stylesheet, and/or other HTML. In the example ofFIG. 2 , thenon-HTTP layer 7 protocol client application has been compiled into a WebAssembly file. Thus, atoperation 222, thebrowser 115 transmits a request for the WebAssembly file that is received by thecompute server 120. The request includes the authorization cookie in some embodiments. Thesecurity service 125 may apply the one or more policies to determine whether the request is allowed to be processed. Assuming that the request is allowed to be processed, the interface application/file server 122 processes the request. Processing the request may include retrieving the requested resource (e.g., the WebAssembly file) from the origin or from a local storage. Assuming that the requested resource is available, the interface application/file server 122 transmits a response that includes the requested resource atoperation 224. - The
browser 115 executes the WebAssembly file. The WebAssembly file is code that when executed by thebrowser 115, executes anon-HTTP layer 7 protocol client atoperation 226. For instance, an SSH client may be compiled into the WebAssembly file and therefore an SSH client may be executed within the browser. Depending on thenon-HTTP layer 7 protocol client application, the user may be required to authenticate with thenon-HTTP layer 7 protocol service. For instance, if the client application is an SSH client, the user may need to authenticate with the remote SSH server. The available authentication methods vary based on server configuration but may include password authentication (e.g., through a prompt to the user), public key authentication (e.g., through a prompt to the user), or automatically through a certificate authentication. - In a certificate authentication method, the
non-HTTP layer 7 protocol client generates a keypair and sends a request with the public key to a signing endpoint (e.g., part of the distributed edge compute and routing service and may be executed on the compute server 120). The request may also include a token that is issued during login that proves the user has been authenticated. The signing endpoint generates a signed certificate and returns it to thenon-HTTP layer 7 protocol client. The signed public key and the generated private key are used to authenticate with the remote SSH server. This certificate may be valid for a relatively short period (e.g., minutes). - Sometime later, at
operation 228, the non-HTTPL7 protocol client 118 executing within thebrowser 115 transmits data that is related to thenon-HTTP layer 7 protocol service and that data is received at thecompute server 120. The data is transmitted using the protocol of thenon-HTTP layer 7 protocol service. For example, if the client application is an SSH client, the data is transmitted in accordance with the SSH protocol. The data may be transmitted over a WebSocket between theclient device 110 and thecompute server 120. The transmission uses alayer 4 protocol such as TCP or UDP. In an embodiment, the index page may cause a client-side script (e.g., JavaScript) to be downloaded that initiates the WebSocket connection and draws the page. This client-side script may send data from the WebSocket to and from the WebAssembly code that implements the majority of the logic for the non-HTTPL7 protocol client 118. - The
compute server 120 receives thenon-HTTP layer 7 protocol service data. Thesecurity service 125 may perform one or more actions after receiving the data. In an embodiment, thesecurity service 125 applies the set of one or more policies to determine whether the data or the requested connection is allowed. In an embodiment, in addition to or in lieu of applying the policies, thesecurity service 125 performs thelog capture operation 230 where thesecurity service 125 may log, record, and/or report the session data of thenon-HTTP layer 7 service. For instance, each event of the session may be logged, recorded, and/or reported. The event(s) may be configured by the operator of thenon-HTTP layer 7 service. The logged and/or recorded data can be sent to an external storage location (e.g., the data may be batched and sent in intervals). - The
compute server 120 proxies thelayer 4 packets received over the WebSocket to thenon-HTTP layer 7service 138. For instance, theL4 proxy service 128 proxies thelayer 4 packets received over the WebSocket over theL4 tunnel 152 to theL4 proxy client 135 atoperation 232. TheL4 proxy client 135 receives the data and forwards the data to the non-HTTPL7 protocol service 138 atoperation 234. - The
non-HTTP layer 7protocol service 138 may transmit data to thenon-HTTP layer 7protocol client 118. Thus, atoperation 236, thenon-HTTP layer 7protocol service 138 transmits data related to the session. The data is received at theL4 proxy client 135 that forwards the data at operation 238 over theL4 tunnel 152 to theL4 proxy service 128. TheL4 proxy service 128 forwards the traffic to thesecurity service 125. Thesecurity service 125 may perform one or more actions after receiving the data such as performing thelog capture operation 240 where thesecurity service 125 may log, record, and/or report the session data of thenon-HTTP layer 7 service. The data is transmitted to thenon-HTTP layer 7protocol client 118 atoperation 242 over the WebSocket. - The embodiment shown in
FIG. 2 proxies thelayer 4 packets over an existing L4 tunnel. However, embodiments are not so limited. If an L4 tunnel does not exist between thecompute server 120 and theprivate network 130, an L4 tunnel can be created. - In some embodiments, the
compute server 120 that receives traffic from theclient device 110 does not have a tunnel established with the non-HTTP L7 protocol service; instead, a different compute server of the distributed edge compute and routing service may have an established tunnel to the non-HTTP L7 protocol service. In such a case, thecompute server 120 may route the traffic toward the computed server that is connected with an L4 tunnel to the non-HTTP L7 protocol service. There may be many compute servers (along with other network equipment) between the compute server that initially receives the traffic and a compute server with a tunnel for the non-HTTP L7 protocol service. For instance, if an origin server is in London and a tunnel is created from a compute server in London to the origin server, and traffic is sent from a client device in California that is received at a compute server in California, the traffic may be routed over multiple compute servers between California and London. - In an embodiment, in conjunction with establishing a tunnel, routing rules are installed in the compute servers of the distributed edge compute and routing service to reach the tunneled destination. In an embodiment, the routing between compute server(s) is performed intelligently based on traffic information (e.g., latency, packet loss data) gathered from other requests that traverse the distributed edge compute and routing service. This allows the distributed edge compute and routing service to pick the best path to the non-HTTP L7 protocol service (e.g., the fastest, most reliable, etc.) depending on current network conditions. In an embodiment, the routing between compute server(s) is based on carrier information. For example, some of the IP address(es) assigned to the tunnel may be from different carriers that may have different routes that can be taken through the distributed edge compute and routing service. The routing may find the optimal path to the non-HTTP L7 protocol service based on which carrier is selected for the routing, which may be based on factors such as speed, reliability, and/or cost. For instance, the prices of different cloud providers can be monitored (the prices can change relatively quickly depending on demand and sales) and the cheaper route can be taken.
-
FIG. 3 is a flow diagram that illustrates exemplary operations for executingnon-HTTP layer 7 protocol applications in the browser according to an embodiment. Atoperation 305, thecompute server 120 receives a request from a browser 115 (e.g., an HTTP/S request) for a resource identified at a domain. Next, atoperation 310, thecompute server 120 determines, based on a set of one or more policies configured for the domain, that the request is allowed to be processed. The one or more policies may be based on one or more of identity, device posture, location, and/or risk signals. If the request was not allowed to be processed, then the request would not be processed (e.g., the request would be dropped). - Next, at
operation 315, thecompute server 120 transmits to the browser 115 a response to the request, where the response includes code that when executed by thebrowser 115, causes anon-HTTP layer 7 protocol client to be executed, where that client communicates with anon-HTTP layer 7 protocol service at an external network. In an embodiment, the code is in a WebAssembly format. In an embodiment, thenon-HTTP layer 7 protocol client is an SSH client, and thenon-HTTP layer 7 protocol service is an SSH server. The SSH client may execute in a tab of thebrowser 115. Depending on thenon-HTTP layer 7 protocol client, the user may be required to authenticate to thenon-HTTP layer 7 protocol service. Thenon-HTTP layer 7 protocol client may present a login prompt to the user and/or a public key prompt to the user for authentication. A certificate generation and authentication may also be performed automatically that allows the user to begin using the application without providing login details. - Next, at
operation 320, thecompute server 120 receives, from thenon-HTTP layer 7 protocol executing in thebrowser 115, data related to thenon-HTTP layer 7 protocol service. The data is transmitted using the protocol of thenon-HTTP layer 7 protocol service. For example, if the client application is an SSH client, the data is transmitted in accordance with the SSH protocol. The data may be transmitted over a WebSocket between theclient device 110 and thecompute server 120. The transmission uses alayer 4 protocol such as TCP or UDP. In an embodiment, the compute server performs logging and/or recording of the data received from thenon-HTTP layer 7 protocol client executing in the browser. The logged and/or recorded data may be transmitted to a storage location for later retrieval. - Next, at
operation 325, thecompute server 120 proxies the data related to the non-HTTP L7 protocol service over theL4 tunnel 152 that is interfaced with the non-HTTP L7 protocol service. For instance, theL4 proxy service 128 proxies thelayer 4 packets received over the WebSocket over theL4 tunnel 152 to theL4 proxy client 135. TheL4 proxy client 135 receives the data and forwards the data to the non-HTTPL7 protocol service 138. -
FIG. 4 illustrates a block diagram for an exemplarydata processing system 400 that may be used in some embodiments. One or more suchdata processing systems 400 may be used to implement the embodiments and operations described with respect to the compute servers or other computing devices. Thedata processing system 400 is a computing device that stores and transmits (internally and/or with other computing devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media 410 (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals—such as carrier waves, infrared signals), which is coupled to the processing system 420 (e.g., one or more processors and connected system components such as multiple connected chips). For example, the depicted machine-readable storage media 410 may storeprogram code 430 that, when executed by the processor(s) 420, causes thedata processing system 400 to perform any of the operations described herein. - The
data processing system 400 also includes one or more network interfaces 440 (e.g., a wired and/or wireless interfaces) that allows thedata processing system 400 to transmit data and receive data from other computing devices, typically across one or more networks (e.g., Local Area Networks (LANs), the Internet, etc.). Thedata processing system 400 may also include one or more input or output (“I/O”)components 450 such as a mouse, keypad, keyboard, a touch panel or a multi-touch input panel, camera, frame grabber, optical scanner, an audio input/output subsystem (which may include a microphone and/or a speaker), other known I/O devices or a combination of such I/O devices. Additional components, not shown, may also be part of thesystem 400, and, in certain embodiments, fewer components than that shown in one or more buses may be used to interconnect the various components shown inFIG. 4 . - The techniques shown in the figures can be implemented using code and data stored and executed on one or more computing devices (e.g., a compute server, a client device, an origin server). Such computing devices store and communicate (internally and/or with other computing devices over a network) code and data using computer-readable media, such as non-transitory machine-readable storage media (e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; phase-change memory) and transitory machine-readable communication media (e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals, digital signals). In addition, such computing devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-transitory machine-readable storage media), user input/output devices (e.g., a keyboard, a touchscreen, and/or a display), and network connections. The coupling of the set of processors and other components is typically through one or more busses and bridges (also termed as bus controllers). Thus, the storage device of a given computing device typically stores code and/or data for execution on the set of one or more processors of that computing device. Of course, one or more parts of an embodiment of the invention may be implemented using different combinations
- In the preceding description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.
- References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether explicitly described.
- While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
- While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.
Claims (24)
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/559,994 US11489909B1 (en) | 2021-04-15 | 2021-12-22 | Non-HTTP layer 7 protocol applications running in the browser |
US17/956,695 US11909808B2 (en) | 2021-04-15 | 2022-09-29 | Non-HTTP layer 7 protocol applications running in the browser |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US202163175525P | 2021-04-15 | 2021-04-15 | |
US17/559,994 US11489909B1 (en) | 2021-04-15 | 2021-12-22 | Non-HTTP layer 7 protocol applications running in the browser |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/956,695 Continuation US11909808B2 (en) | 2021-04-15 | 2022-09-29 | Non-HTTP layer 7 protocol applications running in the browser |
Publications (2)
Publication Number | Publication Date |
---|---|
US20220337654A1 true US20220337654A1 (en) | 2022-10-20 |
US11489909B1 US11489909B1 (en) | 2022-11-01 |
Family
ID=83602972
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/559,994 Active US11489909B1 (en) | 2021-04-15 | 2021-12-22 | Non-HTTP layer 7 protocol applications running in the browser |
US17/956,695 Active US11909808B2 (en) | 2021-04-15 | 2022-09-29 | Non-HTTP layer 7 protocol applications running in the browser |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/956,695 Active US11909808B2 (en) | 2021-04-15 | 2022-09-29 | Non-HTTP layer 7 protocol applications running in the browser |
Country Status (1)
Country | Link |
---|---|
US (2) | US11489909B1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116319763A (en) * | 2023-05-19 | 2023-06-23 | 北京长亭科技有限公司 | File uploading method and device based on WASM technology |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011130038A2 (en) * | 2010-04-15 | 2011-10-20 | Microsoft Corporation | Method and system for reliable protocol tunneling over http |
US20140372509A1 (en) * | 2013-06-14 | 2014-12-18 | Andrew T. Fausak | Web-based transcoding to clients for client-server communication |
US20140372508A1 (en) * | 2013-06-14 | 2014-12-18 | Andrew T. Fausak | Native client tunnel service for client-server communication |
WO2018096232A1 (en) * | 2016-11-28 | 2018-05-31 | Wallix | Integration of a standard network protocol layer in a web browser by compilation to webassembly and use of a websocket |
US10958662B1 (en) * | 2019-01-24 | 2021-03-23 | Fyde, Inc. | Access proxy platform |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100154055A1 (en) * | 2008-12-12 | 2010-06-17 | At&T Intellectual Property I, L.P. | Prefix Domain Matching for Anti-Phishing Pattern Matching |
US8701180B2 (en) * | 2009-12-04 | 2014-04-15 | Sap Ag | Securing communications between different network zones |
US9560036B2 (en) * | 2010-07-08 | 2017-01-31 | International Business Machines Corporation | Cross-protocol federated single sign-on (F-SSO) for cloud enablement |
US10362059B2 (en) * | 2014-09-24 | 2019-07-23 | Oracle International Corporation | Proxy servers within computer subnetworks |
US11102238B2 (en) * | 2016-04-22 | 2021-08-24 | Sophos Limited | Detecting triggering events for distributed denial of service attacks |
WO2018225158A1 (en) * | 2017-06-06 | 2018-12-13 | ヤマハ株式会社 | Communication device, relay device, information processing system, and communication system |
-
2021
- 2021-12-22 US US17/559,994 patent/US11489909B1/en active Active
-
2022
- 2022-09-29 US US17/956,695 patent/US11909808B2/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2011130038A2 (en) * | 2010-04-15 | 2011-10-20 | Microsoft Corporation | Method and system for reliable protocol tunneling over http |
US20140372509A1 (en) * | 2013-06-14 | 2014-12-18 | Andrew T. Fausak | Web-based transcoding to clients for client-server communication |
US20140372508A1 (en) * | 2013-06-14 | 2014-12-18 | Andrew T. Fausak | Native client tunnel service for client-server communication |
WO2018096232A1 (en) * | 2016-11-28 | 2018-05-31 | Wallix | Integration of a standard network protocol layer in a web browser by compilation to webassembly and use of a websocket |
US20210099553A1 (en) * | 2016-11-28 | 2021-04-01 | Wallix | Integration of a standard network protocol layer in a web browser by compilation to webassembly and use of a websocket |
US10958662B1 (en) * | 2019-01-24 | 2021-03-23 | Fyde, Inc. | Access proxy platform |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116319763A (en) * | 2023-05-19 | 2023-06-23 | 北京长亭科技有限公司 | File uploading method and device based on WASM technology |
Also Published As
Publication number | Publication date |
---|---|
US20230199055A1 (en) | 2023-06-22 |
US11489909B1 (en) | 2022-11-01 |
US11909808B2 (en) | 2024-02-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11316825B2 (en) | Establishing and using a tunnel from an origin server in a distributed edge compute and routing service | |
US12034854B2 (en) | Providing single sign-on (SSO) in disjoint networks with non-overlapping authentication protocols | |
US11818279B2 (en) | Certificate authority (CA) security model in an overlay network supporting a branch appliance | |
US11838271B2 (en) | Providing users secure access to business-to-business (B2B) applications | |
US10097523B2 (en) | Method and system for providing secure remote external client access to device or service on a remote network | |
US11425216B2 (en) | Virtual private network (VPN) whose traffic is intelligently routed | |
US20190297161A1 (en) | Traffic forwarding and disambiguation by using local proxies and addresses | |
US10187356B2 (en) | Connectivity between cloud-hosted systems and on-premises enterprise resources | |
US20090260074A1 (en) | System and method for application level access to virtual server environments | |
US11895149B2 (en) | Selective traffic processing in a distributed cloud computing network | |
US11894947B2 (en) | Network layer performance and security provided by a distributed cloud computing network | |
CN113678410A (en) | Computing system and related method for providing connection lease exchange and mutual trust protocol | |
US11909808B2 (en) | Non-HTTP layer 7 protocol applications running in the browser | |
US20240314106A1 (en) | Securing an application or service over a network interconnect using a dedicated egress ip address | |
US20230412638A1 (en) | Systems and methods for providing a native browser experience for Cloud Browser Isolation (CBI) environments |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: CLOUDFLARE, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:KOENIG, KILLIAN;KNECHT, DANE ORION;ROYAL, JAMES;SIGNING DATES FROM 20211221 TO 20211222;REEL/FRAME:058465/0541 |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
FEPP | Fee payment procedure |
Free format text: ENTITY STATUS SET TO MICRO (ORIGINAL EVENT CODE: MICR); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
AS | Assignment |
Owner name: CITIBANK, N.A., TEXAS Free format text: SECURITY INTEREST;ASSIGNOR:CLOUDFLARE, INC.;REEL/FRAME:067472/0246 Effective date: 20240517 |