[trotsky]

If there is one thing that I have considered a flaw in computing, it's that there have been few ways for inexperienced developers and users to use one simple system which allowed them to circumvent their host based firewall, their network IDS, their edge based UTM and the OS security assumptions around localhost being a protected, private interface. The value of a point and click system to expose these directly to the internet and a domain that serves as a collection point for them can not be understated.

If a service is bonding only to ::1, and not 0.0.0.0 or your current routable ip it's explicitly deciding that it shouldn't be accessible from beyond the local computer. And in a lot of cases, it's right even if it doesn't explain why exactly. When exactly did we decide local port forwarding was too hard even for technical people? Or, I dunno, servers?

[drivingmenuts]

I think I just heard many system administrators collectively clutching their chests in pain.

If inexperienced devs and users could suddenly drop their pants at will, imagine the mayhem that would occur if experienced devs with malicious intent were set loose in that environment? You can't pretend they don't exist - in fact, it's better to assume everyone who's not you is out to utterly destroy your data ASAP. Some would argue don't even trust yourself.

Those firewalls, ids, utms and assumptions are pretty much the only thing protecting inexperienced users from themselves.

[derefr]

I think, if you have a system administrator, you're not the target audience for localtunnel. This is for home users who don't understand how to get their computer+router+apartment building's switch+etc to cooperate in getting them a public route.

Maybe they should just make it bind to a port below 1024, so it requires root/Administrator privileges to run. Then, if you are your own sysadmin, you can let yourself in--and if someone else is, you'll have to take it up with them.

[snowwrestler]

I think that making it easy for unsophisticated users to expose their personal machines directly to the public Internet is not a good idea.

The way to test a web project in development is to put it on a cheap web host or VPS. If you want to help newbie developers, make that one-click easy.

[derefr]

The real barrier to entry is the point between "cheap" and "free"--especially when first learning. For me, that was when I was 10/11. No chance of getting hold of a credit card to get a "cheap web host or VPS." I could only experiment with what my computer was willing to do on its own.

Heroku's almost the right thing for this, I think, though it still requires a credit card to sign up fully (it doesn't technically, but it does to enable free add-ons, so without a credit card you don't get, say, database persistence.) Obviously, Heroku is geared for adult developers--or, more specifically, to start-ups that Heroku hopes will become monsters dependent on Heroku's stack.

What would be perfect is a service like Heroku, but specifically for people learning to code; maybe something joined-at-the-hip with an online coding-school website. When you attend a real CS program, you get access to the labs and mainframes to test your programs on--where's the online version of that?

So, anything like this already exist? Or should I build it?

[snowwrestler]

I just think of a 10-11 year old putting their personal--or their family's--computer straight onto the public web with some random hacked-together code, and it makes me feel very nervous. What are the chances they are going to understand all the security implications? Pretty low, I think.

On the other hand, no one ever learned much by always taking the perfectly safe path. And who am I to judge whether people are "ready" for the Web? It's the old freedom vs. security argument.

Amazon does provide a free tier of EC2, which is great for tinkering around. But it takes a certain amount of knowledge to get one working as a web server. A tutorial, or a project that makes it easier, might be a good place to start.

[at-fates-hands]

>>I think I just heard many system administrators collectively clutching their chests in pain.

I was trained to do this by reflex. Anytime you expose anything on your network, not matter what it is, without some layer of security between you and the internet, you're asking for trouble.

Whether this is a warranted reaction or not, I don't know. I'm pretty sure its from spending too much time hanging out with hackers and sys admins. It's just locked in my brain not to doing something like this - ever.

[superuser2]

It's completely impossible to develop for Twilio, Facebook, and many other public APIs without putting your work on the public internet. If you want to develop for a public API in a native GUI text editor, tunneling through your firewall is the only way to do it.

[HerraBRE]

Abstracting away all the firewalls and IP addresses and stuff is really convenient. Restrictions aren't always put in place for a good reason, increasingly they are just a function of IP address scarcity.

