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

261–270 of 315 posts

Re: The New Internet

#261

Post by gorgoiler »

api wrote: post #161
throw0101d wrote: post #131

Earlier quoted context omitted.

> Who was stopping anyone from doing it then, and who is stopping anyone from doing it now? The folks who either (a) got in early on the IPv4 address land rush (especially the Western developed countries), or (b) with buckets of money who buy addresses. If you're India, there probably weren't enough IPv4 address in the first place to handle your population, so you're doing IPv6: * https://www.google.com/intl/en/ipv6/…

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.

In practice I haven’t ever had a problem memorising IPv6 addresses. The significant proportions of any address you might type manually are 48 bits long at one end and a few bits at the other.

An example IPv4 address is 8 to 12 digits:

  10.30.115.5
A memorable IPv6 address at a /56 site — the prefix and then one or two digits — isn’t much longer:

  2001:db8:404:14::42
If you’re with a reasonably clued in ISP you probably get a /48 for your site by default:

  2001:db8:404::42
If you’re enumerating your own /64 prefixes then it’s not much more complicated than:

  site 2001:db8:404::
  net              :14::
  host                ::42

Re: The New Internet

#262

Post by tjoff »

noduerme wrote: post #235
eqvinox wrote: post #230

Earlier quoted context omitted.

> The originate _inside_ because NAT effectively blocks all _external_ requests. You mean the firewall effectively blocks all external requests.

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.

Re: The New Internet

#263

Post by chgs »

Fnoord wrote: post #23
jgalt212 wrote: post #16

Earlier quoted context omitted.

If you had to move off of tailscale, what would you move to?

I use WireGuard. As you add more keypairs, it becomes a bit of a nightmare to maintain, though Vim with syntax highlighting helps a lot. Because of this, I'll be switching to Headscale + Tailscale.

It depends on your use case. I use wg back to two geographically independent locations, keys are managed via our ipam.

I don’t need EW traffic over the VPN, very NS based. Something like Headscale or another SDWan solution (automatically establishing vpn routes) would make sense if I needed to transport a lot of traffic E-W, that’s just not a requirement

Re: The New Internet

#264

Post by snek_case »

teddyh wrote: post #162
ZhongXina wrote: post #150

Earlier quoted context omitted.

No, we definitely don't want "automatic IPSec" (especially IPSec!), or really any enforced encryption at the network level, even if it's something sane at this moment like WireGuard. Look at old VPN protocols or authentication schemes like RADIUS which have glaring security holes and are impossible to fix because of compatibility issues, and they're running at much smaller scales than the whole internet. Hell, the wa…

Your argument seems to be to never implement anything, because eventually it will become old and it will be hard to move away from it? This seems to be an argument against anything new, and it is therefore hard to take seriously.

The argument is more that encryption technologies can become outdated quickly. You also make it harder for small embedded devices to implement network connections if you mandate that all traffic must be encrypted.

A simple protocol is more likely to last.

Re: The New Internet

#265

Post by jeroenhd »

ZhongXina wrote: post #150
teddyh wrote: post #57

The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem . What the internet would need is something like IPv6 with automatic encryption via IPsec, with PKI provided by DNSSEC.…

No, we definitely don't want "automatic IPSec" (especially IPSec!), or really any enforced encryption at the network level, even if it's something sane at this moment like WireGuard. Look at old VPN protocols or authentication schemes like RADIUS which have glaring security holes and are impossible to fix because of compatibility issues, and they're running at much smaller scales than the whole internet. Hell, the wa…

IPSec is still widely deployed, securely even. All manual, of course, because it doesn't do the stuff that makes HTTPS easy.

IPSec is not always a VPN protocol. L2TP over IPSec is often used as one, but IPSec does little more than encrypt a tunnel between two IP addresses. IPSec in tunnel mode can be a minimal VPN, but it's not used as such as in VPN scenarios without a second packet encapsulation protocol, as it lacks authorization beyond key exchange.

As for the risk of ossification: that didn't go away with the current system either. HTTPS over TLS 1.3 looks like a TLS 1.2 session resumption on the wire (in its default configuration) because shitty middleboxes are used often enough that it would impede the protocol.

The "let's remake TCP over UDP" approach QUIC takes has very similar origins. UDP is generally allowed by random firewalls over that network, while other (more suited) protocols for this type of stuff like SCTP are not. The operating system doesn't allow opening raw network sockets without high privileges, so adding a new QUIC protocol at the layer of TCP and UDP to implement them at the right spot in the stack wouldn't be usable for many devices. Same is true for the TCP stack you have to use what the OS provides or get higher privileges to do your own; patching the TCP state machine isn't practical. So, if you want to implement a better version of TCP optimised for web browsing and such, you use UDP, because while technically incorrect, it'll work in most cases and has the least restrictions.

