SNS Privacy Control

I wrote a paper on privacy control in social networking sites. You can find the full paper at http://www.cse.hut.fi/en/publications/B/11/papers/li.pdf. Here’s the abstract:

As social networking services become increasingly popular, more and more attacks against users’ private information are reported. As a result, privacy protection becomes an important concern among users. Previous research has produced many different approaches to deal with privacy control in different social networking sites. In this paper, we make a survey on different approaches proposed to tackle the privacy issue in social networking sites. In particular, we put current approaches into three general categories, i.e. approaches addressing end users’ active participation, security automation based on machine learning algorithms, and privacy preserving by using a decentralized architecture for social networkingservices. Then we introduce and analyze some of the approaches in each category. Finally, we give some suggestions that may help privacy control in online social networks.

Testing Bouncer

Static testing is used to test the bouncer, that is, a separate set of test cases and sample outputs are provided. And the bouncer is given the test cases and its outputs are compared with sample outputs.

A verifier is used to accomplish the above function, and another bash script is written to automate the process.

The bash script is as follows:

The verifier is as follows:

Technical Details

We define a BPF filter as “icmp and dst host <bouncer_ip>”, which filters out all none-ICMP packets and packets not destined to the bouncer. The we compile this filter and set the filter to the capture device.

When the capture device captures a packet, a process_pkt function is called to process the packet. And that is where we validate the packets and then, if the packet is valid, update
the packet and then send it out, or write the packet to a dump file.

The process of validating the packets are as follows:

  1. Validate checksum of IP header.
  2. Validate TTL of IP.
  3. Validate IP source address
  4. Validate ICMP header checksum. 
  5. Validate ICMP type and code. 

Since we write the packet to a dump file in a separate function, so a pointer to the dump file handler is passed to the processing function when the process_pkt function is called. The same method is used to pass server IP address and test mode flag.

We keep a linked list of all the ICMP echo requests. When a ICMP echo reply is received, we go through the linked list to find out where
the original echo request comes from.

The code is as follows.

bouncer.h:

process_pkt.c:

Packet Bouncer Overview

A bouncer bounces packets it receives from clients to servers. This is useful when people want to hide their internal network topologies. In this report, we examine a very simple case of bouncer — a bouncer that only bounces ICMP requests. When it receives an ICMP echo request, it modify the packet and forward it to the server specified by the user. After receiving the echo reply packet, it
again modifies the packet and finds out where to send the packet and then sends out the reply packet.

Code

The code looks as follows.

Multiple Sessions

A linked list of all RUDP sockets is maintained. When rudp_socket() is called, an RUDP socket is created and added to the linked list. An RUDP socket keeps a record of the pees/sessions it talks with. When RUDP receives a packet from an unknown socket address, or when RUDP receives a send packet request to an unknown socket address, a new session is created. And for each session, a linked list of all buffered packets is kept.

Session Establishment and Tearing Down

When rudp_sendto() is called, the protocol first check if there exists a session between the sender and receiver. If not, the protocol will try to setup a session by sending RUDP_SYN messages. And the packet the application wants to send will be buffered in the created session. After an RUDP_ACK message is received, the server side socket start sending out packets. Go back N protocol is used to control the sending process. After the protocol receives a rudp_close() signal, it will first check whether there are still active sessions and packets in the sending buffer. If not, the protocol will send out RUDP_FIN messages and after receiving RUDP_ACKs, the session is torn down.

RUDP Overview

RUDP is a protocol that ensures transfer reliability with UDP. A sliding window protocol (Go back N) is used to realize reliability. Using RUDP, applications can send and receive data packets without worrying about lost packets.

The lines in red signifies state change for RUDP clients (receiver side); while the black lines signifies state change for RUDP servers (sender side).

Multiple Sessions

A SessionManager' is used to manage all the sessions. The SessionManager’ keeps a list of sessions. When it receives data, it will first check which session the data belongs to. Then the data is given to the corresponding session. If it does not belong to any session in the list, a new session will be created and added to the session list.

The basic code looks like this:

Session Establishment and Tearing Down

Each session has a ‘status’, it can be ‘new’, ‘establishing’, ‘cancelling’, ‘established’, ‘tearingdown’ and ‘destroyed’.

When a new session is created, its status is ‘new’.

When an ‘INVITE’ is received, it sends out an ‘OK’ message and change its status to ‘establishing’.

After receiving an ‘ACK’ message the status will be changed to ‘established’.

Then begins the transferring of voice data using RTP.

When the sending finishes the status will become ‘tearingdown’.

A ‘BYE’ message is also sent to the client.

The status becomes ‘destroyed’ after getting ‘OK’ from the client.

When a ‘CANCEL’ message is received, the status becomes ‘cancelling’.

Then it sends back ‘OK’ and ‘Request Terminated’ messages.

After received an ‘ACK’, the status becomes ‘destroyed’.

The thread is as follows:

Generating Voice File

When the web server receives a POST' message from the web page, it will first check whether the message is valid. If so, freeTTS‘ is used to generate a voice file and the file is saved in the `wav’ directory with pre-configured file name.

The voice generator looks as follows:

SIP Speaker Overview

SIPSpeaker is a system that provides answering machine service. When the system receives a SIP call, it will establish a new session with user client and send voice data to the user. The user can configure a customized message using a web interface.

The administrator of the system can configure the interface and port number for the web interface; he/she can also configure SIP service interface, port number as well as user name, either using a configuration file or command line arguments.

The system supports multiple session to be communicated at the same time. It uses SIP to manage sessions, and SDP as the handshake protocol to reach an agreement on media format transfered on wire.

JMF is used to support audio playback. And FreeTTS is used to convert message from text to audio format.

Non-ASCII characters in Email subject

In this system, Email subjects are encoded in Q' scheme, a scheme similar to quoted printable’. The format is “=?charset?Q?encoded subject?=”, in our case, the charset is `ISO-8859-15′.

For example, the Email object in this system is as follows:

MIME Encoding

Quoted printable characters are encoded in the format =XX', where XX’ stands for the hexadecimal value of the character.

The encoder looks as follows: