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

41–50 of 126 posts

Re: Skype backdoor confirmation

#41

Post by nicheuser »

lucb1e wrote: post #26
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:/…

Oh, that quote from the security policy finally explains why this is so big news. MSN still doesn't use SSL and that's not big news in anyway. But MSN never promised to use end-to-end encryption...

That quote isn't from the policy, it is from a third party audit that was done in 2005.

Re: Skype backdoor confirmation

#42

Post by rbanffy »

glurgh wrote: post #25
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…

I don't think it's nitpicky at all - it would be different if Skype, Microsoft or anyone else had actually made a promise that messages that pass through their service are unreadable to them. While it's technically possible it's not the norm and it's hard to come up with examples of services that actually do make this promise - tarsnap is one that comes to mind.

Readable is one thing. Read and used is a completely different thing.

Re: Skype backdoor confirmation

#44

Post by amboar »

johnchristopher wrote: post #37
Sami_Lehtinen wrote: post #33

Earlier quoted context omitted.

There are also truly distributed solutions like Bitmessage. https://bitmessage.org/

Thank you! I was thinking about MTUA, mail, crypto/privacy and bitsync yesterday and was wondering if there could be a new mail system that would be encrypted and decentralized by default (à la bitsync/bittorrent). Bitmessage seems to closely match what I had in mind.

check out syndie : http://syndie.i2p2.de

Re: Skype backdoor confirmation

#45

Post by drivebyacct2 »

StavrosK wrote: post #31
UnoriginalGuy wrote: post #30

Earlier quoted context omitted.

Everything? Sharepoint, DropBox, Owncloud, LogMeIn, Flickr, Google Docs, et al. Private/one-time-use URLs have been a "thing" since practically forever and they're all over the place.

Oh, sorry, I misread "private" for "secure". Would anyone here use a WebRTC-based service that also encrypted the file in transit, thus making it pretty hard for anyone other than the recipients to see it?

How? The recipients have to manually type in the decoding key? Or they have an account and have been given access internally to the content?

Re: Skype backdoor confirmation

#46

Post by StavrosK »

drivebyacct2 wrote: post #45
StavrosK wrote: post #31

Earlier quoted context omitted.

Oh, sorry, I misread "private" for "secure". Would anyone here use a WebRTC-based service that also encrypted the file in transit, thus making it pretty hard for anyone other than the recipients to see it?

How? The recipients have to manually type in the decoding key? Or they have an account and have been given access internally to the content?

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 it somewhere to use whenever you like.

Re: Skype backdoor confirmation

#47

Post by drivebyacct2 »

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:/…

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 transitioned those signaling/directory services to the cloud.

At worst, this gives Microsoft the ability to see who is calling who, I'll grant that. Worst case scenario, you can't negotiate via STUN and UDP hole punching or UPnP port forwarding, then you will get stuck with TURN and that will route through Microsoft's servers.

So, unless someone has proof of a connection that should have established peer-to-peer and instead the call itself was routed through MS's servers TURN style.... then can we ALL please stop repeating this obnoxious rumor about MS eavesdropping on all Skype calls. Or worse yet tying it to some URL lookup service?

Re: Skype backdoor confirmation

#48

Post by drivebyacct2 »

StavrosK wrote: post #46
drivebyacct2 wrote: post #45

Earlier quoted context omitted.

How? The recipients have to manually type in the decoding key? Or they have an account and have been given access internally to the content?

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"... who or what received it?

Of course, Skype's bot won't implement WebRTC.

They'll implement the proprietary blend that they told no one they were working on until everyone else was making serious progress with the implementation that everyone else collaborated on...

http://html5labs.interoperabilitybridges.com/prototypes/cu-r... [hm, they've actually put some money where their proposal is, I'll have to check into this more]

Re: Skype backdoor confirmation

#49

Post by alfaomega »

>How far does this go? Do people need to worry about microsoft IIS web servers with SSL, exchange servers? You do have to wonder if apple backdoored their IM client, below the OTR, or silent circle, or the OS - I mean how far does this go? Jon Callas said not apple, that wouldnt be cool, and apple aims for coolness for users; maybe he should dig a little more.

What? Why bring Apple into this?

>Now are they just hoovering up the skype IMs via the new microsoft central server architecture having back doored skype client to no longer have end2end encrption (and feedind them through echelon or whatever) or is this the client that is reading your IMs and sending selected things to the mothership.

Skype claims the changes were unrelated, not sure if believable but they have some details on them here.

http://blogs.skype.com/2012/07/26/what-does-skypes-architect...

More interesting details here. http://www.zdnet.com/no-microsoft-and-skype-are-not-playing-...

>btw their HEAD request was completely ineffective per the weak excuse microsoft offered in the article at top my php contained a meta-refresh which the head wont see as its in the html body

Yes, but if the links are spreading fast, you can expect more scrutiny. I think they're trying avoid situations like the below.

"New Skype malware spreading at 2,000 clicks per hour to mine Bitcoins" https://news.ycombinator.com/item?id=5502028

Interesting comments on that article, including someone calling for Ballmer to be jailed because he allows malware links on Skype. How can they detect and stop malware with OTR?

Re: Skype backdoor confirmation

#50

Post by mixedbit »

UnoriginalGuy wrote: post #23
mixedbit wrote: post #18

Earlier quoted context omitted.

You are aware that many popular services allow to share stuff privately using URL encoded credentials?

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.
Post reply on HN