As many of you know, a couple of weeks ago we released the first version of the Crust (‘Connections in Rust’) Test. For a short time, anyone could download software and connect directly to others around the world. We saw an amazing level of demand - but also some intriguing results.
The first round of testing has proven that there are some strange things happening out there. We have evidence that data being sent by individuals (one in particular based in the US) has been changed by an intermediary. To be clear, we’re not alleging any direct attack by authorities on the connections between SAFE peers during the test. But neither are we ruling out the possibility that this is taking place.
If you look closely at the image above, you’ll see a difference between the details that are sent and the details received. Without getting into the technical details, the important thing to take away so far is that this provides us with yet more evidence that encryption is not just an optional nice-to-have - but an utterly essential part of a decentralised Web. After all if, say, an ISP can change your IP address, what else is it doing to your data behind the scenes?
Encryption prevents this. That’s exactly why we’ve built the Crust library with this principle in mind. It’s all very well creating a software library that facilitates peer-to-peer communication. But if (as many high-profile projects are doing today) you’re not encrypting every single piece of user data as it hits the wire? You’re little more than a Band-Aid that falls off as soon as the weather turns. And you’re no longer solving the very real problems out there.
On that front, we’re super excited to announce that v2 of the Crust Test is imminent. And once again, you’ll get the chance to play your own part in making history (as some who know the project very well have described it).
I don’t know what the screen shot is supposed to show, but isn’t the difference just the normal Network Address Translation done by ISP router (from local IP address to public one) ?
Well, translation is done both ways by the router and we don’t know which side is sender and which side is receiver. Anyway that seems a plausible explanation for me.
Edit: another one could be a bug in the program that prints the wrong address under some specific conditions.
I got to be honest, I’m not seeing anything nefarious in that image, or even particularly unusual or concerning. Even still, I’m excited to see what improvements have been made from the first round of testing.
How is it possible to know what user actually sent?
It is possible that someone changed sources to send different information with each route (to test how your software will handle such situation).
upd. “Intermediary” could also be antivirus, firewall or broken operating system. upd2. I personally saw how “reliable” TCP connection was randomly getting trash instead of data because of bad firewall.
I think the point really is regardless the intermediary must be prevented from any tampering of data so it cannot even see an ip address in the data and change it like this. Fair enough tcp or udp header info as that is always clear, and must be, but not in data. This is where we win as we do not allow unencrypted or man in the middle altering of data. Routing adds even more as it encapsulates data further in signed packets.
Great work. These tests, the test results, the run up to SAFE-Flemming, and the SAFE-Flemming release itself are full of goodies for crypto and other news outlets to report on.
Who wouldn’t run a story about data being intercepted and changed? … and about the
technology to stop it.
To clarify, are we seeing header information or data within a packet that has been changed?
As others said, if it’s header info being changed by the isp for NAT, I don’t see a big deal. If this is packet data being changed in route… well, that’s a different story.
Just to make it clear - the stuff in the OP is not a tcp header - that is the payload. The IP was embedded in a payload which was 430 B when written to the socket and as captured by wireshark. The payload has other stuff besides just the IP (includes a serialised structure). The change was made to the payload (IP changed) and an extra byte (bogus proabably) added somewhere making it 431 B and failing deserialisation at the destination. The TCP header’s checksum was changed accordingly so that the packet was not discarded on the way to the destination.
Now that could be due to malice, just something unnecessary being done at some router, etc etc.
Once you encrypt, it solves the problem in two ways:
The modifying entity above could not make out the content of the packet, so there’s nothing to infer in order to change something.
If it still changed something there’s a guarantee it will fail at the other end as authenticated-encryption/decryption failure. In the above case we were just lucky that an extra byte was added which led to a deserialisation failure - it’s not always going to be that. Changing IPx to IPy somewhere in the payload is not likely to cause deserialisation failure always (as long as the IP’s are valid). Just like if you were to serialise say an array of length 4 : [10, 12, 13, 14] to [11, 12, 13, 14] it’s not going to fail deserialisation. It would just go unnoticed for a long time and cause failure which we would attribute to a genuine failure and ignore it until analysed deeply someday.
