Hacker News Reader

Comment by alphazard | Hacker News Reader

This is pretty neat, definitely better to move to UDP, so that we can have the proper response to unauthorized contact--no response.

QUIC is fine as is though, no need to layer HTTP3 on top of it.

View on HN

The reason they’re using HTTP is to allow for hiding the SSH server so that it pretends to be a dummy HTTP server that responds to 404 on all requests unless you know the special random URL that hosts the SSH capabilities. It’s a neat idea but overkill when you’re not using that capability (didn’t dig into the code so maybe it is bypassed if you don’t ask for a secret URL). It does make me hesitant as I don’t know how secure Go’s HTTP stack is since an exploit there could expose quite a bit and I don’t know that it’s been hardened to host directly, but it is an interesting idea. May be worth hand-rolling a custom server to do the routing but at the same time it makes it easier to fingerprint. I think it makes more sense to separate the routing secret to a standard reverse proxy that’s harder to fingerprint. One could imagine that the secret URL idea in a normal HTTP stack is susceptible to scanning techniques since there’s only one route to guess.

HTTP/3 is almost indistinguishable from any other protocol running over QUIC, and QUIC itself is almost indistinguishable from random noise in UDP packets. If you want to masquerade as HTTP/3 traffic, just using UDP on port 443 will generally be sufficient.

(Only “almost” indistinguishable, because it’s possible to decrypt the first packets of the client’s handshake and examine the ALPN parameters used to negotiate an application protocol. And QUIC may be further distinguishable from other UDP traffic through statistical analysis of packet sizes and response latencies, as well as the few unencrypted header bits.)

It's not exactly the same but you can "hide" a ssh server on port 443 with haproxy

It's not really hidden as if you initiate a connection with ssh it will reveal itself, but if you try https it will reply as a webserver

It world by looking at the first few bytes and deciding what to do based on that

At one point I was running https/ssh/openvpn/custom-tcp all on one port..

Here is someone else explaining how to do it, I don't think I ever wrote it up

https://news.ycombinator.com/item?id=8925938

I never even thought of that, atlassian has a page on it: https://confluence.atlassian.com/bitbucketserver/setting-up-...

Yeah its overkill. Its like trying to hide a meth lab by just putting up a sign that says daycare. (and if you do a special knock on the door you go to the secret room) Edit: vs having an invisible building which if you knock on it the right way, materializes...

The best thing about QUIC if its udp is definately that it could be made un portscannable.

It's likely the URL can be discovered via basic timing attacks as virtually zero routers do constant-time comparisons for route matching.

If the URL path is meant to be kept secret, such as here, they should use a password hashing algorithm such as for example bcrypt or scrypt for the URL path and hash the path of every incoming request and then check the hash of the path instead of the path itself

I'm unaware of any http router that does this out-of-the-box. It would have to be something custom.

Isn’t it necessary for oauth?

It might be easier to integrate but you’ve got a custom server and client in this case so it should be possible to do both without HTTP being involved for the server/client layer without an HTTP server? At least I think that’s right but it’s been a long long while since I wrote OAUTH code.

Seems like it’s primarily to implement the masking feature to pretend to be a normal HTTP server hosted on a port until the shared secret URL is knocked.

The client and server need to talk http to the authorization server, that doesn't mean they need to talk http to each other.

Reply on news.ycombinator.com