sd-proxy: set up onion service authentication (Restricted Onion Service)

[deeplow]

In order to access the journalist interface's onion service, we need to setup authenticated onion services with arti. This requires two things:

1. Choose key format
2. Configure chosen format on-boot via qubesdb (similar to whonix-config)

From the docs:

From C Tor to Arti

Partially works:

• Arti can use existing C Tor keys.
• Arti uses the SSH format.
• Migrating keys from C Tor to Arti's format is still not available, but
  needs to be implemented at some point, so Onion Service Operators can fully
  migrate their services to Arti.

Issue tracking progress on the conversion tooling is available at https://gitlab.torproject.org/tpo/core/arti/-/issues/860

Background on Key Format Options

1. Arti key store- stores keys in OpenSSH format. There is probably a way to convert it but it's not yet implemented (worked tracked here)
2. ctor format - is supported in arti, but as of writing this is marked as __is_experimental in cargo.toml.

Options

1. ctor format + conversion to arti format:

• (-) official conversion tool not yet available (can we do it via CLI tools somewhat like this)

2. ctor format:

• (+) Should already be working
• (-) is experimental, but does this compromise affect security or just stability

3. arti format + ask admins to regenerate keys

• (+) More future prone - eventually we'll want admins to generate keys with arti and this way we never have to support two configuration formats
• (-) Requires admins' time and attention
• (-) Arti key generation seems is not in by default (arti hsc), it's probably experimental.

[legoktm]

Since we want Arti to be a drop-in replacement, I think we want to keep storing the ctor format in config.json/dom0/QubesDB. So +1 to Option 1, by e.g. having the whonix-config replacement reformat it into the SSH format Arti wants. (AIUI we just need to decode the existing private key and then encode it as a PEM.)

[deeplow]

I had apparently missed the above message

Per discussion with @kunal, we should look into `option 1.` potentially with some python code. There was already some similar effort done for the server. If possible build on top of that, otherwise just implement it from scratch.

[lsd-cat]

It's being worked as part of this year gsoc, and it seems part of it got pushed and merged today.

• https://gitlab.torproject.org/hjrgrn/arti/-/commit/b6c4ba8ad6a69f39eb475eb7eaf077ed69325890
• https://gitlab.torproject.org/tpo/core/arti/-/issues/?sort=created_date&state=closed&search=ctor%20keystore&first_page_size=20&show=eyJpaWQiOiIyMDcyIiwiZnVsbF9wYXRoIjoidHBvL2NvcmUvYXJ0aSIsImlkIjozMzQzNjF9

[deeplow]

I was taking a look at it today. Even though it seemed promising and very timely, unfortunately (for us) the focus on the ctor keys conversion seems to be only for onion service server keys (implemented under the arti hss command), rather than the clients aspect (which would have been under arti hsc -- hidden service client).

According to the gsoc plan, we're now at the end of the "keys migration" deadline and I don't see this in the part of the open issues. So I suspect this is out of scope for the gsco.

Following this, here are our options, as I see them

1. Implement it ourselves as an upstream contribution (requires rust / crypto know-how)
2. Wait for this to be implemented (The closest issue is Write a CLI for generating keys and certificates", but unclear if this is in scope or planned)
3. Defer instead to ctor keys, but seek to clarify how experimental they are (implemented 9 months ago, as of writing)

[lsd-cat]

I worked with some assistance on a quick python script for conversion, which we can use on the fly as we get the key from QubesDB and setup the arti config. I tested it a bit today and seems pretty reliable to me.

https://gist.github.com/lsd-cat/d3bd05412d83628be7145462081462f9