×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

SSL Encryption Coming To The Pirate Bay

Soulskill posted more than 5 years ago | from the privacy-arms-race dept.

Privacy 267

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

267 comments

speed (3, Interesting)

youthoftoday (975074) | more than 5 years ago | (#23894537)

Won't that slow things down quite a lot?

Re:speed (4, Funny)

Anonymous Coward | more than 5 years ago | (#23894571)

Won't that slow things down quite a lot?

Better slow downloads than meeting your new Swedish boyfriend in jail.

Re:speed (5, Funny)

Anonymous Coward | more than 5 years ago | (#23894625)

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.

Re:speed (5, Informative)

just_a_monkey (1004343) | more than 5 years ago | (#23894899)

There are pros and cons to living in Sweden. This law is a big con. So are the taxes, and the regulations. A penal system which is not based on homosexual rape is a pro, though.

Re:speed (5, Funny)

igibo (726664) | more than 5 years ago | (#23894973)

A penal system which is not based on homosexual rape is a pro, though.
Speak for yourself.

Re:speed (2, Funny)

Anonymous Coward | more than 5 years ago | (#23895001)

There are pros and cons to living in Sweden. This law is a big con. So are the taxes, and the regulations. A penal system which is not based on homosexual rape is a pro, though.
Wouldn't that make it a penile system?

Re:speed (2, Interesting)

Anonymous Coward | more than 5 years ago | (#23895697)

The Swedish pen system is based on bean sacs and tv games with three months for rape and five years for tax fraud.

With such small times inside the rapers never get the time to build up enough lust.

Now let's hope FRA doesn't read this...

Re:speed (3, Insightful)

Haeleth (414428) | more than 5 years ago | (#23895341)

Better slow downloads than meeting your new Swedish boyfriend in jail.

Even better, how about paying for your movies, games, and music? That way you can download them as fast as you like, and the government won't try to put you in jail even if they spy on you doing it!

I realise this is Slashdot, where "not getting busted for copyright infringement" is apparently categorised as a "right", so I'm probably about to be modded into oblivion -- but hey, that's life, isn't it?

Re:speed (5, Insightful)

Maxo-Texas (864189) | more than 5 years ago | (#23895443)

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.

Re:speed (5, Insightful)

WeblionX (675030) | more than 5 years ago | (#23895481)

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.

Re:speed (4, Insightful)

Anonymous Coward | more than 5 years ago | (#23895549)

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.

Re:speed (5, Informative)

ozamosi (615254) | more than 5 years ago | (#23894633)

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.

Re:speed (2, Informative)

Anonymous Coward | more than 5 years ago | (#23894727)

... nor will they be affected.

Re:speed (2, Insightful)

SirLurksAlot (1169039) | more than 5 years ago | (#23894635)

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 (5, Funny)

duguk (589689) | more than 5 years ago | (#23894653)

(Yes yes, I know, everyone wants their cake and wants to it too.)

Of course I want my cake and want it too.

Its when you eat your cake and still want it you've got problems.

Re:speed (4, Funny)

SirLurksAlot (1169039) | more than 5 years ago | (#23894665)

You know the worst part? I actually took the time to "proofread" my post before making it too :-P Stupid word-skipping brain.

Re:speed (1)

maxume (22995) | more than 5 years ago | (#23894927)

I notice myself doing this more and more frequently. The hard part is deciding whether I am skipping words more often or noticing more often that I am skipping words. It and is are also frequently interchanged.

Re:speed (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#23894917)

(Yes yes, I know, everyone wants their cake and wants to it too.)

Of course I want my cake and want it too. Its when you eat your cake and still want it you've got problems.
The cake is a lie!

Re:speed (3, Funny)

JamesTRexx (675890) | more than 5 years ago | (#23894961)

Its when you eat your cake and still want it you've got problems.

And don't look at me for sympathy because everyone knows the cake is a lie.

Re:speed (4, Informative)

thermian (1267986) | more than 5 years ago | (#23894753)

Um, no, this change has nothing to do with torrent swarms, so downloading of the files referenced inside a torrent would be unaffected.

Re:speed (1)

alexandreracine (859693) | more than 5 years ago | (#23895593)

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.)
The cake is a lie!

Re:speed (3, Informative)

Zero__Kelvin (151819) | more than 5 years ago | (#23894645)

Most likely not, and it depends ...

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.

Re:speed (1)

RAMMS+EIN (578166) | more than 5 years ago | (#23894837)

It's not just about processor time, but also about network latency. Adding encryption is likely to introduce a couple more round trips, which can be very noticeable, depending on the latency-sensitivity of an application and the way things are implemented.

Re:speed (2, Insightful)

Zero__Kelvin (151819) | more than 5 years ago | (#23895037)

"Adding encryption is likely to introduce a couple more round trips"
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.

"Adding encryption is likely to introduce a couple more round trips, which can be very noticeable, depending on the latency-sensitivity of an application and the way things are implemented."
... and in this case we know the application. It is downloading large files. The two round trips you describe represent negligible overhead in this case. Again, if only I had mentioned that. If I could do it all over again, I would choose the second sentence of the first paragraph of my post :-)

Re:speed (4, Informative)

Anonymous Coward | more than 5 years ago | (#23894717)

Won't that slow things down quite a lot?
We're talking 20KB files here. The encryption will only affect the tracker search portal and the torrent file serving. I'd rather have an encrypted site that takes a couple of ms more to respond than something fast that spews out visible data left and right. All the data transfer is run by the peers and there encryption depends on the individual client settings (and many people already use full stream encryption w/o any slowdown). So "not really" would be an appropriate answer to your question.

Re:speed (4, Informative)

Bandman (86149) | more than 5 years ago | (#23894737)

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.

Re:speed (1, Redundant)

WhatAmIDoingHere (742870) | more than 5 years ago | (#23894771)

You're only download the actual .torrent file through the encrypted connection. All the downloading done with your client will go through your normal (unencrypted) connection. Unless you sign up for TPB's paid encrypted connection service.

Re:speed (0)

Anonymous Coward | more than 5 years ago | (#23895419)

Yep. You need all the bandwidth you can get for those huge torrent files.

A broader lesson (5, Insightful)

dfaulken (1312005) | more than 5 years ago | (#23894607)

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 (5, Interesting)

GIL_Dude (850471) | more than 5 years ago | (#23894641)

I agree with you here.
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?

Re:A broader lesson (3, Interesting)

NormalVisual (565491) | more than 5 years ago | (#23895231)

Quite a while, I'd hope - pretty much all of the court cases that I've read about that touched on the subject ended up treating it as a Fifth Amendment situation, with the end result being that you can't be forced to divulge the passphrases to your keys. I don't know whether any of those cases form precident though.

Re:A broader lesson (2, Interesting)

Anonymous Coward | more than 5 years ago | (#23895255)

Here in the UK you can already get locked up for failing to hand over encryption keys upon request.

I was wondering though... couldn't you setup a script on a linux server to regenerate keys on a regular basis? You can only hand over the latest set of keys then and I believe there is currently no law requiring you to archive/keep keys.

Re:A broader lesson (4, Insightful)

oodaloop (1229816) | more than 5 years ago | (#23894701)

It's about time. If you look at the postal system, people have been using security envelopes or at least sealed envelopes since pretty much the beginning. The only mail postal employees are allowed to read are postcards, since it's pretty hard to stop them. Unencrypted email is basically like a postcard, and it pains me to hear people complain that governments are reading them. Do they complain that postal employees are reading their postcards? If it's important or private, use a security envelope or encryption. Otherwise, don't complain when someone reads it.

Re:A broader lesson (5, Insightful)

dfaulken (1312005) | more than 5 years ago | (#23894741)

If you look at the postal system, people have been using security envelopes or at least sealed envelopes since pretty much the beginning.
This is exactly the problem, though--people are accustomed to using envelopes, whereas getting people to use e-mail encryption requires some serious additional effort, which most people aren't willing to put in.

Re:A broader lesson (3, Informative)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#23894967)

This is exactly the problem, though--people are accustomed to using envelopes, whereas getting people to use e-mail encryption requires some serious additional effort, which most people aren't willing to put in.

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.

Re:A broader lesson (3, Informative)

CastrTroy (595695) | more than 5 years ago | (#23895499)

As far as email encryption goes. PGP is pretty much the defacto standard. I'm sure there are some other methods, but PGP seems to be the way it's done in most cases. I wouldn't be hard for the mail client, outlook or otherwise to completely automate the system. Key exchange would be a little difficult, but not so much. You could either meet someone in person to exchange public keys, or get their public key from somebody else who already has it, who you already trust and share keys with.

Re:A broader lesson (5, Interesting)

devman (1163205) | more than 5 years ago | (#23895645)

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.

Re:A broader lesson (1)

CastrTroy (595695) | more than 5 years ago | (#23895887)

I think this is where the envelope analogy breaks down. Envelopes aren't secure in any way shape or form. Sending a letter is an envelope is like sending an email with the important data in an attached zip file. You can't see the contents of either the zipped email, or the letter in the envelope in proper processing methods. However, either is extremely easy to circumvent. Anybody who delivers the mail could easily open the letter, and read it, and pretend it got lost. Or just put it in a new envelope. If you were interested in the mail enough, it wouldn't be hard to create a fake envelope, so you could reseal the original letter, and deliver it. How many letters fail to reach their destination. Would you know if it was truly lost, or was it intercepted and opened by the government. There isn't really a way of knowing. I don't really know if there is a postal mail equivalent of sending an encrypted email. Unless you encrypt the letter itself. Which still presents you with the same set of problems as the encrypted email problem. Except that you have the added problem of actually decrypting the letter when you receive it. Something that can be automated with email.

Re:A broader lesson (1)

rubypossum (693765) | more than 5 years ago | (#23895849)

Ok, but, nobody has written an easy way to do this! Thunderbird (for example) has no easy, seamless and simple way to do this (and certainly no way that is built in.) Blaming Outlook is a cheap cop-out.

Most business email is a matter of public record anyway. MS has very little reason to push these features. Particularly when the hard-core users don't even care enough to write the features for OSS clients.

It really is kind of sad, since people are sending postcards to everyone and do not know they're doing it.

Re:A broader lesson (1)

Bandman (86149) | more than 5 years ago | (#23894783)

I really think the issue is that people expect a modicum of privacy from their government, and our governments are not really willing to accede to their requests

Re:A broader lesson (1)

oodaloop (1229816) | more than 5 years ago | (#23894877)

Right, a modicum of privacy in a medium that is as inherently open as sending a postcard. It seems private to regular users, but it's no more private than talking on a cell phone in public; anyone can listen in, from governments to individuals. If it's out in the open, expect people are listening. If you don't want them listening, use something more secure. Don't blame the government because they're reading your open emails or postcards.

Re:A broader lesson (1)

CastrTroy (595695) | more than 5 years ago | (#23895529)

Don't blame the government because they tap phones without a court order either. Normal phone calls are made in the clear. You just have to get on the actual wire carrying the call between the two recipients. Yet nobody thinks it's ok for the government to snoop on their phone calls. I don't see why the same shouldn't be true for email. Sure you should take responsibility and just encrypt your email. But that doesn't give the government the right to snoop in on your email.

Re:A broader lesson (1)

Kjella (173770) | more than 5 years ago | (#23895195)

If you look at the postal system, people have been using security envelopes or at least sealed envelopes since pretty much the beginning.
All I need for an envelope is an address - I'm not in any way guaranteed who'll open it. The mailman could just rip it open and read it if he wanted to as easily as the intended recipient. The thing that's annoying about encryption is that you have to exchange public keys, it's more iike sending a safe that needs a key than an envelope. Exchanging that key in a safe way is really very annoying, since it usually means using some out of band method. It's what you have to do as you can't tell read bits from unread bits, but it's not nearly as simple as using an envelope.

Re:A broader lesson (1)

Vectronic (1221470) | more than 5 years ago | (#23895669)

"All I need for an envelope is an address..."

And, the cost of the envelope, the time placing the letter inside the envelope and closing the envelope, paying for and putting the stamp on it, and the time it takes to write/print the address (and the return address)

Although the whole mail analogy works fairly well, comparing envelopes to encryption isn't, something like the Enigma Machine would be better, the envelope is simply the "packet" the data is contained in, there are certain things you can find out from it, like sender/receiver, time, and where its been so far, you can look into an envelope without taring it open, and you can look into a packet without destroying it, you can open an envelope attempt to read its contents, put it in a new envelope, and the chances are no one would notice unless it was a special envelope, and same with a packet.

However, if its encrypted, it doesn't matter if its looked at or opened for snail mail, or packets, the information either still gets transmitted (albeit with a delay if an attempt was made), or gets confiscated (data has to be re-sent), either way the data is safe, just delayed.

And yes I know the Enigma machine was eventually "hacked" but, SSL can be "hacked" aswell given enough time.

"...but it's not nearly as simple as using an envelope."

And considering an envelope secure, is about the same as saying "I switched to port 5678, therefore its secure", or "from UDP to TCP"... or in mail, "I used a different mail carrier/truck"... or "I changed to overnight delivery instead of 3 day"...

Meh, I just woke up...

Re:A broader lesson (0)

Anonymous Coward | more than 5 years ago | (#23895385)

If you look at the postal system, people have been using security envelopes or at least sealed envelopes since pretty much the beginning.

This brings up something I was thinking about. Does anyone know whether the US or Sweden allow the post office to read (whether it is through opening or some other technologies) envelopes that are going across the border? I know they have technology to see whether there are certain chemicals in packages, but can they legally do something as far as just reading the text within an envelope? In some cases this is comparable to what type of communications they are trying to monitor online.

Re:A broader lesson (1, Informative)

Anonymous Coward | more than 5 years ago | (#23895915)

Generally speaking no. Not the post office employees. Customs on the other hand, have the right to open parcels though - if they have reason to suspect it contains some sort of contraband, or something you should pay duty on.

Re:A broader lesson (0)

Anonymous Coward | more than 5 years ago | (#23895825)

You're technically right, but if you're referring to our (yes, I live someplace in Sweden) freshly minted law regarded the Defense Radio Establishment (FRA) and their involvement with civilian communications, you're missing quite a few points. Points that are very important.

1. The law is useless to solve the problem it's marketed as the solution to.
2. The way this law was pushed through the system.
3. This is using military power against your own civilian population.
4. It's against our constitution.
5. It's probably a breach against international treaties.
6. The arguments used in favor of it are not only obvious bullshit, but embarrassingly obvious bullshit.
7. It's not only about email, but also phone conversations, sms and heap of other things.

And maybe most important of all

8. It totally does away with the pretense that you're considered innocent until proven guilty, otherwise considered one of the pillars of the free society, this way EVERYONE is a suspect and is subjected to the equivalent of a warrantless digital house search on arbitrary grounds.

I guess the final point is the one most relevant to your post, but as you can see your comparison with some random postman opening and reading your mail with doing the same in a systematic way on a massive scale sactioned by the state is completely off base.

Re:A broader lesson (5, Insightful)

nine-times (778537) | more than 5 years ago | (#23894793)

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.

Re:A broader lesson (4, Insightful)

Free the Cowards (1280296) | more than 5 years ago | (#23894981)

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.

Re:A broader lesson (5, Insightful)

David Jao (2759) | more than 5 years ago | (#23895023)

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.

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.

Re:A broader lesson (2, Insightful)

SirLurksAlot (1169039) | more than 5 years ago | (#23895115)

Yeah, it seems to me that it was an oversight that networking wasn't encrypted in the first place.

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 centers and universities.

Re:A broader lesson (5, Interesting)

jc42 (318812) | more than 5 years ago | (#23895407)

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

Re:A broader lesson (2, Interesting)

Kjella (173770) | more than 5 years ago | (#23895119)

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) People don't understand how it works
3) People think it's too much work

People ask "is this the real owner of thepiratebay.org" and want an oracle to say YES/NO. If I was to suggest a better way, you should get a SSL certificate free with the domain name, signed through the DNS hierarchy. Site root signs the TLDs, the TLDs sign domains ans the domains sign the subdomains. So slashdot would get a certificate from .org, and could sign their own for yro.slashdot.org. It wouldn't been any certificate of who the fuck that is, only that you're talking to the right host and not some funny man-in-the-middle.

Re:A broader lesson (1)

tsotha (720379) | more than 5 years ago | (#23895249)

In addition to what others have posted, I'd like to point out nontrivial encryption/decryption takes a fair amount of computing horsepower. For a modern processor it's an afterthought, but if they had included encryption in ARPANET the project would have died in the lab for lack of system owners willing to connect.

Re:A broader lesson (1)

nine-times (778537) | more than 5 years ago | (#23895509)

That doesn't seem like a very good reason to me. What I mean is, that's a good reason why you wouldn't have everything encrypted at the outset, but that's not a good reason not to build out the protocols/infrastructure with the option of security/encryption in mind. Because even in cases where encryption is computationally too expensive for every transaction, you might still want to offer the option of encryption for for cases where encryption is worth the expense.

I guess it just seems a bit like the Y2K bug-- sure, it probably made sense at the time, but in hindsight it wasn't the best decision. Even now, secure protocols can seem like a bit of an add-on hack instead of an integrated part of the system. FTP is a pretty good example, IMO. FTP is awful security-wise, and FTP with TLS/SSL can be a bit of a PITA. SFTP looks to be a good solution, but ends up having its own headaches. You generally either have to give people remote shell access or go through extra steps to disable the normal shell and jail the user. I guess OpenSSH is now trying to address the issue, but it's still not particularly straight-forward, IMO. Also, SSH keys have none of the benefits that SSL certs have, e.g. identity verification or the ability to transparently revoke keys and issue new ones.

Re:A broader lesson (1)

devman (1163205) | more than 5 years ago | (#23895687)

Unfortunately you need some kind of certifying authority to verify keys in a key-exchange between third-parties who know nothing about each other. As you said you can always generate your own SSL cert and sign it yourself, but it will be an untrusted signature, and rightfully so.

Re:A broader lesson (1)

Znork (31774) | more than 5 years ago | (#23894851)

and being spied on by governments (not necessarily our own, mind you)

These types of laws typically have provisions against 'domestic spying'. As does the swedish law.

The traditional way to get around that is to simply listen on foreign traffic, then exchange that info with foreign intelligence services (A method which the swedish law explicitly allows).

whether we'll see people using SSL/TLS

Perhaps.

If you really want to make things hard for the listeners, start putting encrypted input from /dev/random as a .sig to every mail you send. They'll never to be able to either decrypt it or verify it contains no real encrypted info...

Then if you ever wanted to send anything you actually mind having listeners to you can just stick it there; either your mail will already have gotten whitelisted to avoid clogging their filters, or it'll get stuck in a queue so deep the sun will have gone out before they can decrypt it.

Re:A broader lesson (1)

Digital End (1305341) | more than 5 years ago | (#23895043)

and being spied on by governments (not necessarily our own, mind you)


Because it's okay to be spied on by your own government.

Forshadowing of the next generation...

Re:A broader lesson (1)

HeroreV (869368) | more than 5 years ago | (#23895139)

why not HTTP as well?
With the current way things are done, that would require millions of costly security certificates, to ensure that the public keys you're getting are really from the people you think they're from. We're talking about enormous amounts of money.

About time (5, Insightful)

nurb432 (527695) | more than 5 years ago | (#23894681)

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 (5, Funny)

You ain't seen me! (1237346) | more than 5 years ago | (#23895133)

*everything* should be encrypted by default, and no unencrypted connections should be offered.

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.

Re:About time (1)

Rhabarber (1020311) | more than 5 years ago | (#23895293)

Lets hope this is just the beginning.

*everything* should be encrypted by default,



YES and YES, I second that.

I always hated that https://slashdot.org just forwards to http://slashdot.org./ [slashdot.org.]

I think it would be defenitely enough if my boss/sysadmin knew WHERE I'm surfing most time of the day.
Why do they need to be able to read every single comment directly off the wire as it passes by?

Ah, and don't tell me to use TOR. I tried it. Reading sucks because it is THAT slow.
And posting doesn't work (you probably blacklist exit node IPs to get rid of spammers, don't you, /. ?).

Re:About time (3, Informative)

Anonymous Coward | more than 5 years ago | (#23895361)

I always hated that https://slashdot.org/ [slashdot.org] just forwards to http://slashdot.org./ [slashdot.org.]

If you're a subscriber it works (though it's been a few years since I've been one, so I might be talking out of my arse with regards to the current setup, here).

A firefox plugin? (2, Insightful)

anilg (961244) | more than 5 years ago | (#23895777)

I've been thinking about this. Gmail provides a https interface, but i've seen people just type in gmail.com and be done with it (the session then uses http)

So my idea of a firefox plugin would be one that automatically tries for a 'https' version of any site (or lookup a list for it) and move to that if it exists.

Circumventing the law (2, Interesting)

nurb432 (527695) | more than 5 years ago | (#23894725)

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 (5, Interesting)

endemoniada (744727) | more than 5 years ago | (#23894761)

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.

Re:Circumventing the law (1)

devman (1163205) | more than 5 years ago | (#23895705)

I would mod you up, but you are already at max. This is true on so many levels. Governments have been spying on us for years, and laws or lack thereof are not going to stop that. There is no reason to think that any actions you perform on the internet will be private unless you make them so. The internet is a very public place. Until there are laws preventing us from protecting our privacy, there isn't much of a problem. The burden is on you the USER to protect yourself, you shouldn't be trusting other "not to look".

Re:Circumventing the law (1)

thermian (1267986) | more than 5 years ago | (#23894779)

No. If they were, then any shopping, banking or other website that used encryption to protect its customers would be too.

Re:Circumventing the law (1)

nurb432 (527695) | more than 5 years ago | (#23894857)

The stated intent is different. The bank doesn't say ' we are doing this to circumvent the law'..

Personally i don't have a problem with with what they are doing, but if i ran around "im going to do xyz to circumvent a law" i bet i get arrested.

Re:Circumventing the law (0)

Anonymous Coward | more than 5 years ago | (#23894937)

They are not actually circumventing the law though, because the law has nothing to do with copyright.

The people doing the surveillance is the Swedish equivalent of the NSA, and they can't hand over info to the police if it's not a matter of national security.

Re:Circumventing the law (1)

fluch (126140) | more than 5 years ago | (#23895009)

Which law is the Piratebay trying to circumvent? The people in Sweeden which are running the Piratebay are not breaking Sweedish law as far as I know. And enabling SSL is also not against any law there as far as I know.

Re:Circumventing the law (0)

Anonymous Coward | more than 5 years ago | (#23894795)

No, because the law in question has nothing to do with what the pirate bay is doing.

The law concerns Signal intelligence with regards to the safety of the nation. I.E there must be a significant threat of terrorism or military action before the agency (FRA) can legally pass the information on.

(The reason people are upset about it has more to do with the risk of leaks and abuse of the sigint system.)

minimal security? (0)

Anonymous Coward | more than 5 years ago | (#23894829)

Can someone please explain why SSL would offer minimal security? Won't this twart the RIAA and MPAA if the client is in the US? Why not?

Re:minimal security? (1)

laederkeps (976361) | more than 5 years ago | (#23894895)

The SSL encryption would presumably only be between you and the Pirate Bay web server\tracker. This would prevent the RIAA from seeing what you download from them (20kB .torrent files, tracker data while seeding\leeching), but the actual files you swap via the bittorrent protocol are not further secured by this.
There are encyption options for that too, but what the Pirate Bay folks are announcing here does not affect how you communicate with other peers (Which, presumably, is what the *AAs are busting you for)

Re:minimal security? (0)

Anonymous Coward | more than 5 years ago | (#23895087)

This would prevent the RIAA from seeing what you download from them (20kB .torrent files, tracker data while seeding\leeching)
You imply that the RIAA is currently able to eavesdrop on communications between you and The Pirate Bay. The RIAA isn't an ISP or a government, so I call BS and you're full of shit. Explain how the RIAA can currently eavesdrop on the data you download from TPB.

Re:minimal security? (1)

laederkeps (976361) | more than 5 years ago | (#23895517)

The question was not concerning what the *AA can or cannot do, but rather how the SSL encryption put in place by the Pirate Bay folks would constitute a "minimal" security increase for users not in sweden.
My post was intended to explain just how this added SSL encryption would help you, the scurvy sea dog, protect yourself against eavesdropping agents of different sorts, and more importantly how it would not.
If you read it again a few times before mouthing off, you'll see that I never said the *AA is looking at your HTTP data, but rather that they (hopefully) base their litigations and such on what you share with your peers in the swarm (the allegedly illegal stuff).
It would, however, not be a far cry to assume that the US government in one way or another (Say, NSA?) is looking at what you do, and as far as I understand, they get payed to look for pirates as well (Who buys your laws?) as "terrorists" and the like. SSL encryption of TPB web servers would mean that they can see whom you are talking to (The Pirate Bay) but not what you are talking about.

Re:minimal security? (0)

Anonymous Coward | more than 5 years ago | (#23895769)

Explain how the RIAA can currently eavesdrop on the data you download from TPB.
Because they collude with the fascist american government intelligence agencies, which colludes with the swedish fra sellouts?

That may or may not be actually happening (certainly at least the americans are not above such things though - remember echelon and airbus/boeing? Probably not, since it wasn't reported in the USA, but basically the americans abused their "anti-terrorism" spy network to make sure american companies got aerospace contracts, and the europeans found out and were Not Happy), but one has to assume it's a strong possibility.

Re:minimal security? (1)

Entropius (188861) | more than 5 years ago | (#23894915)

Because this lot can still connect to the tracker and read off the IP addresses of other people in the swarm.

Copyright issues != terrorism (4, Insightful)

frdmfghtr (603968) | more than 5 years ago | (#23894853)

" Although copyright issues really have little to do with national security... "

Try telling that to the US Gov't.

Re:Copyright issues != terrorism (5, Funny)

Eudial (590661) | more than 5 years ago | (#23894897)

" Although copyright issues really have little to do with national security... "

Try telling that to the US Gov't.

You're getting the lawmaker newspeak confused. Smoking pot is terrorism, piracy is the same as child pornography and paedophilia.

Re:Copyright issues != terrorism (2, Funny)

mini me (132455) | more than 5 years ago | (#23895363)

Do you think terrorists plot their next attack in silence? No, they listen to their favourite Metallica songs downloaded from a P2P networking program. Ergo, copyright infringement = terrorism.

Did anyone expect anything else? (2, Interesting)

Opportunist (166417) | more than 5 years ago | (#23894901)

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?

Re:Did anyone expect anything else? (1)

Digital End (1305341) | more than 5 years ago | (#23895223)

Well lets see... if I was a terrorist I would *gasp* encrypt my data?

But wait, I'm sure that any decent criminal organization would do that... so... wait who's the law supposed to effect? It would only really help with people who DON'T encrypt their data.

Wonder what the largest group of people who send non-encrypted data are.

Re:Did anyone expect anything else? (1)

soilheart (1081051) | more than 5 years ago | (#23895307)

But some encryption can be broken.

Especially if you have the the eleventh fastest computer in the world [top500.org] (and yes, I've heard that just that computer was bought for reasons like this new law)

Re:Did anyone expect anything else? (2, Informative)

Opportunist (166417) | more than 5 years ago | (#23895445)

Just increase the key size. The time encrypting/decrypting takes increases minimally, the time to break it multiplies.

It's trivial to increase the key size enough to render any computer pitted against it useless.

Re:Did anyone expect anything else? (1)

uffe_nordholm (1187961) | more than 5 years ago | (#23895735)

Precisely. Encryption/cracking is just another arms race.

Although the algorith is known to my enemies, my secret is safe as long as they don't have the key with which it is encrypted. They can get a computer to try all possible combinations though (called brute force attack).

My defence against this is to increase the key length so much that all th computers in the wolrd working together would take longer than the age of the universe to test all possible keys.

If 'the enemy' can brute-force an encryption key that is (say) 1024 bits long, I can increase the key length by any number of bits. Each aditional bit will double the length of time needed to test every single possible combination. Adding 10 bits would multiply the time by one thousand, twenty bits would make the time needed one million times longer. Another thousand bits and 'the enemy' can forget about it: the universe is not going to exist long enough for them to crack my encrypted message with brute force atacks, no matter how many computers they use.

Please note that the above only applies to cracking my encrypted message with brute force. I f 'the enemy' is willing to do it they might get a better resutl grabbing me and putting a gun to my head. Or they might try some other method at cracking the encryption.

Re:Did anyone expect anything else? (1)

Opportunist (166417) | more than 5 years ago | (#23895973)

Trying the gunpoint approach could be interesting when everything's done in a computer program that keeps changing the key used (using the encrypted connection to exchange new keys) without even telling you what keys it uses.

You may be able to make people talk, but if they don't know what to say, you're still where you started.

this is an outrage! (0)

Anonymous Coward | more than 5 years ago | (#23895109)

well if sweden wants to intercept the connections it can still do man in the middle attacks on connections going out of sweden as they ought to control the gateways... instead of fighting aftermaths citizens should go out on the street and let their voices be heard, the only way to achieve freedom this is....

This week? (1)

soilheart (1081051) | more than 5 years ago | (#23895325)

Why would they implement it this week? The new law in Sweden doesn't apply until jan 2009...
Suddenly thinking of everyone else who want encryption to TPB around the world?

And all other x countries that does wiretapping? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#23895589)

Sweden is probably one of the last countries in western world to introduce such a wiretapping law. Other countries are probably not as public about it though.

Think USA, UK, Australia and New Zealand which all members of the Echelon "community" of surveillance. France, Germany, Norway and others also have similar massive internet wiretapping in place.

Regardless where you live, you'll probably want SSL for whatever you do. How many actually uses PGP for their e-mails?

Re:And all other x countries that does wiretapping (4, Funny)

ettlz (639203) | more than 5 years ago | (#23895695)

How many actually uses PGP for their e-mails?
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.7 (GNU/Linux)

hIwDupFG1SObtBMBBACAyUZAEDruQO9RlkZ5aGkGYRxv2oxqKdTgg0Glo1ZJk/nF
YS2HUhpzP7r3sVjTQ5h4RDRxUKOGllrFappta3kOfVU7KAS6HSrhmZ3IRU0VJvQP
LTusUO8cVjmon4YB44sMeUksLB/g7Ylm3LuF9abAd8yXH4lNn1OzgExAVtTbf8kf
IS4qtvlxiltgtqYqGw1N8JbFREuKrfyepkKshNxV3w==
=+MLj
-----END PGP MESSAGE-----

drivel (0)

Anonymous Coward | more than 5 years ago | (#23895907)

That's a good news.
I hate some jerk likes to sniff in LAN.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...