6 ms·

If I'm reading this correctly, this requires a shared secret on /every/ system that will be establishing a TCP connection with a peer. Given that large key dis

If I'm reading this correctly, this requires a shared secret on /every/ system that will be establishing a TCP connection with a peer. Given that large key distribution and management undertaking, it seems that if one were going to go through with the trouble, there are better mutual protection mechanisms available, and with much larger key sizes than 32bits. This really gets to be challenging where the public internet is involved, and to be frank, I'm not sure how you'd handle that for public services. Let's say you distributed the shared key with your application. Could I then launch a port scan now that I've obtained the key? I hate to say it, but I wonder if I'm just not getting this, or this is a bit tongue-in-cheek like the "evil bit" of days past.

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!
Spooky23 12y ago
The real value of something like this is getting rid of the costs from a process and procedural POV of deploying segmented networks in data centers. Look at solutions like Unisys Stealth. Mostly used in government today, this sort of technology allows for organizations with lots of multi-tenant compliance issues to take weeks off the process of building IT systems. For a company like Microsoft (one of the co-authors was from there), they have strategic service offerings where solving this problem is a huge benefit (ie. Azure) and have infrastructures that addresses things like key distribution (Active Directory).
- ckozlowski 12y ago
  That makes a bit more sense to me; key distribution is a much easier prospect in the managed datacenter. However, there's a lot of SDN tools these days for deploying VLANs behind a software gateway in seconds. I can do a lot of this with AWS or VMware today, and it doesn't involve rewriting the TCP stack.
  - josho 12y ago
    Good point, but rewriting the TCP stack has the upside of not relying on your vendors to provide the functionality. Presumably pushing this down commoditizes the service, which may not have value for you but it does for others.
ckozlowski 12y ago
Thinking about this some more; I think I can articulate my concern a bit more distinctly: Given that I have two systems, on a network in which I know an adversary wishes to deduce the ports I am advertising (as illustrated by the paper's concern over a MitM attack), how do I distribute my shared secret in such a way that my adversary does not deduce it, and does not require a secure channel that would invalidate the need for this mechanism in the first place? I'm no cryptography expert, but from the portions I do know, the challenge is in key distribution. I feel like that is completely missing from the paper, and without it, it limits this mechanism's feasibility enormously.
- wereHamster 12y ago
  RFC2549

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!

Spooky23 12y ago

The real value of something like this is getting rid of the costs from a process and procedural POV of deploying segmented networks in data centers. Look at solutions like Unisys Stealth. Mostly used in government today, this sort of technology allows for organizations with lots of multi-tenant compliance issues to take weeks off the process of building IT systems. For a company like Microsoft (one of the co-authors was from there), they have strategic service offerings where solving this problem is a huge benefit (ie. Azure) and have infrastructures that addresses things like key distribution (Active Directory).

ckozlowski 12y ago
That makes a bit more sense to me; key distribution is a much easier prospect in the managed datacenter. However, there's a lot of SDN tools these days for deploying VLANs behind a software gateway in seconds. I can do a lot of this with AWS or VMware today, and it doesn't involve rewriting the TCP stack.
- josho 12y ago
  Good point, but rewriting the TCP stack has the upside of not relying on your vendors to provide the functionality. Presumably pushing this down commoditizes the service, which may not have value for you but it does for others.

ckozlowski 12y ago

Thinking about this some more; I think I can articulate my concern a bit more distinctly: Given that I have two systems, on a network in which I know an adversary wishes to deduce the ports I am advertising (as illustrated by the paper's concern over a MitM attack), how do I distribute my shared secret in such a way that my adversary does not deduce it, and does not require a secure channel that would invalidate the need for this mechanism in the first place? I'm no cryptography expert, but from the portions I do know, the challenge is in key distribution. I feel like that is completely missing from the paper, and without it, it limits this mechanism's feasibility enormously.

wereHamster 12y ago
RFC2549