(disclaimer: I created https://pagekite.net/ which is one of localtunnel's competitors)

[trotsky]

and yet when the service binds to localhost instead of a local, private routable address that clearly exists as you're tunneling to the internet, it has said "hey, look, whatever im doing i dont want any other computer anywhere to be able to connect. localhost is identical on everything explicitly so it has zero chance of routing. Why not open tunnels to whatever routable private ip you have up?

And while a bit toung in cheek, i'm not too aware of this whole ip address scarcity thing. I've got a decent chunk of a /29, if you could use a /48 or ten for your local networks just ask! Or would it be tough to squeeze down to only 18,446,744,073,709,551,616 local addresses?

[HerraBRE]

Binding to localhost by default is good security hygene, a "closed by default" strategy, which doesn't necessarily mean you never intend to expose that server ever.

Tools like PageKite and localtunnel are completely in line with that philosophy, nothing is exposed to the outside world until you explicitly request it and then only the named service you chose (as opposed to whatever is on the port or god forbid everything listening on a particular IP). I personally feel more secure temporarily exposing a server using PageKite than I would if my router had been reconfigured to always allow traffic through on particular ports - it's a lot easier to turn PageKite off than it is to go reconfigure my router every time I am done testing.

Convenient security is good security, because it is more likely to be used correctly.

IPv6... well, good luck with that. :-) Aside from how few western ISPs offer IPv6 service, consider the fact that the majority of our devices are mobile these days. My laptop changes networks and IPs many times a day and I still like being able to run a visible server on it. Configuring plain IPv4 or IPv6 to do that elegantly is decidedly nontrivial.

[woah]

I really like pagekite! very convenient!

[mhurron]

I don't even know what to think of this.

Are you arguing that it is a good thing for people who have no idea what they're doing to have a 1 button click to remove all security?

[relaxitup]

I think you missed the sarcasm and irony that was fairly evident in his comment. However, perhaps we can expect a user who can gem install something to have an acceptable level of awareness of the security implications of such a tool?

[mhurron]

> However, perhaps we can expect a user who can gem install something to have an acceptable level of awareness of the security implications of such a tool?

No, we can not. From both personal experience (developers can be dumb as bricks and know nothing outside their specific knowledge domain) and good security practices (you don't trust the user, even if they say they're good for it).

And yes I hope it was just sarcasm I missed, but that's why I had to ask.

[trotsky]

it was indeed complete sarcasm.

[PeterisP]

Can you elaborate on why you equate this localtunnel to "removing all security" ?

I haven't tried it, but it seems to forward a single port that's running service X that I want to make available on the net.

Any way whatsoever of fulfilling that need (no matter if it's one button click or setting up a separate VM for that service) would involve making a hole in all relevant firewalls and making the (possibly buggy) service X available to everyone.

Is the user goal of "making service X available to everyone" bad in itself?

[snowwrestler]

The issue is, what else is on that machine?

When you allow public connections to a service running on a machine, security for that entire machine now largely depends on that service. Are you 100% sure that your copy of Apache or Nginx is patched up to date? That the web app you just coded up won't allow arbitrary command execution? That the OS has no local privilege escalation vulnerabilities?

If you are using a web host or VPS, the risk is limited to the code you're testing. You could lose the whole machine and it's no big deal.

But if you've exposed your personal machine--with all your documents, files, settings, etc.--then you've got a lot more to lose if a bad guy gets in. Worst case is a rootkit install that collects all your passwords and sends them out.

[marquis]

Running Localtunnel with directory listing enabled and root set to / (inadvertently or not) could not be a good idea.

[superuser2]

The primary use case is for web applications which will eventually run on public servers. So yes, it is a good thing for people to be able to easily simulate having their software run on a public server. It's also necessary if you're writing something that receives events from other APIs like Twilio.

[medde]

if outgoing connections are blocked, you are probably ok