Bugging Catches Up To SIP Phones

SkiifGeek writes "After news at the end of last year that mobile phones could be remotely eavesdropped, and there being a long history of remote eavesdropping possible on normal telephones, it was only a matter of time until VoIP devices were found to be eavesdropable (whether intentionally or not). In the last week there have been several exploit code releases, and it seems that some vendors who chose to write their own SIP networking stacks are at risk of their devices being easily eavesdropped on."

Comments

Why no security as standard?

[DamienMcKenna]

So why isn't there security implemented as standard? Come on, there are lots of perfectly good standards: SSL, TSL, SSH, etc.

Damien

Re:Why no security as standard?

[temojen]

Because SSL doesn't work for UDP and IPSec is hard to set up.

Re:Why no security as standard?

[grasshoppa]

Because SSL doesn't work for UDP

Excuse me?

Re:Why no security as standard?

[wolrahnaes]

There is.

Anyways, this has nothing to do with standards, this is all badly implemented software.

SIP uses Digest authentication by default and can be encrypted, RTP can be encrypted, the protocols are secure. Just because Cisco (and apparently Grandstream) don't seem to be able to implement them right (though amusingly enough I just tested both of the Cisco 79x0 exploits against a few 7940s in my office running the 7.4 firmware and they weren't affected, so it's a newly introduced bug).

Re:Why no security as standard?

[jddj]

Howsabout Phil Zimmerman's zfone?

<grammarnazi>

note to editors: A sentence is a lousy thing to hang a preposition on the end of

</grammarnazi>

Re:Why no security as standard?

[jd]

IPSec, using opportunistic encryption, is trivial to set up. You set "opportunistic encryption" to enable. That's it. Alternatively, use Sun's SKIP protocol. Enskip for Linux has been out for a while and there are probably other implementations for it. I wonder if SSL and VPN would work over DCCP - that gives you the reliability whilst remaining UDP-like. So, overall, I don't see this as a particular issue. If people want encryption, they could have encryption. The problem is, people act as if they want to be bugged. Possibly so they have something to complain about. That's why the English mess up England so much. They needn't, they are extremely intelligent, but if they didn't have trains that wouldn't run on the "wrong type of snow" or when there are "leaves on the line", they'd run out of things to say.

Re:Why no security as standard?

[Spy der Mann]

Here's a thought that has been "bugging" me (lol) for a while.

If the US had allowed encryption to be freely used on the net (PGP, https, etc), all of us would be using https to read our e-mail, post on forums, etc.

And encryption would be taken for granted. If a company neglected to use encryption in phones, it would come to the news and this would be called "The bug-gate".

But thanks to homeland security (and US trading laws), people have been slowly forced into using insecure channels for everything.
Isn't this ironic?

Re:Why no security as standard?

[profplump]

You're excused. But SSL still doesn't work for UDP, at least not in any way that's useful for things like SIP.

You can transmit UDP traffic through an SSL-wrapped tunnel, and you can transmit the SSL data using UDP packets, but since SSL is a stream chiper the other end still has to reassemble the enitre stream, in order before it can decrypt anything. And that in-order, no-lost-packets thing is the whole reason you decided against TCP in the first place -- you didn't want to stop the call for 0.5 seconds or more every time you dropped a single packet.

And I'm not sure that OpenVPN uses SSL for UDP traffic anyway. The front page says "OpenVPN's security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP." Which reads to me like SSL is used to setup the tunnel, but that the tunnel itself uses IPSec.

Re:Why no security as standard?

[blhack]

What the hell are you talking about? Those of us that want to use encryption do. Reading things like slashdot in encrypted form is overkill (and undue overhead for the servers).

Was this an extreme failure attempt at funny that a bunch of confused ./ mods thought was insightful or what?

Re:Why no security as standard?

[Anonymous Coward]

But thanks to homeland security (and US trading laws), people have been slowly forced into using insecure channels for everything. Isn't this ironic?

Not in the least. One might argue that national security is benefited because of this situation, and that the situation is engineered in this way. The nation doesn't care about the individual, much like the body doesn't care about a single cell.

Re:Why no security as standard?

[kestasjk]

If people want encryption, they could have encryption. The problem is, people act as if they want to be bugged. Possibly so they have something to complain about. But --

Wh--

**blinking and mouth dropping**

Re:Why no security as standard?

[willb]

It is Orwellian doublespeak. Orwell did not get the year right, but the direction is correct. At the current rate it will be around 2024 rather than 1984. I wonder what name Big Brother will have...

Re:Why no security as standard?

[Beryllium Sphere(tm)]

That would be good, but it would only help against the threat of someone eavesdropping on your phone calls. The article was about something scarier, namely turning your phone into a room bug transmitting audio to the attacker while the phone looks like it's not in use.

Re:Why no security as standard?

[mpeg4codec]

SSL isn't any sort of cypher, it is a suite of crypto tools. The things people most often use it for are public key encryption [usually with RSA] and symmetric encryption. For the latter, an implementation may provide any number of block cyphers operating in various modes that effectively make them stream cyphers. For what it's worth, the only widely used strictly stream cypher is RC4 and I don't hear about it being used much outside of WEP/WPA (although SSL implementations do typically include it for completeness and backward compatibility).

Unless it's changed drastically recently, OpenVPN uses SSL to encrypt each UDP packet. It uses one of SSL's block cyphers in a streaming manner and treats each packet as a distinct stream. That way, it can be decrypted independently of other packets and injected into the tun/tap device on the remote end.

SRTP works in a similar manner, although you are correct in that it doesn't use SSL. Since UDP packets are meant to be semi-independent, both OpenVPN and SRTP have certain issues to handle, such as anti-replay measures and such, but both protocols define ways of handling this and are both quite secure in practise.

Re:Why no security as standard?

[Anonymous Coward]

Yea, weres my SRTP!?

HTTP digest was a laughable attempt for securing web sites and well with VoIP its even funnier. Am I the only person in the world who is just tired of the answer to everything being CHAP discuised in different clothing?

What everyone needs to do is adapot stanfords SRP
http://srp.stanford.edu/

SRP provides mutual authentication without enabling easedroppers to perform offline dictionary attack. It also provides keying required to enable session encryption (SRTP..whatever) No PKI or super long passwords. What more can we ask for?

I don't know why people don't adapot it. Its PDC possibly the coolest authentication protocol ever. Sometimes I think NSA conspiracy but then I think laziness and the perception of unsolved/unknown IP/patent issues with SRP like implementations.

The least we can do is implement it ourselves and then at least make some $$$ off some three letter agency paying us to take it off the market? :)

Re:Why no security as standard?

[Anonymous Coward]

The central issue with encryption is 'trust' .. Without trust relationships all encryption regardless of how cool it may be is *USELESS* IE subject to trivial MITM.

The problem with trust is that its very hard and very expensive to do correctly on a large scale. This is why secure sites pay hundreds of dollars a year for their SSL certs which everyone **trusts** is spent to verify the sanity of those the certs are being issued to rather than going into new Yachts and Fusion powered golf carts.

PGP signing parties might be fun but they are not realistic on a large scale. Using the SSH approach of ... do something stupid once and you'll be safe from then on is stupid, sorry guys :)

PKI on a large/global scale represents an aggregation of eggs in one gigantic basket that we should all be afraid of. There are currently secret rooms within buildings that don't exists complete with armed guards and reinforced vaults that makes most banks look like a locked desk draw. These vaults contain a single computer that is always kept off until needed.

Re:Why no security as standard?

[screeble]

Public? Forum? Did you get that, Joe?

No we wouldn't. Encryption would needlessly create overhead for menial tasks such as reading e-mail and posting on forums.

Media-level encryption on posts going to a public forum is pointless. Security should only be invoked when absolutely needed.

Re:Why no security as standard?

[Akatosh]

> Why no security as standard?

CALEA compliance.

Re:Why no security as standard?

[profplump]

You're right, SSL isn't a chiper. It's a set of chipers and related algorithms inteaded to provide secure data streams. If we're going to be picky SSL is not a set of tools either. OpenSSL is a set of tools; SSL itself defines what those tools are expected to do.

As for stream vs. block, you're right SSL supports block chipers. And they're even commonly used in things like HTTPS. But they all use CBC (Cipher Block Chaining). So while technically not stream chipers, they have the same limitation I was noting, one that makes them inappopriate for SIP -- you still need to get the entire stream in order to decrpyt them.

And other people agree with my understanding of OpenVPN, and the explaination on their front page -- SSL for auth, ESP for the data stream:
Note that OpenVPN doesn't transport its data stream over SSL. They use IPSec ESP over UDP for that, the same as standard IPSec NAT-T does. They just use SSL over UDP for session authentication and management--in other words, as an IKE replacement, as far as I can tell. In that respect, there's really not much to differentiate it from IPSec NAT-T.
http://ask.slashdot.org/comments.pl?sid=197811&cid =16209755

Re:Why no security as standard?

[huckamania]

People have not been forced into using insecure channels for everything, unless you consider a land-line as secure.

Go rent Lethal Weapon and look at the phone that Murtock was using when he calls the shrink. The things as big as an ammo can. Do you think that thing had any encryption?

Your post wasn't ironic, it was just stupid.

Re:Why no security as standard?

[ajs318]

The problem is, people act as if they want to be bugged.

Mod parent up.

People also act as if they want mobile phones to be dangerous. Every time a study says they are harmless, they immediately call for more research to try and find some way they might be harmful.

Re:Why no security as standard?

[mpeg4codec]

I suppose my understanding of OpenVPN must only be applicable to an older version in that case. I'll read into the source a bit more on that, but I do stand corrected.

The whole idea of needing to get the entire stream to decrypt it is absolutely correct. However, it depends on what you define as the ``whole stream''. In the case of SRTP, they define each UDP packet as an entire, distinct stream. In fact, SRTP does not define usage with any stream cypher. The only cypher it allows in the spec is AES [a block cypher] operating in special modes similar to CBC [output feedback or some strange variation on counter] with each packet representing a single stream.

Re:Why no security as standard?

[Bearhouse]

OK, I'll bite. As a Brit, I'm tempted to respond with an equally facile quip about the crumbling public infrastructure in the USA. Collapsing bridges spring to mind. Mind you, I choose to live in France, where the trains are excellent, so...

Returning on topic, I'm not sure that the 'caveat emptor' analogy can be stretched so far. To what extent can we expect people to be tech-savvy enough to know that their device is 'insecure' by default, especially when the marketing hype is to make things 'easy to use'. It reminds me of the old windows 'ships insecure by default' debate. We all know who won that one.

So, is it 'people act as if they want to be bugged', or, 'people have a legal right to privacy, and existing vendors are not taking reasonable steps to ensure that such rights are protected'?

Re:Why no security as standard?

[Anonymous Coward]

"use encryption" means nothing to me, if I don't know how the keys are exchanged.

Re:Why no security as standard?

[jd]

Opportunistic encryption uses D-H exchange, I believe. IKE (Internet Key Exchange) is the section used for this. There's an IKE2 floating around - see Freshmeat for links - but I'm not sure how it compares. I've not dug into the IKAMP (Internet Key And Management Protocol) stuff in some time. But, yeah, the code is all there, as are the RFCs. If you want to know, you can.

Re:Why no security as standard?

[jd]

Oh, the US doesn't have an infrastructure, they just sprayed blacktop on the wagon trails and hoped nobody would notice. :) I'm also an expat, formerly of Stockport. Yes, a northerner. Not some Lancastrian or Yorkshire lad, but a true dyed-in-the-Goyt weirdo.

There is no "right to privacy" in the US, or even a "reasonable expectation of privacy". Indeed, under European law, no EU country should permit the export of personal data to the US due to the lack of sane privacy laws or even sane accuracy laws. Unlike the UK, where you can demand that inaccurate data be corrected and where you can sue people for retaining data without your authorization, the US has a proliferation of services where you can buy credit information, social security information or even entire identities but relatively little. Except in California, companies aren't even required to tell you when your personal data has been stolen or your bank account hacked.

Yes, I expect people to know their products are insecure by default, the same way they know an unlocked car is insecure by default. Yes, there is an obligation on developers to make products secure - if you can enable opportunistic encryption, so can the OEM - but users have obligations too.

I like the traditional UK view on trespass, for example. If you don't "break and enter" and cause no damage, you have almost totally unfettered access to open lands and lands of any kind that have a public footpath or bridleway through them. Back in the mid 1990s, there was a huge Traveler get-together in the north of England - a hundred thousand or so Travelers converged on a field for a festival that almost put Woodstock in the 1960s to shame. The police could do absolutely nothing, because no damage was being done and nobody broke into the field. The farmer could do nothing either. The home may well be an Englishman's castle, but that doesn't extend to fallow land.

