alexmensch

Hi Everyone! We launched Twingate on Show HN 6 months ago. Excited to share more about a concept we’re calling “Identity-First Networking” and a bunch of product enhancements & partnerships.

While most SaaS applications have already moved to SSO and Identity based controls, Twingate extends SSO and identity-based access to everything else on your private networks - private admin interfaces, servers, databases, k8s clusters, etc..

Also, with every network connection authenticated against a central user identity and authorized by security policies defined in Twingate, we also provide an identity-first view of private network flow. All private traffic is always directly associated with user identity, including the authorization rule that allowed the connection, network path information, data volume transferred, and port details. This provides an auditable record for compliance needs, investigating incidents, etc..

Twingate is free to try it out and we’d love to get your feedback!

The most important factor in this decision is maintaining separation of concerns between user authentication (identity provider) and network authorization (Twingate). Since we rely on an identity authority for access, if the user--or an attacker--is unable to authenticate themselves, we can't allow a network connection to proceed, keeping the destination resources safe. This is even more important for customers using an identity provider like Okta, allowing them to continue managing all of their users centrally.

Gotcha. In your example: nothing. We're okay with that. The level of security that results from the setup you described is what we are hoping Twingate will bring to people with convenience and ease of management built-in. I'm always amazed at the very wide range of sophistication that different teams and companies approach security with, and very, very few companies are at the level of your example. That's what we're excited to help change with this new product.

The client (the Twingate app on the user’s device) actually runs a transparent TCP proxy, so we’re just forwarding TCP payloads to the connector at the other end of the tunnel. This avoids the “TCP meltdown” problem of a TCP-in-TCP connection and also why we support any higher level protocol without any special configuration. (By the way, the client also runs a transparent UDP proxy.)

These are all valid points, and we’re keenly aware that trust is central to our offering. On the subject of trust, I’d love to get your take on my response to hlieberman’s comment as I agree that it’s very important.

On the pricing front, our goal is to make the service cost-competitive when you take into account the positive security externalities, but in particular the huge time sink that teams and companies put into deploying, distributing and managing a typical VPN solution. This is a big reason why we’re so focused on ease of use.

Re:BeyondCorp, I brought it up as a comparison point in my blog post, but I don’t want to appear to be making claims that our product is currently a 1:1 BeyondCorp replacement. One of the next things on our roadmap is to start exposing device inventory and posture checks as management options in the product to start getting closer to a full BeyondCorp-like offering.

However, a key insight we had in working with early beta customers is that there is significant pain to address even without getting all the way to a full zero trust / BeyondCorp state. That’s a big reason we decided to launch our product now, even before we’ve had the opportunity to add functionality we know will need to be added in the future.

Could you clarify a bit on "out of band" in this use case? In principle, if you have a way to access your bastion on a completely private--maybe physically separate / leased line--network, then that's going to be extremely secure, but maybe you had a different use case in mind?

Our general approach is to rely on widely-used delegated trust mechanisms (eg. OAuth, SAML, CAs, etc.) and from our perspective the more of that we can do the better, as it helps decentralize control mechanisms and improve overall security. Ultimately, you’re absolutely right that it comes down to trust, and we’re very aware of that.

Like most aspects of security, it’s about assessing the tradeoffs involved. From our standpoint, our interests are completely aligned with our users—earning their trust by keeping them secure benefits us, too. When you compare that to the security risks inherent to VPN (implicit total trust of devices, granting access based on joining a network, etc.) for the complexity of remote access today, what we’re hearing from our initial customers is that it’s a no-brainer.

The best analogy I can think of is Okta. Theoretically, Okta could arbitrarily authorize access to any of your internal applications, but from their customers’ standpoint that potential risk is vastly outweighed by the additional security benefits afforded by SSO.

That said, we definitely want to keep doing everything we can to improve trust in our product. One idea we’ve discussed is allowing our customers to have complete signing authority (on hardware/service entirely under their control) over all tokens in our system. As an example, would that go further to address concerns around trust from your perspective?

This is our very first public launch, and auditing/analytics are next up on our roadmap! Just to be clear, we do not currently and do not plan to intercept any traffic—any client application connections remain encrypted inside of our TLS transport tunnel. What we will be providing is connection-level analytics for Twingate traffic flowing through connectors you deploy on your network. For example, connection start and end times, which authorized user accessed the destination resource and how much data was transferred. How would that fit with your needs?

By the way, this is similar to Cloudflare Access, but we’re protocol agnostic (any TCP or UDP traffic can be proxied) and we don’t require you to change or create any public DNS entries. In fact, our best practice recommendation is that you exclusively use private DNS to cloak your private network.

Hey, great question, and your setup seems very secure, but I’m sure it would be nice to reduce some of the overhead. The right way to support your ephemeral bastion use case with Twingate will ultimately be to use a public API that we plan to launch later this year. That will allow you programmatically deploy connectors as needed.

However, I’d also question whether you even need your ephemeral bastions anymore with Twingate. A big part of the value is that you can do away with any public entry points (even if they are secured as well as you’ve described) and very tightly control who can access hosts on your deeper network. Do your bastions do more than provide access points? For example, session auditing is pretty common.

Currently, yes, we’re focused on connecting users with services, but there’s nothing inherent to the underlying technology that prevents us handling service to service communication in the future. This is a common request, and along with a public API that we plan to release in the future, we think we’ll have a very flexible solution for your use case down the line.

There are similarities in the general approach, but the two biggest differences between us and Teleport are:

1) We support native clients on every major platform (Mac, Windows, iOS, Android and Linux support just a few weeks away) which makes it super easy for anyone in a company or team to gain access without being limited to Linux.

2) Twingate natively proxies any TCP or UDP traffic and we don't care what the underlying protocol is. This is huge given that most teams are using a variety of client applications, protocols and destination servers.