It's a Trap!

It seems almost impossible, but it is true: We landed people on the moon before we put wheels on luggage. Neil Armstrong stepped on the moon on July 20, 1969. The first patent granted for wheeled luggage was issued in 1972. In 2023, Atsign was granted a patent for a new way to communicate across the Internet. Is it a “wheeled luggage” moment?

For decades, networking and security have been synonymous. We have all purchased the latest “solution” (firewalls, VPNs), and now we see AI entering the market with the same promise to make a network secure.

But perhaps we haven’t been approaching the problem from the right angle. Zero Trust Network Architecture (ZTNA), tells us we should never trust the network, even if it is a private network, and we should verify and secure each identity with strong authentication. 

Both are great advice but… 

The trap here is deep inside the networking Internet Protocol itself, and it is also the reason why, after ever increasing spend on Network Security, we still have massive data breaches and CVEs (Common Vulnerabilities and Exposures) on a daily basis.

The problem is that IP networks provide the transportation of data, while the authentication is provided at the application layer. For instance, anything connected to the Internet can connect to your Web Server/RDP/SSH/etc. services and those applications then authenticate you. 

That’s right: Anything on the Internet can reach the service, so if there is a vulnerability in that service—that’s it, game over. Of course, this huge issue has been known about for decades and we have applied bandaids to it. VPNs prevent access to the service unless you can create a “tunnel” to the service. The catch here is that the VPN itself is a service that has to be open to the whole Internet. This problem has been hitting hard with many well known VPN vendors recently. The other approach,firewalls, only allow known IP addresses through to the service. Since you never know the IP address that people in particular are going to come from, the result is cumbersome firewall rules, and, over time, massive unreadable rules. 

The core problem here is that with TCP/IP as a client/server protocol, something has to be listening for connections. If that process has anything of value, it could be compromised. To avoid the trap, no services should be directly exposed (listening) on the Internet, yet anyone with the right identity should be able to access services from anywhere. Any process that is listening should have nothing of value; no unencrypted data and, perhaps more importantly, no encryption keys.

What Atsign has done is solve this fundamental problem. How? By creating a new digital identity called an atSign. An atSign is the combination of a unique string and a set of cryptographic keys that are created by the owner of the atSign. Instead of creating a VPN tunnel, atSigns communicate and authenticate with each other without the Internet service having to be exposed to the Internet at all. Once an atSign has been authenticated and authorized, both the client machine and the service meet at a rendezvous point. The client and the Server are now connected via an end-to-end encrypted connection with keys that only they know. At this point, the client application, for example, a web browser, and the service, for example, a web server, can communicate normally (but via a localhost interface). 

This may sound similar to existing solutions, but it's fundamentally different. The litmus test to ask is, “What ports are open?” and, “How do you authenticate and authorize TCP/IP socket connections?”

Atsign’s answers are equally simple: “No ports are open on client or server” and “With strong public key encryption”.

You need a simple solution to the complexity and hard work of securing Internet communication. Put “wheels” on your Internet connections!