The Pirate Bay's Plans To Encrypt the 'Net

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."

Comments

IPSEC?

[Wonko the Sane]

Doesn't this problem already have a solution?

Man in the Middle

[nahdude812]

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:Man in the Middle

[Fzz]

Yes, anonymous public key exchange is vulnerable to a man-in-the-middle attack, unless you use something like the Interlock Protocol, which is probably a bit heavyweight to use for all connections.

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.

Re:Man in the Middle

[miro f]

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.

Re:Man in the Middle

[huge]

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 still provide protection against casual eavesdropper but not against ISP or government with resources to perform such an operation. Granted, it would still bury the illegitimate traffic to majority of the legitimate traffic and only way to distinguish these two from each other would be by performing MitM attack to all encrypted traffic.

Better than nothing? Definitely yes, but this still addresses only part of the problem.

Great

[uigin]

With a popular site like Pirate Bay behind it. This might actually catch on. If we all had to use an encrypted protocol to communicate with Google all internet traffic would quickly switch to that format.

IPSec + no MTU/NAT issues + zeroconf

[Zarhan]

Not really, from their site

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..

Re:SSL over Tor with Pivroxy

[aaaaaaargh!]

Assuming that the encryption cannot be broken, what difference does it make when the traffic goes over an additional node run by a malicious attacker? What matters is the first node and the exit node, all other traffic is encrypted and anonymized. AFAIK, the more hops, the better, except that traffic becomes slower. Or am I missing something?

There are other vulnerabilities to TOR's anonymity based on traffic analysis, and of course the most widespread problem is that users don't anonymize their applications or erroneously assume that the exit node is not malicious.

he 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.

Or is there something I have missed?

Re:What... wait... IPsec, is that you?

[Anonymous Coward]

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.

Re:But all decent pirating services...

[v1]

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.

Re:What... wait... IPsec, is that you?

[Zarhan]

I'm wondering how much overlap there will be compared to Better-than-nothing-security.

Re:SSL

[n3tcat]

What is being presented is supposed to operate on a totally different level of the OSI model than SSL does.

Re:SSL

[n3tcat]

I should also note that this is why people keep comparing it to IPSEC, as it also operates on the network level.

Re:TOR != encryption

[chihowa]

Tor provides anonymity at the source, too. Your first hop is encrypted from you to the Tor network. Your ISP only sees that you are using Tor, not to whom you are connecting. The last hop's ISP can see your traffic in the clear, though. If there's identifying (or secret) information it is vulnerable at the last hop.

But you're right, Tor is an anonymizing network, it's not end-to-end encryption.

Re:What... wait... IPsec, is that you?

[CharlieHedlin]

I setup a fixed VPN for about 40 networks using IPSec. It wasn't terribly painful, but I did go with a Hub and spoke configuration instead of a full mesh.

I use an IPSec with L2TP network at my office all the time. We have a proper CA and certificates issued to each of the mobile computers. took about 2 hours to setup.

Re:What... wait... IPsec, is that you?

[MikeBabcock]

I'm obviously a masochist. IPSec is easier to deploy than SMTP service, or a properly configured Apache+PHP server. IPSec is much easier to design than a good firewall, or a decent routing architecture, or DNS systems. Obviously you haven't worked enough with other major Internet protocols.

Last I checked, it takes me about 15 minutes, including the download time to configure a strong Openswan connection between two machines using IPSec. Download, open each machine in separate SSH sessions, copy and paste key IDs to the two config files, enter the IP addresses, save and restart IPSec. Done.

IPv6 and IPsec

[c_g_hills]

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:But all decent pirating services...

[zix619]

I believe they called it Opportunistic Encryption. And, actually it died because of the lack of interest from the users (see http://www.freeswan.org/ending_letter.html). But, perhaps now things begin to change with the users caring more about their privacy and a better knowledge of security techniques in general public. I believe IPETEE has the advantage of not relying on DNS fields to publish your key,

You're completely wrong. TOR provides encryption!

[Anonymous Coward]

TOR does not provide encryption. Snooping at your ISP would still show all packets in the clear.

TOR does provide encryption. The only way to see the unencrypted traffic would be to sniff the traffic as it leaves the tor exit node. Sniffing your tor traffic at the ISP wouldn't show anything but an encrypted data stream. Look it up:

http://www.torproject.org/overview.html.en

The number of posts that were modded up after stating that TOR doesn't provide encryption is absolutely mind boggling. Does anyone here even care how TOR works, or is just sounding like an authority good enough to get you a +5 Insightful no matter how off base your statements are? Christ. I'm disappointed in you slashdot mods.