There's something about the way that this is written that rubs me the wrong way. There's a lot of emphasis on how unlikely the attack would be - that the collision would take "significant resources", that many conditions must be true at the same time, that Pulse Security's proof was unrealistically simple.
All of this can be true, but rhetorically, it sends the wrong message to put so much emphasis on this. The message I'd like to see would be more like this:
"We got notified of this security problem. We immediately worked on mitigation and to find out if any customers were affected. We couldn't find any, and we have patched the problem. We have a patch for you to apply to fully prevent the problem.
The problem depended upon an identity collision. We think the probability of this is remote, but we always take this stuff very seriously."
In other words, I want to see platforms like this emphasize their response, rather than try to convince me that the problem is minor. The way these things are phrased matters a lot!
As a network admin I think my primary concern on first reading is actually the severity of the problem and how much I should worry about it. Then it’s good to see that the response was prompt and transparent. Probably can’t satisfy everybody no matter how you write it.
I’m giving them the benefit of the doubt. Sounds like they had some audits / penetration testing done, the security firm found a real weakness, but it’s just unlikely to happen.
They disclosed the issue pretty well, but at the same time, are afraid of the response; they decided to overcommunicate that they attack vector has likely never been exploited, and I can see why they did that.
I’m not sure I see a big difference between what you wrote and what the article said since you also minimize the likelihood of the attack and the article also talked about their response.
I certainly agree with you. I just posted a few days ago saying I would never trust this company.
In fact, I would never trust a company that didn't explicitly state that the company having a central server facilitating operations (Signal, et all) is a huge risk.
Definitely. We've had formal design audits, informal audits, and open source audits (like the one that found this issue). Formal audits are in the works.
We're glad this was found and glad that this is the first significant vulnerability report we've received in many years of operation, but we don't want that to make us arrogant. Distributed systems are hard and cryptography is hard. Distributed systems with cryptography are REALLY hard. :)
We've talked to Pulse Security about hiring them in the future. The fact that they found this obscure issue is a pretty strong pitch.
From this response it's not quite clear to me: So this identity collision is against their Curve25519 implementation? Does this mean the attacker has effectively found a new brute force attack on that specific public/private key algorithm? That seems it would be bigger news and affecting more than just zerotier. Or is here some proprietary crypto in place on which the collision has been generated? Maybe I'm missing an important link with the details?
I believe in some areas there was a shortened, truncated form of the public key being used as an "address".
If a device went offline and was forgotten about (but still trusted), an impersonator spoofing the same (truncated) public key could gain access, as long as the server didn't reject this identity and say "that's not the public key you had before". I believe truncation was used to facilitate typing it into the UI.
So in short, it seems to me this aspect was based on truncation of a public key or hash, and the inevitable finding of collisions in this reduced address space.
[+] [-] spenczar5|4 years ago|reply
All of this can be true, but rhetorically, it sends the wrong message to put so much emphasis on this. The message I'd like to see would be more like this:
"We got notified of this security problem. We immediately worked on mitigation and to find out if any customers were affected. We couldn't find any, and we have patched the problem. We have a patch for you to apply to fully prevent the problem.
The problem depended upon an identity collision. We think the probability of this is remote, but we always take this stuff very seriously."
In other words, I want to see platforms like this emphasize their response, rather than try to convince me that the problem is minor. The way these things are phrased matters a lot!
[+] [-] wrs|4 years ago|reply
[+] [-] stingraycharles|4 years ago|reply
They disclosed the issue pretty well, but at the same time, are afraid of the response; they decided to overcommunicate that they attack vector has likely never been exploited, and I can see why they did that.
[+] [-] squidlogic|4 years ago|reply
[+] [-] insilicophage|4 years ago|reply
[+] [-] atok1|4 years ago|reply
In fact, I would never trust a company that didn't explicitly state that the company having a central server facilitating operations (Signal, et all) is a huge risk.
[+] [-] Terretta|4 years ago|reply
Feels like a contra-indicator to me when I read it, like “military grade encryption”.
[+] [-] aborsy|4 years ago|reply
Any plan for a careful audit of the code, considering that ZeroTier is a popular security product?
[+] [-] api|4 years ago|reply
We're glad this was found and glad that this is the first significant vulnerability report we've received in many years of operation, but we don't want that to make us arrogant. Distributed systems are hard and cryptography is hard. Distributed systems with cryptography are REALLY hard. :)
We've talked to Pulse Security about hiring them in the future. The fact that they found this obscure issue is a pretty strong pitch.
[+] [-] tptacek|4 years ago|reply
[+] [-] m4lvin|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] dominicl|4 years ago|reply
[+] [-] g_p|4 years ago|reply
If a device went offline and was forgotten about (but still trusted), an impersonator spoofing the same (truncated) public key could gain access, as long as the server didn't reject this identity and say "that's not the public key you had before". I believe truncation was used to facilitate typing it into the UI.
So in short, it seems to me this aspect was based on truncation of a public key or hash, and the inevitable finding of collisions in this reduced address space.
[+] [-] RL_Quine|4 years ago|reply
[+] [-] tptacek|4 years ago|reply