
Show HN: Lynk – Securely expose local TCP and HTTP services to the web - loopholelabs
https://lynk.sh
======
billyhoffman
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 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.

~~~
loopholelabs
This was a mistake on our website, which as since been removed.

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.

~~~
deathanatos
You allow the user's machine to obtain a valid certificate for a subdomain of
lynk.sh? (This would seem to me the only way to accomplish E2EE, given the
example of connecting over TLS to a lynk.sh host, and it also seems very
unlikely.)

~~~
mcpeepants
why does that seem unlikely?

------
jhgg
This product offering is a bit confusing. Not that I don't get the offering -
but that the marketing around it confuses me.

It's designed for forwarding applications for development purposes? But then
why the in-depth monitoring and alerting (something that seems to imply a
production system might be running on top of this.)

The "meaning your website performance won't take a hit no matter where your
users are" doesn't really make sense in this context either. My "users" are
hopefully my coworkers/the client I'm demoing to. And if I'm tunneling up my
site over wifi from my laptop, a "highly available" and "globally distributed"
load balancer setup really doesn't make sense, nor is it relevant for the
development use-case.

And if it's "6x more performant" than ngrok- is that really relevant if you're
using it for a trivial amount of traffic in a development environment? Why is
this a selling point to me?

Further - if I'm tunneling TCP, does "end to end" really matter? If I'm
tunneling something that's not encrypted on my application (let's say a
plaintext redis connection) the link between this service and the person
connecting to the tunnel is still unencrypted. Which means the whole "end to
end" marketing really doesn't make much sense - unless of course I don't trust
the network I'm running on - but for some reason maybe trust the network the
person accessing the tunnel is on (super unlikely situation...)

The example also irks me - exposing a database directly to the internet (if
it's a database for development, hopefully - it's probably fine?)

Is this trying to compete with ngrok, or something like Cloudflare's Argo
tunnels? Because the marketing material leads me in two different directions,
which is pretty confusing.

------
tptacek
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 closed source desktop tunneling software.

~~~
loopholelabs
Hi!

I've written an analysis of Lynk's performance vs. Ngrok here:
[https://medium.com/@shivanshvij/building-a-better-ngrok-
dbc1...](https://medium.com/@shivanshvij/building-a-better-ngrok-dbc104754822)
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.

~~~
tptacek
It might be a good idea to make that post or something like it way more
prominent.

------
carlosdp
If I can just offer one bit of feedback, if you just type any email and
password in the "Sign in / Register" page, it just creates an account for you
if it doesn't exist.

There's a ton of reasons you don't want that, and should probably have a
separate "sign up" flow for email/password login. Here's a few:

1\. It's not at all clear you can actually do that. One guy in the comments
below thinks you can only sign up using Github/Gitlab/etc.

2\. Many of us have multiple emails, what if I don't remember what email I
used for your service? Every time I try the wrong one, it'll just create a
separate account, and it'll take me a few minutes to realize this isn't my
account, but I just created a new one.

3\. No double "password confirmation". Some sites skip this step now, so I
guess it's not required, but not having it is part of why people will think
this isn't a sign up field.

~~~
loopholelabs
That makes a lot of sense, thanks for pointing this out! I assumed that asking
people to verify their emails would be enough but it never hurts to make
things clear.

I'll make those changes as soon as possible.

~~~
StavrosK
Yeah, I was extremely confused at not finding a way to sign up with just
email, and was about to leave when I saw this comment.

------
ficklepickle
I wanted to like this, but I couldn't get passed the awful landing page.

It brought my phone to crawl. Moving wireframes in the background would have
been distracting at the best of times, let alone on an older phone.

It gives me the impression they value style over function, which is a huge
turn off for me.

------
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...](https://medium.com/@shivanshvij/building-a-better-ngrok-
dbc104754822)) and support technologies such as HTTP/2 (with HTTP1 fallback)
and Websockets.

Check out our open beta and documentation here:
[https://lynk.sh](https://lynk.sh)

~~~
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...](https://security.stackexchange.com/questions/19911/crime-how-to-beat-
the-beast-successor/19914#19914)

------
iampims
One piece of feedback: for security reasons use a different domain for
tunnels.

lynk.sh & lynkapp.sh

Heroku, Netlify, Github made the same mistake of originally using their main
domains for user hosted apps and it lead to several vulnerabilities.

------
cachestash
I honestly don't see the use of this. Why would anyone want to expose a
development environment to the internet, especially in the age of devops and
reproducible environments. 98% of all my development happens over 127.0.0.1
now. I have zero need to expose a service when I can replicate multi sites on
a lan with the lightweight environment given to me with containers and vms.

~~~
kelnos
One of the original popular use cases for services like this was if you're
developing against a third-party service that wants to send you webhooks.

But it's also useful if you want to run something locally and show it to a
friend or co-worker. The co-worker bit is especially useful now with people
working from home.

Regardless, this space is pretty crowded, so I'm not sure what a new offering
could do to differentiate. I'm skeptical of their "6x faster than ngrok"
claim, and even if it is true, I don't think this is a use case where that
metric really matters all that much.

(Full disclosure: the founder of ngrok is a friend of mine, so I'm certainly
biased here.)

------
benmmurphy
How are you handling connections? I think the original ngrok had a control
connection and then opened a new connection for each request. I think they
have now switched to multiplexing. I've heard multiplexing multiple HTTP
connections over a single HTTP connection can have issues if there is packet
loss.

For example if you have 1% chance of dropping a packet, and your conversation
involves 1 packet then if you have 10 conversions each with its own TCP
connection you will average 0.1 conversations being stalled from packet loss.

But if you multiplex those 10 conversations over 1 TCP connection then you
will average ~ 1 conversation being stalled from packet loss.

I'm guessing this is not such a big problem with typical packet loss and a low
number of conversations but if you are pushing a lot of conversations
simultaneously over a single TCP connection then it could become noticeable.

------
kevincox
> we offer end-to-end SHA-256 encryption

Is this a mistake?

~~~
loopholelabs
Yes, it was and this has since been removed.

------
l2dy
[https://lynk.sh/faq/#privacy](https://lynk.sh/faq/#privacy)

> We only ask for personal information when we truly need it to provide a
> service to you. We collect it by fair and lawful means, with your knowledge
> and consent. We also let you know why we’re collecting it and how it will be
> used.

Be specific on this _in_ your privacy policy. What information do you collect?

------
momothereal
I echo the sentiments that the features you promote seem overkill for the
"primary use-case" of local development.

On another note I suggest you improve the accessibility of your pages. The
contrast of the text in the navigation bar and on the FAQ page makes it hard
to read, and is below the WCAG standards.

------
sairamkunala
Canyon add up comparisons with inlets and cloudflare warp? It may help migrate
existing customers.

~~~
alexellisuk
??

------
johnmarcus
Interesting. But I hate getting random endpoints, that means I need to keep
updating configs. I'd rather use a self hosted solution, there are some easy
ones out there.

~~~
loopholelabs
We'll be releasing an update soon that will enable both custom domains (so you
can bring your own) and reservable subdomains. Furthermore we plan on
releasing a self-hosted version and open-sourcing the client.

------
benma
Immediately reminds me on [https://ngrok.com/](https://ngrok.com/) which
should do basically the same

------
alexellisuk
Author of [https://inlets.dev](https://inlets.dev) here, inlets is open-source
(client and server) and can be self-hosted along with link encryption with
TLS. We use web sockets which can penetrate almost any firewall/NAT situation.
It's also important to note the Kubernetes and cloud integration for
provisioning your own exit hosts. Take a look. TCP support in PRO edition with
personal license available.

------
m1keil
This reminds me of cloudflare access with faster ui/ux. The cli interface
looks very similar to cloudflared.

Will give it a go when in need, cheers.

------
badrabbit
Malware/bots will abuse this a lot just like with ngrok.io because of the free
tier.

------
senderista
How is this better than ngrok?

~~~
loopholelabs
I've written up an in-depth analysis here:
[https://medium.com/@shivanshvij/building-a-better-ngrok-
dbc1...](https://medium.com/@shivanshvij/building-a-better-ngrok-dbc104754822)

------
mkoryak
Can the client run on a raspberry pi?

------
TheNoxier
To tunnel your whole infrastructure traffic through a third party is one of
the dumbest ideas I have ever heard of.

~~~
loopholelabs
We'll be releasing a self-hosted server and client soon that will allow you to
decouple completely from our infrastructure and bring your own SSL
certificates.

However, to be clear, this is intended primarily for local development use,
for traffic that isn't necessarily sensitive.

