Slashdot Mirror


Encrypted Torrents Growing Fast In the UK

angryphase writes "The British Phonographic Institute (the UK's RIAA) has noticed a significant increase in the amount of encrypted torrents — from 4% of torrent traffic a year ago to 40% today. Whether it follows a trend for hiding suspicious activities or an increased awareness of personal privacy is up for (weak) debate. Either way, this change of attitude is catching the eye of ISPs, music industry officials, and enforcement agencies. Matt Phillips, spokesman for the UK record industry trade association explains, 'Our internet investigations team, internet service providers and the police are well aware of encryption technology: it's been around for a long time and is commonplace in other areas of internet crime. It should come as no surprise that if people think they can hide illegal activity they will attempt to.'"

4 of 432 comments (clear)

  1. Re:Could someone clarify... by fictionpuss · · Score: 5, Informative

    Torrent encryption was developed primarily to avoid traffic-shaping. E.g. a good percentage of those legitimately downloading Fedora 8 today via torrent will probably use encryption just to ensure a quicker download.

  2. Re:Could someone clarify... by DaleGlass · · Score: 5, Informative

    It's not for that.

    Encryption prevents traffic analysis, which means that a router can't easily detect that something is a BitTorrent connection and throttle it.

    Really this seems to be a case of "the more you tighten your grip, the more will slip through your fingers". The excessive amount of filtering first made sure that about everything learned to talk over port 80. Now they'll add encryption over that, so that ultimately a large percentage of traffic will be completely opaque and going through port 80, making it pretty much impossible to filter.

    There might be a consequence for the RIAA though: It means that no traffic analysis will tell you what somebody is downloading. Sure you can see which computers and tracker are involved, but you don't know what's the file being transferred. So no way to tell anything by listening to traffic at strategic points, now you need to maintain a connection with a tracker for every file you want to monitor.

    As an user this doesn't seem like such a bad thing, but as a sysadmin it has the potential of becoming quite annoying. Read on what it takes to stop Skype from working for a preview of what might become universal eventually.

  3. Re:Won't Work by PhilipPeake · · Score: 4, Informative

    You misunderstand how HTTPS works.

    When I connect to a https site, during the handshake the remote site gives me a copy of its certificate. I (my browser) do two things with that certificate: I validate that the domain name embedded in the certificate matches the name of the website I was asking to connect to, and I verify the signature on the certificate using the public key of the signing authority.

    Unless the ISP has private key of the signer, there is no way that they could possibly generate a false certificate on the fly - so I *know* I am talking to the server I wanted to connect to, not to an intermediate proxy server.

    once that handshake is complete, I and the remote site have a private encryption key which we both use to encrypt/decrypt traffic between us. The ISP can't do anything with that traffic but pass it through (or block it).

    The *only* way that an ISP could get in the middle would be for them to block ports 80 and 443 and insist that you configure your browser to use *their* proxy server. If you ever come across an ISP that does this, don't walk, run, to another ISP.

  4. Re:Won't Work by Skapare · · Score: 4, Informative

    You understand how HTTPS works, but not how a proxy works for HTTPS.

    When your browser connects to a proxy for an HTTPS method, it makes a CONNECT request. The proxy makes a TCP connection to the IP address and port requested and passes the traffic both ways unchanged and uncached. The browser then performs the usual certificate validation on the contents received from the remote web site.

    An ISP could force the use of a proxy. An ISP could disable HTTPS through their proxy. An ISP could slow down HTTPS through their proxy. An ISP could monitor your traffic volume through their proxy (or their routers). An ISP could record every encrypted bit going both ways. An ISP could also corrupt the encrypted traffic bits. But an ISP cannot interpret the bits in your encrypted traffic, nor modify them, in any meaningful way, without cracking the encryption.

    --
    now we need to go OSS in diesel cars