4 ms·

True. If you don't understand why that was ever a thing: This comes from a time where in networks (and, to some degree at some point, the entire Internet), bas

by anyfoo 4y ago

True. If you don't understand why that was ever a thing: This comes from a time where in networks (and, to some degree at some point, the entire Internet), basically only non-administrator users were not trusted. Besides this weird idea of "privileged ports" that would prevent a non-administrator user to pose as a system service to other computers, it was also entirely common to just use IP address ranges for authentication. It was an entirely different world. The thought that someone rogue could plug in an entire malicious machine into a network, rather than just being a random student having user-level access, was present, but often not considered a serious enough threat. And it may not have been, given what a lot of networks--and computers--were used for back then, compared to today.

ggm 4y ago
This is also half the story in some ways. SRV records didn't exist because the DNS didn't exist. Email "was" port 25 because that was the assigned port. It was uplifted into the WKS (well known services) model as IANA port allocations, and then rei-ified by "ask IANA for a port" and low number assignment implicitly meant a service daemon which had to setuid() to the user for specific delivery events (most things were store-and-forward) Once SRV records were invented, at the cost of 2+ DNS RTT you can ask "hey, where do I talk SMTP to this place" and be told what port to bind to. But lots of stuff was godfathered in, great-grandfathered in. Too many people think SSH is on 22 and don't want to incur the DNS costs. before this, its 25 for mail. 110 for POP, 123 for NTP for pretty good reasons: we didn't have anything else, except inter-host agreement which ports bound to which service, and the services were almost exclusively launched by root from init process. The trend to dropping effective UID came pretty damn quickly after people realized SMTP as root meant remote actors sending Subject: "|bad stuff; even worse" subject lines to exec() calls which did implicit shell uplift. (I am eliding this a bit) I run SSH on a shifted port. If I could convince myself that URLs with :port embedded were "cool" I'd move off 443 and 80.
- api 4y ago
  SRV record support is still very inconsistent. Loads and loads of stuff just always hard codes the port.
  - ggm 4y ago
    yep. its one of those "we could but we don't" moments. We could stop using WKS if we were willing to try.
- anyfoo 4y ago
  Not sure, I think it was more complex than that. The "tcpmux" port 1 in /etc/services hints to some of the story. And wasn't there an early competing name system (called NAMES maybe?) that included the port as well, which lost out against DNS for... some reason? I think there were some nuances that are long forgotten.
- wahern 4y ago
  Before SRV records existed, there was portmap for RPC services like NFS. Most system and network administrators hated portmap, still hate portmap, and the requirement for portmap was removed from NFSv4, at least for querying the target port of remote services. People are too accustomed to relying on firewall rules. We can't have nice things like SRV not because they're too difficult to use, but because they're too difficult to control with simple, static, external ACLs lower down the networking stack.
- voltagex_ 4y ago
  OpenSSH doesn't support SRV records by default - it would make things easier to move if it did.
duxup 4y ago
Heck I remember when whitehouse.gov had an open mail relay. Th internet was a very trusting place once. I sent a lot of mail through there…
kazinator 4y ago
TCP and UDP communication doesn't just go over a network. If you're talking to a service on the same machine, and the port number is in the privileged range, then (in theory) you have the assurance that it's a root process and that sending messages to it is as secure as passing data to the kernel.
- anyfoo 4y ago
  Should probably better use a UNIX domain socket for that, which honors POSIX permissions on its file.
  - kazinator 4y ago
    Unix domain socket permissions are quagmire of portability, aren't they? It adds complexity to the app if the app also does speak over the network. It's more than just changing how you create the sockets, and a few details around that. You will find that the detailed semantics of some of the socket operations will be different here and there. E.g. exactly how a non-blocking connect works over a AF_UNIX versus AF_INET in all the cases that may arise; things like that. The configuration may be exposed to the user who may have to learn to specify a Unix socket for the local case or else an IP address. If there is some configuration language, it may have to be tweaked to indicate the address type. (Could be as simple as a hack somewhere that if there is a leading slash, it's AF_UNIX).
deleted 4y ago
[deleted]

by anyfoo 4y ago

ggm 4y ago

This is also half the story in some ways. SRV records didn't exist because the DNS didn't exist. Email "was" port 25 because that was the assigned port. It was uplifted into the WKS (well known services) model as IANA port allocations, and then rei-ified by "ask IANA for a port" and low number assignment implicitly meant a service daemon which had to setuid() to the user for specific delivery events (most things were store-and-forward) Once SRV records were invented, at the cost of 2+ DNS RTT you can ask "hey, where do I talk SMTP to this place" and be told what port to bind to. But lots of stuff was godfathered in, great-grandfathered in. Too many people think SSH is on 22 and don't want to incur the DNS costs. before this, its 25 for mail. 110 for POP, 123 for NTP for pretty good reasons: we didn't have anything else, except inter-host agreement which ports bound to which service, and the services were almost exclusively launched by root from init process. The trend to dropping effective UID came pretty damn quickly after people realized SMTP as root meant remote actors sending Subject: "|bad stuff; even worse" subject lines to exec() calls which did implicit shell uplift. (I am eliding this a bit) I run SSH on a shifted port. If I could convince myself that URLs with :port embedded were "cool" I'd move off 443 and 80.

api 4y ago
SRV record support is still very inconsistent. Loads and loads of stuff just always hard codes the port.
- ggm 4y ago
  yep. its one of those "we could but we don't" moments. We could stop using WKS if we were willing to try.
anyfoo 4y ago
Not sure, I think it was more complex than that. The "tcpmux" port 1 in /etc/services hints to some of the story. And wasn't there an early competing name system (called NAMES maybe?) that included the port as well, which lost out against DNS for... some reason? I think there were some nuances that are long forgotten.
wahern 4y ago
Before SRV records existed, there was portmap for RPC services like NFS. Most system and network administrators hated portmap, still hate portmap, and the requirement for portmap was removed from NFSv4, at least for querying the target port of remote services. People are too accustomed to relying on firewall rules. We can't have nice things like SRV not because they're too difficult to use, but because they're too difficult to control with simple, static, external ACLs lower down the networking stack.
voltagex_ 4y ago
OpenSSH doesn't support SRV records by default - it would make things easier to move if it did.

duxup 4y ago

Heck I remember when whitehouse.gov had an open mail relay. Th internet was a very trusting place once. I sent a lot of mail through there…

kazinator 4y ago

TCP and UDP communication doesn't just go over a network. If you're talking to a service on the same machine, and the port number is in the privileged range, then (in theory) you have the assurance that it's a root process and that sending messages to it is as secure as passing data to the kernel.

anyfoo 4y ago
Should probably better use a UNIX domain socket for that, which honors POSIX permissions on its file.
- kazinator 4y ago
  Unix domain socket permissions are quagmire of portability, aren't they? It adds complexity to the app if the app also does speak over the network. It's more than just changing how you create the sockets, and a few details around that. You will find that the detailed semantics of some of the socket operations will be different here and there. E.g. exactly how a non-blocking connect works over a AF_UNIX versus AF_INET in all the cases that may arise; things like that. The configuration may be exposed to the user who may have to learn to specify a Unix socket for the local case or else an IP address. If there is some configuration language, it may have to be tweaked to indicate the address type. (Could be as simple as a hack somewhere that if there is a leading slash, it's AF_UNIX).

deleted 4y ago

[deleted]