undefined | Better HN

0 pointsloopholelabs5y ago0 comments

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

0 comments

billyhoffman5y ago

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.

loopholelabsOP5y ago

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.

thanksforfish5y ago

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

kelnos5y ago

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

loopholelabsOP5y ago

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

j / k navigate · click thread line to collapse

0 comments

billyhoffman5y ago

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

loopholelabsOP5y ago

I should have been more clear.

thanksforfish5y ago

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

kelnos5y ago

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

loopholelabsOP5y ago

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

j / k navigate · click thread line to collapse