(That particular incident led to a clause in the Criminal Justice Act, banning groups larger than four traveling with a common purpose. That clause was overturned in the House of Lords on the grounds that it unfairly restricted the freedom of the reincarnation of King Arthur and his knights. Yes, I am serious.)

The world the British live in, especially, is a world in which even ancient animal tracks that are under use but once in a single year cannot be obstructed, by law. Which is why there are so many bridges over motorways. Not all of them are roads, overhead pipes, or links between housing estates. Whether anyone likes it or not, computer networks won't ever be treated any differently. If you leave them as public rights of way, they will become public rights of way. If you don't want them to be public, then you can't go treating them as if they were.

Which gets back to my original point. If customers wanted secure devices, they could be adding the security themselves. They do so for their homes (most don't have alarms fitted as standard), they do so for their cars (steering wheel clamps are fairly popular add-ons), they do so for their bicycles (clamps and chains with combination locks proliferate). Alternately, they could be pressing the manufacturers to be adding it (cars with electronic keys, the provisions of the Data Protection Act, Swindon's experiment with Mondo).

But they don't. In the past few years, tens of millions of cases of identity theft have occurred over insecure computer systems - that we know about. Remember, most States have no reporting rule, so the actual number could be much higher. Wiretapping of the Internet has gone from being a national secret to being a national boast. SIGINT's activities are unknown but comments by senior officials in Canada and Australia suggest it's not entirely benign. Airbus even sued the US Government over industrial espionage. I forget what the recent inspection concluded in terms of abuses of FBI Letters to bypass the courts, but as I recall the percentage of abuses was very very high.

Despite all of this, ther

Re:Why no security as standard?

[Bearhouse]

Hello JD, thanks for your long and thoughtful reply. Sorry it took me a while to respond - 'trouble at mill...' (shitstorm @ a client). Fixed now...

There's several points in your post, but to boil it down, I'm not sure that I agree that mass protest is the legitimate and essential prerequisite for taking action on subjects of public interest. Bit of a cop out, eh? "Gazillions of people have not complained about our insecure-by-design product, so we'll do nothing..."

You're right in practise, (just look at the success of Skype), but that does not make it - uh - right.

Since you're clearly a student of history, how about the Tolpuddle Martyrs? Was their unjust sacrifice in vain? Do we have to have specfic crisis and sacrifices every time? Can we not learn from history and widely apply general principles of fairness and common sense?

Guess not...

Re:Why no security as standard?

[Jeruvy]

So why isn't there security implemented as standard? Come on, there are lots of perfectly good standards: SSL, TSL, SSH, etc.

Damien There are actually no good implementations ATM. Many are looking into just such an appliance, but implementation as a standard may take so many years, we may just evolve around it.

Re:uhh...

[TheRealMindChild]

[insert reply in which I say nasty things about your mother and somehow tie in the existence of underwear gnomes]

Re:uhh...

[Anonymous Coward]

Can you hear me now?

Re:uhh...

[chill]

Apparently not only can HE hear you now, but so can several other people whether you know it or not.

This is just a ruse by phone makers

[EmbeddedJanitor]

Its a way to explain why phones don't live up to their advertised battery life.

But think of the situations where you have to turn a cell phone off for safety reasons: hospitals, gas stations, planes. Activating a cell phopn'e transmitter is not always a good idea.

Re:This is just a ruse by phone makers

[jdogalt]

I wonder how much the feds paid apple to make the battery in the iphone non-removable? (blatant troll... yes I know removing the battery casing is a legitimate benefit)

Re:This is just a ruse by phone makers

[digitalchinky]

I'm not quite sure if you are trolling, perhaps not. Here in the Philippines, most hospitals have overcome this simply by keeping up to date with modern equipment. Everything is shielded, there are no bans at all on cell phones in any part of the vast majority of hospitals. I'm not sure where you from, though I guess the difference could be somewhat cultural - in the US it seems to me that people like someone or something to blame, no matter how outlandish the logic. I know this is a stereotype, but it does exist.

Haven't you seen enough stories here on slashdot that debunk the whole aircraft and fuel station dangers?

I'm not sure what kind of cell phone you have that you might think it could be remotely activated to become a nice little spy toy. I don't know of any evidence that is indicative of off the shelf consumer device being able to do those things in their default state. I've been around active SIGINT for a lot of years, if it were that easy, it'd would have been exploited years ago. Symbian doesn't allow squat to get installed without a series of confirmation dialogs, if there were a remote way in over the air or otherwise, it would be have been exploited many times over. The unlocking scene has long since reverse engineered every aspect of most phones, they'd be the first to speak up if they found back doors of this magnitude, not for the spying ability, but simply because it would be fool proof way to bypass TPM.

Re:This is just a ruse by phone makers

[mikiN]

For my reply, I'll let my .sig do the talking...

Re:This is just a ruse by phone makers

[caluml]

Symbian doesn't allow squat to get installed without a series of confirmation dialogs

Unless it's signed by the network operator, or, gasp, the phone manufacturer.
You're telling me that you don't think it likely that Nokia (for example) wouldn't sign an app that installed, and ran without any prompts at the behest of a national security agency? You're crazy. It's probably written into contracts for legal intercept.

Security is defined by one's perspective

[Nymz]

Security from a consumer perspective would/could equal less control over the system for the system owner. Of course, if the consumer would/could take more responsibility for parts of the system (code/encryption/3rd party devices) then they cold ensure more security.

I figure it comes down to cost, and to most consumers that added cost (money/time/self education) is simply too high to justify for the small security benefit.

Re:Security is defined by one's perspective

[digitalchinky]

I don't quite understand how more security options would equate to less control for the system owner in such a way that it would matter to the owner. Never underestimate the small (very large actually) benefit of encryption. VOIP is no more complicated to intercept than any other trunk. I personally don't want to be categorized, logged, parameterized, and stored in a nice big database by any number of 3 letter agencies right across the world. Ultimately it's not so much that they can hear what I say, but more about the traffic analysis that is possible and how easy it can be to elevate ones 'insignificant' status to something a little less innocuous.

Encryption doesn't solve the fact that I communicated with A, who then communicated with B and C, while X - a known bad guy, called up C and dragged me in to focus, even though I've never heard of B, C or X. Most people don't care, but having worked for the man myself, I have a bit of a vested interest in the state of the art. It's a never ending arms race between convenient consumer solutions, and those behind the scenes that have a keen interest in keeping up.

Re:Security is defined by one's perspective

[davester666]

Aren't the manufacturers of these devices required to build in this support so the FBI can listen in to all our calls.

Otherwise, the terrorists win!

Re:Security is defined by one's perspective

[Anonymous Coward]

