Version 0.6 is out! (RC2)

After a long time working on this release, we’re proud to finally announce the release of Retroshare 0.6 !

Note: additional information is available on the final release post here.

Overview

The network paradigm has changed a little bit: Retroshare still offers the possibility to securely connect nodes using SSL links, authenticated by PGP signatures. But now, in addition, the users have the possibility to create pseudo-anonymous identities which can be used to sign forum posts, talk in chat lobbies, send distant messages, etc. This decorrelates the identities from the actual nodes of the Retroshare network.

We also took the opportunity to change a lot of low level protocols, and pushed a significant number of long waiting changes. As a result, the new 0.6 version is not compatible with the 0.5 version. That means you will need to upgrade your friends too if you want to keep them. Of course, the PGP keyrings and signatures stay, so your web of trust stays intact. In order to make the transition easy, we made it possible to use both Retroshare 0.5 and 0.6 on the same computer simultaneously. Linux executables and packages being 100% independent (except for the keyrings)

What hasn’t changed a bit is the rule of thumb: all the data that comes or leaves your node get through your trusted friends.

Major new features

Version 0.6 brings some very cool features. A separate blog post will probably cover some of these topics in the near future.

Retroshare Identities

When talking over the Retroshare network(s) you need to be able to consistently know who posted which information, whereas that person might not want to be tracked either.

We solved that problem by adding pseudo-anonymous identities. These are RSA key pairs that can be used to encrypt/sign/authenticate posts. They can be either signed by your PGP key (which makes them extremely hard to impersonate) or anonymous (quite impossible to trace).

The new “People” tab allows you to manage your own identities (you can have as many as you want) and also displays the identities relevant to your own local view of the network. Every time an identity is needed, it is asked to your friends, along the flow of data that also uses the same identities. Forum posts for instance are signed by these identities, and the public keys that allow to check the signatures can always be requested to whoever transmitted the post to you.

Pseudo identities can have avatars, Utf8 encoded names, etc. The only not-yet-activated thing is the ability to make groups out of them, and control access to data in the network based on these groups. But this is ongoing development.

Hidden Nodes using Tor

Retroshare now offers—as an option—the possibility to create nodes that are only visible through the Tor network, represented by an onion address. As such, users of a hidden node totally hide their IP address even from their own friends. Hidden nodes do not use the DHT, and only share .onion addresses through the network discovery system. Hidden nodes do not use “Tor exit nodes” either except when talking to non hidden nodes. Beyond anonymity, hidden nodes are an excellent way to bypass firewalls, at the cost of an insane amount of crypto (basically DHE-SSL over Tor  😉 ).

Connecting to a hidden node is also possible if running a normal node, as soon as you are also running Tor on your machine (without any further configuration). Just make sure the Tor proxy port is correctly given in config/server/Tor (9050 is the default). Each hidden node you connect to will appear with IP equal to 127.0.0.1.

In order to run your own hidden node, you need in addition to create a Tor hidden service: edit your Tor config file (e.g. /etc/tor/torrc on linux)  and add:

HiddenServiceDir /var/lib/tor/retroshare/
HiddenServicePort 9023 127.0.0.1:5781

Now just launch Tor, and read the onion address (should look like  uido4sbabwem5bq6.onion)  that Tor created for your Retroshare node in

/var/lib/tor/retroshare/hostname

In the node creation manager at start, select “advanced” and then “Create a hidden node”. Supply your onion address and port:

Note that this can be changed afterwards in the server->Tor options. Also make sure to use the right port. In the node creation window, the port that is expected is the port in the Tor network (here 9023).

Integrated Web interface

Although we already had a web interface, we recently came up with a simpler and integrated web interface based on react.js and libmicrohttpd, thanks to the work of a new member of the team (thank you electron!). The web UI currently covers basic functions such as adding/removing friends, controlling file transfers and searching files. It is under heavy development at the time of writing this post.

The web UI works with both Retroshare-nogui and Retroshare. If enabled, it is basically accessible by pointing your web browser to localhost:9090 (or whatever port you chose for the web UI either in the config or using command line parameters of Retroshare-nogui):

/usr/bin/RetroShare06-nogui --webinterface 9090 \
           --docroot /usr/share/RetroShare06/webui/

A clean and secure way to access the web UI from a distant machine is therefore to create a SSL tunnel to forward the local port: use Putty on Windows; on linux just do:

ssh username@server.com -L 1463:localhost:9090 -N

That command securely forwards port 9090 on server.com where Retroshare06-nogui runs, onto port 1463 on localhost (the machine from which you type the ssh command). From know on, you can access your web UI at localhost:1463.

Reshaped forums and channels, and new Posted service

Forum, Channels and Posted are 3 instances of services based on the new cache system (see below). They share the ability to post comments, vote over posts, and sign posts with pseudo-anonymous identities. From posts, you may send distant messages to forum posters, talk to them in the chat lobbies, or privately using a secured chat tunnel.

Non subscribed threads no not transfer anything more than the number of posts available and we also collect the number of friends who are advertising them, giving a reliable measure of popularity.

Posted is a new service which allows you to share html links and vote for them or comment them. It is not entirely finished yet, but still quite usable. So it is included in the RC of v0.6 as a way to get some feedback about how we may improve it.

Distant chat and distant messaging

The distant chat system now allows to talk to a Retroshare pseudo-anonymous identity using an encrypted tunnel. The tunnel is secured using DHE+AES and authenticated using the RSA key pairs that represent talking identities on both ends. A led indicates the status of the tunnel, which may be interrupted because of network topology changes. Nevertheless, tunnels soon reconfigure and you’re able to talk again. Nothing guaranties that a person is close enough to be reached that way, but the distant chat still offers the possibility to privately talk to a lot of people.

The distant messaging system also connects pseudo-anonymous identities using a multi-hop e-mail system, that is asynchronous (mails can be received after the source has disconnected). Messages are encrypted and signed using the identity RSA keys. The system also includes a signed receipt mechanism which is used to remove the message sent from the outbox. So when that happens, you can be sure that the destination got the email.

Additional goodies

Fine service-based tuning

It is possible to disable services manually using a dedicated widget in the configuration window. The widget displays both your own enabling status and your friends enabling status. Only when both are ok does the data flow for each particular service.

Network statistics window

We did a bit of graphical work there. You can get from that window all sorts of statistics about what’s going on: bandwidth, tunnels, routing matrix, etc. with cool graphs to look at 😉

New certificate format

We got rid of the old ascii certificate format. The certs now look like a blind block of text, which—at the expense of ease of read—provides a lot more robustness and compactness. It’s quite impossible now to accidentally mis-cut or mis-copy one part of the certificate. We also improved the UI so that tooltips show the user the actual content of the certificate.

Improved file transfer

File transfer now supports multi-tunneling, which means that multiple tunnels can link the same (source, destination, hash) triplet. As a consequence the data flows more efficiently into the best tunnels at every moment during a transfer. The speed of transfers has also been improved. It is of course limited by the upload capacity of every link along a tunnel, but we drastically improved the handling of data which makes it possible to transfer along single links at up to 10MB/s, if the connection bandwidth allows it.

VOIP plugin now does video

 Although not entirely satisfactory, we have already all the building blocks for a real Video chat system. The UI has been improved as well, so as to give a reasonable experience to the user. The codec we’re using currently is however extremely basic and therefore does not allow much control yet.

Whitelist/blackist system

Retroshare has recently been “attacked” by what we think are network profiling actors who basically used the DHT to impersonate your friends and blindly relay the traffic between peers, without the ability to decrypt it. Still, such an attack would allow to progressively map the network and measure bandwidth. We contacted the abuse service of the related internet ranges but got no answer. So we implemented multiple measures to efficiently get rid of this problem:

• A black list system automatically collects suspicious IPs from multiple sources. (1) the DHT reports masquerading IPs when the same DHT peer claims to have multiple IPs at once; (2) friends exchange suspicious IPs using a dedicated service; (3) you might enter IP ranges to ban manually. In the interface, you can then choose how drastically you want to use the blacklist: ban everything or just ranges automatically created for you. The default settings should keep you reasonably safe.
• A white list allows to override the blacklist. The white list is totally controlled by you, and is quite useful to remove  false alarms raised when using the most drastic options from the blacklist system
• Optionally, you may request some friends to be white-listed before connection. This is a very secure option, but it is painful to use for friends who do not have a static IP. So this option can be switched for each friend independently.
• Once connected using a secure authenticated channel, friends exchange their effective address of connection. If a friend reports to you a contact address that is different than what your Retroshare node thinks its own external address is, a warning is raised in the news feed. This very efficiently detects traffic forwarding. However, false positive warnings will be raised when your IP is changing and a friend connects before Retroshare has figured it outs. Just keep an eye on them.

When many IPs in the same range are reported as suspicious by the DHT, Retroshare automatically creates banning rules for them in the black list. When you’re sure of them, the safe move is to make them permanent (by selecting them, adding a comment and submit them to the black list). To avoid traffic forwarding with 100% efficiency, either require all peers to be in the white list, or use a TOR hidden node.

Under the Hood – New Back-end

The GXS cache system

Forums, channels, posted and identities are all handled by a common back-end system called GXS (General eXchange System), which replaces the old—inefficient—cache system based on file transfer. GXS improves over the old cache system in many ways:

• cache metadata is stored encrypted, using the sqlcipher library.
• the cache uses a differential update system which only transfers what’s needed. As a result the network load due to cache exchanges is  limited to the bare minimum.
• cache storage is much more efficient than in v0.5 and shouldn’t be a problem any longer.

The basic brick of the GXS system is Groups, which is used to represent all actors: forums, identities, channels, etc. It’s quite a complex system which will require a blog post in itself.

The global router

The global router is a passive decentralised data routing system, which securely brings data from one Retroshare Identity to another. It is asynchronous and redundant, which means that you do not need the source and destination of a data packet to be simultaneously online.

The routing mechanism mixes two redundant system: tunnels provided by the anonymous tunnel system (also shared with distant chat and file transfer) and friend-to-friend routing, based on the so called “routing matrix” that encodes for each peer the best friends to which a packet to a given Identity should be sent. The construction of the routing matrix is achieved as forum/channel post signers get known: a friend sending a signature from a given identity will be more likely to be used as a route toward that particular identity.

The global router is currently used to send distant messages between Retroshare Identities. It can also be used by new services installed by plugins, since only the source and destination of a packet need to be able to handle its real content. The global router ensures authentication and encryption of the data that is sent.

Work plan

Our workplan is the following:

• implement identity circles. This is actually almost done. Retroshare still needs a way to encrypt the data that is restricted to a circle of identities in a reliable way. The rest of the software already has what’s needed to manage access rights based on groups. This is currently all hidden in the GUI to avoid confusion with unfinished stuff.
• implement new differential file list system and get rid of the old cache system. The current file list system is the last bit of Retroshare that uses the old cache system. We would like to get rid of it, and take that opportunity to re-design the file list exchange in a way that is more responsive and more efficient. Basically we’re aiming at a differential update using a priority list that would ensure that when you’re browsing friends’ files, they get updated first.
• IPv6 support. This is almost done and preliminary experiments are very encouraging. We still need to make the whitelist/blacklist system compatible with IPv6.
• add a serious video codec to VOIP. Our video codec now is based on encoding each frame in JPEG, which is quite a shame. We need to plug in a x264 codec. If anyone wants to help us with this, we would be eternally grateful. This is not a difficult task since it will not require to understand the Retroshare back end. It needs some knowledge on how to use the codecs and good programming skills. If you feel like doing it, contact us!
• use our own DHT, where we can add a bit more authentication between peers, so that it is not possible to perform large scale traffic forwarding attacks.

Conclusion

As you can see, we have been quite busy. I would like to thank the many contributors to this great project for this step. Beyond the official developers who devote a significant part of their life making the things happen (coding, packaging, debugging, etc) we are constantly encouraged and given very useful feedback by many devoted testers (Special mention to Jolavillette, ASmith), some of which submitted very good patches (Special thanks to Cave, Chozabu, G10H4ck, Henry, Phenom, Sehraf, … please forgive me if I forgot any of you!). Many thanks also to Beluga for the new web site!

We provide builds for windows and all supported Ubuntu. Still missing are builds for Debian (Will be very soon hopefully) and some special distribution-architecture combinations such as debian+arm. Unfortunately we don’t have MacOS builds at this time either, but we’re working on it.

Since this release contains many new features, and we obviously cannot test all configurations, we partly rely on you to send us as much feedback as needed to improve this release candidate 1. We’ll publish an improved version soon based on what feedback we get.

We hope that Retroshare-0.6 will be a step forward to our ultimate goal: providing a social network that can avoid surveillance. It is designed to be powerful and safe, but we cannot ensure you that it is perfectly secure either. So use it wisely!