Skip to content

Arti does not support hostnames in proxy_ports config

Summary

The proxy_port config only supports IP addresses, not hostnames.

Having it to work for hostnames would be useful, like in containerized environments.

Steps to reproduce

  1. Build and Arti container with --features=onion-service-service.
  2. Try with the following configuration:
[onion_services."default"]

proxy_ports = [
    ["80", "httpd:80"],
]

Minimum Reproducible Example

Using either Docker or Podman:

  1. Build and Arti container with --features=onion-service-service:

    • Either use this example with podman build -t arti:alpine.
    • Or pull an image with podman pull containers.torproject.org/tpo/onion-services/onimages/arti:alpine.

  2. Create the following configuration file (onionservice.toml):

[onion_services."default"]

proxy_ports = [
    ["80", "httpd:80"],
]
  1. Create a network and setup a backend HTTP server:
podman network create onionservice
podman pull containers.torproject.org/tpo/onion-services/onimages/httpd
podman run -d --net onionservice --name httpd httpd
  1. Run Arti from the container, adding it to the onionservice network, so the httpd host is reachable:
podman volume create arti
podman run --rm -it --net onionservice --name arti \
  --mount type=volume,src=arti,target=/home/arti \
  --mount type=bind,src=onionservice.toml,target=/srv/arti/configs/onionservice.toml \
  arti:alpine

What is the current bug behavior?

Arti refuses to start:

podman run --rm -it --net onionservice --name arti \
  --mount type=volume,src=arti,target=/home/arti \
  --mount type=bind,src=onionservice.toml,target=/srv/arti/configs/onionservice.toml \
  arti:alpine
arti: error: read configuration: Config contents not as expected: Couldn't load configuration: Could not parse onion service target type "httpd:80" for key "default.onion_services.default" in srv/arti/configs/onionservice.toml TOML file

What is the expected behavior?

It would be expected to have a normal bootstrap sequence:

podman run --rm -it --net onionservice --name arti \
  --mount type=volume,src=arti,target=/home/arti \
  --mount type=bind,src=onionservice.toml,target=/srv/arti/configs/onionservice.toml \
  arti:alpine
2025-04-02T11:24:31Z  INFO arti::subcommands::proxy: Starting Arti 1.4.2 in SOCKS proxy mode on localhost port 9150 ...
2025-04-02T11:24:31Z  INFO arti_client::client: Using keystore from "/home/arti/.local/share/arti/keystore"
2025-04-02T11:24:31Z  INFO tor_hsservice: Generated a new identity for service default: [scrubbed]
2025-04-02T11:24:31Z  INFO tor_hsservice: Launching onion service nickname=default
2025-04-02T11:24:31Z  INFO tor_hsservice::ipt_mgr: HS service default failed to select IPT relay: error: bad or insufficient netdir: No directory information available
2025-04-02T11:24:31Z  INFO tor_dirmgr: Didn't get usable directory from cache.
2025-04-02T11:24:31Z  INFO arti::socks: Listening on [::1]:9150.
2025-04-02T11:24:31Z  INFO arti::socks: Listening on 127.0.0.1:9150.
2025-04-02T11:24:31Z  INFO tor_dirmgr::bootstrap: 1: Looking for a consensus. attempt=1
2025-04-02T11:24:31Z  INFO tor_hsservice::ipt_mgr: HS service default failed to select IPT relay: error: bad or insufficient netdir: No directory information available
2025-04-02T11:24:31Z  WARN tor_chanmgr::transport::default: Connection to [scrubbed] failed: error: Network unreachable (os error 101)
2025-04-02T11:24:32Z  INFO arti::reload_cfg: Successfully reloaded configuration.
2025-04-02T11:24:34Z  INFO tor_dirmgr::bootstrap: 1: Downloading certificates for consensus (we are missing 9/9). attempt=1

It would also be expected that the Arti container would pass requests to the httpd container.

The expected bootstrap happens when httpd is replaced with an IP like 127.0.0.1, but it's difficult to track which IP a backend currently have, especially with containers.

With C Tor, this is possible with HiddenServicePort 80 httpd:80 (check the Onimages README for a working example).

Environment

  • Arti version: 1.4.2.
  • Operating system:
    • Host: Debian GNU/Linux 12.10 (bookworm).
    • Container: Alpine 3.21.3.

Possible fixes

While strict validation of proxy endpoints is desired, the requirement for only valid IP addresses could be relaxed, allowing for hostnames (but not invalid IPs).