Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

This page describes the architecture of Yona. 

High level overview

On network level, this is how it looks like:

Initial support is limited to mobile devices. These devices will access the internet through a VPN tunnel that is terminated on the web traffic classification server (SmoothWall). The server will not filter, in the sense of blocking sites, but just classify the sites. This classification will happen for HTTP and HTTPS traffic, see this page. The requests will be passed on to the target web server. For requests that in categories of interest to Yona, the classification server will post a message on a queue to the Yona server. The Yona server is responsible for maintaining the user and buddy administration and to inform users about events that conflict the goals defined by the users. The Yona app on the device interacts with the Yona server to see buddy events and everything supported by Yona.

Subsequent sections zoom in on the app, the web traffic classification server and the Yona server.

Mobile App

The mobile app is the only user interface provided for Yona. There are no plans to provide a web site. The mobile app has the following high level responsibilities:

  1. Provide the user interface for all features provided to Yona users
  2. Configure the VPN connection
  3. Reconnect the VPN in case it disconnects
  4. Send a request to the Yona server to inform the buddy in case:
    1. The user uninstalls
    2. The user disables the app
    3. The user disables or otherwise hampers the VPN connection

The app generates and stores a key in the secret storage of the app, that is required for all interactions with the server.

Web traffic classification server

The heart of this server is SmoothWall. Kliksafe uses this product to filter requests. For Yona, it will be deployed as a classification server. The SmoothWall server provides us with the following features:

  1. VPN server
  2. Classification engine
  3. Man-in-the-middle proxy for HTTPS servers. See this page.

Every request passed through the filter engine is logged in the Dansguardian log. Given the constraints of the Linux OS of the SmoothWall server, we will use a Perl script to filter the events that are of relevance to Yona and post these on the queue to the Yona server. The log file is normally written in a file. Instead of the file, we will create a named pipe and have toe Perl script read from it.

Yona server

Diagrams

Global architecture, drafted after discussion with Bert and Ron.

Data model

Questions/remarks

  1. We believe that the URL Hits table needs to be encrypted using asymmetric keys. 
    1. can these keys be derived from a client certificate?
    2. can the client certificate be used in SmoothWall, or should it be the other way around?
    3. we assume that the URL hits are created for the actor and his buddies. Only them should be able to see the actual URLs. But the actor/buddy column should be encrypted as well!
  2. Do we need the Account table to be encrypted as well?

 

  • No labels