Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The New Internet

tailscale.com

Post reply on HN
Print view View original

271–280 of 315 posts

Re: The New Internet

#271

Post by otabdeveloper4 »

teddyh wrote: post #160
tomjen3 wrote: post #149

Earlier quoted context omitted.

Why should you have access to the SSH host for my pie? Or, more to the point, the server that I use to run my RSS feed reader? Or my NAS? Tailscale makes these more secure and more accessible for me. They are never meant to have the world access them. Now for email and a few other things, sure, their nature is that they need to access the world.

> Why should you have access to the SSH host for my pie? Because that is how the internet is meant to work. It is an end-to-end network. If SSH would not be secure enough to handle this, it would need a secure replacement. > Or my NAS? […] They are never meant to have the world access them. What is a NAS, if not a Network-Attached Storage, i.e. meant to be accessed from the network? The concept of a ”local”, ”secure”…

> Because that is how the internet is meant to work.

No. The "internet" is literally the "inter-network", a way to connect private networks between each other.

The fact that VPN technologies sit behind proprietary corporate intellectual property is not by design, it is a failure of the internet standardization process as it was gamed by corporate interests.

Re: The New Internet

#272

Post by eqvinox »

pas wrote: post #268
superb_dev wrote: post #260

Earlier quoted context omitted.

So then what’s this default firewall rule I have that blocks all non-established connections? NAT is not required for any of the things you’re talking about.

okay now I'm curious what happens with an incoming packet if there are no firewall rules on the NAT gateway/middlebox? without having a corresponding conntrack entry they will be dropped (and maybe even an ICMP message sent back, depending on the protocol), no? for example if there is an incoming TCP packet with a 4-tuple (src ip, src port, dst ip, dst port) ... by necessity "dst ip" is the public IP of the NAT box,…

On a directly connected outside system, you can set a route for your LAN address space via that router and it will just work. It requires telco or physical access but I have in fact done this before.

Re: The New Internet

#273

Post by Esras »

rsync wrote: post #199
jclulow wrote: post #15

An incredibly long ramp up to complaining about centralised control by rent seekers (a very reasonable complaint!) which gets bogged down in some ostensibly unrelated shade about whether client-server computing makes sense (it does) or is itself somehow responsible for the rent seeking (it isn't; you can seek rent on proprietary peer to peer systems as well!) to then arrive at: > There’s going to be a new world of ha…

"An incredibly long ramp up ..." Agreed. We would all do well to learn about, and begin implementing, "Iceberg Articles": https://john.kozubik.com/pub/IcebergArticle/tip.html

This feels like an overly-complex treatment of the Inverted Pyramid in journalism: https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism), or Bottom Line; Up Front: https://en.wikipedia.org/wiki/BLUF_(communication).

Start with the important statements, then expand. Doesn't have to be the "Tell you what I'm telling you, tell you, tell you what I told you" format that many (American) students were taught, but starting with your thesis statement does help ground it.

On the other hand, the topic blog is somewhat of a story, and I can hear the presentation being given behind it. It's just translated 1:1 to a blog, which is a different medium.

Re: The New Internet

#274

Post by throw0101d »

dilawar wrote: post #234
api wrote: post #161

Earlier quoted context omitted.

There is another reason: the addresses are long and impossible to remember and hard to type. I always bring this up and it’s always dismissed because tech people continue to dismiss usability concerns. Even “small” usability differences can have a huge effect on adoption.

Thanks for pointing this out. It's hard to communicate ipv4 and I dread even reading ipv6. I don't understand why they didn't just add two or four more fields to ipv4 e.g. 0.91.127.0.0.1 is localhost where 0.91 can be omitted in the local context. PS: I don't understand how networking works. Feels very very complex and full of jargons.

> I don't understand why they didn't just add two or four more fields to ipv4 e.g. 0.91.127.0.0.1 is localhost where 0.91 can be omitted in the local context.

Because they thought that 64-bits would not be enough, and did not want to have to go through yet another transition.

The IPng proposal that was chosen, SIPP, was originally 'only' 64-bits:

* https://datatracker.ietf.org/doc/html/rfc1752#section-9

See also §10.2:

* https://datatracker.ietf.org/doc/html/rfc1752#section-10.2

Specifically (§11.1):

    * scale - an address size of 128 bits easily meets the need to
      address 10**9 networks even in the face of the inherent
      inefficiency of address allocation for efficient routing

Re: The New Internet

#275

Post by throw0101d »

pas wrote: post #268
superb_dev wrote: post #260

Earlier quoted context omitted.

So then what’s this default firewall rule I have that blocks all non-established connections? NAT is not required for any of the things you’re talking about.

okay now I'm curious what happens with an incoming packet if there are no firewall rules on the NAT gateway/middlebox? without having a corresponding conntrack entry they will be dropped (and maybe even an ICMP message sent back, depending on the protocol), no? for example if there is an incoming TCP packet with a 4-tuple (src ip, src port, dst ip, dst port) ... by necessity "dst ip" is the public IP of the NAT box,…

