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

Serve2d – A protocol detecting server

github.com

Post reply on HN
Print view View original

41–50 of 77 posts

Re: Serve2d – A protocol detecting server

#41

Post by nadams »

BillinghamJ wrote: post #12

Why? The entire point of ports is so you don't have to do this. Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.

> Why? The entire point of ports is so you don't have to do this.

There are use cases - many nefarious cases but some real world cases.

Let's say your university allows everything through 80 but blocks everything else. You could SSH home or stream content.

Another use case could be that you have a web site and game server on same server. An interesting implementation could be to listen on port 80 so that they could connect to yourserver.com via HTTP and view information about the game/server and connect on the same port. Interesting but not very practical.

I suppose an acceptable/respectable use case would be custom load balancers or honey pots.

Re: Serve2d – A protocol detecting server

#42

Post by stock_toaster »

[deleted] wrote: post #40
falcolas wrote: post #27

Earlier quoted context omitted.

Doesn't even have to be that nefarious - I am blocked from using my OpenVPN tunnel (UDP and TCP) from at least two restaurants that I'm aware of.

[deleted]

"Those who sacrifice connectivity for bourguignon deserve neither." -- Internet Ben Franklin

Re: Serve2d – A protocol detecting server

#43

Post by scrollaway »

marssaxman wrote: post #38
poizan42 wrote: post #24

Earlier quoted context omitted.

That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.

The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order t…

There are other important downsides to static linking. Namely, critical security updates to shared components. It's better to have to update your tls library once per system, than to update every app that came with it. And that's the best case scenario where the developer notices and the app is actually repackaged.

Re: Serve2d – A protocol detecting server

#44

Post by vidarh »

sigjuice wrote: post #20
BillinghamJ wrote: post #15

Earlier quoted context omitted.

Wouldn't a VPN or tunnelling solution be better? You pass all your traffic through a fixed port on one host, then unwrap it and use the web as though the restriction wasn't there.

VPN or tunneling solutions are unlikely to work if severe network restrictions are in place. e.g. firewalls that only allow TCP ports 80 and 443.

Nothing stops you from passing a VPN through a TCP connection on port 80 and 443. There are few protocols people haven't tunnelled IP over (DNS included...)

Re: Serve2d – A protocol detecting server

#45

Post by skarap »

marssaxman wrote: post #38
poizan42 wrote: post #24

Earlier quoted context omitted.

That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.

The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order t…

It's hard to be sure why exactly shared libraries and dynamic linking appeared. Your explanation about reducing file size for smaller HDD and RAM footprint is probably one of the reasons, but I don't believe it's the only one - I don't remember many shared libraries from MSDOS days (where with 2MB of RAM and 40MB of HDD, storage was really scarce). In fact - I don't remember any libraries! To run Doom you just borrowed the floppies from a friend and it would 100% work. The same for Warcraft 1.

I believe it's more similar to Database Normalization from RDBMS world than to anything else. And the most important objective of Database Normalization is considered "Freeing the database of modification anomalies".

My own experience with shared libraries is pretty positive. I have fixed OpenSSL vulnerabilities many times by just updating the OpenSSL library and restarting all services. Compared to my own experience with docker where after waiting for a few weeks I had to change my base images (as nobody was updating them) updating just a single shared library and having the vulnerability fixed is way easier!

This, of course, is true if those who maintain the software you use do care about backwards compatibility (which tends to be true for the "boring" stuff and false for the stuff considered "cool" - looking at you nodejs library developers who break my build at least once a month).

Re: Serve2d – A protocol detecting server

#46

Post by marssaxman »

scrollaway wrote: post #43
marssaxman wrote: post #38

Earlier quoted context omitted.

The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order t…

There are other important downsides to static linking. Namely, critical security updates to shared components. It's better to have to update your tls library once per system, than to update every app that came with it. And that's the best case scenario where the developer notices and the app is actually repackaged.

Yes, that's the argument I was referring to, and as I said in the comment you're replying to, I don't believe that the cost is worth the benefit.

Re: Serve2d – A protocol detecting server

#47

Post by vidarh »

oasisbob wrote: post #19
BillinghamJ wrote: post #12

Why? The entire point of ports is so you don't have to do this. Don't get me wrong, it's kinda cool, but it seems like a really bad idea to actually do it.

It's not a bad idea, though I'm not sure why someone would want to do this on their own in a bolt-on manner. For an example of a place where demux is encouraged, see RFC 6335: Conservation of the port number space is required because this space is a limited resource, so applications are expected to participate in the traffic demultiplexing process where feasible. The port numbers are expected to encode as little info…

Modern apps seems to do their best to require lots of ports numbers, often with very little justification. It's incredibly annoying.

Some of it understandable, e.g. when one port is for stuff that is always meant to stay behind your firewall, and another for public access. In that case it actually makes things easier to do properly. But so often it appears to be entirely gratuitous.

Re: Serve2d – A protocol detecting server

#49

Post by marcosdumay »

marssaxman wrote: post #38
poizan42 wrote: post #24

Earlier quoted context omitted.

That's a very weird way to look at it. Static linking was there before everything else. gcc/ld and, well, any other C/C++ toolchain can do that as well. There is a reason this isn't usually done. It's like you are trying to spin a bad thing into something good.

The reason this isn't usually done is that executable size was significant relative to storage capacity up until the early 2000s or so, and people tried to economize by deduping common parts of their executables via shared libraries / DLLs. This worked well enough to catch on, but came with an extremely high cost in added complexity, and over the years a whole layer of additional infrastructure was created in order t…

Well, you wouldn't want every executable to copy some unknown version of OpenSSL, and you'd get into all kinds of problems if you had several different versions of glibc around.

But for most libraries it may really be overkill.

Re: Serve2d – A protocol detecting server

#50

Post by nly »

haproxy can do this out of the box. I've been using it for some time to put SSH on port 443 as a backup (not an alternative).

    frontend mux
        mode		    tcp
        bind                EXTERNAL_IP_HERE:443
        acl                 is_tls req.ssl_ver gt 3
        acl                 is_ssh payload(0,8) -m str SSH-2.0-
        tcp-request         inspect-delay 5s
        tcp-request	    content accept if is_ssh
        tcp-request         content accept if is_tls
        use_backend         ssh if is_ssh
        use_backend	    https if is_tls
where 'ssh' and 'https' are tcp mode backends.
Post reply on HN