FIELD

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.

BACKGROUND

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 access layer 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.

SUMMARY

Layer 7 protocol (non-HTTP) client applications are executed in the browser. 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. As an example, an SSH client (a non-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. 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.

