Comment by Afforess | Hacker News Reader

Comment by Afforess | Hacker News Reader

Parent Full thread

Yep. I think a big point that has not been addressed is how we got into this situation. Most internet users are locked behind home or corporate networks, without a real addressable IP and every port but 80 and 443 blocked. A lot of this was done in the name of security (exactly how does blocking a port or ignoring a ping response make you secure? I've never heard a valid technical reason for this being more secure, beyond tradition-says-so answers.), but is really due to cargo-cult sysadmin behavior and bad default settings on hardware.

Now we've basically ruined IPv4, peer to peer communication doesn't work for enough users to make it useless, forcing the centralized server-client model. It's not just hardware with bad defaults - try accessing a (non-localhost) website hosted on a port 6666 in Chrome. You can't, Chrome has a blacklist of "insecure" ports. I am baffled such a concept even exists, ports aren't secure or insecure, they are a channel for data. Then I look at websockets and laugh, We rebuilt udp over http over tcp, just so web developers can send arbitrary data again...

I get very upset when I see the same sort of ideas taking hold in IPv6, we have another chance not to ruin this, and yet we seem to want to force the broken IPv4 model, with firewalled NATs, blocked ports, and more broken default settings.

Ping of death has happened before. You do not serve any purpose by opening ports that you do not intend to use. Closing all unneeded port is called minimizing attack surface.

Ports may not be inherently secure or insecure, but the history of their usage give them bias towards likely being secure or insecure. Chrome does the right thing by blocking these ports as an overwhelmingly large percentage of their users will probably hit this port under "insecure" situations. Those who need to use these ports can and will find alternate ways to do it.

What "attack surface"? Almost all your ports, no applications listen to. Closing them serves no useful purpose.

If an application has problems accepting input on a port it is listening to, that is an application bug. Closing your ports doesn't solve this, it just hides the problem under the rug, and breaks the Internet in the process.

> Closing your ports doesn't solve this, it just hides the problem under the rug, and breaks the Internet in the process.

To be fair, if you don't listen to tin-foil-hatters like GRC and configure your firewalls to REJECT non-invalid [0] traffic, rather than DROP, the only thing you'll break is the ability for others outside your network to connect to services on those ports.

[0] In the iptables CONNTRACK sense of "invalid".

The firewalls you mentioned were NAT/Enterprise level. They do not generally have absolute control of what programs are running on one of their internal computers. May be that port left open is used by a C&C client installed on one of the user's computer inside LAN, hereby possibly compromising the whole internal network. There is a reason why DMZs exist.

Corporate security is a different sort of beast from almost every other security environment. What's acceptable in that arena is almost always an unacceptable management practice for someone who is designing and operating what is supposed to be a network of peers.

> ...try accessing a (non-localhost) website hosted on a port 6666 in Chrome. You can't, Chrome has a blacklist of "insecure" ports.

The reasoning for that is -apparently- as follows: "So, why does Chrome refuse to connect to some ports? Because the Google engineers has gone through the list of well known ports, and worked out how tolerant the protocols that use these ports are to being sent HTTP requests, and if they are tolerant, they've marked it as unsafe and so blocked it, to prevent Google Chrome from being an open proxy to a secured network." [0]

I'm not sure how I feel about that reasoning.

[0] https://jazzy.id.au/2012/08/23/why_does_chrome_consider_some...

Reply on news.ycombinator.com