Slashdot Log In
SSL Encryption Coming To The Pirate Bay
Posted by
Soulskill
on Sun Jun 22, 2008 10:20 AM
from the privacy-arms-race dept.
from the privacy-arms-race dept.
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."
Related Stories
[+]
Politics: Wiretapping Law Sparks Rage In Sweden 344 comments
castrox writes "This Wednesday at 9am the Swedish Parliament is voting on a new wiretapping law which would enable the civil agency (FRA — Defense Radio Agency) to snoop on all traffic crossing the Swedish border. E-mail, fax, telephone, web, SMS, etc. 24/7 without any requirement to obtain a court order. Furthermore, by law, the sitting Government will be able to instruct the wiretapping agency on what to look for. It also nullifies anonymity for press tipsters and whistleblowers. Many agencies within Sweden have weighed in on this, with very hefty criticism, e.g. SÄPO (akin to FBI in the US), the Justice Department, ex-employees of FRA, and more. Nonetheless, the ruling party block is supposedly pressuring its members to vote 'yes' to this new proposed law with threats to unseat any dissidents. After massive activity on blogs by ordinary citizens, and street protests, the story has finally been picked up by major Swedish news sources. The result will likely be huge street protests on Wednesday. People have been completely surprised since this law has not gotten any media uptake until very late in the game."
[+]
Wiretapping Bill Passes Swedish Parliament, 143 to 138 326 comments
Assar Bruno Boveri writes "Swedish lawmakers came down in favour of a fiercely debated surveillance bill in a vote at the Riksdag on Wednesday evening. Despite some cosmetic changes, Sweden's proposed surveillance law is still a monster, writes Pär Ström from the independent New Welfare Foundation." The Swedish newspaper DN (in Swedish; translations welcome) compares the implications of the proposed law with activities carried out by East Germany's Ministerium für Staatssicherheit (STASI).
Submission: SSL Encrpytion Coming to The Pirate Bay by Anonymous Coward
[+]
Technology: The Pirate Bay's Plans To Encrypt the 'Net 297 comments
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."
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.
speed (Score:3, Interesting)
Re:speed (Score:4, Funny)
Better slow downloads than meeting your new Swedish boyfriend in jail.
Parent
Re:speed (Score:5, Funny)
Hmm... A Swedish jail boyfriend.
A List? Lets.
Pros:
Funny Accent? Check
Athletic? Check
Likes Wooden Shoes? Check
Digs Meatballs? Check
Cons:
Makes you scream in a funny accent? Check
Athletic (in all the wrong places)? Check
Likes pain and Abuse? Check
Digs _your_ Meatballs? Check
It's a hard call.
Parent
Re:speed (Score:5, Informative)
Parent
Re:speed (Score:5, Funny)
Parent
Re:speed (Score:5, Informative)
Parent
Re:speed (Score:4, Informative)
Parent
Re:speed (Score:4, Insightful)
Parent
Re:speed (Score:4, Interesting)
Parent
Re:speed (Score:5, Insightful)
I agree with your general point and agree that recent material that is still in print should be either paid for or ignored.
That being said, I torrent.
I use it for
1) Movies that I can't buy if I want to.
2) Comics that I grew up with and can't buy if I want to.
3) Anime that isn't for sale in the U.S. (This has lead to be buying anime when it does become available- like Stand Alone Complex)
And I do draw the line 28 years (the original terms before our governments sold out to disney and other companies and sold away the public domain to them). And I could get fined or go to jail for that activity. I keep that in mind, so I use peer guardian and other techniques to keep a low profile. But mainly, I stay away from new hot shit. Mostly, new hot movies you can buy for $5-$7.50 within 18 months of them coming out. Why risk prison/ fines to see a movie 18 months early? And more importantly, creators do deserve *some* compensation for creating.
Parent
Re:speed (Score:5, Insightful)
...creators do deserve *some* compensation for creating.
Which is EXACTLY the point. They're product isn't *worth* anything if it isn't scarce. With digital medium nothing is scarce making it worth whatever the public is willing to pay - simple economics. What pisses me off is that media companies are allowed to force artificial scarcity. I have no sympathy and don't believe hiding their greedy little faces behind corrupt bureaucrats should be tolerated by the general public.
Parent
Re:speed (Score:5, Insightful)
Wait, so I can now buy HD movies online and download them as fast as my connection allows legally? I thought I had to drop a wad of cash on a new disc drive then had to either go out and buy or wait for it to ship to get the movie, then I had no option to put it on my computer (legally). This is all news to me.
Parent
Re:speed (Score:4, Insightful)
Oh, I'll pay, when they offer me what I want to buy, not what they want me to buy.
I certainly don't want to pay for drm, which I can't play in Linux without having to circumvent their stupid restrictions.
Parent
Re:speed (Score:5, Informative)
The actual file transfers are peer-to-peer, so they won't be effected (also, they're usually encrypted already, to avoid bandwidth throttling). This is for accessing the website and/or for contacting the tracker.
Web pages have been using SSL for years without being especially slow.
Contacting a tracker is a lightweight request that is being performed once every 30 minutes or so - if it was a few seconds slower, nobody'd notice anyway.
Parent
Re: (Score:3, Insightful)
Possibly, but it's a trade-off. Do you want speed or do you want security? (Yes yes, I know, everyone wants their cake and wants to it too.)
Re:speed (Score:5, Funny)
(Yes yes, I know, everyone wants their cake and wants to it too.)
Its when you eat your cake and still want it you've got problems.
Parent
Re:speed (Score:5, Funny)
You know the worst part? I actually took the time to "proofread" my post before making it too :-P Stupid word-skipping brain.
Parent
Re:speed (Score:5, Funny)
Parent
Re: (Score:3, Funny)
Re:speed (Score:4, Funny)
And don't look at me for sympathy because everyone knows the cake is a lie.
Parent
Re:speed (Score:5, Informative)
Um, no, this change has nothing to do with torrent swarms, so downloading of the files referenced inside a torrent would be unaffected.
Parent
Re:speed (Score:4, Informative)
On the server side, presumably the bottleneck is the network connection or the storage medium access times, and not the CPU of the server. The network overhead to an SSL connection is minimal, to the point where it is negligible. The access times to the storage medium will not change to any measurable degree. The only way this will slow downloads considerably would be if the CPU was already at or close to 100% utilization, or if it is pushed "beyond 100%" utilization (i.e. the bottleneck becomes the CPU) due to the need to calculate SSL certificates, etc. Since The Pirate Bay is doing this in a planned and intentional way, they have almost certainly thought of this and will likely add processing power if need be on the server end.
From the client side, YMMV, but the above holds true in general. If you are downloading and doing CPU intensive things in parallel, then yes, things will slow down considerably.
Parent
Re: (Score:3, Insightful)
If only I had thought to address the network connection issue somewhere. I think if I could do it all over again I would have done it in the first sentence of the first paragraph of my post.
... and in this case we know the application. It is downloadin
Re:speed (Score:4, Informative)
Parent
Re:speed (Score:5, Informative)
There are really a lot of hardware solutions to speeding up SSL.
The real issue is that, typically speaking, the server which is responsible for the server-side processing is also responsible for encrypting the stream.
By putting a hardware or software solution in front of the client-access machine, you offload encryption to that host, leaving the application server free to concentrate on serving applications.
This can also be useful for debugging sessions, as you (the provider) have an unencrypted stream to examine.
Securing that stream between the application and the encryption device becomes of paramount importance, in that case.
Parent
A broader lesson (Score:5, Insightful)
While this particular instance doesn't concern me, it seems that, more and more, we're seeing reasons to start encrypting most data that we send across the Internet--certainly we would encrypt IMAP/POP3 sessions, Jabber and whatnot--why not HTTP as well?
Yes, there might be some performance drawbacks, but, on the whole, it seems to me like the less data we send in plaintext, the less we open ourselves up to identity theft, and being spied on by governments (not necessarily our own, mind you).
So I tend to think that this is just a manifestation of this broader trend towards encryption in all Internet transactions. I think the real question is whether we'll see people using SSL/TLS for things like checking the weather or sports scores.
Re:A broader lesson (Score:5, Interesting)
I think it will be an escalation though between the people who want to know what everyone is doing and those of us who want privacy. For example, if we encrypt everything - how long will it take these same wiretapping morons to pass more laws requiring that sites make the decryption key available for all "official agencies" or some such?
Parent
Re:A broader lesson (Score:4, Interesting)
Parent
Re:A broader lesson (Score:5, Insightful)
Parent
Re:A broader lesson (Score:5, Insightful)
Parent
Re:A broader lesson (Score:4, Informative)
The real problem is that people have to put in additional effort, because their e-mail program doesn't handle it seamlessly. Their e-mail doesn't handle it seamlessly because it isn't easy to do, because there is no one dominant standard, but there is one dominant e-mail client (Outlook) which is controlled by a monopolist who has no incentive to make things better for their customers (because they have a monopoly). This is one of the many hundreds of ways the computing industry is constantly being held back by MS's monopolies.
Parent
Re:A broader lesson (Score:4, Informative)
Parent
Re:A broader lesson (Score:5, Interesting)
I disagree, email clients have native support for S/MIME and signed PKI certificates. Conversely, most clients do not have native support for PGP, though you can get it through plug-ins (Thunderbird).
Certainly you can get a email signing cert from Verisign by paying for it (It's very inexpensive and integrates well with most email clients). You can also generate your own key pair and get it signed by Thawte (so long as you complete there "Web of Trust" requirements), if you are worried Verisign might keep a copy of your private key (they don't).
The problem with the whole system is that while only you need a PKI cert to sign an email (recipients client will auto verify it), but in order to encrypt an email your recipient must have a PKI cert and you must have there public key. That means both parties must care enough to encrypt email. This is where the envelope analogy breaks down, because to receive a sealed envelope in the mail I don't have to do anything.
Parent
Re:A broader lesson (Score:4, Informative)
I actually just set that up (literally -- I created my key immediately before typing this), and I think it could be easier. Namely, after installing EnigMail in Thunderbird, it didn't immediately work. Why was this? Because I needed to install GnuPG separately, which was not mentioned in the "how to install in Thunderbird" steps on EnigMail's Thunderbird addon page [mozilla.org]. Either it ought to be added to that list, or (better yet) GnuPG itself ought to be somehow included in the EnigMail installer itself.
Parent
Re:A broader lesson (Score:5, Insightful)
Yeah, it seems to me that it was an oversight that networking wasn't encrypted in the first place. When lots of these protocols were being developed, security didn't seem to be much of a consideration.
It's about time that these things got rectified, but I'm not sure what the best course is. For example, using SSL concerns me in that we've accepted the convention that certificates should be issued by certain set organizations that require exorbitant fees. I mean, hundreds or thousands of dollars per year for an SSL cert? Seems a bit much to me. Yeah, I know you can generate your own, which will cause you to get complaints from your websites' users when they see what looks to them like an error message.
I'm not a security expert, but I get the sense someone needs to go back to square one and figure out how to build a coherent, open, and secure model for networking that doesn't rely on giving such control to a small number of companies.
Parent
Re:A broader lesson (Score:5, Insightful)
If TCP/IP had been encrypted from the beginning, we'd be worse off, not better.
Why? Because any crypto available from that time is trivially crackable today. So instead of an obviously insecure communications medium, you'd have an insecure communications medium that everyone thinks is secure because, hey, it's encrypted! It wouldn't change anything except make people more complacent.
Parent
Re:A broader lesson (Score:5, Insightful)
You may be too young to remember this, but until 1997, it was for all practical purposes illegal to transmit cryptography software over the internet because of ITAR regulations [wikipedia.org].
As a result, during the formative years of the internet when networking protocols were being designed, there was no practical way to include security as a requirement. A cynic would interpret this state of affairs as being exactly the goal that the US government had in mind when they made cryptography illegal.
Parent
Re:A broader lesson (Score:4, Insightful)
... if USA was the whole world.
Parent
Re: (Score:3, Insightful)
Correct me if I'm wrong here, but as I understand it security was outside of the scope of networking technology when it was first created. ARPANET was created in order to facilitate information sharing, and it started out quite small. Encryption at that point would've been counterproductive. Security wasn't much of a consideration because the network was connected and used by trusted nodes, namely research
Re:A broader lesson (Score:5, Interesting)
... as I understand it security was outside of the scope of networking technology when it was first created. ARPANET was created in order to facilitate information sharing, and it started out quite small. Encryption at that point would've been counterproductive. ...
Well, yes and no. Note that the ARPAnet project was funded by the US Dept of Defense. There were security experts around from the beginning. But it was well understood back in the 1960s that building the security into the low-level networking code was a bad engineering design. Everyone involved pretty much understood that you got (data) security by end-to-end encryption, and doing encryption at any level below the user app was simply a waste of cpu cycles. So the network-level design goal was reliable transport on unreliable ("battlefield") hardware. The design meant that the people working on the network layer could concentrate without distraction on the job of getting the bits reproduced accurately at the other end.
The primary argument against low-level encryption has always been the same: The two endpoints have no reliable knowledge of or control over most of the data path. The history of encryption is full of stories about someone cracking someone else's encryption and reading their messages for a long time before they were found out. We must assume this can happen with any encryption scheme. This means that if a low-level link in the middle of a data path is decrypted (or even intercepted), the endpoints generally have no way of knowing it has happened, and also have no way of changing that link's encryption scheme. Low-level encnryption is thus only usable if you control every piece of hardware in the data path. This requirement would totally eliminate the wide-area networking that ARPA was trying to achieve. So if the ARPAnet was to meet its design goals, encryption of low-level data links was a pointless waste of cpu time.
End-to-end encryption at the application layer, however, is totally under the control of the endpoints. It can be changed at any time, for any reason. It eliminates dependence on the security of the low-level links that aren't controlled by the entpoints.
And there's a reasonable argument that end-to-end encryption increases security: It means that the data packets can be scattered across many different data paths, making it difficult for anyone to intercept all of the packets for a given conversation. Previous secure communication required tight control of the data path, and usually meant that there was a single data path for a given conversation. This is easy to intercept and either block or subvert, giving a copy of the conversation to an enemy. But if your packets are sprayed across all the available paths, interception and packet collection become nearly impossible.
This is, of course, a very loose, off-the-cuff summary. But it's easy enough to find the early ARPAnet docs in various Internet archives, where you can easily spent far too much time learning about the subject.
Parent
Re: (Score:3, Interesting)
I'm not a security expert, but I get the sense someone needs to go back to square one and figure out how to build a coherent, open, and secure model for networking that doesn't rely on giving such control to a small number of companies.
We could, but not without a huge increase in complexity. With a simple tree structure, it's pretty much a binary - either you're trusted or you're not, but it places all the control at the top. Without it, you need to manage who you trust, those that want to get trusted has to get many signatures that others trust them and everybody has to deal with all sorts of partial trust through unauthoritative peers. It's been tried with PGP email and the results are:
1) People want an oracle, not trust management
2) P
About time (Score:5, Insightful)
Lets hope this is just the beginning.
*everything* should be encrypted by default, and no unencrypted connections should be offered.
I don't care that i'm doing nothing wrong, its no ones business.
ya, there is a performance hit, but thats just part of the deal to have your communications remain private.
Re:About time (Score:5, Funny)
If you were to start using unlimited encrypted connections here within the UK, I guess the thought-police will immediately assume you to be a terrorist and bang you up for 42 days.
Parent
Circumventing the law (Score:3, Interesting)
Since they are publicly announcing they are using SSL to circumvent a law as its primary goal, can they be held personally liable?
Re:Circumventing the law (Score:5, Interesting)
The law says that the government has the right to listen, nowhere does it demand that everyone speaks loud enough to be heard. We still have every right to encrypt everything we want, and newspapers/tabloids here in Sweden have already been running articles like "5 ways to not get wiretapped" and guides on encryption techniques.
Parent
Copyright issues != terrorism (Score:5, Insightful)
" Although copyright issues really have little to do with national security... "
Try telling that to the US Gov't.
Re:Copyright issues != terrorism (Score:5, Funny)
" Although copyright issues really have little to do with national security... "
Try telling that to the US Gov't.
Parent
Did anyone expect anything else? (Score:3, Interesting)
Now duh. You spy on me, I counter with encryption. No, really? Who would have thought?
Now, let's assume for a moment that those laws are actually enacted to counter terrorism, as they allegedly are. Now, we see how companies and organisations act who are (allegedly) no target for those laws, and behold, they can very easily avoid being affected by the laws.
Question for 500: Are terrorists affected?
The gvmts legislating themselves out of options (Score:4, Insightful)
As more and more wiretapping laws and eavesdropping systems come on line, the more and more the technology movers will make it impossible.
Every last thing is going to be encrypted, IM, web, email, etc. The more of this crap they pull, the more they will be unable to do. If they break the encryption, we'll make it better.
Re:And all other x countries that does wiretapping (Score:5, Funny)
Version: GnuPG v1.4.7 (GNU/Linux)
hIwDupFG1SObtBMBBACAyUZAEDruQO9RlkZ5aGkGYRxv2oxqKdTgg0Glo1ZJk/nF
YS2HUhpzP7r3sVjTQ5h4RDRxUKOGllrFappta3kOfVU7KAS6HSrhmZ3IRU0VJvQP
LTusUO8cVjmon4YB44sMeUksLB/g7Ylm3LuF9abAd8yXH4lNn1OzgExAVtTbf8kf
IS4qtvlxiltgtqYqGw1N8JbFREuKrfyepkKshNxV3w==
=+MLj
-----END PGP MESSAGE-----
Parent