I do not know if companies have standards like that to comply with (i'm not ruling that out) but having had some experience with the Air Force's OSI, I happen to know that any cell phone thats powered on is a potential listening device and it has been that way long before the patriot act. Not that people were arbitrarily spied on , the OSI only deals with Air Force personell and most civillian rights are waived upon enlistment.

Although VOIP is completely different, I'm not suprised at all that if someone wants to know bad enough and has enough money, they can find out what i'm saying on skype. Or anything else for that matter.

voipong

[Cytlid]

I was part of a few voip beta tests a few years ago both for places I've worked and competitors. I installed this program, and it worked well. It's like a sip packet sniffer. So this is really nothing new.

Zfone?

[hedley]

Should VoIP users consider using Phil Zimmermans Z-fone? possibly a bit more secure than what we have now
I would wager.

http://zfoneproject.com/

Combined with WiFI and no encryption

[drspliff]

Disclaimer: I work for a VoIP company.

One of the main problems if you're really paranoid is that there is no standard for encryption of SIP calls or RTP streams. There are viable options such as SSL for SIP sessions over TCP then using libZRTP (from the ZFone people) - but it's non free and non-standard.

Consider this, you use WiFI roaming on your phone and route calls over SIP whenever possible because it's free, combine this with off the shelf tools (like Oreka) and you can easily record both sides of all VoIP calls on your base station.

iirc on the 3G and GSM side of things there are open standard for encryption that all devices support, but normal SIP phones and software (e.g. PSTN gateways, application servers) are all lagigng behind.

I've done research into developing encrypted RTP protocols with no bandwidth overheads, but haven't had the time to implement much of it yet, although when I do finally get round to it it'd probably end up as a commercial project and would be trying to standardise it unless there was a business case for it (not my domain).

A bit of a tangent and not really a direct comment on the article (buggy sip stacks), but I'm just thinking of the bigger issues here.

Re:Combined with WiFI and no encryption

[muonzoo]

Somehow you didn't notice section 26 of RFC 3261 or RFC 3711?
There are many interoperable, secure SIP devices -- the industry chooses not to deploy them for a variety of reasons, some good, some bad.

Re:Combined with WiFI and no encryption

[chebucto]

How would you do this? I'm imagining a scheme were the phone speaks to a VOIP server using encrypted data, and there server relays that data unencrypted to the PSTN, or encrypted to another VOIP server.

Re:Combined with WiFI and no encryption

[badfish99]

the industry chooses not to deploy them
Which is the whole problem. Section 26 of RFC3261 is entitled "Security Usage Recommendations" and describes a variety of security mechanisms that implementors may (or may not) choose to use.
If I am in control of both ends of the SIP conversation, I can arrange things so that it is secure. But if I just call some random person on a SIP phone, it look like I've got no guarantee that the two ends will negotiate any sort of encryption, and if they do not, there is no feedback to tell me that my conversation is insecure. So in practise I've just got to assume that all SIP conversations are insecure.

Re:Combined with WiFI and no encryption

[drspliff]

When you're terminating with a PSTN service, it would be decrypted by the PSTN termination server and passed onto the PSTN, however all data between the user and the SIPPSTN server would be encypted.

The same applies calls between users, just like you negotiate codecs, the higest priority codec would be the encrypted one - so if available both sides use the encrypted codec, otherwise they fall back to AMR or G729 etc.

Re:Combined with WiFI and no encryption

[jesup]

The problem isn't *no* standards for encryption with SIP; the problem is *too many* ways. Not really the actual data encryption, but the ways for exchanging keys. Someone did a matrix for an IETF meeting a year or so ago; there were something like 15+ methods, mostly incompatible, all with different side-effects on early media, conferencing, forking (having multiple phones ring), processing overhead, etc, etc. And there's no agreement on them. People are trying, however. For the data encryption, mostly that's SRTP

Another point was that offers of RTP/SAVP or RTP/SAVPF are often rejected out-of-hand and killed the entire call with phones that don't support it, since SIP/SDP didn't provide any easy way to say "I'd like to do encryption, but it's not absolutely required". A recent effort has been made to correct this (best-effort-srtp and the work on capability negotiation in mmusic). Doing this makes it more important to signal to the user the encryption status - much easier on a hardphone with a screen or videophone than an ATA acting as translator for older POTS phones.

Yes, I work for a company that does encrypted videophones.

Well Duh!

[Anonymous Coward]

Where I work the phones are VOIP and they record calls for customer quality monitoring. Everyone knows that 10% of their customer service time is recorded and examined. I'm not sure why it's a surprise that VOIP os buggable.

Control & Encryption

[Nymz]

I don't quite understand how more security options would equate to less control for the system owner in such a way that it would matter to the owner. Never underestimate the small (very large actually) benefit of encryption.

If you (and others) had more options to choose from, then you (and others) might not purchase the solutions offered by the system owner. As for encryption, I share your value of it, but most consumers do not, and will not until something bad happens to them (Death Threats).

Uhhh, not really

[Sycraft-fu]

The problem with encryption uptake is way more than just governmental. I mean the US's export restrictions never did much, there was strong crypto available from outside sources. The more important reasons for lack of crypto uptake:

1) The speed. These days, it has gotten to the point that encryption is pretty much trivial. We have better algorithms that are faster to do in software, and processors have gotten many times faster. This was not true in the mid 90s when the Internet started to take off. Encryption was a large hit, especially on a server. Thus you didn't use it unless there was a good reason.

2) Convenience. Encryption is harder to use than not. In the case of something like a website, it means getting a certificate. Yes, you can just generate your own, but then web browsers cry. In the case of e-mail it means you have to have a way of distributing and checking keys and such. With unencrypted e-mail you just send someone a message, with encrypted e-mail there are a number of additional steps, especially if you want to make sure you really are doing it securely.

3) Lack of a reason. When the Internet was getting going there just wasn't really a reason to use encryption. There wasn't the problem with hackers and shit there is today. I mean in its origins, it was just a research network connecting select institutions with a few users. If you had problems, you could probably just call the guy that was causing them. Nobody really saw a need to encrypt it. Likewise, when consumers first started getting in to it it was mostly just a playtoy. You weren't conducting business over it so who gives a shit if someone sees what you are doing?

We are now seeing a rise in encryption because there IS a reason, and computers don't have much trouble handling it. However it'll still probably never be totally pervasive because that's a pain and useless. I mean what good would it do to have Slashdot go over SSL? It's all public. You could intercept this post in transit, or you could wait 2 seconds and just read it. Likewise until someone comes up with a good method for e-mail encryption that is both secure and no more effort than what we've got now, it isn't going to happen on a wide scale.

While I'm sure the US government's export regulations didn't help, to peg that as the cause is just wrong.

Re:Uhhh, not really

[AnyoneEB]

I mean what good would it do to have Slashdot go over SSL? It's all public. You could intercept this post in transit, or you could wait 2 seconds and just read it. I will agree that encryption Slashdot seems a bit extraneous, but using HTTPS would be meaningful. An HTTP connection can be easily man-in-the-middle attacked if you have access to the connection between the client and the server, which, admittedly, is not a trivial conditional to fulfill. Such an attack would allow someone to hijack you session and... post flamebait to drive down your karma... Yeah. That really does not sound very serious, but it is something.

Re:Uhhh, not really

[Anonymous Coward]

That's very shortsighted. Knowing which articles my team is reading and commenting on (not just "something on /." which is all TLS gives away) is pretty close to telepathy. Web searches are even more important. Almost every company I've ever worked for paid a bonded service to shred my printouts, and those don't give competitors nearly as much insight into my current work.

Re:Uhhh, not really

[Bomarrow1]

It would be nice if slashdot supported ssl even if it was just a self signed cert I would be happy to memorise it. The number of times I have wanted to log on and I know the guy sitting next to me is sniffing my traffic and then I have to route it through ssh to my server is really annoying.

I for one

[Anonymous Coward]

welcome our phone-taping overlords.

TLS!!

[whardier]

Many phones and PBX's support SRTP by using TLS. This is still a huge privacy issue for most people, however encryption fixes privacy issues with most network tapping systems. You guys having a hard time with Comcast and BitTorrent? YOu can use IPSEC to get around a lot of that, or LogMeIn/Hamachi. If torrent sites existed in Hamachi networks (why not?) which is purely P2P as well as free and encrypted then you can go about your business with 802.3 segments encrypted and sent over completely dynamic IP ports.

Re:TLS!!

[mikiN]

Isn't the free version of LogMeIn a 'hosted' service? Or: who is watching over your shoulder?

Re:TLS!!

[whardier]

There is a public server that helps link P2P nodes together, however the data itself is encrypted between p2p peers only. Its quite secure, the only thing the server knows is the IP address your client responds to, the same goes for any node connected to that specific hamachi network. There is no evil eye.

The concept behind Hamachi and LogMeIn is incredibly simple. Connect to server, punch hole in NAT, look for local peers, use server to negotiate issues with p2p connections, connections between each peer has distinct encryption. The p2p encryption is based on locally generated private and public keys.

Have fun.

Question for actual lawyers

[scooter.higher]

Is listening in on a conversation connected by VOIP the same as listening in on a PSTN conversation, legally speaking?

Encryption vs. authentication and User Interface

[billstewart]

Encryption can help against some attacks, but this is partly an authentication / permission issue (who do you accept calls from and when? SIP is peer-to-peer with proxies, and you might want your PBX to be doing presence management and voicemail handling for you, etc.), and partly a user interface design problem (the phone received a call, didn't ring the ringer, and didn't ask for user permission before answering? Yikes! Who let that through the feature definitions phase?) It's one think to have the *user* able to choose answering methods (e.g. do I want voice-enabled answering so that I can tell the phone "Ok Answer", or do I only want it to answer if I hit a button on the earpiece or open the flip-phone?) But having the caller pick the answering criteria is just wrong.