> what happens with an incoming packet if there are no firewall rules on the NAT gateway/middlebox?

See perhaps stateless NAT:

* https://wiki.nftables.org/wiki-nftables/index.php/Performing...

Re: The New Internet

#276

Post by throw0101d »

tjoff wrote: post #262
noduerme wrote: post #235

Earlier quoted context omitted.

Regardless, it's a fair point. Most of the attack surface on client / end user boxes these days is through social engineering and end user stupidity. Vanishingly little of it on modern OSes comes from external sources like a scan revealing a mistakenly open port. It's just that the threat profile has shifted toward making users make mistakes to the point where so much resource is thrown at fooling users now that, by…

That is because most systems comes with a firewall on and fairly limited surface area in the form of exposed services. But, there are billions of other devices (IoT etc). that barely has any security protections in place that rely completely on not being exposed to the outside world.

> But, there are billions of other devices (IoT etc). that barely has any security protections in place that rely completely on not being exposed to the outside world.

Yes. And you can not-expose them via default deny firewall rule.

My home printer had an IPv6 in a prefix assigned from my ISP, but it was not accessible to the Internet (it was actually ping6-able because my Asus allowed ICMPv6 by default, but I could not connect to its web interface, like I can internally). Neither could I SSH into my macOS desktop or laptop from the outside (but could between the two internally).

And even if my globally addressable devices were globally reachable (which they were not), good luck scanning a /64.

Re: The New Internet

#277

Post by tjoff »

throw0101d wrote: post #276
tjoff wrote: post #262

Earlier quoted context omitted.

That is because most systems comes with a firewall on and fairly limited surface area in the form of exposed services. But, there are billions of other devices (IoT etc). that barely has any security protections in place that rely completely on not being exposed to the outside world.

> But, there are billions of other devices (IoT etc). that barely has any security protections in place that rely completely on not being exposed to the outside world. Yes. And you can not-expose them via default deny firewall rule. My home printer had an IPv6 in a prefix assigned from my ISP, but it was not accessible to the Internet (it was actually ping6 -able because my Asus allowed ICMPv6 by default, but I could…

I know. But this old NAT vs. firewall crap was pointless decades ago.

Still is.

Re: The New Internet

#279

Post by DyslexicAtheist »

tptacek wrote: post #195
DyslexicAtheist wrote: post #90

Earlier quoted context omitted.

I never thought of this. Forces me to rethink every negative post people made against DNSSEC which shaped my opinion. I still think that IPv6 and DNSSEC do more harm in practice than what they solve. Maybe the SCW podcast can do a deepdive on this together with somebody who is militantly-pro DNSSEC. edit: maybe even invite 2 or 3 DNSSEC advocates @tptacek :)

I don't think the analysis upthread should make you rethink DNSSEC, since it, too, is a centralized system; rather than being controlled by Avery Pennarun (you could do worse), it's controlled by an unholy alliance of world governments and companies like Verisign. If we could find a credible DNSSEC advocate (for our audience; that is: a cryptography engineer, vulnerability researcher, or an engineering leader at a ma…

thanks much appreciated to you and teddyh for these links. really needed this opposite views.

Re: The New Internet

#280

Post by mrkstu »

throw0101d wrote: post #267
aboardRat4 wrote: post #225

Earlier quoted context omitted.

> https://blog.ipspace.net/2011/12/is-nat-security-feature/ >>Basic NAT (as defined in RFC 2663) performs just the IP address translation (one inside host to one IP address in the NAT pool). The moment the inside host starts a session through the NAT, it becomes fully exposed to the outside world. This is a lie. A "session through the NAT" does not really expose the host to the outside world, because in 99% of the ca…

> Most modern attacks start from an internal host exactly because NAT makes external attacks infeasible for the majority of scenarios. Or, you know, because firewalls block stuff. I've had hosts with public IPv4 addresses attacked on (e.g.) tcp/80 and tcp/443 because that's what the firewall allowed through so the web service was available to the public. I've had hosts with internal IPv4 addresses attacked on web por…

You have a mix of accurate mix with not so much here.

> I've had hosts with internal IPv4 addresses attacked on web ports because they were behind a (reverse proxy) load balancer for serving traffic: the fact that they had a 10/8 and were behind a NAT did not protect them from attack.

You explicitly set up a NAT bypass (reverse proxy) and then claim NAT didn't protect them. If I am an external attacker coming in towards a single public IP where the backside hasn't set up UPNP/Port Forwarding/STUN/Reverse Proxy, NAT does exactly what the previous poster said. It drops packets because the 'destination' is the router itself in the packet. It has no where else to go, it has literally reached its destination.

A stateful firewall is in no way necessary for this functionality to exist. Even UDP stateless packets cannot bypass the NAT because there if there is no table tracking the conversation from the POV of the inside->out initiating the conversation because the router would have zero idea which interior host to forward the packet to and no reason to do so.

Post reply on HN