5 ms·

I don't disagree. But the problem began decades ago when sysadmins started using firewalls to control what employees could access. During early 2000's I was in

I don't disagree. But the problem began decades ago when sysadmins started using firewalls to control what employees could access. During early 2000's I was involved in moving a lot of apps that used a bespoke port to port 80/443 just to make sure our apps and services didn't have any client hiccups due to (rightly so?) belligerent sysadmins. All this has really done has made sysadmins lives harder bc of packet inspection. So, all app developers and now infrastructure solution devs must run thru 443, otherwise the take up wouldn't happen. The internet is effectively running on one port nowadays.

throw0101a 7y ago
> But the problem began decades ago when sysadmins started using firewalls to control what employees could access. If the sysadmins were told "We don't want people doing X on company time: stop it.", that is hardly the sysadmins' fault. Do you think IT / Helpdesk wants the drama of extra calls because certain things are blocked? That they're sitting in their cubicles twirling their sinister mustaches thinking of ways to make people's lives more difficult?
- aduitsis 7y ago
  The Bastard Operator From Hell! :-)
- mrfredward 7y ago
  Honestly, I've met a handful of IT bureaucrats who enjoyed the power trip of holding up dozens of people on a multimillion dollar project over an outdated policy. These people are the exception, not the norm, but it only takes one.
  - pdkl95 7y ago
    > holding up ... over an outdated policy https://en.wikipedia.org/wiki/Slowdown#Rule-book_slowdown https://en.wikipedia.org/wiki/Slowdown#Rule-book_slowdown When used carefully, it can be a very effective tactic.
ma2rten 7y ago
Why not extent the existing protocol and keep it on port 53, which DNS already uses?
- snuxoll 7y ago
  Because some companies run with an effective iptables -t filter -A FORWARD -p udp --dport 53 -j DROP And prevent anything from their own internal resolvers from accessing outside DNS services, especially now that encrypted SNI is moving more web filtering to the DNS layer.
  - mlyle 7y ago
    But that one is OK. DNS over HTTPS doesn't exist to circumvent enterprise content filtering (hence why you can hint you don't want it to run with a DNS entry, making it vulnerable to downgrade attacks). Easier to make the orgs internal recursive resolver "does the right thing" than all clients, too.
    - growse 7y ago
      > DNS over HTTPS doesn't exist to circumvent enterprise content filtering Replace "enterprise" with "ISP" or "nation state", and that's closer to what the DoH aims are.
  - unionpivo 7y ago
    Sure, if you have internal only sites, you pretty much have to, and this is used even in small and medium shops. DOH will cause so much drama when internal sites wont resolve any more.
    - lazylizard 7y ago
      Its perfectly ok to let your internal sites be resolved outside your network? Abc.internal resolves to 192.168.0.101 is fine?
      - 7y ago
belorn 7y ago
Early 2000's was also when email got encryption between a mail client and the server. Belligerent sysadmins may try to block all ports except 80 and 443, but users get a bit upset when 143, 993, 25 or 465 get blocked and mail stop working.
api 7y ago
I did a talk on this phenomenon once. It's a form of Red Queen's Race: admins block stuff, protocols not blocked grow to subsume blocked functionality, repeat. In the end we will have a virtualized Internet 100% encrypted and tunneled over port 443, rendering the physical IP header worthless legacy baggage. To IT admins: the more you tighten your grip, the more protocols will slip through your fingers.
- marcosdumay 7y ago
  It's the consequence of a design flaw on IP, because every information for consumption only of the final host should have been encrypted. Nobody knew better at the time, but this time we know. Fortunately, it will end at HTTPS, and it's just a matter of optimizing it well enough (in HTTPS4, or 5, or how many it takes) to make it behave like an internet-level protocol and replace IP.

throw0101a 7y ago

> But the problem began decades ago when sysadmins started using firewalls to control what employees could access. If the sysadmins were told "We don't want people doing X on company time: stop it.", that is hardly the sysadmins' fault. Do you think IT / Helpdesk wants the drama of extra calls because certain things are blocked? That they're sitting in their cubicles twirling their sinister mustaches thinking of ways to make people's lives more difficult?

aduitsis 7y ago
The Bastard Operator From Hell! :-)
mrfredward 7y ago
Honestly, I've met a handful of IT bureaucrats who enjoyed the power trip of holding up dozens of people on a multimillion dollar project over an outdated policy. These people are the exception, not the norm, but it only takes one.
- pdkl95 7y ago
  > holding up ... over an outdated policy https://en.wikipedia.org/wiki/Slowdown#Rule-book_slowdown https://en.wikipedia.org/wiki/Slowdown#Rule-book_slowdown When used carefully, it can be a very effective tactic.

ma2rten 7y ago

Why not extent the existing protocol and keep it on port 53, which DNS already uses?

snuxoll 7y ago
Because some companies run with an effective iptables -t filter -A FORWARD -p udp --dport 53 -j DROP And prevent anything from their own internal resolvers from accessing outside DNS services, especially now that encrypted SNI is moving more web filtering to the DNS layer.
- mlyle 7y ago
  But that one is OK. DNS over HTTPS doesn't exist to circumvent enterprise content filtering (hence why you can hint you don't want it to run with a DNS entry, making it vulnerable to downgrade attacks). Easier to make the orgs internal recursive resolver "does the right thing" than all clients, too.
  - growse 7y ago
    > DNS over HTTPS doesn't exist to circumvent enterprise content filtering Replace "enterprise" with "ISP" or "nation state", and that's closer to what the DoH aims are.
- unionpivo 7y ago
  Sure, if you have internal only sites, you pretty much have to, and this is used even in small and medium shops. DOH will cause so much drama when internal sites wont resolve any more.
  - lazylizard 7y ago
    Its perfectly ok to let your internal sites be resolved outside your network? Abc.internal resolves to 192.168.0.101 is fine?
    - 7y ago

belorn 7y ago

Early 2000's was also when email got encryption between a mail client and the server. Belligerent sysadmins may try to block all ports except 80 and 443, but users get a bit upset when 143, 993, 25 or 465 get blocked and mail stop working.

api 7y ago

I did a talk on this phenomenon once. It's a form of Red Queen's Race: admins block stuff, protocols not blocked grow to subsume blocked functionality, repeat. In the end we will have a virtualized Internet 100% encrypted and tunneled over port 443, rendering the physical IP header worthless legacy baggage. To IT admins: the more you tighten your grip, the more protocols will slip through your fingers.

marcosdumay 7y ago
It's the consequence of a design flaw on IP, because every information for consumption only of the final host should have been encrypted. Nobody knew better at the time, but this time we know. Fortunately, it will end at HTTPS, and it's just a matter of optimizing it well enough (in HTTPS4, or 5, or how many it takes) to make it behave like an internet-level protocol and replace IP.