3 posts tagged with "haven"

• Introduction
  • Wait, I can't run Haven on mobile?
• Notes
  • Notification if contact's fingerprint changes
  • Find/add contacts
  • Supported push notification services
  • Legal jurisdication
• Conclusion

Introduction​

Today I forked and published a comparison of various messengers. Why?

Because as the author of the original comparison can't possibly include everything (he actually checks and compares all those details, which requires non-trivial efforts) and he focuses on major messengers so Haven't currently isn't included. (He welcomes requests, so you could suggest Haven - Haven't (pun intended).)

Not having a mobile version probably doesn't help.

Wait, I can't run Haven on mobile?​

As of today, yes. I mean, you can run Haven on mobile Android and Linux devices with WASM-capable browsers, but the UI isn't responsive and it doesn't attempt to save battery, so it won't be pretty.

xx Messenger was a mobile app that would probably have done well in a comparison, but it used an older xxDK and is no longer maintained.

Haven is the main reference application for xx Network confidential & private messaging. There's a patch for responsive UI which was delivered as part of Hacktoberfest 2024 activities, but it hasn't been merged yet. Keep an eye on that in coming weeks - if merged, that would make Haven more suitable - although just the UI - for Android browsers with WASM support.

Anyway, back to the main topic, which is I wanted to create a post with some notes regarding the Haven column in that comparison page.

Notes​

These are notes that clarify some of the values I picked for the Haven column in that comparison chart.

Notification if contact's fingerprint changes​

Most people have tried Signal. If you swap your phone or such, your Signal chat counterparts will be informed that your "fingerprint" changed. There's no such thing on cMixx (and in Haven).

Haven identity is the only user-facing cryptographic identity.

You can't ""change" a fingerprint or anything like that. If you lose access to your identity (forget the password to encrypted identity file, or lose the identity file), you must assume a different identity. In that case there's no mechanism for you to rejoin a private Space (1-on-1 or group chat) and message contacts saying "this identity replaces this other identity". Who can tell if that's the same person?

If you have backups of the invite links and pass phrases you can rejoin those spaces using the new identity. But there's no way for others to know if the new identity is owned by the same person.

The only way to do this is to use the old identity to message everyone "from now on, I'll be using this new identity".

Another way is to use an external identity service where people can look up identities you claim on xx Network. But that assumes they know your external identity.

Find/add contacts​

See the previous point - there's no name service in Haven, so you can't "find" anyone.

You can use external identity services mentioned just above.

xx Messenger had this custom IDs, but Haven does not. Personally I don't miss those - I think external ID services are the way to go because messenger contacts are just one of many things you need to have an address book for.

Since Haven is one of few messengers that is anchored in a blockchain, knowing someone's cMixx name is not enough. We want their wallet addresses (probably not just for xx coin, but for several currencies), their ENS name, and other public Web3 data they choose to publish.

Why you can't "add" contacts either? Well, we'd need to sync them somewhere. xx Messenger could upload (backup) its data to S3, so contacts could be saved as well.

xx Haven currently doesn't do that so contacts must be searched in external services where people publish their Haven identities. That location is a matter of choice as well - not just in terms of usability, but also privacy, cost, and more. Having to publish your data on ENS (and pay that fee) may or may not be liked by all users which is why I think Haven should leave those integrations to other cMixx messengers when they appear. I don't mind looking it up in whatever way is convenient for me and my contacts.

Supported push notification services​

xx Messenger used a centralized push service, but Haven doesn't currently doesn't have it which means it's limited to constant polling which is power-consuming.

That doesn't matter much for desktops (there's more "unnecessary" activity from Cover Traffic than from notifications), but matters on mobile devices.

Legal jurisdication​

The xx Foundation is a non-profit in the USA.

Mixnet round scheduling is done by the Foundation and that server is - if I'm not mistaken - in located the EU. The scheduling node isn't involved in data handling.

Client-side ecrypted user data has five copies per each cMixx round and so user data from each conversation lives in dozens of jurisdications (see the cMix dashboard). The scheduling server doesn't know which messages went into which mixnet round - only the sender and recepient(s) do, so those not included in a conversation wouldn't even know where encrypted data is.

Encrypted data is kept on cMixx gateways for 21 days after which only local (cached) copies may remain on participants' clients.

Conclusion​

I obviously don't speak for the author of the original document, so the values I picked for Haven are my own.

