PostgreSQL Database Access via Tor Hidden Service

The configuration is straightforward: PostgreSQL listens on localhost:5432 (default, no public exposure). Tor is configured with a hidden service pointing to localhost:5432. Clients connect to the .onion address via a Tor SOCKS proxy. The PostgreSQL client (psql, pgAdmin, Sequelize, SQLAlchemy, etc.) must support SOCKS5 proxy configuration for this to work. In torrc: HiddenServiceDir /var/lib/tor/postgresql/ and HiddenServicePort 5432 127.0.0.1:5432. The .onion address is in /var/lib/tor/postgresql/hostname. Share this address with authorized clients along with standard PostgreSQL credentials (user, password, database name). No firewall changes required - PostgreSQL remains bound only to loopback.

Most PostgreSQL clients support SOCKS5 proxy through environment variables or configuration settings. For command-line psql: the PostgreSQL client itself does not directly support SOCKS5, but you can use proxychains: proxychains psql -h youraddress.onion -U dbuser -d dbname. Install proxychains4 and configure /etc/proxychains4.conf: socks5 127.0.0.1 9050. For Python applications using psycopg2 or asyncpg: use the PySocks library to route the connection through Tor. For Node.js with pg (node-postgres): use the pg-socks-proxy wrapper. For pgAdmin: set the connection to use a SOCKS5 proxy in the Connection settings. For SQLAlchemy (Python): create a custom create_engine call with a SOCKS5-wrapped socket factory.

PostgreSQL authentication over Tor: use scram-sha-256 authentication (the most secure option in pg_hba.conf): host dbname dbuser all scram-sha-256. Combined with the Tor hidden service, this provides: Tor-layer encryption (the TCP connection is encrypted through Tor circuits), PostgreSQL connection-level TLS (configure ssl=on in postgresql.conf and provide server certificate), and scram-sha-256 password authentication. Triple-layer security: the database is completely unreachable without knowing the .onion address, and even knowing the address requires valid credentials. Enable PostgreSQL connection logging (log_connections=on) to track who connects. Implement pg_hba.conf restrictions: only allow connections from localhost (127.0.0.1/32) even though Tor connections appear from localhost anyway - defense in depth.

Database operations over Tor are subject to Tor's latency. Impact analysis: query execution time itself (backend processing) is unaffected, but round-trip time for each query operation increases by Tor latency (100-600ms). For interactive queries (single queries with human review between them), this latency is barely noticeable. For applications that execute many rapid queries in sequence (ORM batch operations, reporting queries with many round trips), Tor latency can significantly increase total operation time. Mitigation: use connection pooling (PgBouncer) with a persistent Tor circuit to amortize connection setup cost, batch operations to reduce round-trip count, and use server-side logic (stored procedures, views) to minimize the number of client-server round trips for complex operations.

PostgreSQL replication and backup to remote servers can be routed through Tor. For pg_dump to a remote backup location: pg_dump -h primaryonion.onion -U backupuser dbname | gzip > backup.gz (with proxychains for SOCKS5 routing). For streaming replication to a standby server that is also a hidden service: configure primary_conninfo in recovery.conf with the standby's .onion address and route through proxychains. This creates a replication setup where neither the primary nor standby IP address is exposed - replication traffic flows anonymously through Tor. For disaster recovery, ensure the .onion private key for both servers is backed up separately - losing the key means the .onion address changes and all configured connections must be updated.