Обновить

New life for XMPP. Making a messenger that can't be blocked

Время на прочтение 4 min
Количество просмотров 49K


The idea of ​​making a P2P messenger independent from corporations is not new, but developing a new protocol and client applications for it is quite an expensive and lengthy process. What if you use the good old XMPP, in which everything has long been thought out and filed?


But this is not a real peer-to-peer, you say, for XMPP to work you need your own server and domain. This is true, but we can run the server on localhost, and to communicate with the servers of other users use a hidden service in I2P virtual network. Using I2P will save us from having to pay for a domain with hosting, and will also protect our communications from criminal online surveillance.


Thus, we get:


  • Hybrid P2P messenger that can be run on both user devices and a full-fledged server.
  • Features that other P2P messengers lack: offline messages, storing contacts and history in the cloud, working with several clients with one account.
  • Ready-made client applications for every taste.
  • Due to the use of I2P, it is invulnerable to various *supervisions (sorry for the swearing).

Let's get down to implementation...


Installing I2P and creating a server tunnel


In this guide, we will use a lightweight C++ client as an I2P router i2pd. Installation instructions are in documentation.


After installation, we create a server I2P tunnel - this is a virtual address through which our XMPP server will be accessible to the rest of the world. To file tunnels.conf add the following lines:


[prosody-s2s]
type=server
host=127.0.0.1
port=5269
inport=5269
keys=prosody.dat

[prosody-c2s]
type=server
host=127.0.0.1
port=5222
inport=5222
keys=prosody.dat

If you plan to use it only on a localhost, you don’t need to add the prosody-c2s section. Reboot i2pd to apply the settings. We look for the I2P address of the created tunnel in the web console http://127.0.0.1:7070/ On the page I2P tunnels.



You can also find out the b32 address of the new tunnel by grabbing the logs:


grep "New private keys file" /var/log/i2pd/i2pd.log | grep -Eo "([a-z0-9]+).b32.i2p" | tail -n1

Save this xxx.b32.i2p address, this will be the domain for your XMPP server.


Installing and configuring XMPP server


We will use as an XMPP server prosody, it is the lightest and there is a ready-made module for it to work via I2P. The installation is described in the official documentation, in Ubuntu it’s easy to do apt install prosody.


For work mod_darknet you need the lua library bit32. If you have lua version less than 5.2 (most likely) we perform apt install lua-bit32.


Installing the module mod_darknet. It is needed for prosody to make outgoing connections through the Socks5 i2pd server. Download this file to the prosody modules directory, usually this /usr/lib/prosody/modules.


Now we edit the /etc/prosody/prosody.cfg.lua config. Replace xxx.b32.i2p to your address:


interfaces = { "127.0.0.1" };
admins = { "admin@xxx.b32.i2p" };
modules_enabled = {
    "roster"; "saslauth"; "tls"; "dialback"; "disco"; "posix"; "private"; "vcard";  "ping";  "register"; "admin_adhoc"; "darknet"; 
};
modules_disabled = {};
allow_registration = false;
darknet_only = true;
c2s_require_encryption = true;
s2s_secure_auth = false;
authentication = "internal_plain";

-- On Debian/Ubuntu
daemonize = true;
pidfile = "/var/run/prosody/prosody.pid";
log = {
    error = "/var/log/prosody/prosody.err";
    "*syslog";
}
certificates = "certs";

VirtualHost "xxx.b32.i2p";
ssl = {
    key = "/etc/prosody/certs/xxx.b32.i2p.key";
    certificate = "/etc/prosody/certs/xxx.b32.i2p.crt";
}

The last step in setting up prosody is generating encryption certificates. In niks it is done like this:


openssl genrsa -out /etc/prosody/certs/xxx.b32.i2p.key 2048
openssl req -new -x509 -key /etc/prosody/certs/xxx.b32.i2p.key -out /etc/prosody/certs/xxx.b32.i2p.crt -days 3650
chown root:prosody /etc/prosody/certs/*.b32.i2p.{key,crt}
chmod 640 /etc/prosody/certs/*.b32.i2p.{key,crt}

Reboot the prosody server to apply the settings.


A slight digression is needed here. In the I2P network, any connections are end-to-end encrypted and, it would seem, additional encryption is unnecessary here. But, in practice, it turned out to be easier to generate keys than to try to configure all programs to use plaintext. You can try, but I warned you.


Creating accounts and connecting clients


Adding an admin account:


prosodyctl adduser admin@xxx.b32.i2p

Now we configure the XMPP client (for example Pidgin).



If you are connecting to a localhost, then in the client settings we specify the connection to the server port 127.0.0.1 5222.



If you connect to the server remotely via I2P, then specify Socks in the proxy settings5 127.0.0.1:4447.



If everything is done correctly, you will be able to add other users to the I2P federation and chat with them. It is also possible to configure your already running server on the regular Internet to correspond with servers inside I2P. To do this, all other users will need to add mapping for your domain to their prosody config. For example, this is how I did it to communicate with the server i2p.rocks:


darknet_map = {
    ["i2p.rocks"] = "ynkz7ebfkllljitiodcq52pa7fgqziomz4wa7tv4qiqldghpx4uq.b32.i2p";
    ["muc.i2p.rocks"] = "ynkz7ebfkllljitiodcq52pa7fgqziomz4wa7tv4qiqldghpx4uq.b32.i2p";
}

That's all. Happy chatting!

Tags:
Hubs:
Всего голосов 42: ↑40 и ↓2 +38
Комментарии 58
+58

Comments 58

New life for XMPP. Making a messenger that can't be blocked

The main thing is that none of the US protesters use this messenger. Otherwise there will be “Russian hackers”, “the hand of the Kremlin”, “new sanctions against the Russian Federation”, “expulsion of diplomats”»,…

At a minimum, XMPP is an already well-known standard with a bunch of clients for many platforms.


By the way, please tell me why you made a link to one of the closed messenger channels, instead of a direct link to the official website https://matrix.org/blog/home/?

a well-known standard with a bunch of... shortcomings
A UFO flew in and published this inscription here

This trivial task is remarkably solved with the help of two extensions: XEP-0313 (Message Archive Management) and XEP-0280 (Message Carbons).

A UFO flew in and published this inscription here

You have some outdated information. From servers it is supported at least in ejabberd, from clients - at least in Gajim, Xabber and Conversations.

Prosody also supports.
We tried to launch matrix.org and liked its Riot Web client. I can’t say anything about the protocol itself, maybe there are some advantages, but they are not so obvious.

It was not possible to create a federation within I2P, as far as I remember, the federation protocol is strictly tied to DNS and for the darknet you will have to make some crutches.
A UFO flew in and published this inscription here
Well, in general, of course, I use the matrix and I like it, but I must say that maintaining your own federation at the moment is a very expensive pleasure, because... this is tons of data in the database and tons of consumed RAM, in short - “fat”. And an XMPP server, even if you pick up a new one with half a kick, costs almost nothing. Plus there (in the matrix) there are still problems with identity servers, in general this is a topic for a separate study, and, as far as I know (I superficially follow all sorts of weekly video reports from developers, see the “matrixdotorg” channel on YouTube), now it’s impossible to work normally raise a matrix instance completely cut off from other federations (see “anally guard yourself”), unlike XMPP, but they are working on it. To begin with, developers must finally finish the “dendrite” - a “synapse” rewritten in Go, and “synapse” is a matrix server written in Python and which is very greedy for the frame from the very nature of the piston, one of my friends from the Internet, by the way, I put my matrix instance down for an indefinite period, because... it just didn’t fit into the frame, with the words: “well, I don’t have 4 GB of extra frame.” My verdict is that it’s too early to talk about starting your own matrix federation with half a kick and long-term planning for the amount of data that will need to be stored and processed in real time.
I also forgot to say that of the desktop clients that you can use, I found only a couple - this is Riot, which is essentially a web browser, with all that it implies, including gigabytes of consumed frame, when you have more than 150 rooms in which you are a member ( I personally have a lot of rooms bridged on freenode in profile chats, yes, the matrix can be used as an IRC client for freenode with free offline logs), as well as nheko, which is actively being sawed by the maintainer, but is still very limited in functionality and basic does not handle disconnections well; for example, there is no support for e2e encryption, and encrypted rooms created by Riot simply cannot be read.

When will you master telepathy? She certainly won't be blocked

Telepathy seems to be a high-level library, it not only supports XMPP, why even raise the question that it could be blocked? It's the protocols that block, not the implementations, which is what I'm doing wrong?
upd: I understood exactly what we are talking about telepathy.freedesktop.org/components?

I guess it was sarcasm after all :)

Why won't they block it? It's very easy to block. Everyone will be required to wear tin foil hats - and here you have a blocking of telepathy.

Kyu!
made from Telekill™ alloy
It feels like the article ends at the most interesting part. Where is the description of the mechanisms of interaction between different servers?
If everyone has their own local server, how to find other users?
Or this
all other users will need to add to their config
— inevitability? Then it won't take off, as it seems to me.
I agree with you, the article turned out to be purely practical. Perhaps it is worth supplementing it with theory or writing separately about the insides of such a system - how I2P tunnels work and how servers interact via mod_darknet. If I have time, I'll finish it.

how to find other users?

Just like they do in regular instant messengers - whatsapp, telegram, etc. Here your jabber id acts as a user identifier.

it won't take off, it seems to me.

These, it seems to me, are minor things. What is more important to take off is a ready-made client application, in which all configuration is reduced to a minimum. And it’s quite possible to do this, all programs are open source. If they were collected into a ready-to-eat product, it would turn out to be candy.
Almost none of the non-TI people will go through the configs and add something there.
I2P in enter-exit mode is also not very good - it wants long and thoughtful work.
For this whole plane with pools and everything to take off, it should work out of the box without a file on any rotten lines (I regularly visit places where 1 kb per minute - for happiness).
And for identification, you need to use the combination of zhber-id + server_address (no one thinks that everyone will be on the same home server, which turned off and that’s it) and how will this be looked at for memorization / dictation, especially over the phone?
What didn't you like about Tox??

Antox for example works very poorly. Freezes and glitches on video and audio calls. Messages are often not delivered even though it is enabled on both devices. We have to use shamanism so that both clients see each other online and exchange messages.

Well, wait until the project is completed tox-rs/tox, rewriting in Rust.

A few years? :(
Arris A couple of years have passed…
humbug Have you given up or are you continuing slowly??

Another thing is that the budget has run out, and now it is being finished in lazy mode.

I’m the only one who doesn’t understand, what does p2p have to do with it? Yes, there are a lot of servers, and it’s easy to set up, but this is a slightly different principle than p2p, each server has its own lists of users. Unless you make a single “blockchain” with a list of ALL users)), but as far as I know, this is beyond the scope of the xmpp standard specifications.

I didn't understand either. Perhaps the author meant decentralization? But jabber itself is decentralized, like mail.
And you can run a server on any network, even on the Internet, even in a local area, even through hiddenservicec in Tor. The only problem is that it will only be possible to communicate with clients from the same network.
Most XMPP implementations go beyond the standard specification.
Each server has its own lists of users

But the servers communicate well with each other (as in, for example, email).
For XMPP, for so many years, it’s not that they haven’t written sane clients, but... compare the convenience of the regular official Telegram client, and everything that has been built for XMPP over the years!

Personally, I am sure that at one time XMPP lost the battle for users, incl. and in this.
Oh yes, contacts constantly jumping back and forth in the list, the need to know the phone number to rename these same contacts, the lack of groups of these same contacts, the lack of support for TeX, trim() in code blocks (due to which the exhaust uniq -c, framed in ```, always looks crooked), a huge pile of other unpleasant little things and the ability to use stickers about your favorite soda - this is just the height of convenience!>

Although all those Telegram users I know really think that this is an order of magnitude more convenient than IRC or XMPP, they themselves cannot really explain why..
Yeah, but with such a literally boorish approach, they won’t. :3
Perhaps standardization - for the average user it’s easier to install one application, enter a phone number and start communicating.

I can, but let's talk in private. I'm not talking about stickers, but about convenience. Today, of the old ones, only Miranda can be used (as it was possible then).

The regular official Telegram client appeared already in the era of dominance of new interfaces.

If the XMPP client were being created now, it would look much more beautiful.

If the protocol were done now, I think it would also be more interesting. But I'm not talking about beauty, about convenience.

The Psi client was quite convenient. True, it ultimately weighed 120 megs, because... was pulling some kind of goofy library with it (QT it seems)…
Let me remember: an archive of messages in the form of html, viewing the archive for each day (i.e., to find something sent a year ago - just grep in the files), and a lot of shortcomings in the UI - it’s not that good, it’s a little not the only one, but not the best (it’s like second place with the number of participants = 1), and certainly not to be compared to him. One joy is that it is built on purple, as almost all the others are built on it. And, yes, it is possible to use all the variety of possibilities that XMPP can theoretically provide, but it is very complicated.

He consumes resources like crazy, he does a little - a typical client from eight years ago. Compared to Miranda, he always looked like a half-baked product made by programmers-not-designers. It's a pity that Miranda is not available for Linux.
Made haphazardly - you're right.

In general, it had two versions - the new one, with QT and weighing about 120 megs (I won’t say anything about the resource gluttons) and the old one, weighed 20 meters. Also a lot, but not 120.

An archive of messages in HTML form is not so bad. This is actually good if you think about it. Better than plain text, IMHO.

QIP Infinium generally had an archive of messages in a closed proprietary encrypted format.

At that time he was the best of what there was (not counting Miranda, but I could never get used to her).

However, telegram is not that convenient either.

Limitation on copying 100 messages at a time, no export of chat history to a file - well, what good is this in 2018???
He also eats up resources like crazy.
A UFO flew in and published this inscription here
Explain to me why creating an open source and encrypted messenger is so difficult? There are a huge number of good open source programs. There are mega-sophisticated bitcoins and all sorts of i2p networks. Why is there no normal messenger??
What's stopping you from taking an email protocol, adding encryption to it, making a beautiful interface with visualization of the delivery process and chats instead of a list of letters??
Are there any fundamental difficulties when writing an open source messenger? or there is no need for a messenger?

Yes, precisely that there are fundamental difficulties. A messenger that no one uses is of no use to anyone. Therefore, the most important thing in the messenger is advertising, not code. Unfortunately.

There are some fundamental difficulties when writing an open source messenger?

I think that the fundamental principle “it will do” is getting in the way. For example, the author, he’s great, he wrote a large detailed article, told where and what commands need to be executed, where in what configs what to fix. But what next? Which telegram user will collect logs, and, most importantly, why? In order for there to be even the smallest, most microscopic chance of takeoff, you need a ready-made solution that can be installed with one button on all platforms, proven a thousand times, and tested in the most unimaginable configurations. But this is not the case. Because it will do anyway.
The reason is also that modern instant messengers are largely mobile instant messengers. During the first years of Skype, there were desktops that had no problems with traffic and power consumption. The peer-to-peer scheme worked through supernodes. And even then there were centralized authorization servers. Now smartphones are behind NAT (CGN) and firewalls, they need an external relay. They do not last long on a single battery charge and even for this reason cannot be relays. Smartphones are on packages with limited traffic - the third reason.
That is, the feast-to-feast scheme does not work.
The messenger infrastructure for hundreds of millions of users is quite expensive.
Promotion is expensive.
So it turns out that the main market is in the hands of very large and very financial players.
I think the point is that there is not even a theoretical chance of making money on this, and there is a shortage of enthusiasts, the guys started making Tox, but then it died out.
Due to the use of I2P, it is invulnerable to various *supervisions (sorry for the swearing).

But here, unfortunately, you are wrong. i2p is well protected (but by no means invulnerable) from internal surveillance, which is not at all included in the actions of the RKN. A feature of RKN is blocking, and blocking i2p is quite possible - just block reseed servers and limit access to receiving lists of floodfill routers - and i2pd simply will not establish communication with initial peers.

We hope that Telegram is slowly working on the mechanism of invulnerability to blocking, etc..

Why not just write software that uses what already exists? Messenger, mail. Let it hang in memory and sniff the text typed by the user in the messenger input field and, when you click “send,” cut it out, encrypt it and paste it back into the input field or steganograph it into a random picture. Or even if it has its own interface, it will only send encrypted information using any other service.

IN GnuPG you can encrypt the text with the interlocutor’s public key and send it in any way.

with the key

1) keyOm;
2) no text is ever encrypted with a public key, especially in GnuPG.

the interlocutor’s public key + your private key. What's wrong?

no text is ever encrypted with a public key, especially in GnuPG

Can you tell me more from now on??

Only full-fledged users can leave comments. Sign in, Please.