The Pirate Bay's Plans To Encrypt the 'Net 297
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."
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...
Re: (Score:2)
On the other hand there haven't been much reason to care since no one have been allowed to snoop at your traffic or get your contact information from your isp earlier.
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.
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.
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. :-)
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
Server sharing or multiple servers (Score:3, Insightful)
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.
But that workaround doesn't account for :
- Hosting service that host several web sites on a single server, thus all sharing the same IP but answering to different DNS names in the HTTP request. It happens a lot, almost any of the cheap hosting service works that way.
=> You'll get multiple connections anyway, and there's no single website to check for advertised content.
- Although there *are* bittorrent trackers written in PHP, there are a lot of people using a simple web server for the website and indexi
Re: (Score:3, Interesting)
That way all traffic appears to be going to the same port, regardless of service. Because it's encrypted, no DPI can be applied.
Maybe not but your local friendly government of choice could legislate something like the RIP Act and demand keys to the traffic on that one port.
A sensible solution would be to promote the spread of IPv6 which I gather has scope for IPSEC built into the specs.
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.
Re:But all decent pirating services... (Score:4, Insightful)
Re: (Score:3, Interesting)
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.
Re: (Score:3, Interesting)
Re: (Score:2, Interesting)
Honestly, the best possible route is not this hack upon TCP or UDP (did you read the part about how it opens and closes connections while doing the handshake?), but rather an opt-in private network like anonet [anonet.org].
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.
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.
Re:TOR != encryption (Score:5, Informative)
But you're right, Tor is an anonymizing network, it's not end-to-end encryption.
Re: (Score:3, Insightful)
With the use of Hidden services [wikipedia.org], it is. If you connect to a Hidden service on Tor, the last hop in the Tor network is to the server your connecting to and it is end-to-end encrypted.
.torrent transfer would be good uses for this channel, but not the raw data. I'm surprised TPB doesn't have it already set up.
Tracker data and
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.
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
ISPs react (Score:2, Insightful)
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?
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.
Re: (Score:2)
and without all the config hassle...
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.
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].
Re: (Score:3, Interesting)
OpenSwan also supports doing encryption with peers based on certificates. Assuming we geeks agreed on a set of certificate authorities, we could have our opportunistic encryption.
See my thoughts [slashdot.org] from earlier.
Re: (Score:2, Insightful)
> and without all the config hassle...
If you're expecting end users to do anything, then anything more complicated than `pick a password` and then later `enter the password` is not going to work. Even then, you'll have to deal with people forgetting passwords.
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.
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.
Re: (Score:3, Informative)
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: (Score:3, Informative)
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 pas
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..
Re: (Score:2)
Solved problem! (Score:2, Interesting)
Better yet, they could find use for an existing proposal, complete with code: OTCP [google.com]. It transparently encrypts TCP sessions in a way that would defeat Comcast's (and China's) eavesdropping/RST forging; if they wanted to defeat OTCP, they'd have to intercept and rewrite all SYN packets, which is a lot more burdensome. It can't guarantee perfect security, but perfect security is mutually exclusive with providing full backwards compatibility with the existing Internet.
FAQ:
Q: Can't this be broken by man-in-the-m
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/
Re:Pirating or not (Score:4, Insightful)
/b/? (Score:2)
I not only knew what you were tallking about but passed over it and started reading the next comment without a stutter. A few seconds passed. Then I cringed and wondered "What have I become?"
Thanks a lot for shaking me to the core. Nice way to start the day. :-(
IPSEC? (Score:2, Informative)
Doesn't this problem already have a solution [openswan.org]?
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.
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.
Re: (Score:2)
I was only half-surprised that this wasn't already mentioned. But then, didn't they say something like they expected most internet traffic to be encrypted using their system by 1998 or something? Such epic failure, it's probably safe to ignore them.
you think you can defeat govt that easy? (Score:4, Insightful)
reply:
"pirate bay has become a haven for child pronographers. shut it down"
Re: (Score:2)
I wonder if the demonstrations against the Swedish government, which mostly have been peaceful except for DoS attacks against the government's web servers when the FRA law was approved, would continue to be peaceful if TPB was shut 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.
Re: (Score:2)
The only "defences" you could have against such MITM attacks would be either chains of trusted keys for every site that uses the system (a hefty burden and a central repository of trusted keys makes it the main target for attack, either DoS or infiltration) or: have sites supply their public key information via DNS or similar and have clients cache it, which is easily spoofed, but at least you'd know when something "changed". A bit like SSH's authorized_keys.
Re: (Score:2)
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.
Re: (Score:2)
I've got to admit cryptography isn't my greatest strength so I could well have misunderstood here but I thought you could handle it as follows-
You have a public key system to transfer the keys for the encryption system used for the main transfers, the public key can decrypt in such a way that only the private key can decrypt. So:
- Person 1 takes person 2's public key and encrypts their transfer encryption/decryption key with it
- Person 2 decrypts person 1's key encrypted with his public key using his privat
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.
Re: (Score:2)
Cheers for that ;) Makes sense now!
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: (Score:2)
A perception of security is generally far worse than no security at all.
It wouldn't be far fetched to imagine a bespoke MITM proxy that decrypts all connections and logs them to a backend.
Re: (Score:2)
I'm mostly concerned about keeping my traffic private from my ISP, so that is a real problem. But I'm not sure how else you can get the private key out to people. Maybe a separate server that generates one-time keys? So your ISP sees you're making a connection but can't find out what the key is because it's no longer available.
Re: (Score:2)
Why do you think your web browser includes root certificates?
Re: (Score:2)
HTTPS relies on root certificates to authenticate the remote peer.
Re: (Score:2)
Then how do you defend against the mitm substituting his own keys?
Great (Score:2, Informative)
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.
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: (Score:2)
I used Opera exclusively back in the 5.x days. Since then I find the interface less and less agreeable, sorry (and all the features I enjoyed are becoming more standard, and are all easily available via extensions)
Re:Watt?! (Score:5, Funny)
Pirates prevent global warming. Heretic.
Re: (Score:2)
True. They are reducing the number of plastic disks that need to be manufactured.
FF2? (Score:2)
Not totally following your point. Looking "like it was written in C" is.. a bad thing?
Re: (Score:2)
I think that he's insinuating that IE8 is such a POS that it makes FF2 look super fast and stuff.
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!
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.
Re: (Score:2)
A VPS is even easier to be snooped onto than a good-ol' iron server in some datacenter, imho.
where do you think the VPS is located? in a magic teapot?
Re: (Score:3, Interesting)
Yes.
Now let's suppose my customer rents the whole big iron as it is, they do whatever they want on it. They have root on it, I don't. Can I snoop on their network traffic? Yes I can, though it's not that trivial like with the VPS. Can I take a look at their files? I could, but not that easily. I guess t
Clean up your act first, encrypt later. (Score:2, Insightful)
i know it shouldn't be that way but...the world isn't as it should be. If someone wants to start encrypting anything and everything, including legitimate usages without heavily sensitive information (which is fine and dandy and helps privacy, so its all good and fine), don't start associating it with people who DO have something to hide.
TPB is doing a huge disservice now. The idiots up there will automatically be like "SEE SEE SEE ?!?!?! Encryption == Piracy, pirates download porn, porn == child porn, think
Re: (Score:2, Interesting)
I'll use the Larry Flynt defense here: by protecting pirates' (and for all it matters terrorists' and pedophiles') right to use crypto, you de facto protect yours.
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)
This already exists (Score:2)
This already exists; furthermore, it's been around for years. It's called Freenet: http://en.wikipedia.org/wiki/Freenet [wikipedia.org]
Here in Buenos Aires, Argentina I use a local version:
http://www.buenosaireslibre.org/ [buenosaireslibre.org]
What about Anonet? (Score:3, Interesting)
There's a project called Anonet [anonet.org] that has developed a similar wrapper infrastructure.
Anonet [anonet.org] is a "virtual Internet" that utilizes OpenVPN [openvpn.org] and Quagga [quagga.net] to provide a layer of anonymity and deniability on top of the Internet. It uses a chaotic yet cooperative routing scheme which allows any one to use any IP address while still maintaining their existing Internet connection.
It has everything on it that the Internet does: torrent trackers, web servers, FTP servers, DNS infrastructure, PGP keyservers, IM, IRC, streaming audio, game severs, etc. All Internet-aware applications should work fine as Anonet [anonet.org] is simply an addition to your operating system's routing table.
Re: (Score:3, Funny)
Anonet [anonet.org]...Anonet [anonet.org] ...Anonet [anonet.org]
Anonet [anonet.org]
;-)
Just in case someone missed the first three
Useless (Score:2)
Its needed (Score:4, Insightful)
What about GNUnet? (Score:2)
This projects has been worked on for years now. I never read their papers, so I can't comment on the technical side, but they surely designed it for decentralization and anonymity:
http://gnunet.org/ [gnunet.org]
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)
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?
Re: (Score:2, Informative)
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 applicatio
Re: (Score:2)
Assuming that the encryption cannot be broken [...] Or am I missing something?
Yes.
Re:SSL over Tor with Pivroxy (Score:5, Interesting)
Not to be a dick, just sayin'.
Re: (Score:2)
Did you read the parent post? Communication from the exit node to the end point remains unencrypted, and exit nodes can't be trusted. SSL between nodes doesn't help, you aren't magically connecting to an unencrypted service with SSL.
Re: (Score:2, Interesting)
It isn't SSL between nodes. It is SSL between you and your destination. SSL is an application layer protocol so it does not affect IP traffic (the message is encrypted, not the IP headers). If you are worried about the exit node you can access sites on the onion ring itself and bypass that problem. And if you want to access a site off of the onion ring, with SSL you are no worse than any other method. If the onion network grows as large as the P2P networks (which is a logical extension), then the govern
Re: (Score:2, Interesting)
More exit nodes in the Tor network controlled by the governments and malicious parties (directly or indirectly with hidden remote administration tools). And then all we, Tor users, are screwed. The last hop is unencrypted and usually contains some information which helps to identify the user.
Re: (Score:2)
Except that they never actually intended to buy the island and made it quite clear on the site that they didn't intend on doing it.
Re: (Score:3, Insightful)
believe it or not, some people don't think that taking other peoples work for free is cool. When you grow up and get a job, you will understand.