This post elaborates on all the rows where I felt felt sharing some notes would be helpful. If the original author reviews and adds Haven to his document, I may or may not update my fork (I wouldn't if I completely disagreed with this evaluation, for example).

I have some other comparisons in other blog entries - you can search the site for "comparison" to find them.

security.txt​

The Dutch Digital Trust Center mandates that all government sites must have a security files under the .well-known directory located at the root of Web site.

Use cases:

• Go-to place to get information on how to report vulnerabilities affecting the site or organization
• Improve the speed of getting in touch

Example​

https://www.ncsc.nl/.well-known/security.txt captured on Jun 1, 2023.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Domeinen van de Rijksoverheid kunnen met een 302 redirect verwijzen naar
# het centrale bestand op https://www.ncsc.nl/.well-known/security.txt
# omdat het NCSC het centrale meldpunt is voor kwetsbaarheden en incidenten
# voor de Rijksoverheid.
#
# Dutch central government domains can redirect to the central file located
# at https://www.ncsc.nl/.well-known/security.txt with a 302 redirect,
# because NCSC-NL is the central point of contact for vulnerabilities and
# incidents for the Dutch central government.

Expires: 2024-01-31T22:59:00.000Z
Canonical: https://www.ncsc.nl/.well-known/security.txt

Policy: https://www.ncsc.nl/contact/kwetsbaarheid-melden
Policy: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd

Contact: https://www.ncsc.nl/contact/kwetsbaarheid-melden
Contact: https://english.ncsc.nl/contact/reporting-a-vulnerability-cvd
Contact: mailto:security@ncsc.nl
Encryption: https://www.ncsc.nl/contact/pgp-key
Preferred-Languages: nl, en

Acknowledgments: https://www.ncsc.nl/wall-of-fame
Hiring: https://www.werkenvoornederland.nl

-----BEGIN PGP SIGNATURE-----
Version: Encryption Desktop 10.4.2 (Build 1298)
Charset: utf-8

wsDVAwUBY+9c0P4Vd0fJc7lbAQpUmQwAwZ1vWyI1VKBChsciufRcvxy5zzMZMx6v
YjD5CXuDV4GL+tRl7wClnQO023e3ZChTH69y7O3veS+5/zNVUvpyqJfS8pNzG0pA
B4vea3fQ41t5UpCVYvPopIFiT1oeQJA9w4NqBD2+2jW5lS5L8k9xz192gWJvhxq8
mTukJXYDiJLzxKbUMHEG2GNaMeoRj5Pvgr8buzQELP0VZHfzF05Hr6NOoWvS6SRX
KGW6rgg6fEUPcMTjBqn6gL/w82FXwrh93AmYkP/sBWP4It3NpbiNuazc5iynhhih
+ZlfzsFV6agF4MZR0IQZ6X4jsCxKFrPIWW51/7W+PIDkqy6za/bDjDeiinid0HOC
2rro6N9FXSyxHz9nteMppd+YMTCt+Z67HONsssR+7ojxORGOs0rTcjUucaVikFJQ
wAls9p+vuIzFRViQaXe3Nndspr1cCIu4z3ZfdkcWREQP7acOjNgbmeQOlH4jnYWq
lNVMWzOncidAWM0nXcuYTjZagRAagthF
=yC4A
-----END PGP SIGNATURE-----

Use case for Haven​

• security.txt is PGP-signed to confirm that it was signed by the key owner and that's fine. But in reality most people hate to use it to compose emails or messages
• it is time-consuming for the recipient to download every sender's key which also delays reading encrypted messages
• Haven gives the reporter anonymity, both parties enjoy encryption and privacy, and can interact in real time (and still move to email if they so choose)
• Haven uses quantum-resistant encryption (I haven't checked, but it should be superior to PGP)

Haven public chat link can be added to security.txt. Example:

Chat: https://.............. (security vulnerabilities only)
Contact: email - mailto:.........; chat - send DM to `aCertainTestifier`
Encryption: https://www..../contact/pgp-key

Because public chat could have several permanently present strangers in it, direct messages (DM) should be sent to contact person.

What are the weaknesses of using Haven here?

The way I see it, the biggest is that xx Network keeps messages for 21 days and then they disappear. To prevent the situation where nothing happens for three weeks and messages disappear, the reporting person should move on to email if no response is received within hours.

With time, spam may become a problem for Haven. But it is already a problem for email now, so Haven is not worse.

Conclusion​

Haven uses xx Network to store encrypted messages and Haven users can connect to xx Network from any (trusted) application server - whether it's container on own desktop client, the official Haven instance, etc.

Compared to an email or Web service as means of communication, Haven is less likely to be affected by a vulnerability at the same time as your corporate email or Web service, so it is a cost-free, "out-of-band" solution that's more resistant to unplanned concurrent downtime or DDoS.

Haven gives you zero maintenance, quantum-resistant encryption, superior privacy (compared to email and PGP), and far more convenience.

Containerized or non-containerized Haven​

It's probably easier to run Haven in a container. If you have Docker or Postman and want to run Haven in a container, try this.

In the case you want to self-host a non-containerized Haven, read on!

Home or cloud​

You may install Speakeasy at home or in the cloud.

Haven Web server doesn't hold any data but its OS and Node.js logs may store client IPs, that's all.

With that in mind, some high-level considerations would be:

• We don't want our Speakeasy Web app or underlying OS to get compromised
• If your Haven is not open to public, or is accessed "by invite" (maybe with basic authentication or VPN, for your family and friends), you may run it at home
• If your Haven is located in the cloud, that's acceptable as long as you can protect it from getting compromised so that application code doesn't get replaced, OS compromised, or visitors' IPs leaked.

Regarding this last point, if you feel comfortable hosting your Haven server in a small (1G RAM) VM, it is better to open it to public to have the Web server accessed by a variety of addresses. As long as you know how to protect the VM.

Software and hardware requirements​

Use a Linux OS or VM, x86_64 or ARM64 architecture. Haven's hardware requirements are minimal:

• 1 vCPU
• 1 GB RAM
• 3 GB disk

All Haven app/web server does is serve the app to the client(s) and that's one-time download from each client (around 100 MB download).

One vCPU is enough and won't be significantly utilized except when Node.js builds the application or when container image is updated - that takes a long time (15 minutes), but has to be done only when Haven code is updated or rebuilt.

Install Node.js​

On generic Linux OS, follow installation instructions for Node.js version 16.14 or above.

This post was prototyped on DietPi Linux, which currently uses Node.js 20. On DietPi, you may install Node.js as follows:

sudo dietpi-software install 9

Or, run dietpi-software, select Search software, search for Node.js, and proceed with installation.

Deploy and run Speakeasy​

We need to pick a directory for the application, clone the source to that directory, change some parameters and install.

sudo mkdir -p /usr/src/app/speakeasy/.next

If your username is joe, you could run it as such. Otherwise, create a non-sudoer account and use that.

sudo chown -R joe:joe /usr/src/app/speakeasy

That should allow you to run the rest without using sudo.

Next, clone the Haven source code, change configuration parameters and run it.

git clone https://git.xx.network/elixxir/speakeasy-web /usr/src/app/speakeasy
cd /usr/src/app/speakeasy

Pick Haven Web application port​

Most Node.js apps traditionally use port 3000, but you'll need something else if you have another app using that port.

Pick a port for Haven, such as 7080, and use it consistently later:

sed -i 's/next start/next start -p 7080/g' package.json
sed -i 's/const nextConfig = {/const nextConfig ={\\n  productionBrowserSourceMaps: true,/g' next.config.js
rm -rf node_modules && npm install -g npm@9.6.5 && npm install && npx next telemetry disable && npx next build

If that went well, you can try to start it from the same directory.

npm start

Check if Haven is up and running by going to http://${SERVER_IP}:7080. You may need to open OS firewall for that. Example for Ubuntu:

sudo ufw allow 7080/tcp

Since that port doesn't need to be exposed when Speakeasy is running behind HTTPS proxy, it is advisable to delete the rule after testing the application.

sudo ufw status numbered

You won't be able to do much with Speakeasy running at http://host:7080 because there's no reverse HTTPS proxy in front of Speakeasy. If you attempt to create an identity you will get stuck at the Find your Codename step.

Assuming the rules for 7080/tcp are number 7 and 8, and your HTTPS reverse proxy will run on the same host, you can delete the rules: sudo ufw delete 7 ; sudo ufw delete 8.

The right firewall port to open on the host would be whatever port is used by your HTTPS reverse proxy (e.g. 14443).

Reverse HTTPS proxy​

Deploy reverse HTTPS proxy in front of Speakeasy so that external port is forwarded to Speakeasy's application port (example: https://fqdn:14443 -> http://localhost:7080). To use 14443/tcp, open that firewall port on external network.

sudo ufw allow 14443/tcp

Now configure HTTPS reverse proxy to forward incoming 14443/tcp to 7080/tcp, and if you wish make HTTPS reverse proxy and Speakeasy Web app start (npm start) automatically.

For that you may use Caddy, Traefik, NGINX or other.

There are many ways to deploy each reverse proxy and at the same time there are no Speakeasy-specific steps here, so the details are an exercise for the reader. Find and try the official or community examples for your proxy and Node.js.

Custom port, host or path​

In the case Speakeasy is the only application proxied by HTTPS reverse proxy, it is most convenient to expose it at https://host:443.

In the case the same HTTPS reverse proxy is used for several applications, Speakeasy can be hosted in a directory (or, more complicated, at a dedicated virtual host name or FQDN).

TLS certificate​

In any and all cases, your reverse HTTPS proxy would need a TLS certificate.

If your reverse proxy integrates with Let's Encrypt, you could expose reverse proxy (and indirectly Speakeasy) to the Internet rather than use internal or even self-signed TLS certificate - it's more secure, especially if you additionally protect HTTPS proxy with firewall rules or basic (or other) authentication.

Haven Web server doesn't host any account or chat data. If you expose Speakeasy to the Internet, the main concern is to prevent NodeJS from application server take-over and tampering, so it can be advantageous to run it using a limited local account, and optionally add some form of authentication to your HTTPS proxy.

Once a TLS-enabled proxy is functional, you can access Haven, create a new codename or import existing, and start using Haven.

Update Haven​

As mentioned before, Haven can be simply wiped and re-installed because only serves the application code and does not store any client data.

The official instance (haven.xx.network) normally runs the latest version, so visit that site from time to time, or watch the Speakeasy repository for new releases, or follow xx Network on Twitter.