Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Privacy The Internet

ITU Approves Deep Packet Inspection 152

dsinc sends this quote from Techdirt about the International Telecommunications Union's ongoing conference in Dubai that will have an effect on the internet everywhere: "One of the concerns is that decisions taken there may make the Internet less a medium that can be used to enhance personal freedom than a tool for state surveillance and oppression. The new Y.2770 standard is entitled 'Requirements for deep packet inspection in Next Generation Networks', and seeks to define an international standard for deep packet inspection (DPI). As the Center for Democracy & Technology points out, it is thoroughgoing in its desire to specify technologies that can be used to spy on people. One of the big issues surrounding WCIT and the ITU has been the lack of transparency — or even understanding what real transparency might be. So it will comes as no surprise that the new DPI standard was negotiated behind closed doors, with no drafts being made available."
This discussion has been archived. No new comments can be posted.

ITU Approves Deep Packet Inspection

Comments Filter:
  • by Anonymous Coward on Tuesday December 04, 2012 @09:45PM (#42187333)

    You should do some research on what the ITU is. It is mostly old fogy bureaucrats from state owned telcos, and not elected politicians. Or even unelected ones. And the old fogy bureaucrats that sit on ITU committees are the worst of the bunch, as they specialize in creating standards and rules. So they do nothing but create rules and standards.

    The ITU is why it costs more to call one country than another, even though sending an email to Egypt or Portugal is the same price. Why do phone calls have different rates? It is 2012.

    The ITU voted in 2011, to confirm that FAX was the only authorized way to distribute committee documents! Email was determined to be not widespread enough (?), and less reliable. That should just you some idea of the mindset you are dealing with.

    And even with their so called "stewardship" of the public switched telephone network, it is still riddled with fraud and scams. In fact, there has been accusations that some of the ITU members benefit from these scams, and are creating a regulatory framework to allow them to continue.

  • by BitterOak ( 537666 ) on Tuesday December 04, 2012 @09:54PM (#42187413)

    End-to-end encryption. Problem solved.

    That's not quite the ultimate solution that many believe it to be. There are firewalls and routers on the market now that have man in the middle programming right in the hardware, and decryption is a basic part of the DPI system. How many people actually check that the certificates match who their supposed to, and how do we know which root authorities can be trusted? I imagine the vast majority of people don't even look at the certificate information. And how many ssh users actually check the key fingerprints and verify they match those stored on the remote host? Is that even possible in most circumstances? And if you do discover something's up, what then? If a router is doing man in the middle DPI, your choices are pretty much accept it, or don't communicate with the remote host at all. Most people just sigh and go on doing what they're doing.

    And that doesn't even take into account hacks on your computer, like browser attacks which quietly install new trusted certificate authorities, or more aggressive malware like keyloggers and such. Encryption is much harder to use properly than most people realize, and it is highly unlikely that people on BOTH ends of the connection are using it properly.

  • by Mashiki ( 184564 ) <mashiki@nosPaM.gmail.com> on Tuesday December 04, 2012 @10:41PM (#42187737) Homepage

    This is Canada's response on DPI from the privacy commissioner. [priv.gc.ca] For what it's worth, this won't fly here.

  • by smellotron ( 1039250 ) on Wednesday December 05, 2012 @12:30AM (#42188301)

    But if someone sets up BT on 80, how do you verify the protocol without looking at the payload? Even then, there are "tricks" where P2P protocols can use HTTP GET and PUT in the payload to be able to manipulate inspection.

    Ugh. I had to do some research on SOAP as a part of an internship at an "Enterprisey" software shop. Many SOAP software stacks advertised themselves as firewall-friendly because they would "punch through the firewall on port 80". That is, the SOAP service was encapsulated in HTTP, with the implication that this was superior to getting permission from your network admins. Of course, these same service providers also provided "SOAP firewalls" so they could profit off of your company's internal dysfunction. What a pile of garbage, all of it.

    Anyhow, I can see why BT would want to encapsulate itself in HTTP, but it stinks of an arms race.

  • by Roman Mamedov ( 793802 ) on Wednesday December 05, 2012 @03:01AM (#42189089) Homepage

    And how many ssh users actually check the key fingerprints and verify they match those stored on the remote host? Is that even possible in most circumstances?

    Hello, have you ever used ssh? As in, at all? It raises a holy hell if the keys have been tampered with.

    $ ssh hostname.tld
    @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
    The RSA host key for hostname.tld has changed,
    and the key for the corresponding IP address xxxxxxxxxxxxxxxxxx
    is unknown. This could either mean that
    DNS SPOOFING is happening or the IP address for the host
    and its host key have changed at the same time.
    @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
    IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
    Someone could be eavesdropping on you right now (man-in-the-middle attack)!
    It is also possible that a host key has just been changed.
    The fingerprint for the RSA key sent by the remote host is
    zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.
    Please contact your system administrator.
    Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
    Offending RSA key in /home/username/.ssh/known_hosts:76
    RSA host key for hostname.tld has changed and you have requested strict checking.
    Host key verification failed.

Remember, UNIX spelled backwards is XINU. -- Mt.

Working...