Problems in Diaspora: A Distributed Social Network
Yousra Javed
[email protected]
ABSTRACT
Recently, the notion of distributed social network has been introduced to address the limitations of centralized social networks. These limitations include lack of interoperability with other social networks and inability of the users to have control over their own data. In a distributed social network, every user owns their data by creating their own node (pod) in the distributed network and is able to communicate with any user on any other pod.
Diaspora is among the pioneers of distributed social net-working services. It is an open source and free software; any person can install it on their own server known as ”pod” and be able to communicate with other users on other servers/pods. There is not enough literature on the design and perfor-mance evaluation of Diaspora. In this project, I have studied the internal working of Diaspora and reported the possibility of Denial of Service, Sybil attack and defeating the encryp-tion scheme. Similarly, there is informaencryp-tion incompleteness problem in the Relayability mechanism, and, usability issues in Web interface of Diaspora.
1.
INTRODUCTION
In our daily lives, when we talk to our friends, we don’t need to hand our messages to a hub and get them sent over to our friends through that hub. Our virtual lives should work the same way. All the existing social networks such as Facebook, Twitter and LinkedIn are however, centralized and store the user data on a central server.
Centralized social networks have numerous problems. First and the most important is lack of privacy and data own-ership. The user data is handed over to third parties for personalized advertising. Also, even after deleting the ac-count, the user data remains stored on the central servers. Secondly, these social networks do not allow interoperabil-ity with other social networks. Therefore, if a Facebook user wants to communicate with a Twitter user, they are unable to do so and have to create separate accounts on each social network to communicate with their friends on that social network.
In order to address these limitations, recently, the idea of distributed social networks came into being. Distributed social networks are 1) open source and free 2) decentralized; they are not owned or run by one central authority 3) Fed-erated; users on one social network are able to communicate with users on another social network
Diaspora[1] is an open source software which implements distributed social network. Diaspora aims to provide the users more control over their privacy, and the ownership and
dissemination of their information by enabling the users to set up their own server (or “pod”) to host content; pods can then interact to share status updates, photographs, and other social data. It allows its users to host their data with a traditional web host, a cloud-based host, an internet ser-vice provider (ISP), or a trusted friend’s pod. Other pop-ular implementations of distributed social networks include Friendica and StatusNet [4][5].
The Diaspora project started in 2010 and is in its alpha release version. It is fairly new and currently has about 56 pods. Although the developers claim that they are the most private social network to date, preliminary studies of Dias-pora have highlighted that there is a potential of numerous problems in its design [8] [9]. In this project, I have studied the Diaspora’s architecture in detail and report the prob-lems existing in the Diaspora’s federation protocol, possible attacks the code vulnerabilities might lead to and the us-ability issues in Diaspora’s web interface. I chose Diaspora over other distributed social networks because it is the first among these networks and has a relatively better documen-tation as compared to Friendica and StatusNet.
The rest of the project is organized as follows: In Section 2, I discuss the related research work in this domain. In Section 3, I discuss the architecture and working of Dias-pora. Section 4 discusses the possible attacks and identified problems in Diaspora. Finally, I conclude the project.
2.
RELATED WORK
Recently, the distributed social networks have gained some attention in the research community. Hong et al. have sur-veyed the computer crimes in centralized and distributed social networks [9]. They have highlighted the areas in Di-aspora which could possibly have problems. These include bugs in the open source software, technology knowledge re-quirement by the end-users to install their own servers and trustworthiness of the pod owner. However, they have not discussed in detail about what problems are possible in each of the three categories.
Han et al. include social butterfly have provided a so-cial cache based solution to effectively disseminate the data between users on different servers in a distributed social net-work[7]. Certain friends cache the updates for other friends, and these selected friends act as “Social Caches”. By uti-lizing social caches, the social message traffic can be opti-mized, and the transmission latency and bandwidth usage in the network can be reduced.
Researchers have also analyzed Diaspora’s open source code to find any existing vulnerabilities [8]. They have
pointed out some severe coding errors related to authen-tication and authorization checking that could lead to other problems. We report the possible attacks that results from their vulnerability findings.
3.
DIASPORA ARCHITECTURE
This section explains the design of Diaspora social network and how the communication takes place between users.
3.1
Design
Diaspora’s design consists of distributed personal web servers. Installations of Diaspora’s open source software on these servers forms nodes (termed “pods”) - the core components of Diaspora. The interaction between these pods creates a distributed social network system. Figure 1(a) shows a ba-sic overview of the Diaspora pods and their communication. Each pod itself can be considered a small social network of trusted users(and therefore have their data on the same server). Each pod is able to communicate with other users on other pods/social networks.
Every user on Diaspora can either set up their own pod, or choose one of the existing pods to register their account with. There are approximately 56 Diaspora pods currently available. Figure 1(b) shows a user(you) on pod 1, who has friends in each of the two pods 1 and 2. The data of friend is stored on their own pods. Diaspora somehow works like a peer-to-peer network. The only difference is an individual’s data exists only in one or maybe a few pods. In contrast to the P2P network, storing more copies of the same data in different servers is favorable.
3.2
Web Interface and Features
The Diaspora features are pretty much a mix of Facebook and Twitter. Currently, the following are supported on Di-aspora:
Other features including comments/likes/private messages and notifications are similar to Facebook. Figure 2 is a snap-shot showing the above mentioned features in Diaspora’s web interface.
3.3
Federation Protocol
Diaspora’s federation protocol is used for communication between the servers. The servers communicate with one another in the following situations:
1. Discovering information about users on another pod 2. Sending information to friends, the users are sharing with Below is an explanation of how the servers communicate in each of these situations.
3.3.1
User discovery
Diaspora pods must be able to discover users on other pods, given the other user’s webfinger address [6]. The user’s webfinger address is a combination of their username and the pod name. This communication is required when the user is trying to find a friend by name on a pod or when the sender or receiver’s public key is to be extracted.
The first step is to get the webfinger server address using the host-meta file for the friend to be discovered. This is be-cause, it is not necessary that the friend’s webfinger profile is hosted on their pod. The next step is to transform the friend’s webfinger address by combining it with the ger server address and making a GET request. The webfin-ger server responds with the friend’s webfinwebfin-ger profile. This
profile contains the friend’s webfinger address, their guid, public key, seed location and an hcard to friend’s other pro-file information. Figure 3 demonstrates an example of user discovery where alice on one pod is trying to discover bob on the other pod.
3.3.2
Sending and receiving information
All the data exchanged between the pods is encrypted to protect the privacy of data even if it is transmitted over HTTP. The encryption and decryption method used in Di-aspora is Pretty Good Privacy (PGP). Every user created on a pod is assigned a unique public/private key pair and an ID called guid. The pod encrypts request and response data before they are sent out. When a request or response is received, the data will be decrypted and then passed to users.
Salmon slap (part of the Salmon Protocol)[3] is used to construct all the data messages. A salmon slap is comprised of three parts:
1. Encryption header: It contains the encrypted header json object. This object is composed of header en-crypted using inner Advanced Encryption Standard (AES) key bundle (using the outer AES key bundle) and encrypted outer key bundle using receiver’s Rivest Shamir Adleman (RSA) public key.
2. Payload message: It is encrypted using inner AES key and initialization vector (which are stored in the en-cryption header).
3. Salmon magic envelope: It consists of the encryption header, payload message and the sender’s signature in order for the receiver to verify the sender’s identity. This message is sent to the url of receiver’s salmon endpoint. This url is constructed by finding the receiver’s pod location and their guid by extracting the user’s webfinger profile as described in Section 3.3.1. Figure 4 shows the procedure of sending message to a user in Diaspora. The receiver first
de-Figure 4: Sending a message using Diaspora’s Federation Protocol
crypts the header and then the payload message to get the information about the sender. This is because, only the pay-load contains the sender’s handle. After getting the sender’s
(a)Pod Communication Graph (b)User with friends on different pods Figure 1: Diaspora Design
Figure 2: Diaspora Web Interface
Table 1: Diaspora Features
Feature Details
Asymmetric friendship One way friendship. Just like the following feature on Twitter, user A may choose share their data with user B while the other user B might not share their data with user A.
Stream This is a combination of Facebook’s Wall feature and News feed. Here a user can post status, videos and pictures with intended audience and view posts from other users.
My Activity This feature allows the user to view all the posts/likes/comments they have made.
Aspects This feature allows the user to group their friends into categories. It enables the user to share data with a limited audience. It is similar to friend lists in Facebook and circles in Google+
@mention It enables the user to tag a friend in a post in order to notify them about a post just like in Facebook Hashtags Hashtags enable categorization of the posts so that people with interest in the relevant categories
can view these posts too
Followed Tags These are categories of interests to the user. Posts related to these categories will appear in the user’s stream
Connect Service This feature enables the user to simultaneously post to the status/photo/video to Twitter, Facebook or Tumbler for their friends not on Diaspora. This is done through the APIs of these social networks
handle, their public key is extracted using the Webfinger protocol to verify the sender and send back a response.
3.4
Message Semantics
Messages are sent to the receiver’s pods for each of the following:
• Notification that a user has begun or ceased sharing with a friend
• Posts,likes,comments that a user has made on their own posts or one of their friend’s posts
• Conversations (each thread in the inbox has an object representing it)
• Messages (each individual message in a Conversation) • Profile information
• Retractions of posts,likes,comments
Each post has an ID called guid and the sender’s handle. If the post is a response e.g., a comment or a like, then the parent post’s guid and author’s signature is also included in the message. When the originator of the post wants to relay these comments/likes to the rest of the audience, they also include their own signature called parent author signature in the message in order for the receiver to verify that the message is not fake [2].
3.4.1
Issues
Numerous issues arise because of the notion of users on different servers. These issues should be handled in order for Diaspora to communicate information between the users properly.
1. Local vs Remote delivery
Diaspora has the notion of local and remote people. For each pod, its local people are the users in that pod while all the other users not on that pod are considered as remote people. Whenever a user on one pod makes a post which is visible to friends on that pod as well as to friends on other pods, Diaspora should deliver all relevant notifications to local people as well as the remote people. For local people, only the pod’s internal database needs to be updated but for remote people the message must be sent over the wire. The local people should be able to see the comment, even if it never reaches the remote people.
2. Relayability
There are certain circumstances where the originator of a post is on different pod than the users replying to that post. For example, Bob and Alice live on different pods. if Bob makes a post and Alice comments, all of the people who saw Bob’s post should see Alice’s response as well. Alice will send a “relayable” response to Bob, and Bob will determine who needs to see the response, and will relay it accordingly.
3. De-duplication
In Diaspora, the sender of the message sends each remote receiver a separate salmon slap. De-duplication is used to avoid storing more than one copies of a message that is vis-ible to multiple users on one pod. For example, Alice and Eve live on the same pod, but Bob lives on a remote pod. Bob makes a post that should be visible to Alice and Eve. Therefore, he prepares two separate messages. When Al-ice receives her copy of Bob’s original message, AlAl-ice’s pod stores the cleartext in the database. When the second one comes in Eve’s pod just makes a note in a local visibility-permission table, noting that Eve should be able to see the message. However, this is only possible in case the users’ private keys are stored on the pod, otherwise it will not be possible to decrypt the messages and find out if they have been received multiple times.
4.
POSSIBLE ATTACKS
This section discusses the possible attacks identified in Diaspora.
4.1
False Reputation (Sybil Attack)
Due to the popularity of social networks and the large number of users, most businesses target them to advertise their products and gain user attention. For example, on Facebook, anyone can create a page for their business and ask users to visit their page for the product information. If the users are interested, they might like the page. Other vis-itors of the page form opinions about the business reputation from the number of fans/likes on the business page.
Sybil attack is popular in reputation systems in order to increase the rating of a user/product. The attacker creates multiple false identities and uses them to cast a vote or in-crease the number of likes. Facebook tries to limit the num-ber of accounts per person by associating a phone numnum-ber to each number. However, sybil attack is possible in Diaspora because of the following reasons:
• Each user can create multiple accounts by using the same email address on different pods
• Each user can create multiple pods; each pod is a small social network in itself
Existing defenses against Sybil attack involve creating a trusted central authority to verify credentials (e.g., credit card or passport) that are unique to actual human beings. However, Diaspora currently does not have any such mecha-nism. Neither any phone number is required to be associated with each account. Yu et al. [10] have proposed SybilGuard which leverages the social network among the users to de-tect the sybil nodes in the network. The underlying idea is that it is hard for the sybil nodes to create trust links with the honest nodes. The resulting network graph has a small quotient cut which is a small set of edges who removal dis-connects a large number of nodes from the rest of the graph. To achieve this, each node performs a random route of a cer-tain length. The verifier node then checks the intersection of the random routes of each node with its route. The nodes for which the routes do not intersect are considered as sybil nodes. This defense is more applicable to peer to peer net-works in which the sybil nodes try to outvote honest nodes. However, in Diaspora, there is no way of telling which users are honest and with whom the trust links should be build. This is because each pod is a social network in itself and it is not necessary for the users on a pod to have links with users on other pods. Figure 5 illustrates this scenario. The attacker creates an account for a product on the business pod. Then multiple accounts are created on each of the three pods using the same email addresses and connections are made between each of these users. The product page is then liked using these accounts (shown in red lines) to increase the rating.
Figure 5: Illustration of false reputation (Sybil attack) in Diaspora
4.2
Denial of Service (DoS) Attack
A denial of service attack is possible to launch in Diaspora by exploiting its code vulnerabilities [8]. Diaspora is imple-mented using Ruby on Rails 3.0 Web framework1. A major vulnerability in Diaspora’s code is that the security- sensi-tive actions on the server used parameters from the HTTP request to identify pieces of data they were to operate on, without checking that the logged-in user was actually au-thorized to view or operate on that data. Diaspora uses De-vise library to handle authentication. However, DeDe-vise does
1
http://guides.rubyonrails.org/
not handle authorization. Secondly, Rails by default uses mass update, where update attributes and similar meth-ods accept a hash as input and sequentially call all acces-sors for symbols in the hash. Figure 6 highlights the code displaying these vulnerabilities. Objects will update both database columns (or their MongoDB analogs) and will call parameter name = for any : parameter name in the hash that has that method defined.The attacker can leverage both these vulnerabilities i.e. unchecked authorization and mass update to meddle with user profiles. An attacker can create an arbitrary number of accounts, changing the owner id on each to collide with a victim’s legitimate user ID, and in do-ing so successfully delink the victim’s data from his or her login. This amounts to a denial of service attack, since the victim loses the utility of the Diaspora service. Secondly,
ac-Figure 6: Code vulnerabilities
cording to Diaspora’s federation protocol, the receiver has to perform a three step process before accepting or rejecting a message and cannot directly accept/reject a message. In the first step, the outer AES key bundle in the salmon enve-lope’s header is decrypted using the receiver’s public key. In the next step, this key bundle is used to decrypt the other part of the header and get the sender’s information and inner AES key bundle that was used to encrypt the payload mes-sage. In the third step, the receiver gets the sender’s public key and verify the sender’s signature in order to accept or reject the message.
In Diaspora, the messages can be sent over plain HTTP because the communication is encrypted. Since, the public key of the receiver can be easily acquired using the Webfinger protocol, a malicious pod can exploit this fact to construct messages with fake sender information and signature and flood a specific pod with these messages and deny services to other legitimate users.
4.3
Defeating the encryption scheme
Diaspora uses encryption when communicating messages between the users on different pods so that they are not vul-nerable to sniffing. This is Diaspora’s main feature for pre-serving privacy. However, using the vulnerabilities identified in the previous section i.e., the combination of unchecked au-thorization and mass update can be used by the attacker to replace the user’s public/private key pair with one the at-tacker has generated. Hence, the atat-tacker is able to break
the existing encryption scheme regardless of how well im-plemented Diaspora’s cryptography. The attacker can read the user’s messages at will since they have the private keys. This defeats the core value of Diaspora that the user data will remain safe and in their control.
5.
OTHER PROBLEMS
This section describes problems regarding incompleteness of information and usability issues in Diaspora’s web inter-face.
5.1
Information Incompleteness
Information incompleteness represents the absence of in-formation that is required to make a decision. The Dias-pora’s federation protocol is vulnerable to scenarios where a user needs to form a decision based on the response of another user. The relayability mechanism is one example, discussed in Section 3.4.1. It lets the originator of the post make sure that the remote users are able to see comments by users from other pods. However, consider a scenario in which Alice and Eve are on the same pod, while Bob and Diego are on separate pods. Bob makes a post which is visible to Alice, Eve and Diego. Bob sends a copy of the message to each of the three users. Each user who comments on the post will get a reward amount. However, the amount is calculated based on first come first serve basis. The first person to comment gets the award and so on. Now, if Alice comments on the post, this comment will be immediately available to Eve because they are on the same pod. However, Bob must relay the comment to Diego. If the relayed comment never reaches to Diego because Bob’s pod was down or the message got dropped in between, then Diego is unable to calculate his exact reward amount. He might be of the opinion that he made the comment first because Alice’s comment never reached him. See Figure 7 Similarly, there might be other cases where Diego’s decision is completely be based on Al-ice’s comment and he does not have enough information to form a decision because her comment never reached him.
Figure 7: Information Incompleteness in Relayability
5.2
Web Interface
If a user shares a post with only a specific number of friends by selecting the aspects they are placed in, then “lim-ited” appears beneath the post. This is used to preserve the privacy of the audience with which the post has been shared. However, unlike Facebook, where the author of the post is
able to look at the privacy settings of a post at any time af-ter it has been created, on Diaspora’s current inaf-terface, the author is unable to view or change the post settings. This is a drawback because people do not remember their privacy settings. Moreover, the sharing intentions might change over time due to the change in relationships with the post’s audi-ence and the author might want to edit the privacy settings to shrink or expand the audience. Currently, the only way to achieve this is by deleting the post and reposting it with the new audience.
Currently, the access control in Diaspora is not very fine grained and is based on allowing access control lists only. However, a user might want to add negative rules in the policy. Secondly, in some scenarios it is desirable to intro-duce exceptions by allowing a complete list and denying a specific friend. This is currently not possible in Diaspora’s current interface.
6.
CONCLUSION AND FUTURE WORK
In this project, I have explored the problems existing in Diaspora’s design. Diaspora is among the pioneers of dis-tributed social networking services. The vulnerabilities in the code can be exploited to launch a Denial of Service at-tack and can defeat the encryption scheme deployed in Di-aspora. Moreover, it is easy to create false reputation and launch a Sybil attack by creating multiple fake accounts. Similarly, there is information incompleteness problem in the Relayability mechanism where the remote user is un-able to make a decision because the information from the other user never reaches them. There also exist several us-ability issues in Web interface of Diaspora. These include the inability to view and edit the post settings and lack of fine-grained access control in the form of negative rules and exceptions.
7.
REFERENCES
[1] Diaspora. https://www.joindiaspora.com/. [2] Federation message semantics.
https://github.com/diaspora/diaspora/wiki/ Federation-Message-Semantics.
[3] Federation protocol. https://github.com/diaspora/ diaspora/wiki/Federation-Protocol-Overview. [4] Friendica. https://www.friendica.com/. [5] Statusnet. https://www.status.net/.
[6] Webfinger protocol. http://code.google.com/p/ webfinger/wiki/WebFingerProtocol.
[7] L. I. Lu Han, Badri Nath and S. Muthukrishnan. Social butterfly: Social caches for distributed social networks. In SocialCom/PASSAT, pages 81–86, 2011. [8] P. McKenzie. Weapons of mass assignment. Queue,
9(3):40:40–40:48, Mar. 2011.
[9] L. B. P. W. H. M. Pang Chun Hong, Chow Shing Yu and Y. K. Wa. Computer crimes on social network services. Technical report, April 2012.
[10] H. Yu, M. Kaminsky, P. B. Gibbons, and A. Flaxman. Sybilguard: defending against sybil attacks via social networks. SIGCOMM Comput. Commun. Rev., 36(4):267–278, Aug. 2006.
