Introducing Private Sockets - Hiding your private resources
In this blog, we’re introducing a new feature called “private sockets” to solve for the use-case where you’d like your sockets to remain hidden and not visible in the public DNS system. With this, we’re also taking our first steps into a more advanced client, which will allow for more client-side innovation as we progress.
The video and the blog post below demo and explain what "private sockets" are and how to use them.
Learn more about private sockets in this demo video
The use-case for Private Socket
The case for private sockets is a direct result of conversations with our users; The two examples below were cases that motivated this new feature.
Keeping your resources invisible.
For many users, it’s a requirement for their corporate resources to remain hidden and all access is fully authenticated and logged. This means that ideally, no public DNS record exists for the resources.
Migration scenarios, Migrating to a cloud-delivered zero-trust private access solution.
Imagine today your users are accessing wiki.corp.com which is hosted in your private data center, reachable via 10.10.10.10. Meaning it’s reachable only when on the VPN or otherwise on the corporate network. Recognizing that the traditional VPNs are no longer ideal, the security and IT team move to Mysocket. Big bang moves are challenging, so what the team really wants is the ability for the legacy and new solution to co-exist in parallel. This should be done without changing the existing DNS records. This allows for easy testing and migration without the need to choose one of the other.
Private sockets provide a solution for both use-cases by bypassing the traditional public DNS system. This means the name for A Private Socket doesn’t need to be resolvable via the traditional means. It also ensures that only those users that are authenticated can resolve the DNS name, assuming the policy allows them to.
Although ZTNA cloaks services from discovery and reconnaissance, it erects true barriers that are proving to be more challenging for attackers to circumvent than older notions of simple obfuscation.
A Smarter Client
Until recently, our focus has been to provide a beyond-corp-style private-access solution without the need for a client. I.e. be as lightweight as possible and super easy for users to consume resources on mysocket on any device, any time, anywhere. However, as we venture into more advanced use-cases we are now also making the mysocket client more advanced.
The Mysocket client will run on all devices that need access to these private sockets. The mysocket client will make sure that the "hidden" private DNS names can be used by authenticated and authorized users. With the mysocket client installed on the users' device, we can bypass the traditional public DNS system and make private sockets work.
Use any DNS name you want
One of the cool side effects of bypassing the traditional DNS system is that you can now use any name you want, as long as you register it with Mysocket in your account.
Installing the client
To benefit from “private sockets” we’ve extended the mysocketctl client with a few more commands and the ability to run it as a service. Clients that are visiting your private sockets need to have the mysocketctl service installed; this is as easy as:
$ sudo mysocketctl client service install Install MySocket.io Service: [ OK ] Starting MySocket.io Service [ OK ] # check the service staus: $ sudo mysocketctl client service status Service (pid 38579) is running...
Next up, the client will need to login like below:
$ mysocketctl client login --org firstname.lastname@example.org Login successful #check login status: $ mysocketctl client login status Token Valid, logged in as email@example.com
The org parameter is the organization identifier; for now, we’re using the mysocket admin email that owns the resources as a placeholder for the organization identifier. The plan is to change this to a more user-friendly name soon, in this example that could be "corp.com". Think of this as a similar action as logging in with your VPN client.
This will cause a browser window to pop up, and the user will be guided through the login experience. In the background, the mysocket service will continuously check in with the mysocket API and make sure that the private sockets in this organization are now DNS resolvable, assuming the user is authorized by the policy to have access to this socket. The result is that these private names are now visible and usable for authenticated users without the need of having a traditional public DNS record.
Custom TLS certificates
Private sockets are hidden and not resolvable for unauthenticated and unauthorized users. This makes it not possible for us to automatically generate (letsencrypt) TLS certificates for your socket. To work around that, we’ve added the ability to upload your own custom public / private key pair to your socket. This will make sure you can still provide TLS enabled services while also taking advantage of private sockets.
Wrapping up and Looking forward
In this blog, we introduced the new private socket feature, allowing you to keep your DNS names private, further increasing your security posture. As part of that, we extended the mysocket client with new functionality, taking our first steps into the world of smarter clients. Keep in mind that for now, the client has only been tested on macOS. I’m looking forward to testing on Windows and adding support for that as well. Now that we have a smarter client running as a service in the background, this opens up a few more capabilities, such as posture checks, or even mesh-VPN, and more for future enhancements. Stay tuned!
Private Socket Demo