Browser-Based SSH Client via Layer 4 Proxy Tunnel
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Non-HTTP layer 7 protocol applications, such as SSH and RDP, face challenges in security, integration with single sign-on, and data control due to their reliance on private networks and legacy authentication methods, and existing solutions like GRE tunneling and VPNs are cumbersome and inflexible.
Innovation Solution
A non-HTTP layer 7 protocol client application executes in the browser, connecting to a compute server that proxies layer 4 packets to the origin network, allowing users to interact with services like SSH without client-side configuration or agents, using WebAssembly for execution and applying policies based on identity, device posture, and risk signals.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If GRE tunnel or VPN is used to secure services and hide origin, then security and origin masking are improved, but device complexity and implementation time increase
Solution Approach 1:
The patent introduces a cloud-based gateway as an intermediary between the SSH client and the SSH server. This gateway handles the complex tunneling and encryption operations, masking the origin server while providing secure access. The gateway acts as a mediator that simplifies the client-side implementation while maintaining security and origin protection.
2Ease of operation
If non-HTTP layer 7 protocol applications are exposed to the general internet, then accessibility is improved, but security and vulnerability to attacks worsen
Solution Approach 1:
The cloud gateway serves as a secure intermediary that allows SSH clients to access servers on the general internet without exposing the servers directly to internet attacks. The gateway handles authentication, encryption, and traffic filtering, enabling broad accessibility while protecting the origin servers from direct exposure to internet threats.
3Adaptability or versatility
If SSH clients execute in the browser using an agent at an intermediary device, then browser-based SSH access is enabled, but the solution becomes cumbersome and flexibility decreases
Solution Approach 1:
The patent extracts the SSH client functionality from traditional thick client applications and implements it directly in the browser using web technologies. This eliminates the need for separate agent installations on intermediary devices, as the browser itself becomes the execution environment for SSH operations, reducing complexity while maintaining browser-based accessibility.
4Ease of operation
If legacy authentication methods like SSH keys and passwords are used, then authentication functionality is provided, but integration with single sign-on and data control capabilities are lost
Solution Approach 1:
The cloud gateway implements a universal authentication system that supports multiple authentication methods including traditional SSH keys and passwords, while also integrating with modern single sign-on providers. The gateway acts as a multi-functional authentication hub that maintains backward compatibility with legacy methods while enabling forward compatibility with enterprise SSO systems and device posture requirements.
Data Source
AI summary
A server receives from a browser executing on a client device an HTTP request. The server transmits a response to the HTTP request to the browser. The response includes code that when executed by the browser, executes a non-HTTP layer 7 protocol client that communicates with a non-HTTP layer 7 protocol service at an external network. The server receives, from the non-HTTP layer 7 protocol client executing in the browser, data related to the non-HTTP layer 7 protocol service. The server proxies the data related to the non-HTTP layer 7 protocol service over a layer 4 tunnel that is interfaced with the non-HTTP layer 7 protocol service. The server logs event data received from the non-HTTP layer 7 protocol client executing in the browser.