Live data from Hacker News

Show HN: Twingate – A modern solution for remote access

twingate.com

31–40 of 52 posts

Re: Show HN: Twingate – A modern solution for remote access

#31

Earlier quoted context omitted.

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 T…

Can you explain how this is more secure than SSH to a bastion host via an out of band network?

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?

Re: Show HN: Twingate – A modern solution for remote access

#32

Earlier quoted context omitted.

Can you explain how this is more secure than SSH to a bastion host via an out of band network?

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?

Out of band could be as simple as ngrok, or cloudflare Argo - or as you suggest by a separate connection.

SSH is two factor - key + password and Argo,ngrok,wireguard to a VPS provide DDoS mitigation and attack surface concealment and reduction.

I think I’m missing what your product adds.

Re: Show HN: Twingate – A modern solution for remote access

#33

A few issues I have with these NoVPN products: * They are entirely proprietary or are proprietary extensions on top of open source software * The clients are mostly proprietary and the distribution channels are limited. I'm guessing no .DMG is offered for macOS due to Apple's insane restrictions on OS-integrated VPN clients. * There is usually a hard dependency on the provider for the connection, negotiation, or key…

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.

Re: Show HN: Twingate – A modern solution for remote access

#34

A few issues I have with these NoVPN products: * They are entirely proprietary or are proprietary extensions on top of open source software * The clients are mostly proprietary and the distribution channels are limited. I'm guessing no .DMG is offered for macOS due to Apple's insane restrictions on OS-integrated VPN clients. * There is usually a hard dependency on the provider for the connection, negotiation, or key…

The real raison d'etre with these new wave of commercial NoVPN products like this one and Tailscale is to build a high margin SaaS business without really having the infrastructure liabilities of SaaS businesses. The problem with these kinds of products is that they are, from a security perspective, a disaster. Not only your entire network is compromised if they get hacked or if even they want to get into your network whenever they want which is an unlimited power I've never seen in any SaaS product, also your network becomes prisoner to their services, so if their services go down for any reason, you and everyone in your network will be unable to connect to your network even if it's perfectly working.

At least Twingate doesn't try to do sanke oil advertising like Tailscale and sells itself as an "open source" (go have a look at their Github open issues, it's a complete disaster) while it is not. Also the other thing is, if you have a relatively small company of 50 people you will end up actually paying MORE than those seemingly overpriced yet established products like Zscaler ZPA.

For me, the only serious alternative to expensive products like ZPA are Zerotier and Pritunl. They are as transparent as open source yet still viable as businesses without being greedy or captive to VC money to extract every single dollar out of you.

Re: Show HN: Twingate – A modern solution for remote access

#35

Very cool! How does this compare with Tailscale which utilizes Wireguard under the hood?

Thanks! One of the things that we've really focused on is making Twingate super, super easy to deploy. From all of our customers conversations we've found that despite acknowledging that a better approach to remote access is possible , most people are really turned off by how hard it seems to be to implement a "zero trust" type solution. Our product goal is a 15-minute deployment, and our initial customers have been…

> ...with all transport encryption done via TLS...

Is it a TCP-only tunnel? Do you mitigate the issues with TCP-in-TCP in any way? Or do you mean DTLS?

Re: Show HN: Twingate – A modern solution for remote access

#36
In general it seems convenient to configure; but in terms of operation how does it really differ from connecting your services as clients to a VPN LAN? With WireGuard for the tunnels themselves, you can even have as many routers/"relays" as you want, with virtually no overhead.

Re: Show HN: Twingate – A modern solution for remote access

#37
The modern solution for remote access is to move all of your business systems to the web, employ TLS1.2+ with strong cipher suites, and enable MFA as appropriate.

We already have 100% of our business systems for 1 project using web-based access. This makes ramping new employees and doling out restricted access so much easier. If you give someone VPN access, you need to hire a full time guy to manage that bucket of pain if you want granular per-user permissions at the network-level. Web has no such problems. Everything is typically a completely independent security context in terms of network for any layer below HTTP. VPN means you have ~layer 3+ access by default to everything on that network.

There is an argument to be made for "XYZ doesn't have a web interface/API". But, I pose that this is a weak argument in 2020. Every cloud provider can be automated 100% via API calls. Every single thing you can do on the GitHub[Lab] web UI can be automated. Even if there isn't an explicit API, you can automate literally any legacy application with some mild scripting and duct tape. I've seen automation that samples a 3d application output in real-time and checks pixel colors for eventing, so I know this can be done. Bonus points here because these are typically legacy static and never-changing systems so you can code for it 1 time. There aren't really any excuses in my shop for manual labor. Setting up a new public webapp that can 2FA your employees and provision cloud resources via the AWS JSON API is not hard. You can make it hard, but you can also make it very very easy if you just focus on the value angle. Once you build one of these things, the next one takes 1/10th time time because you know how to do it. Maybe you just add a 2nd navigation option to your 1st one to manage that additional system...

Re: Show HN: Twingate – A modern solution for remote access

#38

Earlier quoted context omitted.

Thanks! One of the things that we've really focused on is making Twingate super, super easy to deploy. From all of our customers conversations we've found that despite acknowledging that a better approach to remote access is possible , most people are really turned off by how hard it seems to be to implement a "zero trust" type solution. Our product goal is a 15-minute deployment, and our initial customers have been…

> ...with all transport encryption done via TLS... Is it a TCP-only tunnel? Do you mitigate the issues with TCP-in-TCP in any way? Or do you mean DTLS?

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.)

Re: Show HN: Twingate – A modern solution for remote access

#39
Is it just me, or do the installation instructions for the client really say you just enter a company name..... No other user/pass/key

https://docs.twingate.com/docs/download

To me that reads that I could just pick a known company using your service and get right in. What's going on here folks?

Re: Show HN: Twingate – A modern solution for remote access

#40

Earlier quoted context omitted.

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?

Out of band could be as simple as ngrok, or cloudflare Argo - or as you suggest by a separate connection. SSH is two factor - key + password and Argo,ngrok,wireguard to a VPS provide DDoS mitigation and attack surface concealment and reduction. I think I’m missing what your product adds.

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.
Post reply on HN