Wikipedia:Reference desk/Archives/Computing/2011 January 9

= January 9 =

Could intermediate networks alter my data?
If I do a traceroute to Wikipedia I see that the connection goes through several seemingly unrelated networks before reaching "ge-2-2.br1-knams.wikimedia.org". To simplify things for my question, lets assume it's just; - myisp.org - somenetwork.net - wikimedia.org

I assume my http requests, ip address, and other info are sent to each link along the connection? What verification checks are in place (if any) to ensure that one of the links doesn't corrupt or alter the info either by accident or on purpose for some nefarious reason? For example, "somenetwork.net" receives my ip as 82.44.55.25 but sends my ip as 12.34.56.78 to wikimedia.org. Is such a thing possible? Would wikimedia.org see 12.34.56.78? 82.44.55.25 (talk) 22:05, 9 January 2011 (UTC)
 * Unless you use the https link to wikipedia there is no such guarantee. Dmcq (talk) 22:16, 9 January 2011 (UTC)
 * So if I owned "somenetwork.net" I could make it appear as though I had any ip address I wanted? 82.44.55.25 (talk) 22:28, 9 January 2011 (UTC)


 * You are making the assumption that your request and the response are all in one packet. See TCP/IP model for a better idea how internet traffic works. --  k a i n a w &trade; 22:31, 9 January 2011 (UTC)


 * Also see man-in-the-middle attack, which is what it's called when there's an attacker controlling some part of the path between you and the entity you're trying to communicate with. 67.162.90.113 (talk) 23:41, 9 January 2011 (UTC)


 * They could mess with your data just like food distribution companies could mess with your groceries. Your ISP pays a bigger ISP for bandwidth which it subdivides among its customers, that ISP gets its connection from an even bigger ISP, and so on. Eventually (usually very quickly) this tops out at the tier 1 network providers, which own the physical world-spanning cables. Your route to Wikipedia goes up your ISP chain to the tier 1 providers, then down Wikipedia's ISP chain to their datacenter. These big ISPs don't want to corrupt your data packets because that wouldn't maximize shareholder value. Whether somebody is eavesdropping on the connection is another matter; probably many governments have arrangements with the tier 1 providers to give them access to the traffic. -- BenRG (talk) 09:40, 10 January 2011 (UTC)
 * Actually, forget the grocery analogy. A much better analogy is UPS or FedEx. If you track your package through their system you'll see it percolate up to a major hub, then possibly to a different one, then back down the hierarchy. They have internal measures in place to prevent damage/tampering because it would undermine their business. And governments inspect the mail of people they've placed under observation.


 * On the other hand, if you use Tor then your traffic can be sniffed and modified by the random unaccountable people who run Tor exit nodes, and apparently some of them do try to conduct MITM attacks on SSL (HTTPS) connections. (You're safe from this attack as long as your browser validates site certificates, which the major ones all do.) -- BenRG (talk) 01:52, 11 January 2011 (UTC)

It is technically very possible for someone in the middle to alter the data without the endpoints noticing. The only protection against that is an authentication scheme. Https, IPSEC, and similar protocols provide some protection against this if done correctly. Note that authentication here is different than encryption, although a good encryption system will almost certainly have authentication (the opposite doesn't have to). Shadowjams (talk) 00:30, 11 January 2011 (UTC)


 * What OP are describing is routinely being done. See Network address translation.  It's beeing done in order to use local adresses on your LAN and only have a single public IP adress.  This is needed because there are too few IPv4 adresses.  But you can't use it to show any IP adress, because you need to use IP adresses that actually gets routed to your network.  Taemyr (talk) 08:54, 12 January 2011 (UTC)