Insta-SSL as a simple way to use RDP / VNC / SSH into LANs

July 11th, 2017 Company News

Tldr;

beame.io offers open source tools allowing extremely scalable and simple deployment of the X.509 certs, as well as connectivity solution for devices residing on LANs.  The certs can be used for many purposes: authentication of an IOT device, 2fa, digital signatures etc.  

Below you will learn about new features we’ve just added to one of our most popular products.

beame-insta-ssl is a tool intended to expose applications running on LAN to global network through HTTPS. The tool, as its base service, allows receiving public SSL certs for hashed hostnames, under beame.io domain. These certs are fully trusted by mobile devices and browsers alike. The hashed structure represents a trust tree (defined by yourself), to which only you or those you delegate can add/modify  members.

Now access can be granted to specific resources to specific parts of the tree, and it can be managed.

In this post we present is a feature, allowing you to establish a TCP tunnel from point A to point B, with pretty much as secure as it can get. What can this be used for ? Remote Service and Support, connecting devices using an insecure protocol over WAN infrastructure. Do you have a unique use case for it ? let us know…

Many of you, beame-insta-ssl users, have asked for it and now it is here. This means you can use it now for secure remote access/support of desktops, IoT devices, and servers alike, yes you can use it to fix your mom’s computer, if you can get her through the installation of nodejs. (-. We will make this easy and deployable with one click. I promise.

We are launching new versions of beame-sdk & beame-insta-ssl (comes in single installation of insta-ssl). New key features are now being exposed.

TCP-2-TCP Tunnelling

Background: We want to transmit data over the public internet, between point A and point B. The data can be any TCP payload, so RDP, VNC, SSH, DICOM,  HL7 or anything else just fit into it.

Till today there was simply no technical option without addition of the remote segment as a network through a (a) VPN connection or (b) intermediate breaking the crypto in between like all remote support tools.

We are now proposing a secure, simple, easy and cheap mechanism to establish a TCP connection between points A and B, with end to end security using standard TLS as a transport, over an untrusted network, without a need for a VPN. This is easy, manageable and cheap.

To understand the core problem in today’s access model, please consider the following:

Suppose you are deploying a device, a router, a robot, you install it at a customer, and now you want to access the device, for service and maintenance.  You have lots of techs, they come and go, how do you manage this secure vendor access?

 

Tree Based Trust

Suppose the following model:

 

This is a layer-structured tree, with L0 (Level zero) being its top. Current solution allows any node on the tree, to define its trust criteria, by choosing the desired top (highest level up to L0and depth (number of layers beneath the node).

 

How does it work?

Connection diagram:

Description of the flow

beame-insta-ssl is started with its destination being localhost:22. Upon launch beame-insta-ssl will register its endpoint for global access through the beame-router. This endpoint is capable of receiving signed TLS traffic which will relay the traffic over the websocket connection to the beame-insta-ssl on the client side. Then at some point in time user will start  the beame-insta-ssl client and the connection will be created between the two insta-ssl instances, using client auth and the trust tree logic for authentication. Next, user will start an SSH client pointing to the localhost, at port to which the client beame-insta-ssl is bound.

Wait there is a client ?

Yes. This use case is specifically intended for insecure protocols, such as DICOM for example, which simply can not go unencrypted. So if you want client-less – you https from a browser, this is to get data from point A to B safely.  The good thing that beame-insta-ssl comes with both client and server components in the main repository.

 

But there is SSH already?

Yes, and this comes as a layer below SSH. SSH requires port 22 which is closed  in most enterprise environments. The way how this would work with SSH is – you would require a server accessible to both sides, and you would have to map a machine to a specific local port. The end user keys have to be individually inserted into each of the target machine, and keys of the target machines on the proxy.  All of this is easily done for one or two boxes, beyond then it becomes a gigantic pain. Beame addresses the issue and secures it at the tunnel level.

 

What is the big advantage of beame ?

Major differences :

  1. No man in the middle by design
  2. Easy management of access
  3. Easy tools for management of access, and trust based on crypto.
  4. This is as secure as any tunneling technology is going to get.

 

How do you get this to work

Suppose you are accessing a machine that resides on LAN by ssh:

** Prerequisites: node 6.9.x installed

ON THE SERVER SIDE

  1. Install beame-insta-ssl by:
    npm install -g beame-insta-ssl
  2. Register at https://ypxf72akb6onjvrq.ohkv8odznwh5jpwm.v1.p.beameio.net/insta-ssl
  3. Run the command from the email and voila you have L0 credential
  4. Now generate the token for your client device:
    beame-insta-ssl creds getRegToken --fqdn fqdn-you-just-got
  5. Copy the reg token, and somehow securely deliver it to the client machine
  6. Start the tunnel host by running:
    beame-insta-ssl tunnel make --dst 22 --proto tcp --fqdn YOURL0 --highestFqdn YOURLX --trustDepth 3 --noAuth false

Lets dig in and understand this:

— dst — destination port to which traffic will be forwarded (22 is for SSH)

— proto — (tcp/http/https)

— highestFqdn — VERY IMPORTANT: the FQDN of the most senior ancestor which, if found in the certificate chain of client cert, will allow him access.

— trustDepth — how many generations of child nodes (created below your cred) will you trust

noAuth — set it true if you do not require client authentication or just skip it

ON THE CLIENT SIDE

  1. Run if there’s no insta-ssl yet (skip this step if you have it):
    npm install -g beame-insta-ssl
  2. Then run using the TOKEN you got on step 5 above (this will create client cert):
    beame-insta-ssl creds getCreds --regToken TOKEN
  3. Now lets create actual client to connect to our host
    beame-insta-ssl client make --dst 1234 --fqdn myclientcert.v1.d.beameio.net --src YOURL0
  4. Start ssh client in shell:
    ssh 127.0.0.1 -p 1234

At this point you tunnel should be up and running and ready to receive connections

RDP? Just replace port number in the example above with 3389, and instead of the last step run RDP client application with pre-configured Username/Password to 127.0.0.1

Such tunnel runs all the way over standard TLS and is available over global network to any requestor that holds valid credential.

And for the end: If you didn’t spot it – Yes, it supports unauthenticated connections if such needed. Just use –noAuth true on server-side and you can skip client cert (–fqdn) for tunnelClient and all related to authentication on server.

Distributed as open source. Install now from npm. Get sources on beameio-github

Recent Posts

Private cloud is easy

PKI based identity on a blockchain

VMs, Docker and Beame.io vs NSA

x.509 based identity, OS level or dedicated application?

SSO and custom Identity Providers