Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skype backdoor confirmation

lists.randombit.net

Post reply on HN
Print view View original

51–60 of 126 posts

Re: Skype backdoor confirmation

#51

Post by alfaomega »

westoque wrote: post #35

I guess it's time for Google Hangouts to shine.

Why? I don't think it's encrypted in such a way that Google can't read it. References?

I don't think you can trust Google with your chat and docs as well.

From:http://www.wired.com/threatlevel/2010/09/google-spy/

>Google acknowledged Wednesday that two employees have been terminated after being caught in separate incidents allegedly spying on user e-mails and chats.

>David Barksdale, 27, was fired in July after he reportedly accessed the communications of at least four minors with Google accounts, spying on Google Voice call logs, chat transcripts and contact lists, according to Gawker, which broke the story Wednesday.

http://gawker.com/5637234/gcreep-google-engineer-stalked-tee...

Re: Skype backdoor confirmation

#52

Post by StavrosK »

drivebyacct2 wrote: post #48
StavrosK wrote: post #46

Earlier quoted context omitted.

https://myservice.com/#chan=somerandomid&secret=somerand... Then you have to give the URL to the recipient (over a secure channel), but the app will optionally allow you to not automatically send the file, but tell you how many people are connected (e.g. if there are two when you're expecting one) and begin transfer manually. Also, I'm planning to make it all a single HTML file so you can download/verify it and store…

I wrote a few paragraphs but don't want to talk past you, that sounds fine for a secure channel, but are you going to warn users against using Skype for example? I mean, I don't know if someone has tried Google Docs with Skype, but I know I posted a GDoc link somewhere a while back only to have a bot pop into the doc. So, if the same happens with Skype, someone "joins" this shared resource... and you hit "Transmit"..…

Yes, I'll make sure to tell users to share the link over a secure channel, or to verify each other's IDs. So, even if a bot does join, it ostensibly won't MITM the intended recipient when they say "my ID is ZXCV-BNMA", so you can still tell if the recipient is in.

Obviously it's not going to be secure against coordinated attacks by governments (which I will also make clear), but my intention is to have it be secure enough for 99% of people while being easy to use. It'll at least be more secure than Dropbox/Box/Skype/whatever, which aren't secure in the slightest.

Mega, for example, might be secure, but I haven't personally seen their implementation, don't trust them not to implement any backdoors, and don't trust them not to change it. I'm aiming to make mine as small as possible, so you can verify it at pretty much a glance.

Re: Skype backdoor confirmation

#53

Post by alfaomega »

austengary wrote: post #9
UnoriginalGuy wrote: post #2

This is totally nit-picky, but strange use of the word "backdoor." When I read "backdoor" I was expecting to read about some malware-like functionality within the Skype client itself, but instead this is just telling us that Microsoft can read content after it is sent to them via the client and decrypted. I would prefer Microsoft stopped scanning/reading my conversations, and I agree that what they're doing (e.g. acc…

A backdoor in their encryption protocol. They claim it is secure. "The Skype Security Policy is: ... 4. Messages transmitted through a Skype session are encrypted from Skype-end to Skype-end. No intermediary node, if any exist, has access to the meaning of these messages. [1]" [1]: http://download.skype.com/share/security/2005-031%20security... Aforementioned referenced on + additonal security overview/facade: http:/…

>Their hybrid peer-to-peer/client–server implementation allows for eavesdropping. This is now confirmed to be in practice.

Is it possible that the communication itself is OTR, but the Skype client receiving the message sends only the URLs to the server?

Re: Skype backdoor confirmation

#55

Post by UnoriginalGuy »

mixedbit wrote: post #50
UnoriginalGuy wrote: post #23

Earlier quoted context omitted.

Indeed. Add this to the 1,000,000 other reasons why you should never use GET requests for authentication/verification.

What do you mean by 'using GET requests for verification'? I think you are mixing different concepts. The problem is caused by URL encoded credentials and has nothing to do with GET requests. It is perfectly fine (and often desirable) to authorize GET requests.

You can only encode credentials in a URL via GET. Therefore if people stop using GET and start using POST (aka forms) for authentication this issue goes away. Even just a simple pin.

