4 ms·

> ZeroTier uses a construction where the identity is the outer envelope Does this mean that any node along the network path would be able to track communicatio

> ZeroTier uses a construction where the identity is the outer envelope Does this mean that any node along the network path would be able to track communications between nodes? Maybe a snoop wouldn't be able to pin an envelope to a named identity, but they would be able to track which other identities its connecting to down to the communication bandwidth between each source and destination and correlate the identities of those connections between separate devices. Is this an accurate description?

api 4y ago
Yes, and that's a downside. My opinion though is that unless you are tunneling every single bit of your network traffic through something that is concealing your identity, fingerprinting the vast majority of devices and users is trivially easy. There is just an amazing amount of surface area: browser fingerprinting, protocol version fingerprinting, network access pattern fingerprinting, DNS snooping, TCP fingerprinting, and so on. Since ZT (and Tailscale and Nebula and other similar things) are all P2P it's trivial to fingerprint someone by just collecting the IP endpoints they routinely communicate with. Anyone who belongs to a private net with a few fixed points can be easily identified over time by the fact that they talk to those things in a certain pattern. I have some thoughts about features to really defeat this. We've got an entry on our feature queue for guard nodes you can run in the cloud and have also researched implementing a form of "light" onion routing. It wouldn't be intended to be as strong (or as slow) as Tor, but sufficient to prevent passive dragnet surveillance. In any case there is a conflict here between goals. So far the performance, rapid startup, and enterprise goals have won out over the small privacy benefit of the ephemeral-outer-key construction. It's a scope thing. So far we've never scoped ZeroTier as a meta-data-concealing protocol like Tor, just as a P2P mesh protocol for easy remote access between devices and locations. Still... it's tempting to try to find something in the V2 design to at least mitigate this issue. It's something we're thinking about.
- infogulch 4y ago
  I like the guard nodes idea ("gateway" or "proxy" nodes?). Maybe introduce a gateway node type, and add a way to pass traffic through a particular gateway (with a second tor-like encryption layer) defined using an extension to the current flow rules language. That would collapse all the traffic behind the gateway into a single identity (the gateway's), and probably be general enough to support all kinds of fancy features like onion-routing, monitored link balancing, etc.
  - api 4y ago
    Yeah. I think a TL;DR on my reply above: I think the difference in privacy between identity(ephemeral(x)) and ephemeral(identity(x)) is not significant. It's more honest to tell people that our product offers only content privacy not meta-data privacy unless we are truly implementing strong countermeasures against tracking by ISPs or others that can pervasively sniff the net. Just nixing the identity key visibility is not a strong countermeasure for the reasons I described.

api 4y ago

Yes, and that's a downside. My opinion though is that unless you are tunneling every single bit of your network traffic through something that is concealing your identity, fingerprinting the vast majority of devices and users is trivially easy. There is just an amazing amount of surface area: browser fingerprinting, protocol version fingerprinting, network access pattern fingerprinting, DNS snooping, TCP fingerprinting, and so on. Since ZT (and Tailscale and Nebula and other similar things) are all P2P it's trivial to fingerprint someone by just collecting the IP endpoints they routinely communicate with. Anyone who belongs to a private net with a few fixed points can be easily identified over time by the fact that they talk to those things in a certain pattern. I have some thoughts about features to really defeat this. We've got an entry on our feature queue for guard nodes you can run in the cloud and have also researched implementing a form of "light" onion routing. It wouldn't be intended to be as strong (or as slow) as Tor, but sufficient to prevent passive dragnet surveillance. In any case there is a conflict here between goals. So far the performance, rapid startup, and enterprise goals have won out over the small privacy benefit of the ephemeral-outer-key construction. It's a scope thing. So far we've never scoped ZeroTier as a meta-data-concealing protocol like Tor, just as a P2P mesh protocol for easy remote access between devices and locations. Still... it's tempting to try to find something in the V2 design to at least mitigate this issue. It's something we're thinking about.

infogulch 4y ago
I like the guard nodes idea ("gateway" or "proxy" nodes?). Maybe introduce a gateway node type, and add a way to pass traffic through a particular gateway (with a second tor-like encryption layer) defined using an extension to the current flow rules language. That would collapse all the traffic behind the gateway into a single identity (the gateway's), and probably be general enough to support all kinds of fancy features like onion-routing, monitored link balancing, etc.
- api 4y ago
  Yeah. I think a TL;DR on my reply above: I think the difference in privacy between identity(ephemeral(x)) and ephemeral(identity(x)) is not significant. It's more honest to tell people that our product offers only content privacy not meta-data privacy unless we are truly implementing strong countermeasures against tracking by ISPs or others that can pervasively sniff the net. Just nixing the identity key visibility is not a strong countermeasure for the reasons I described.