3 ms·

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,

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.

heyoni 3y ago
Isn’t it necessary for oauth?
- vlovich123 3y ago
  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.
- the8472 3y ago
  The client and server need to talk http to the authorization server, that doesn't mean they need to talk http to each other.
vlovich123 3y ago
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.
- withinboredom 3y ago
  It's likely the URL can be discovered via basic timing attacks as virtually zero routers do constant-time comparisons for route matching.
  - codetrotter 3y ago
    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
    - withinboredom 3y ago
      I'm unaware of any http router that does this out-of-the-box. It would have to be something custom.
- jofla_net 3y ago
  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.
- gnyman 3y ago
  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 https://news.ycombinator.com/item?id=8925938
  - stjohnswarts 3y ago

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.

heyoni 3y ago

Isn’t it necessary for oauth?

vlovich123 3y ago
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.
the8472 3y ago
The client and server need to talk http to the authorization server, that doesn't mean they need to talk http to each other.

vlovich123 3y ago

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.

withinboredom 3y ago
It's likely the URL can be discovered via basic timing attacks as virtually zero routers do constant-time comparisons for route matching.
- codetrotter 3y ago
  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
  - withinboredom 3y ago
    I'm unaware of any http router that does this out-of-the-box. It would have to be something custom.
jofla_net 3y ago
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.
gnyman 3y ago
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 https://news.ycombinator.com/item?id=8925938
- stjohnswarts 3y ago