Privacy and security

Haven administrators need to consider the privacy and security implications for their users.

Some of the main objectives and concerns are shared below.

But before that, let's see how our deployment choices reflect on Haven users.

Haven from user's perspective

From the user's perspective, Haven infrastructure consists of two types of servers:

• Haven Web server (can be self-hosted, doesn't handle and not in path of messaging data)
• xx Network nodes (hundreds of community-run gateway nodes (see xx Dashboard) which mix, receive and send client-encrypted data)

Connecting to both of these is required to be able to send and receive messages on the xx Network.

How do different approaches compare?

• Use 3rd party's instance of Haven Web server
  • Regular approach: exposes client's IP to the Web server operator and to xx Network gateways.
  • High privacy approach: client may use Socks5 proxy to access Haven Web app and the xx Network gateways. This option hides the client's IP from the Web server operator and also from the community-operated xx Network gateways.
• Use self-hosted Haven Web server
  • Enhanced privacy: this is better than regular approach because the client's IP is known only to community-operated xx Network gateways.
  • Top privacy: host own Web server instance and access the xx Network gateways through the The Onion Router (aka Tor; more secure, but slower) or a VPN (less secure, but faster). This doesn't identify you to Haven Web site owner or 3rd parties as a Haven user and also hides your client IP from the xx Network gateways. Because all traffic is routed via Tor (or Arti) or a VPN, user experience may be impacted depending on use case and network overheads.

If you recall this diagram, a proxy or VPN don't need to encrypt your data (it is encrypted client-side in Haven) or hide connections among chat participants (that's done by xx Network) - it only hides user's 'IP from xx Network and Haven Web app server.

As a Haven administrator we need to check user's requirements and preferences and deploy what's best for our user.

Another look at Haven client's connections to xx Network's cMix service:

• Option 1: route connections via a proxy
  • Pros: hides client's IP address from xx Network's gateway nodes
  • Cons: higher latency, possible timeouts
• Option 2: direct connection to cMix network
  • Pros: fastest performance
  • Cons: xx Network gateway nodes or anyone watching their traffic knows you're using xx Network (but not other details)

Connections to Web servers can also be routed via a Socks5 proxy or VPN:

• Option 3: access 3rd party Haven Web app via a proxy
  • Pros: client's IP address hidden from Speakeaasy Web server's owner
  • Cons: slower application start
• Option 4: access 3rd party Haven Web app directly
  • Pros: fastest application startup
  • Cons: Haven Web server's owner may identify your IP as xx Network user (but not other details, assuming the server is not compromised)
• Option 5: access own Haven Web app (through HTTPS reverse proxy)
  • Pros: does not reveal user's IP address to Haven Web server's operator; lowest risk of server take-over or compromise
  • Cons: requires TLS certificate, reverse HTTPS proxy, Haven Web server
• Option 6: Haven Web server in a VM or bare metal server with Node.js
• Option 7: containerized Haven Web server

What else do Haven admins need to consider?

Client's outgoing network connections

Haven client needs to connect to Haven Web server to download the app (normally, tcp/443 to reverse HTTPS proxy) and then only outgoing connections to xx Network (normally the gateway servers running at tcp/22480, perhaps initially to cMix permissioning, tcp/443).

These may be viewed in the browser or at OS level.

If Socks5 proxy or VPN proxy is used to protect client's IP address, one or both of these connection types may exist only between that proxy and Haven (or xx Network), while client may open several connections to its Socks5 proxy.

Protect Haven Web server from being compromised or taken over

The OS and application administrator(s) aim to keep Haven Web server from being compromised or taken over.

A compromised server may result in code tampering and be used to compromise the clients, leak their IP addresses and more.

Avoid excessive logging

Excessive logging of client IP addresses doesn't protect their privacy.

While that doesn't leak data, it exposes metadata (IP addresses) and may help identify Haven users. (This is still not enough to determine the participants in a conversation, let alone its contents, but slightly increases the risk.)

Client IP addresses may be logged by:

• OS (firewall, likely to log client IP if verbose logging is on)
• Reverse (HTTPS) proxy (client IP is likely to be logged here)
• Haven Web application (unlikely that client IP address-identifying information will be logged here)
• Log, analytics, observability applications (if any logs are forwarded)

Do what you can to minimize or eliminate those.

Remember that each Haven client can use a different (including own) Haven Web server instance, which minimizes the blast radius.

One way to lessen the risk of client IP leaks is to run a public Haven Web server, which means more traffic and potentially other risks, but creates additional noise in terms of clients' IP addresses.

Another is to encourage channel participants to use different Haven servers.