In the context of the network, IPSec is the new protocol here, not the result of ossification.

Re: The New Internet

#266

Post by jeroenhd »

DyslexicAtheist wrote: post #90
teddyh wrote: post #57

The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem . What the internet would need is something like IPv6 with automatic encryption via IPsec, with PKI provided by DNSSEC.…

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 may be in favour of DNSSEC, but I admit that it's time for a v2 of the RFC that removes the stupid "encryption can't be done at the endpoint" restriction. In practice you can just turn on validation on many computers and gain its benefits, especially if used in the manner as described here where you can just block connections to unprotected hostnames to work around the most glaring issue, but the whole spec is written for a world we've moved beyond.

IPv6 doesn't have that problem, though.

Re: The New Internet

#267

Post by throw0101d »

aboardRat4 wrote: post #225
throw0101d wrote: post #208

Earlier quoted context omitted.

> Also, NAT is desirable for security/network isolation reasons […] This is security theatre. People have been saying that NAT is not a security feature for over a decade: * https://blog.ipspace.net/2011/12/is-nat-security-feature/ but the message still has not sunk in. The "Zero Trust" paper was published by John Kindervag in 2010: * https://media.paloaltonetworks.com/documents/Forrester-No-Mo... Most modern attacks…

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

Before recently switching ISPs, my last one had IPv6 (new one does not). They activated IPv6 at some point, and I enabled it on my Asus, and suddenly all my internal devices got an IPv6 address (via RA), including things like my printer.

I had SSH enabled on my macOS laptop and desktop, but could not SSH into them from an outside source. My printer has a web interface on port 80 that I could connect to internally, but not externally. Even though all the devices had IPv6 addresses.

Just because a device is globally addressable does not mean it is globally reachable.

> What about I don't do it, and the system is still _automatically_ secure, because NAT does exactly that while being _required_ for the system to work.

Because NAT is doing that I describe, so you are doing it. The firewall is checking state on incoming packets and rejecting those that are not in its state table. The firewall is also coïncidentally just happening to also be fiddling some bits in the address field.

It is the stateful inspection that is protecting you.

* https://en.wikipedia.org/wiki/Stateful_firewall

Re: The New Internet

#268

Post by pas »

superb_dev wrote: post #260
Sophira wrote: post #257

Earlier quoted context omitted.

You are technically correct that iptables is what provides the NAT functionality on Linux (by way of the MASQUERADE target), which many routers run. However, you are very incorrect that the firewall is directly involved in blocking the request. The reason NAT works for this is because by default there are no Internet-accessible services available via the router. If a request is received by the router that doesn't mat…

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, and on a pure NAT box there are no bound listening sockets. so whatever "dst port" is .. unless it gets picked up by an established NAT flow ... it will splash on the wall and getting a TCP RST.

isn't the argument that "NAT is not required", but that "NAT is implicitly a firewall"?

Re: The New Internet

#269

Post by otabdeveloper4 »

teddyh wrote: post #57

The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem . What the internet would need is something like IPv6 with automatic encryption via IPsec, with PKI provided by DNSSEC.…

The problem with TCP/IP is the lack of a standard and robust VPN/overlay network protocol. Everything we have is extremely fragmented and/or proprietary.

IPv6 is completely useless and doesn't solve this problem.

Normal people don't care if they have to pay 5 dollars instead of 50 cents to rent an IP address. This is a problem specific only to the huge providers, and we don't need to rollout a whole internet upgrade just to optimize a tiny part of the operational costs for huge providers.

Re: The New Internet

#270

Post by otabdeveloper4 »

teddyh wrote: post #142
tomjen3 wrote: post #137

Earlier quoted context omitted.

I think that is excessively negative take. Tailscales value proposition is also "you can connect to your network wherever you are, safely, and others cannot". That does not go away because of IPsec.

Network- and location-based security is ultimately unworkable. It’s like if you, in order to work, had to go to a ”virtual office” to even send mail to your colleagues. Mail, and related internet-enabled services, should be accessible from anywhere , and be secured at the end points, not at the network layer. (Most attacks are internal, anyway.)

No, network- and location-based security is a necessary and indispensable layer in your security stack.

> should be accessible from anywhere, and be secured at the end points, not at the network layer

If you're not securing at both the network layer and the endpoints, then you have utterly failed security and you need to go sit in the dunce corner.

Post reply on HN