Slashdot Log In
The Pirate Bay's Plans To Encrypt the 'Net
Posted by
timothy
on Fri Jul 11, 2008 05:50 AM
from the pretty-ned8bdrnki(bdr## dept.
from the pretty-ned8bdrnki(bdr## dept.
Keeper Of Keys writes "According to newteevee.com, The Pirate Bay, those fun- and freedom-loving Swedes, have embarked on a project to encrypt all internet traffic, probably by means of an OS-level wrapper around all network connections, which would fall back to an unencrypted connection when the other end is not similarly equipped. The move has been prompted by a recent change in Swedish law, allowing the authorities to snoop on network traffic. This will be a boon to filesharers and anyone else concerned about authorities and trade groups' recent moves towards 'policing' network traffic at the ISP level."
Related Stories
[+]
Your Rights Online: SSL Encryption Coming To The Pirate Bay 267 comments
An anonymous reader writes "The Pirate Bay, in response to Sweden's new wiretapping law, will start offering SSL encryption to its user base this week. Although copyright issues really have little to do with national security, The Pirate Bay knows its population is uneasy with the recent legal change. The encryption will mostly benefit Swedish users living under the current law. Since The Pirate Bay and its servers are not hosted in Sweden, the additional security offered to outside users could be comparatively minimal."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
But all decent pirating services... (Score:5, Insightful)
Re: (Score:3, Interesting)
NewTeeVee alumn Jackson West pointed out back in March that long-planned projects like The Video Bay, the music site PlayBle and a new and secure P2P protocol have yet to be launched
Admittedly "secure internet" would be more useful to file sharers than "secure P2P" (better plausible deniability); but if they've failed to even do the latter so far, I wouldn't hold out too much hope...
answer two (Score:4, Insightful)
Not to forget some people would probably argue that your general privacy and freedom to talk to others with no one listening is more important than file sharing.
Some other people would probably not since those are the people which hopes to catch some bad guys using techniques such as this one and don't care about the breach of their own privacy since they have nothing to hide them self and trust everyone to be good.
Parent
Re:But all decent pirating services... (Score:5, Insightful)
Yeah, but then you can tell pretty closely what they are. Port number & encrypted protocol are pretty indicative.
Instead, encrypting the majority of traffic would make the sniffing capability moot.
But frankly, I'd rather see them use Tor [eff.org], maybe with some optimizations for latency-critical operations.
Parent
Re:But all decent pirating services... (Score:5, Interesting)
I don't know how this would work specifically (didn't bother to RTFA), but it seems to me that the current model of connecting to application ports is broken from a privacy perspective.
The solution is a hopefully cheaper version of setting up a vpn tunnel and using THAT to connect to the application port. That way all traffic appears to be going to the same port, regardless of service. Because it's encrypted, no DPI can be applied.
Of course, I could just go to that site's web site and see what they advertise, assuming that most people are going there for that purpose. If I'm sniffing the user's connection at their ISP, I could also see if they're connecting to 10-20 other user sites simultaneously, which would look a lot like bittorrent.
The advantage to using end-to-end encryption by default would be plausible deniability. If the site carries both legal and illegal content, then it would be difficult to prove that the user was downloading one or the other by simply inspecting their traffic patterns. Because encryption is used by default, the argument of "Why encrypt if you have nothing to hide" goes out the window.
I hope this made sense. I'm still waiting for the coffee to perk. :-)
Parent
Re:But all decent pirating services... (Score:5, Interesting)
The FreeS/WAN guys were working on transparent IPSec negotiation for just this reason. It prevents many types of traffic analysis, spoofing, packet injection, etc just as you want.
They've given up because nobody cared :S
Parent
Re:But all decent pirating services... (Score:5, Informative)
most BT servers run their web server on port 80, and they always encourage users to change the default BT port to something else. As long as you offer legitimate torrents, and run https encrypted to prevent people from seeing what torrents you download, then all you know is they are running BT on a torrent on the server. If you are using encrypted BT, they can't see what it is you're downloading when you start up the torrent. Beyond knowing they're running BT, (which is still legal, for now) there's nothing more you have on them.
Parent
Re:But all decent pirating services... (Score:4, Insightful)
Parent
Re: (Score:3, Insightful)
Re:But all decent pirating services... (Score:5, Interesting)
TOR is not robust enough to handle P2P traffic. PLUS IT DOES NOT HIDE THE DATA YOU ARE TRANSFERRING. This plan by TPB is designed to encrypt the traffic. A separate TOR-like plan would be required to anonymize source/destination IP's. Or a third option that does both.
TOR was designed to help people remain anonymous and communicate safely on the web. Misusing it for illegal purposes will cause TOR to become unavailable for its original purpose, which will be sad.
Parent
Re: (Score:3, Interesting)
Re:But all decent pirating services... (Score:5, Insightful)
Tor and encryption serve orthogonal purposes. Encryption hides what you're sending, tor hides who you're sending it to.
Parent
TOR != encryption (Score:5, Insightful)
Please don't blindly use TOR for P2P. You'll bring TOR to its knees. TOR is supported by volunteers and isn't designed for the massive load P2P would put on it. Plus, TOR only provides anonymity at the destination, and it only hides your IP. TOR does not provide encryption. Snooping at your ISP would still show all packets in the clear.
Parent
Re:TOR != encryption (Score:5, Informative)
But you're right, Tor is an anonymizing network, it's not end-to-end encryption.
Parent
Why encrypt? (Score:5, Interesting)
Why encrypt pirate traffic?
AFAIK, they "get you" by joining the network as a peer and then writing down all the IPs that send them pieces of the torrent.
I don't think they do it by monitoring network traffic--that would be a pain in the butt.
It's not hard to gain access to many of these networks, and their real goal is just to slow piracy (stopping it is a little far out). All they really need to do to slow it is start suing users and the rest will run scared, like they did with Kazaa et al. Real pirates will go underground, for sure, but they wont have as much of an impact on sales as say, Napster.
Parent
What... wait... IPsec, is that you? (Score:5, Insightful)
Sounds like a poor man's implementation of IPsec to me...
oh wait, without the standardisation of course.
IPSec + no MTU/NAT issues + zeroconf (Score:5, Informative)
Not really, from their site [tfr.org]
The goal of transparency to the transport layer means that the user will not have to configure anything, just install the encryption software and go. It also makes sure that encrypted traffic will travel over IP carriers without trouble (except in the case of mandatory transparent proxying). Current IP-transport encryption using tunneling or IPSec do not have the same property. Many low-cost ISPs filter IP protocols and TCP/UDP ports to block encypted traffic and there is always a cost to the user in configuring key-exchange, NAT-traversal and such. Anonymity can be provided by existing IP-anonymizing networks such as tor and i2p since the encryption is transport-independent.
So they are planning to roll out zeroconf IPSec that doesn't NEED to have specific support for NAT traversal. Now, "NAT Traversal" technically just means UDP encapsulation (which in turn results in all fancy MTU problems).
It seems that they are only interested in encrypting the TCP/UDP payload, with key negotiation happening at the start of the session (SYN/ACK packets for TCP, and as a completely separate negotiation with UDP).
If they can go with this, I sure hope they write an informative RFC..
Parent
Re:What... wait... IPsec, is that you? (Score:4, Informative)
There is little to no config hassle if you use IPSec with opportunistic encryption. IPSec tunnels through UDP if there is NAT on the way, so that isn't a problem either. The trouble with IPSec is that it only does opportunistic encryption with DNSSec for key management, and that is not deployed. The PirateBay's solution to key management however is not to use any, so their solution only helps against passive eavesdropping. I'm not impressed.
Parent
Re:What... wait... IPsec, is that you? (Score:5, Informative)
I'm wondering how much overlap there will be compared to Better-than-nothing-security [ietf.org].
Parent
Re:What... wait... IPsec, is that you? (Score:4, Insightful)
Parent is spot on.
IPSEC *may* be very well engineered but few of us would want to touch it even with a 10ft pole. Especially those of us who *had* to work with it in the past.
It should be possible to implement IPSEC without the warts. Hell, IPSEC could be zero-configuration out of the box (linklevel encryption only) with only minimal configuration for peer certificates.
Good Crypto doesn't have to be painful, see OpenSSH, OpenVPN (commonly chosen instead of IPSEC), GnuPG.
I just don't see what this has to do with P2P at all? Solution looking for a problem?
When the ISPs can't sniff our traffic anymore they'll just connect to the trackers and look at the offerings.
But then I again I never understood the legal fuzz about P2P in first place.
To me the key is plausible deniability. Store your shared content on an encrypted drive and that's it.
Parent
Re:What... wait... IPsec, is that you? (Score:4, Insightful)
I concur.
Having to set up some corporate VPNs in the past, I cannot even fathom why anyone in their right mind would choose IPsec over, say, OpenVPN, other then being forced into it by some idiot vendor or a moron manager. The difference in complexity, amount of work on the part of the network designer and sysadmins is just astronomically different between the two solutions.
From first-hand experience I can only confirm that IPsec is for masochists. Anyone I know who ever tried to deploy the thing does only so once.
Also note that more convoluted and difficult to control a security solution is, more chances of security vulnerabilities, both from the perspective of possible errors in design and implementation of such complex schemes, but also (more likely in practice) from the perspective of faulty deployment by people who do not have time to parse word by word 300 page deployment manuals bristling with obscure acronyms and arcane cryptography concepts.
Parent
Pirating or not (Score:5, Insightful)
I can't see a downside from a user perspective, and the only Govt/ISP/etc justifications not to do this are an invasion of privacy (packet headers could be used for QoS, etc). It's like, I dunno, posting all your mail in an sealed envelope instead of on a postcard - you can still put an economy or airmail sticker on it, it just means the postman can't (easily) read your message anymore.
Re:Pirating or not (Score:5, Interesting)
Makes you wonder what the internet would look like if you had real privacy actually. Hope you like /b/
Parent
Re:Pirating or not (Score:4, Insightful)
Parent
you think you can defeat govt that easy? (Score:4, Insightful)
reply:
"pirate bay has become a haven for child pronographers. shut it down"
Man in the Middle (Score:5, Informative)
Without preshared keys, this is vulnerable to a man in the middle attack. Your ISP or the government's spies or whoever simply intercept your communications with the other peer at the time of hand shaking and key exchange, and hands their own encryption information to both parties. Decrypt each message, and encrypt it for the other party before sending it down the line.
This protects against casual snooping, but it completely fails to account for the level of involvement that domestic spying already suffers from.
Re: (Score:3, Insightful)
Re:Man in the Middle (Score:5, Insightful)
The purpose of this thing is to enable regular home users to avoid the dragnet filtering that the swedes are implementing. Forging replies for every tcp/udp connection crossing the swedish border would make that filtering a lot more expensive.
Parent
Re:Man in the Middle (Score:5, Informative)
But what this does do is tilt the balance of power against the eavesdropper. It prevents passive eavesdropping attacks - for example it prevents anyone recording all traffic and then after-the-fact deciding what they want to decode.
Anyone wanting to decode your traffic is forced to be an active adversary, and this makes them detectable, which means they won't do it all the time because there'd be a huge outcry. No more mining all the traffic that passes on internet backbone links - you could tell when the first ISP put an eavesdropping box into their network, and switch to another ISP, which would strongly discourage anyone from doing this in the first place.
It's much more expensive to be an active man in the middle for all traffic - the best bet would be to downgrade traffic by pretending the other end didn't support the option. Even this isn't cheap. To leave the traffic encrypted and intercept it all would require a ridiculous number of public key accelerators cards.
In the end, it doesn't stop anyone eavesdropping if they suspect one particular person, but it does make such interception detectable if you know what you're doing, and it does stop them eavesdropping all traffic in the hope of hearing something incriminating.
Parent
Re: (Score:3, Informative)
You nailed it.
Pre-shared keys, root certificates and and PGP-like key signing aren't likely to scale to truly ubiquitous encryption.
Any system that wants to provide ubiquitous encryption that isn't susceptible to man-in-the-middle attacks needs to either implement chain of trust or to overcome the problem in some completely different manner.
In order to ubiquitous encryption to really fly, we need similar break through in authentication as public-key encryption was in cryptography.
Like you said, this would s
Re:Man in the Middle (Score:5, Informative)
The main problem is in step 1.
- Person 1 takes person 2's public key and encrypts their transfer encryption/decryption key with it
the big problem with public key cryptography is that you get a public key from person 2, how do you know this public key is actually from person 2 and not from person 3 trying to listen to the conversation? If there's a person listening in the middle they can intercept the traffic on both ends and replace each other person's public key with their own. That way they can pretend to be person 1 to person 2, and pretend to be person 2 to person 1.
It makes it more difficult, but it's still not impossible, to snoop on that traffic.
It's the delivery of the public key from person 2 and person 1 that is the biggest problem with public key cryptography, and a problem which certificates and Certificate Authorities have mitigated (to an extent). But for the greater Internet, it's a more difficult proposition to give everyone certificates.
Parent
Watt?! (Score:3, Insightful)
If several million people all started encrypting all of their traffic, there's gonna be a whole lot more CPU usage and therefore more power consumption going on. ThePirateBay, think of the penguins!
(Come to think of it, the consumption increase might be offset by firefox 3 raping CPUs less than firefox 2 used too :)
Re: (Score:3, Funny)
might be offset by firefox 3 raping CPUs less than firefox 2 used too
My CPU is brand new so would that be statutory rape?
Re: (Score:3, Interesting)
That sounds good but its just not true. I run on encrypted root and home and there is no noticeable performance difference, even in big file copies. Network encryption is very very little work for the cpu.
Re:Watt?! (Score:5, Funny)
Pirates prevent global warming. Heretic.
Parent
Obligatory (Score:4, Funny)
Va Fbivrg Ehffvn, lbh rapelcg gur Cvengr Onl
Not just about pirating (Score:5, Interesting)
The sad thing is I don't even have anything to hide. But I detest the idea that someone, somewhere, might be monitoring what I'm doing. I use an anonymous email service with PGP encryption, I do all my browsing over a VPN connection to a (cheap) VPS server in another country. For added protection I can then tunnel using SSH to another server in another country which then uses tor to make my final connection.
Security is cheap (the whole setup probably sets me back around $50/mo including my 8mbit dsl line), but it just requires the time, persistence and knowledge to set it up in the first place. If an end-to-end solution can be built-in to the OS AND we can be certain as can be there are no back doors, then this can only be a good thing.
For those who in the meantime who want to protect themselves but are not too sure where to begin, get yourself a cheap VPS (hundreds of providers out there), set up OpenVPN and off you go. You can even use SSH to tunnel a SOCKS connection for an easier option. I would suggest OpenVPN as a starting point though, as it makes it easier to expand later, e.g. tunneling an SSH connection to another server through the VPN, which can then connect to tor running on localhost on the second machine. Should your connection be intercepted at the ISP level (the most likely?) then they'll have a double-encrypted tunnel to deal with, and then probably an ssl-encrypted https stream inside that as well if you're careful about where you surf.
Anonymous Coward for obvious reasons
Re:Not just about pirating (Score:5, Funny)
Hi Jeff. I've been archiving copies of that porn site you started with your girlfriend. Cool security setup you've got though. Glad its working out. Tor exit node campers ftw!
Parent
Re: (Score:3, Funny)
For over 2 years I have been encrypting my internet connection using a roll-my-own solution. I trust my ISP implicitly - they are one of the few good guys left in the ISP arena. I don't trust my government.
China or something? Oh, no, wait, you must be from the US!
The sad thing is I don't even have anything to hide. But I detest the idea that someone, somewhere, might be monitoring what I'm doing. I use an anonymous email service with PGP encryption, I do all my browsing over a VPN connection to a (cheap) VPS server in another country. For added protection I can then tunnel using SSH to another server in another country which then uses tor to make my final connection.
Do you fully trust your VPS provider? A VPS is even easier to be snooped onto than a good-ol' iron server in some datacenter, imho.
SSL (Score:3, Interesting)
Surely what they're proposing is basically SSL, everywhere, if a handshake shows that they support it?
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Its needed (Score:4, Insightful)
IPv6 and IPsec (Score:4, Informative)
This is yet another problem solved with IPv6, for which IPsec support is mandatory. RFC 4025 provides a method for opportunistic encryption between hosts using keys stored in DNS (type "IPSECKEY").
The implementation is simple:- when initiating a connection, look up the IPsec key of the destination using the IPSECKEY record of the destination address in the reverse dns zone (ip6.arpa).
I think Sweden's law is actually a good thing. The more governments and/or companies that are snooping on internet traffic, the more encouragement it provides for people to use encryption.
Re:SSL over Tor with Pivroxy (Score:5, Insightful)
Parent
Re:SSL over Tor with Pivroxy (Score:5, Interesting)
Won't work like that, I'm affraid.
When Finland started "Filtering the internet to protect the children" and among other sites filtered a website that criticized quality of the work that police was doing with the internet censoring it got difficult for me to get to that site by using TOR. Why? Because with so many tor servers in Finland it often took several extra reloads to get a server outside the borders of the censorship.
The last thing I want to do now is add more anonymous and uncontrolled hops, which could be to servers in countries that watch the traffic too closely or even ran by such governments. Every hop is an extra chance to MitM attack. Unless I first aquire the Public Key directly in which case anyone monitoring already knows what site I'll access to and makes TOR needless.
Or is there something I have missed?
Parent
Re:SSL over Tor with Pivroxy (Score:5, Interesting)
Not to be a dick, just sayin'.
Parent
Re:IPSEC? (Score:4, Insightful)
How many users do you know that (a) even knows what dns is (b) controls the dns name for their ip (c) is able to configure said dns to include their public key?
OE works fine for geeks, but is too heavy if the goal is to get average home users encrypted.
Parent
Crypto Barbie: "IPSEC IS HARD" (Score:5, Insightful)
You're complaining about shortcomings in implementation. That's a general problem with crypto... crypto geeks don't care about iser interfaces. RSA goes back to 1977, and we still don't have good PGP/GPG support in most email clients. The solution is not to invent a new protocol, it's to invent a new user interface that's compellingly easy. SSL is a pain in the neck... except when you're using it in a web browser it's almost invisible, and SSH bootstraps from it to make something that's much easier to set up than SSL telnet.
Yes, Crypto Barbie, if TPB doesn't at least make it possible to use IPSEC as the encryption layer (whether they have a workaround for ISPs that block IPSEC or not) they're not part of the solution.
Parent
Re:ISPs react (Score:5, Insightful)
Isn't that the point? If all your traffic is encrypted, how is the ISP supposed to tell what is what?
Parent