Opened 4 years ago

Last modified 4 years ago

#18020 new enhancement

RFE: Introduce privsep to secure OS and hidden service keys

Reported by: jirib Owned by:
Priority: Medium Milestone: Tor: very long term
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: privsep
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


I'm not sure if anything has been implemented to prevent running tor process to read hidden service private key after (not during) startup or to browse OS filesystems.

For example after heartbleed issue OpenBSD has implemented couple of another protection layers to restrict a running daemon using private keys to be read them after startup.

This is commit message from OpenBSD's relayd (load-balancer) so you can get an idea what is the reason:

Introduce privsep for private keys:

  • Move RSA private keys to a new separate process instead of copying

them to the relays. A custom RSA engine is used by the SSL/TLS code
of the relay processes to send RSA private key encryption/decryption
(also used for sign/verify) requests to the new "ca" processes instead
of operating on the private key directly.

  • Each relay process gets its own related ca process. Setting

"prefork 5" in the config file will spawn 10 processes (5 relay, 5
ca). This diff also reduces the default number of relay processes
from 5 to 3 which should be suitable in most installations without a
very heavy load.

  • Don't keep text versions of the keys in memory, parse them once and

keep the binary representation. This might still be the case in
OpenSSL's internals but will be fixed in the library.

This diff doesn't prevent something like "heartbleed" but adds an
additional mitigation to prevent leakage of the private keys from the
processes doing SSL/TLS.


Thus it would be nice if tor would privsep so a new tor process could not access the key directly.

Privsep would also help people in the future to "sandbox" logical functionality of tor (eg. OpenBSD's pledge, seccomp etc...), so it would not be possible for example to browse whole OS filesystem etc. in the future.

Child Tickets

Change History (4)

comment:1 Changed 4 years ago by jirib

Component: - Select a componentTor

comment:2 Changed 4 years ago by yawning

Milestone: Tor: very long term
Version: Tor: unspecified

Triaging. It's worth noting that as of 0.2.7.x, HS keys do not need to ever be on the filesystem, since HS creation via the control port is supported.

A lot of these things would be good ideas for long lived cryptographic material in general, but it's unlikely for the work to happen prior to tor being refactored into a more modular design.

comment:3 Changed 4 years ago by nickm

We also support offline ed25519 identity keys as of 0.2.7, and prop224 will get support for other methods of offline HS keys.

That said, I'd love to get support for more sandboxing in Tor.

comment:4 Changed 4 years ago by jirib

Hm, after watching it seems valid naming would be 'broker design'. Anyway above url has nice ideas and describes technically the reason for this RFE (opening unrelated files on filesystem, etc...).

Note: See TracTickets for help on using tickets.