[loopholelabs]

Hi Hackernews,

We're excited to announce that the Lynk Beta is now live!

We've been hard at work building out Lynk's tunnelling protocols to make them faster, more stable, and all around better. We're happy to announce that vs. Ngrok our tunnels perform up to 6 times faster (source: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1...) and support technologies such as HTTP/2 (with HTTP1 fallback) and Websockets.

Check out our open beta and documentation here: https://lynk.sh

[ignoramous]

This is great. Congratulations on the launch. It reminds me of DERP [0].

A few questions:

1. What are the top few things in the protocol that improved speed upto 6x in comparison to ngrok?

2. Is Lynk based on your earlier work on Parasite?

3. The website claims "CDN-like performance" with "highly-available load-balancers" over the tunnel, and so:

3a. Is the limit on number of connections (100 to 200 per minute) a soft limit? Can it be raised? If so, by how much?

3b. Do you have servers across the globe like CDNs do? Or, plan to?

4. I see a flat $5 fee for enterprise usage and a notice about "no tricks pricing"... Is bandwidth something you monitor for "fair-use" and might charge extra for? Or, is bandwidth simply unlimited?

5. "Lynk Web UI for Request Capture and Playback" Neat. And so:

5a. This works for both TCP and HTTP? Any video/screencast that shows this in action?

5b. Is the HTTP tunnel a reverse-proxy or in fact a HTTP CONNECT tunnel or something else?

5c. Does TCP tunnel over SSH? Or HTTP? Or both? Or neither?

5d. How do you deal with TCP over TCP performance issues, if at all: https://github.com/apenwarr/sshuttle/blob/master/docs/how-it...

You might want to update the FAQ section of your website. It seems to be out-of-date.

Thanks.

[0] https://github.com/tailscale/tailscale/tree/master/derp

[vlovich123]

I'm curious about the note that you apply compression. Are you proposing your customers rely on your encryption rather than doing their own E2E encryption? If not how significant are the compression savings if you're just compressing encrypted data.

[loopholelabs]

Yes, we are doing E2E encryption and compression between the Lynk Infrastructure and Lynk Clients. As with Ngrok, for a quick hosted tunnel our encryption will be more than suitable, and we are working to release a self-hosted version soon that will allow you to bring your own certificates (for both ingress traffic and the traffic between the Lynk Client and the Lynk Infrastructure).

[billyhoffman]

You didn't really answer the question about the value of the compression. There are 2 options:

1- If people are using their own E2E encryption below your tunnel, then your compression provides essentially zero value, since properly encrypted traffic should not have repeating patterns to compress.

2- If you are telling people to not use their own E2E encryption, and instead rely on the Lynk tunnel's E2E encryption (with Lynk applying compression before encryption) then people are exposing their raw traffic to you, a seemingly random person on the internet.

[loopholelabs]

I should have been more clear.

The client compresses responses from your local services before they're encrypted and sent to the Lynk infrastructure. This application is designed primarily for development work and takes the hassle out of setting up a reverse proxy or dealing with port-forwarding.

If your local application provides its own encryption (ie, it's running over HTTPS), then your traffic won't be exposed to Lynk. In this scenario, you're right - there would be very little compression gain.

[thanksforfish]

Theres an important security tradeoff here. Compress then encrypt leaves you vulnerable to attacks like CRIME[1]. How much this matters depends on the application.

[1] https://security.stackexchange.com/questions/19911/crime-how...

[kelnos]

Given that many people likely would use this for HTTP traffic, and HTTP already supports compression natively, what's the value-add here?

[loopholelabs]

HTTP will compress traffic from the lynk endpoint but we also compress the traffic from the client to that endpoint which helps save bandwidth and keeps things snappy even in slow network conditions

[dryicerx]

Any plans on offering a ssh reverse tunnel endpoint? This makes life so much easier as no special client is required.

[loopholelabs]

That's in the works as well, we're just looking into how we can properly tie these tunnels to your Lynk account

[mobilio]

Great!

But i can't sign up using mail only.

[loopholelabs]

Would you be able to discuss this bug with us? We're in Beta right now and are looking to document and squash as many bugs as possible.

Please email us at [e-mail]

[mobilio]

Nevermind, i just was able to make a new account.