If you think the private messages you send over Skype are protected by end-to-end encryption, think again. The Microsoft-owned service regularly scans message contents for signs of fraud, and company managers may log the results indefinitely, Ars has confirmed. And this can only happen if Microsoft can convert the messages into human-readable form at will.
With the help of independent privacy and security researcher Ashkan Soltani, Ars used Skype to send four Web links that were created solely for purposes of this article. Two of them were never clicked on, but the other two—one beginning in HTTP link and the other HTTPS—were accessed by a machine at 65.52.100.214, an IP address belonging to Microsoft. For those interested in the technical details, the log line looked like this:
'65.52.100.214 - - [16/May/2013 11:30:10] "HEAD /index.html?test_never_clicked HTTP/1.1" 200 -'
The results—which were similar but not identical to those reported last week by The H Security—prove conclusively that Microsoft not only has ability to peer at the plaintext sent from one Skype user to another, but that the company regularly flexes that monitoring muscle.
In one sense, this shouldn't come as news. Skype's privacy policy clearly states that it may (emphasis added) use automated scanning within Instant Messages and SMS to identify spam and links to sites engaged in phishing and other forms of fraud. And as Ars reported last year, since Skype was acquired by Microsoft, the network running the service has been drastically overhauled from its design of the preceding decade. Gone are the peer-to-peer "supernodes" made up of users with sufficient amounts of bandwidth and processing power; in their place are some 10,000 Linux machines hosted by Microsoft. In short, the decentralization that had been one of Skype's hallmarks was replaced with a much more centralized network. It stands to reason that messages traveling over centralized networks may be easier to monitor.
Perception, meet reality
Still, there's a widely held belief—even among security professionals, journalists, and human rights activists—that Skype somehow offers end-to-end encryption, meaning communications are encrypted by one user, transmitted over the wire, and then decrypted only when they reach the other party and are fully under that party's control. This is clearly not the case if Microsoft has the ability to read URLs transmitted back and forth.
"The problem right now is that there's a mismatch between the privacy people expect and what Microsoft is actually delivering," Matt Green, a professor specializing in encryption at Johns Hopkins University, told Ars. "Even if Microsoft is only scanning links for 'good' purposes, say detecting malicious URLs, this indicates that they can intercept some of your text messages. And that means they could potentially intercept a lot more of them."
Specifics of the Microsoft scanning remain unclear; one possibility is that the scanning and spam-checking happen on Microsoft servers as communications pass through supernodes. Another possibility is that the Skype client on each end-user machine uses "regular expression" programming techniques built into the software and sends only the links to Microsoft servers.
"Either way, the finding does confirm that somewhere along the stream, Microsoft/Skype has the ability to intercept/extract content from your communications though we can't conclusively say where," Soltani wrote in an e-mail to Ars. "For example, even if the scanning was happening client side, it's plausible that MS could be compelled to push a ruleset to the Skype client that just logs/transmits all our activity (similar to what CarrierIQ was doing on the HTC phones)."
Helping to feed this confusion about exactly what measures are taken to protect Skype messages is Microsoft's management, which remains vague about the precise type of encryption its service uses. Asked for comment on this story, a spokeswoman offered a statement that was identical to a single sentence in the privacy policy. The statement didn't address my other question that's equally important: does Microsoft record the links and other content sent over Skype? Eventually I found the answer, and unfortunately it gives Microsoft all the wiggle room it needs. It states: "Skype will retain your information for as long as is necessary to: (1) fulfill any of the Purposes (as defined in article 2 of this Privacy Policy) or (2) comply with applicable legislation, regulatory requests and relevant orders from competent courts."
To be fair, Microsoft's scanning of Skype messages isn't too different from techniques Facebook reportedly employs, and what any number of other online services do, too. As Green notes, these companies have a duty to make sure their services aren't abused to circulate malware.
What's different in the case of Skype is the misunderstanding among many users that links and other content sent over the service are private. This misunderstanding is all the more unfortunate given the possibility that this information plucked out of private messages could be logged and retained for as long as some nameless, faceless Microsoft manager deems appropriate. Add to that the fact that a server bearing a Microsoft IP address very well may click on any link you send over Skype and it may not be such a good option for dissidents trying to lay low.
So the next time you use Skype, enjoy the clarity of the voice communications, its generally slick user interface, and its many other benefits. Just don't think the service can't peer into your messages and store indefinitely what Microsoft managers want. It can, and until officials specifically disclose their practices, users should assume it does.
Promoted Comments
That's misleading. Either something is secure or it's not, and Skype is not. Even if you trust MS and the Feds, the fact that they can decrypt the communications means that anyone that compromises a Skype server can do it also. We're well past the point where the only hackers are kids doing it for kicks, there would be a lot of money in silently compromising a server like that and selling the captured info.
If you need security you need to control both endpoints. having the server be an endpoint is never going to be secure.
Just imagine: "So, your job is to run some servers. They will programmatically visit any arbitrary URL that any Skype user wishes to feed them. Have a nice day, and try not to get compromised."
If you issue a HTTP GET from your favorite programming language, there isn't much risk of a browser exploit working. I'm pretty damn sure MS doesn't script Internet Explorer to visit all those pages.
Presumably, if they are looking for phishing/malware/etc. they have to be running something of reasonable complexity against the payload. Just poking the server and getting a 'yup, it's here!' would indeed be fairly safe; but also entirely pointless. They have to be running some sort of AV system or something for the system to be worth operating at all.
As shown in the log file snippet included in the article, the HTTP GET request was not issued; they sent a HEAD request, which does not retrieve page content. From section 9.4 of the HTML 1.1 spec:
The HEAD request is used for checking if a file or object exists at all, checking its size, etc. - meta stuff.
As for Microsoft's/Skype's methodology, my first bet was, as others have mentioned, the client checking links for phishing or other malicious addresses just as a browser does. However, the questions (mysteries!) there are why it would actually check the link by issuing the HEAD request, which proves very little as it it would "catch" temporary network issues or server outages, etc. Useless for security. And also, why it comes from a Microsoft address, not the client's address. Browser "safe browsing" features typically involve DNS requests and requests sent to a safe-browsing service's network, such as Google's safe browsing look-up service, from the client. The Microsoft source address has other implications, in my opinion.
1. Message encrypted by "A" such that only "B" can decrypt it.
2. Message is passed from "A" to "B" without being decrypted.
3. Message is decrypted by "B"'s local client.
4. "B"'s local client parses internet URLs and sends them to Microsoft's SmartScreen filter.
5. Microsoft's SmartScreen service checks the existence of the URL and/or does some follow-up, reports back to the client.
Now, I'm not saying I know that this is what is happening. In fact, I kind of doubt it, just because it would be more efficient (especially for group communications) to manage encryption from client to server only. But would this not would show the results presented in this article while still being end-to-end encryption? How can you rule out this scenario from this test?
Is there any meaningful difference between "message is encrypted by A, sent to MS's servers, decrypted, stored, re-encrypted, and forwarded to B" and "message is encrypted by A, sent to B, decrypted by B, forwarded to MS's servers, and stored"?
Either way, MS's servers still have a theoretically-permanent copy of the message that A sent to B; either way, Skype is not functionally offering end-to-end encryption; either way, Skype is not as secure as the article suggests most people believe it to be.
The functional difference would be that a MITM attack which modified the message before being received by B would be impossible.
However, as Xavin points out, a Skype server being compromised in order to snoop on the plain-text info would still be in play. Also, in the scenario proposed by pusher-robot, would this not open up the recipient's connection back to MS as another attack vector?
1. Message encrypted by "A" such that only "B" can decrypt it.
2. Message is passed from "A" to "B" without being decrypted.
3. Message is decrypted by "B"'s local client.
4. "B"'s local client parses internet URLs and sends them to Microsoft's SmartScreen filter.
5. Microsoft's SmartScreen service checks the existence of the URL and/or does some follow-up, reports back to the client.
Now, I'm not saying I know that this is what is happening. In fact, I kind of doubt it, just because it would be more efficient (especially for group communications) to manage encryption from client to server only. But would this not would show the results presented in this article while still being end-to-end encryption? How can you rule out this scenario from this test?
Is there any meaningful difference between "message is encrypted by A, sent to MS's servers, decrypted, stored, re-encrypted, and forwarded to B" and "message is encrypted by A, sent to B, decrypted by B, forwarded to MS's servers, and stored"?
Either way, MS's servers still have a theoretically-permanent copy of the message that A sent to B; either way, Skype is not functionally offering end-to-end encryption; either way, Skype is not as secure as the article suggests most people believe it to be.
In the latter case, the client could theoretically be sending the URL's only, not the complete message. That seems to be a meaningful difference to me, especially if you have already chosen to use the SmartScreen service.
The functional difference would be that a MITM attack which modified the message before being received by B would be impossible.
However, as Xavin points out, a Skype server being compromised in order to snoop on the plain-text info would still be in play. Also, in the scenario proposed by pusher-robot, would this not open up the recipient's connection back to MS as another attack vector?
I see your point; I should have asked whether, from a privacy perspective, there was a meaningful difference. Modified messages, while certainly not good, don't have the privacy implications that the stored-indefinitely copies present.
Clearly, MitM is worse than "B (or A) forwards copies to MS", but they still both end with MS having a copy of the message.
1. Message encrypted by "A" such that only "B" can decrypt it.
2. Message is passed from "A" to "B" without being decrypted.
3. Message is decrypted by "B"'s local client.
4. "B"'s local client parses internet URLs and sends them to Microsoft's SmartScreen filter.
5. Microsoft's SmartScreen service checks the existence of the URL and/or does some follow-up, reports back to the client.
Now, I'm not saying I know that this is what is happening. In fact, I kind of doubt it, just because it would be more efficient (especially for group communications) to manage encryption from client to server only. But would this not would show the results presented in this article while still being end-to-end encryption? How can you rule out this scenario from this test?
If the local client is reading the info and acting on it, then it's not end-to-end encryption. It is still a MiM scenario, only that the "Middle" is really close to one of the endpoints, a Man at almost the Endpoint attack if you want to name it.
You must login or create an account to comment.