Hi!
Great work on that draft! :)
My comments follow:
SiNA Rabbani:
> *Adversary Model*
>
> We use the range of attacks available to the adversary adversary as the base for
^^^^^^^^^^^^^^^^^^^
one adversary is not enough? ;)
> our Threat Model and proposed requirements.
> *SOCKS Proxy support for WordPress*
> WordPress has the ability to proxy its outgoing connections, however the
> current implementation only supports HTTP proxy. We propose to submit a
> patch to WordPress core, enabling SOCKS Proxy support:
> http://core.trac.wordpress.org/browser/tags/3.6.1/wp-includes/class-http.php
Ok, this one might be a crazy idea but what about wrapping Apache or PHP
with torsocks?
> *OnionPress plugin*
> Instead of hard-coding our modifications to control WordPress'
> functionalities, we propose to develop a custom plugin.
> The plugin will provide a new menu in the Administrative panel of the
> site. Providing options to interact with Hidden Service features.
> (Note that Administrative features are going to be restricted from
> the public and only available to localhost)
So we need WordPress to interact with the ControlPort, here. This opens
a new set of potential problem. It would be great if we could allow tor
to only accept a very limited set of commands.
> *User Authentication/Permission Levels*
>
> a) Blog Administrator
> This person is hosting the blog on a local computer and has physical
> access to the installation. There is only 1 of such role. This
> login will be restricted to localhost only.
As you are proposing to package the whole thing using a virtual machine,
this would not be localhost. Unless you are thinking to have a GUI on
the VM? In that case, this would probably be better to write it clearly.
> b) Blog editors/contributors
> These are the active content publishers. Each person has the ability
> to remotely connect, login and publish content. Editors do not have
> any administrative permissions such as adding or deleting users.
> Each editor is assigned a dedicated key and .onion hostname using
> the HidServAuth and HiddenServiceAuthorizeClient features in
> stealth mode.
>
> "HiddenServiceAuthorizeClient auth-type client-name,client-name,â
> If configured, the hidden service is accessible for authorized
> clients only. The auth-type can either be 'basic' for a
> general-purpose authorization protocol or 'stealth' for a less
> scalable protocol that also hides service activity from
> unauthorized clients. Only clients that are listed here are
> authorized to access the hidden service. Valid client names
> are 1 to 19 characters long and only use characters in
> A-Za-z0-9+-_ (no spaces). If this option is set, the hidden
> service is not accessible for clients without authorization
> any more. Generated authorization data can be found in the
> hostname file. Clients need to put this authorization data
> in their configuration file using HidServAuth."
What worries me usability-wise is that we currently have no way to
configure this without needing users to edit their torrc. Tor Launcher
UI could probably be extended in a way or another, but that probably
needs to be part of the plan.
> c) Readers (the world)
> These are the site visitors, they will be able to send GET requests
> to the .onion address and receive HTML and multimedia content.
> No login or comment posting permissions granted.
One thing in the model you describe requires WordPress to be able to
transparently run from at least 2 different addresses: localhost,
editor2222222222.onion. As far as I understood from the discussion held
around proposal 204 and the upcoming support of hidden services by the
noblogs.org platform this kind of setup was not something that WordPress
supported out of the box. I might be mistaken, but that's worth taking
a closer look.
> *Packaged System*
>
> We propose to design and develop a Debian based Live OS that can
> be started as a Virtual Machine or to boot a personal computer. This OS
> will include Tor, LAMP stack and a running copy of WordPress.
>
> The LAMP installation will be hardened and configured to meet our
> security desires. We require a secondary USB disk for persistent storage.
> Desired outcome is a point-and-click and maybe portable solution that
> can be launched from inside of Windows, Linux or Mac OSX.
>
> VirtualBox is a second candidate to host the VM.
> http://wiki.qemu.org/Main_Page and/or https://www.virtualbox.org/
This is *not* an easy task to do properly. Tails âserver editionâÂ[1]
might be a more ambitious project, but even something simplier based on
Tails would require a lot of attention to details. Starting from scratch
even more.
For example, USB support in VirtualBox is non-free and qemu does not
have good support for USB 2 devices IIRC. Not sure how to reconcile that
with the âVM or bare wardwareâ feature.
[1]Âhttps://tails.boum.org/blueprint/server_edition/
How about using APAF?
How about updates?
> *Edge Cache Nodes*
>
> In order to provide "blazing-fast" access to the published content
> outside of the Tor network, we propose the deployment of caching servers
> operated by semi-trusted third party organizations or persons. These are
> similar to tor2web nodes:http://tor2web.or/
>
> The content providers (bloggers) would select from a list of available
> edge servers and send a pgp signed zip file of the latest static version
> over Tor. Edge servers will reduce traffic from the Tor network, also
> provide a chance for content to reach the world in case of a DDoS or
> technical issues with the Tor network itself.
>
> Having cached copies available remotely make it possible for the blogger
> to get on-line, publish content and go back off-line, minimizing the
> amount of time and traffic spent on the Internet.
This is a really good idea, but maybe this should be tackled in a second
(or third) phase of the project?
--
Lunar <lunar@xxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev