We are renewing our Cybersecurity insurance for the first time since adding Twingate to replace some StS VPN links. I’ve explained that in our opinion we are safer since we now only allow access to specific resources rather than entire networks and in any event, it is safer than a misconfigured VPN.
They are concerned that traffic is sent through TG relays and I can see their concern - except in our case, that rarely happens. Relays are used to set up the connection then its direct between connectors.
I have sent the insurance company copies of TG’s security posture and they are reviewing it. Anyone else have any recommendations on how to keep cybersecurity insurers happy?
As I understand it, point to point communications are encrypted, so the relays are not a weak point. The relays don’t have any special access to the encrypted packets that are passed through them.
Encrypted packets are already being relayed across the untrusted Internet, and I don’t think Twingate’s relays present any additional risk.
Twingate is as secure as these things come. I work in a high security industry and we specifically chose Twingate because of their security. Having Twingate has also helped us check off a lot of boxes on various security assessments. We are pursuing FedRAMP in the next year so having strong vendors in terms of security is critical for us.
Great question! I wonder if we should do a quick write-up of security in Twingate actually…
I’d break down how secure Twingate is the following way (especially compared to a more traditional VPN):
Attack surface: no inbound open port required: this prevents anyone from discovering a VPN gateway of sorts and trying to either brute force access or exploit a vulnerability of it.
Integrated device security: since Twingate takes into account the context of the connecting device, credentials and MFA are not enough to access the most critical resources
Bast radius: if configured properly, each user should only be able to see what they have legitimate access to and nothing else. Port or host scanning won’t work, preventing lateral movement and limiting the bast radius of any attempt
Encryption: the Relays often come up here as a question from folks. Here is the quick overview on that:
The primary role of Relays is to establish P2P tunnels between Clients and Connectors (they act as STUN servers and use NAT traversal to do so). Their secondary role is to relay traffic between Clients and Connectors if P2P cannot be established.
All communications between all parties are systematically encrypted (regardless of P2P or Relay)
Communication between Clients and Connectors (which are both hosted by the customer and not by Twingate) are encrypted using TLS1.2 (which implies both asymmetric and symmetric encryption with keys generated / shared between them only and with no involvement of the Relays).
Is it not TG controlling the auth tokens generation, tracking them… Possibly forging new hidden “passepartout” ones a major flow of their “Zero Trust” model?
I have a serious question and I have been managing networks and clients nearly 30 years so I’ve been around the block a few times. All the security that twingate offers and talks about sounds great, but what happens if they’re hacked? Let’s say their internal systems are compromised by a very good and very malicious third-party…would that third party gain access to customer connections? Before you say no and talk about encryption do you know what you say to be absolute fact?
Also, could a simple code mistake such as the recent Crowdstrike issue expose customer connections?
The comment about “allows access to only certain network resources” didn’t sit well with me because that is irrelevant…said resources are connected via the network, therefore, one could assume could be jumped to other network resources. I would rather stop an intruder at the front gate before they’re in the building is my point.
So, what are the serious thoughts about potential exposure here? We live in a world where anything is possible and having third-party connectors inbound to data repositories just seems like a really bad idea.
Data-carrying traffic may pass through Relays on a transient basis and Relays do not store any traffic or network-identifiable information. Traffic that passes through a Relay has already been encrypted, since the Relay is essentially a hop along the end-to-end encrypted TLS tunnel between the Client and Connector. No data-carrying connections are terminated at the Relay.
I have similar concerns here. twingate in theory has all our keys (I assume if I can see them on the webpage, they have a copy somewhere too), so what prevents an adversary from conducting mitm if they are on the relays? they have to find the keys which are probably hosted within twingate infrastructure right? what about an SSL “break and inspect” type of attack?
u/cublainc u/Polyphemus10, I am not a Twingate expert, but I understand that the Twingate Client and Connector, whether peer-to-peer or via Relays, are using end-to-end session encryption (using a public key from its self-signed certificate) so that nothing between them, including any Relays, can decrypt packets.
What I do not know is if you can bring you own keys/CA, rather than having Twingate manage them.
I work on the open source OpenZiti project - https://openziti.io/. We use mTLS between each hop and E2EE between source and destination. While Ziti includes its own PKI, you can bring you own so that you maintain your own keys, rather than whoever may be hosting the solution for you. In this way, they attacks you mention are not possible.
Twingate is like a private tollway on a freeway, and TeamViewer is like a railroad. Both are transportation, but that’s where the similarities stop.
Twingate provides you with a secure connection to a remote network (like an office network). You still need to use other software to communicate over this secure connection in whatever way you want (remote desktop, SSH, webpages, file shares, etc.)
TeamViewer exclusively provides a method to screen share and transfer files to any computer with the TeamViewer client installed. It’s very simple, but has proven to be highly insecure due to TeamViewer’s bad business practices to eavesdrop your connection.