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

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.

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

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.