GET issues are primarily related to the fact that an attacker can automate their access. So they could trick a user into going to a specially crafted site, and then request content on that user's behalf via GET forgery, and return it to the web-server you control.

It is very convenient, but fairly insecure.

Re: Skype backdoor confirmation

#56

Post by GhotiFish »

buster wrote: post #32
claudius wrote: post #28

Earlier quoted context omitted.

I have reason to believe that the government cannot access all my mails. But if it could, I’d be even happier, as it would either prove a fault in GPG (unlikely) or a working quantum computer implementing e.g. Shor’s algorithm. And who wouldn’t want to hear of the latter?

I have reason to believe that you're wrong, because if you're under surveillance by the FBI or whatever, they will be able to read your mail. Unless you're the ultra-paranoid guy there are ways to get to your password physically :( (so, since you're coming up with GPG which i obviously was not referring to i can also come up with some unlikely scenario, ok?)

I can't really think of how one gets around that link. I'm not sure what you mean.

Re: Skype backdoor confirmation

#57

Post by spellboots »

drivebyacct2 wrote: post #47
austengary wrote: post #9

Earlier quoted context omitted.

A backdoor in their encryption protocol. They claim it is secure. "The Skype Security Policy is: ... 4. Messages transmitted through a Skype session are encrypted from Skype-end to Skype-end. No intermediary node, if any exist, has access to the meaning of these messages. [1]" [1]: http://download.skype.com/share/security/2005-031%20security... Aforementioned referenced on + additonal security overview/facade: http:/…

No. No. No, no, no, no. These are two different things. One is a feature designed to allow them to check URLs, fetch thumbnails, etc. The other is a very pivotal core decision in how Skype works. Skype has always been primarily node-to-node. Doing p2p connections like that required signaling/directory services. In the past, users' computers were used for that functionality. After their purchase, Microsoft transitione…

I think you are missing the point - the article proves (unless the author is flat out lying) that text chat through skype, which is claimed to be end-to-end encrypted, is not, as requests are being made to the URL.

It may currently be for innocent purposes (check URLs, thumbnails etc as you said). However the fact is that they can make these requests at all show that the encryption is not end-to-end, otherwise they wouldn't know the URL to make a request to at all! The request isn't being made from the client, the IP shows it comes from Microsoft's servers.

So, you're talking about voice, but this is proof that the textual chat connection that should be secure end-to-end is decrypted and routed through Microsoft's servers.

Re: Skype backdoor confirmation

#58

Post by jrochkind1 »

UnoriginalGuy wrote: post #55
mixedbit wrote: post #50

Earlier quoted context omitted.

What do you mean by 'using GET requests for verification'? I think you are mixing different concepts. The problem is caused by URL encoded credentials and has nothing to do with GET requests. It is perfectly fine (and often desirable) to authorize GET requests.

You can only encode credentials in a URL via GET. Therefore if people stop using GET and start using POST (aka forms) for authentication this issue goes away. Even just a simple pin. GET issues are primarily related to the fact that an attacker can automate their access. So they could trick a user into going to a specially crafted site, and then request content on that user's behalf via GET forgery, and return it to…

you are also ruling out HTTP auth, yes?

Re: Skype backdoor confirmation

#59

Post by burgreblast »

maaaats wrote: post #12

This is misleading, it's not a backdoor. At least not my definition of backdoor. Anyways, if you need secrecy, don't use a service like this. I have read people speculating if it's for spam/malware protection. They screen the urls to see if it's a redirect to known malware.

Agreed. This is one of those "improve the service things".

GOOG would do the same, but then sell ads against the data and everyone would say the ads are ok, because they're also operating a free, and very useful service.

Re: Skype backdoor confirmation

#60

Post by tomjen3 »

np422 wrote: post #22
UnoriginalGuy wrote: post #2

This is totally nit-picky, but strange use of the word "backdoor." When I read "backdoor" I was expecting to read about some malware-like functionality within the Skype client itself, but instead this is just telling us that Microsoft can read content after it is sent to them via the client and decrypted. I would prefer Microsoft stopped scanning/reading my conversations, and I agree that what they're doing (e.g. acc…

If you provide means for private communication, it's not preferred that it's private - it's a requirement. Gentlemen don't read each others mail.

Your last statement is so painful, because reality is so far from what it should be.
Post reply on HN