3 ms·

Yes, after you've got the shared key from whatever source you can port scan. However, getting that shared key is not do-able if you really keep it secret (e.g.

by dtech 12y ago

Yes, after you've got the shared key from whatever source you can port scan. However, getting that shared key is not do-able if you really keep it secret (e.g. as an additional security measure for SSH) or really hard to do automatically (e.g. crawling the web or app store) It's far from perfect, but it probably is the best you can do without breaking TCP (the new "stealth" SYN's are still valid SYN's under current TCP) However for most use-cases, I don't know if it is a better solution than using a non-standard port.

mnw21cam 12y ago
For most use cases, if you want to hide your connectivity behind a reasonable cryptographic layer, a better (and stronger) option is to firewall everything except incoming ssh, and then do ssh port forwarding. I can see people using this, but it should not be relied upon as a security measure - rather it is a mechanism for reducing log file clutter for the multitudes of random probes that an internet-connected machine receives.
- calgoo 12y ago
  I was thinking that this could be used similar to a session key in an application. So if you made a web server, you could allow all traffic to say: /login that then recieves the key after authentication. This could then be used to reach the secure area of your application, and anyone without the secure key cant even detect that part of the app.
ckozlowski 12y ago
I guess my hangup is, if the primary goal of this is to prevent drive-by port scanning, then that means implementing this on the public internet. And I cannot conceive of how you'd distribute a pre-shared key over that large a base and not 1. make it trivial to obtain your key and 2. Not create a massive headache for your users.
- shawnz 12y ago
  > [...] that means implementing this on the public internet. And I cannot conceive of how you'd distribute a pre-shared key over that large a base [...] Sure, the servers in question would have to be internet connected for this to be useful. But that doesn't mean they are open-access. If they were, of course it wouldn't make sense to use this. But consider, for example, that you are setting up a server at your organization to provide employees with remote access. Nobody but your employees need to have access, but it still must be internet visible. Wouldn't that be a good use case for this?
  - ckozlowski 12y ago
    A VPN would be better then.
    - shawnz 12y ago
      I am not suggesting to not use a VPN. But a VPN alone doesn't solve the visibility problem. Similar to port knocking, this would prevent anyone from knowing that the server even exists without knowing the IP and key in advance. This isn't an alternative to VPNs. In fact, as far as I'm concerned, this proposal is only useful when combined with a VPN!

by dtech 12y ago

mnw21cam 12y ago

For most use cases, if you want to hide your connectivity behind a reasonable cryptographic layer, a better (and stronger) option is to firewall everything except incoming ssh, and then do ssh port forwarding. I can see people using this, but it should not be relied upon as a security measure - rather it is a mechanism for reducing log file clutter for the multitudes of random probes that an internet-connected machine receives.

calgoo 12y ago
I was thinking that this could be used similar to a session key in an application. So if you made a web server, you could allow all traffic to say: /login that then recieves the key after authentication. This could then be used to reach the secure area of your application, and anyone without the secure key cant even detect that part of the app.

ckozlowski 12y ago

I guess my hangup is, if the primary goal of this is to prevent drive-by port scanning, then that means implementing this on the public internet. And I cannot conceive of how you'd distribute a pre-shared key over that large a base and not 1. make it trivial to obtain your key and 2. Not create a massive headache for your users.

shawnz 12y ago
> [...] that means implementing this on the public internet. And I cannot conceive of how you'd distribute a pre-shared key over that large a base [...] Sure, the servers in question would have to be internet connected for this to be useful. But that doesn't mean they are open-access. If they were, of course it wouldn't make sense to use this. But consider, for example, that you are setting up a server at your organization to provide employees with remote access. Nobody but your employees need to have access, but it still must be internet visible. Wouldn't that be a good use case for this?
- ckozlowski 12y ago
  A VPN would be better then.
  - shawnz 12y ago
    I am not suggesting to not use a VPN. But a VPN alone doesn't solve the visibility problem. Similar to port knocking, this would prevent anyone from knowing that the server even exists without knowing the IP and key in advance. This isn't an alternative to VPNs. In fact, as far as I'm concerned, this proposal is only useful when combined with a VPN!