Next thing you know, there'll be attacks where people call up your phone, turn on the speakerphone instead of the mike, volume up to 11, and start talking without you hitting a button to answer. So not only can the FBI call up and listen to your conversations, but the Nigerian Bureau of Investigation can call up and tell you about this money they're trying to get out of the country.

Maybe it's time to get a Linux mobile phone after all, so this sort of bugging is fixable ...

This isn't listening in on calls

[billstewart]

I'm not a lawyer, but I have played a politician on TV.

This isn't the same thing as listening in on calls between your target and someone else. This is making a call to somebody and bugging their conversations. You're probably supposed to get a warrant, at least in pre-Bush America. (Though in the real pre-Bush America, that mainly mattered if you wanted to use what you heard in court or needed the telco's help for the wiretap; otherwise you just happen to have gotten "an anonymous tip" that your target met so-and-so and talked about such-and-such, which was enough evidence to get a real warrant from a judge.)

Re:This isn't listening in on calls

[michaelhood]

Are you just making things up as you type them out? Whether or not a two-party conversation could be recorded with knowledge only of one of the parties has always been a state issue. Here is a list of states that allow one party, or require two party notification. (Disclaimer: I'm not associated with this site, just found it on Google, and make no claims to its' accuracy.)

Re:This isn't listening in on calls

[scooter.higher]

This is exactly the distinction I was asking about.

Do VOIP conversations have the same legal protection that PSTN conversations have?

(Maybe I should have asked it like that the first time)

Re:This isn't listening in on calls

[billstewart]

The question of whether a conversation can be recorded with one, two, or all of the participants knowing isn't relevant here (though thanks for the interesting pointer.)

RTFA - This is about police setting up calls so they can bug a conversation with Zero of the participants knowing that the conversation is being recorded, and there's not only the question of whether that's legal at all (without a warrant), but also whether the information they gather can be used in court.

Scooter's question about "Do VOIP conversations have the same legal protection that PSTN conversations have?" isn't the right question here (because this isn't what this bugging technique does), but it also probably doesn't have a well-defined answer. When the Feds wanted to force VOIP companies to make their infrastructures wiretappable, they argued that VOIP providers have the same responsibility to give the FBI a blank check that the telcos have, and any of them that are subject to US regulation have had to comply (so lots of the VOIP product literature talks about CALEA as well as 911 support.) On the other hand, when the Feds want to wiretap VOIP calls without doing as much work as they need to do for a standard wiretap warrant, they tend to argue that they don't need it.

In the Bush Administration environment, there's been a sufficiently rabid attack on privacy that they can probably get away with non-warrant VOIP wiretapping legally, even now that Gonzales has left, and I haven't heard any of the leading Democrats saying they plan to change this and force DoJ, DoD, and Homeland Security to start acting like Americans. (In particular, my memories of John Edwards's debates when he was trying to get the Democratic nomination in 2004 were that he was all in favor of the wiretapping-for-national-security crowd. And while it's possible that we'll end up with the major parties nominating Dennis Kucinich and Ron Paul, I think it's rather more likely that lightning will strike all the FBI buildings at once.)

Re:This isn't listening in on calls

[michaelhood]

I don't have information to give me reason to think that they wouldn't, but IANAL and this isn't legal advice.

Whitenoise

[jlebrech]

Everyone should add some whitenoise to their conversation.

Just replace the words "mother" with "dealer", "holiday" with "bank job", "tv" with "nuke", any "john" with "osama", "cook" with assasinate.

That way, they wont be able to dicypher the real from the fake.
Then again someone should try it first.

Let me know how it goes, and I will start doing this.

Encrypted Mobile Communications

[Pooldraft]

With all of the wiretapping/easedropping going on in the US these days, I am looking for a mobile solution. ISPs and Telecom companies are now being directed by the government to keep these backdoors open for them to be able to listen in on communications.

There has to be a way to get a secure/encrypted communication on a mobile device. I am thinking of VoIP on a mobile phone using service providers internet connection or if you are in Wifi range then use that. The idea is to create a system that secures wireless data communication in the US.

Another idea I had was using Sonopia to mask the data. (for those that don't know Sonopia is a social networking system that allows you to create your own carrier, I think it buys wholesale from the big V). I didn't get too far into the Terms of Use yet.

Does anyone have any-other ideas?