AT&T's Plan to Play Internet Cop

Ponca City, We Love You writes "Tim Wu has an interesting (and funny) article on Slate that says that AT&T's recent proposal to examine all the traffic it carries for potential violations of US intellectual property laws is not just bad but corporate seppuku bad. At present AT&T is shielded by a federal law they wrote themselves that provides they have no liability for 'Transitory Digital Network Communications' — content AT&T carries over the Internet. To maintain that immunity, AT&T must transmit data 'without selection of the material by the service provider' and 'without modification of its content' but if AT&T gets into the business of choosing what content travels over its network, it runs the serious risk of losing its all-important immunity. 'As the world's largest gatekeeper,' Wu writes, 'AT&T would immediately become the world's largest target for copyright infringement lawsuits.' ATT's new strategy 'exposes it to so much potential liability that adopting it would arguably violate AT&T's fiduciary duty to its shareholders,' concludes Wu."

Comments

Re:Not just copyright ....

[boaworm]

Yea, that's the whole point of the article, you should really try and read it ;-)

Re:Encryption...

[AKAImBatman]

that doesn't work, all they have to know is that some ip address is serving up copyrighted material on a given port and shut of that port for that server.

I think you misunderstand how a Virtual Private Network works. The first thing you must understand is that there is not spoon^W ports. Once you realize that there are no ports, then you only need to route packets over a secure channel that's indistinguishable from valid business. Is this user networking with his small-business employer, or a pirate spreading illegal wares? Impossible to tell from the traffic itself.

Re:Who do I use for Internet access now then??

[acoustix]

This issue isn't just limited to AT&T customers. It affects everyone because AT&T is a tier 1 provider, meaning that they provide backbone access for several ISPs. They are looking to sniff *all* traffic, not just traffic of their DSL customers.

Nick

Re:we've already done this to death

[Cheerio Boy]

Does Speakeasy offer DSL in your area? That's what I did until I could go with RCN. Speakeasy DSL costs more, but they have highly technically skilled customer support people, an expectation that their customers run servers, and a rock-solid network. I highly recommend them.

Your packets will still likely go through an AT&T network and thus still be inspected.

Because AT&T is so large this will affect a good chunk of the Internet - especially US networks.

Hell their backbone runs the entire length of the us.

This map is from 2000 so it's probably much more invasive now:

http://www.cybergeography.org/atlas/att_backbone_large.gif

-sigh.. Why Man-In-The-Middle is easily stopped

[KWTm]

This was written, and then modded "insightful" by somebody who does not understand how encryption.

Agree. I've previously written a post about this, but it would be useful to review the relevant portions.

In a nutshell, a "man-in-the-middle" attack is no more to be feared than a "dictionary" attack on a password: the attack only works if the security is implemented poorly. In the same way that you wouldn't say, "They use a password? How useless --simply do a dictionary attack!", you would not say, "Encryption? Just do a man-in-the-middle attack!"

I know that ssh takes steps to store the public keys and warn you if they've changed. Why would it bother doing that if man-in-the-middle attacks aren't possible?

For the same reason that they warn you when you change your password: "Your password is too short!" or "Your password is dictionary-guessable!" etc. Why would it bother doing that if dictionary attacks aren't possible?

You said:

My understanding is as follows:

Party A contacts Party B and sends it's public key. Party E (evil guy) intercepts this public key and replaces it with his own. Party B replies with his public key, which is also intercepted and replaced. Party A and B are now "encrypting" the traffic with the public key provided by Party E, whom decrypts it, and re-encrypts it with the original public keys provided by A and B prior to forwarding that traffic on to them. Party E now has access to the complete conversation between A and B whom are none the wiser, unless they have an outside method of verifying the keys they received.

I fail to see how an exchange of a random number stops this, when Party A never actually received Party B's key to begin with, because said key was replaced by Party E.

This is a common question about public key encryption. I'm going to quote my own post:

People worried about man-in-the-middle note that the phone company owns the channel, and thus can intercept everything! But that's not enough for a man-in-the-middle attack (MitM attack, where attacker K intervenes in the conversation between A and B; K tells A that K is really B, and K tells B that K is really A, and relays the conversation). The key to breaking MitM is to recognize the additional condition for such an attack: the attacker must completely replace the messages from the sender with his own messages. Otherwise, either:

        * the attacker is only eavesdropping, but won't be able to get any info once sender and receiver start using encryption, or
        * sender and receiver realize that there is someone intercepting, and switch encryption or move to a different channel

Thus, sender and receiver must prevent a MitM attacker from completely replacing all the messages. The way to do this is to exchange messages through more than one channel, at least in the beginning.

With the usual PKE such as GPG over email, for example, the sender doesn't just send public keys to you and say, "Here's my public key; now let's talk." [...] And, no, the way to make it more secure is NOT to send more data, like "Here's my public key and my photo. Now do you believe that it's my real key?" That would just be sending more data over the same channel. You need another channel.

Hope that clarifies things for anyone who's still confused about WHY public key encryption works. The GP poster is correct.