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.
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?
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 L0) and depth (number of layers beneath the node).
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.
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.
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.
Major differences :
Suppose you are accessing a machine that resides on LAN by ssh:
** Prerequisites: node 6.9.x installed
ON THE SERVER SIDE
npm install -g beame-insta-ssl
beame-insta-ssl creds getRegToken --fqdn fqdn-you-just-got
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
npm install -g beame-insta-ssl
beame-insta-ssl creds getCreds --regToken TOKEN
beame-insta-ssl client make --dst 1234 --fqdn myclientcert.v1.d.beameio.net --src YOURL0
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.