11–20 of 53 posts
To tunnel your whole infrastructure traffic through a third party is one of the dumbest ideas I have ever heard of.
However, to be clear, this is intended primarily for local development use, for traffic that isn't necessarily sensitive.
> we offer end-to-end SHA-256 encryption Is this a mistake?
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 Webs…
Any plans on offering a ssh reverse tunnel endpoint? This makes life so much easier as no special client is required.
> We take security very seriously, especially when it comes to our users. This is why we offer end-to-end SHA-256 encryption
You take security seriously, but are confusing pretty basic and fundamental concepts of encrypting vs hashing.
Given that the point of this service to expose local services to the internet, and only provides compression benefits if I expose the plaintext traffic of my service, I'm not seeing a lot of information that gives me confidence you truly understand the importance of doing what you are doing securely and safely. Not to mention confidence to defend against what an attractive target this makes you for attackers to passively tap or pivot into your customers.
Earlier quoted context omitted.
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).
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 (wi…
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.
I want to be supportive, and I believe this solves a real issue, but this giving me serious pause: > We take security very seriously, especially when it comes to our users. This is why we offer end-to-end SHA-256 encryption You take security seriously, but are confusing pretty basic and fundamental concepts of encrypting vs hashing. Given that the point of this service to expose local services to the internet, and on…
1. We'll be open sourcing our client in the coming weeks so you can check out our code yourselves.
2. We will be offering a self-hosted version which will decouple you entirely from our infrastructure and you can provide you own SSL certificates.
3. Lynk can forward traffic to your encrypted services - which of course would mean losing out on compression benefits, but Lynk is designed primarily for quick development work like testing out a Stripe or Github webhook on your local machine, or demoing your webapp to a remote client. For production use we recommend a reverse proxy or self-hosting Lynk.
The standard answer to this problem is ngrok, so it'd be useful to have a direct comparison. I couldn't find any encryption code in the Github repos you have exposed (I didn't look hard); obviously, since you've documented "SHA-256 encryption", you should probably write that up a lot better. I assume that at least the client side of this will be open source, in that people are going to be squeamish about running clos…
I've written an analysis of Lynk's performance vs. Ngrok here: https://medium.com/@shivanshvij/building-a-better-ngrok-dbc1... and our documentation stating "SHA-256 Encryption" has been since removed as a mistake.
The client side will absolutely be open sourced probably by the end of next week once I've cleaned up some spaghetti code.
> we offer end-to-end SHA-256 encryption Is this a mistake?
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 Webs…
Great! But i can't sign up using mail only.
Please email us at lynk@loopholelabs.io