[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6411 [Tor]: Adding hidden services through control socket
#6411: Adding hidden services through control socket
-------------------------+-------------------------------------------------
Reporter: | Owner:
kevinevans | Status: needs_revision
Type: | Milestone: Tor: unspecified
enhancement | Version: Tor: 0.2.3.19-rc
Priority: normal | Keywords: hidden-service control maybe-
Component: Tor | proposal tor-hs globalleaks-wants
Resolution: | Parent ID: #8993
Actual Points: |
Points: |
-------------------------+-------------------------------------------------
Comment (by yawning):
So, I said I'll look at this the other day in IRC.
Replying to [comment:11 meejah]:
> 1. create a hidden-service private key (without touching the
filesystem). This could be a command-line option to tor (e.g. like --hash-
password) that dumps to stdou or a controller command (e.g.
"CREATE_HS_KEY" that returns the key-blob).
>
> 2. add an HS private key to a running Tor.
>
> a) To fit in with the other HiddenService* options, it would probably
make sense to have something like "HiddenServicePrivateKey" or similar
that can take some kind of single-line giant-string representation of the
private key. So this would be done via a SETCONF.
>
> OR b) a separate command that sets all the options at once or something
for a hidden service (which is sort of what the above is?).
This is "b".
> For both the above, you still need some way to get the .onion address --
either the controller has to write compatible code that derives from the
private key, OR there's a controller command (e.g. some GETCONF thing?)
that can tell you the .onion for a given hiddenservice.
I think for ephemeral hidden services, the key management and generation
should be the application's problem. That allows the app to persist it's
HS key on it's own if it want's to. Deriving the onion address from the
public key is trivial as well.
{{{
ypres :: ~ % go get github.com/Yawning/orkey/or-key-tool
ypres :: ~ % ~/.local/go/bin/or-key-tool
File: - N/A (Generated) -
Type: RSA1024 Private Key
Fingerprint: 3B414C1DBF3638F47F946B8906D09D53FBB1F21C
Identity (Base64): O0FMHb82OPR/lGuJBtCdU/ux8hw=
Onion Addr: hnauyhn7gy4pi74u.onion
-----BEGIN RSA PUBLIC KEY-----
[Redacted Base64 encoded blob]
-----END RSA PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
[Redacted Base64 encoded blob]
-----END RSA PRIVATE KEY-----
ypres :: ~ %
}}}
[Snip]
> OR you use a controller that knows how to speak the "set up a hidden
service" commands, which would all be new. There's then also the matter of
"what's the unique name of a hidden service?" which is currently "the
hidden service dir" but of course that doesn't make sense if there isn't
one at all.
This seems the simplest. I don't see what's wrong with using the onion
addr to refer to each HS... For something that's easy to do, and only
requires a control spec patch:
For the controller:
* `ADD_EPH_HIDDENSERVICE KEY_TYPE PRIVATE_KEY [virtport targetAddr]...` -
Initializes a hidden service, using the `KEY_TYPE` private key
`PRIVATE_KEY` (so, something like "RSA1024 [Base64 encoded blob]"), with
the HiddenServicePort list as specified. (Key type is specified as a
future-proofing measure).
* `DEL_EPH_HIDDENSERVICE ADDR` - Removes the hidden service `ADDR`.
Open questions:
* `HiddenServiceAuthorizeClient` is kind of annoying, so I'm going to
ignore it for now.
* Is it unreasonable to expect people to be able to generate an RSA1024
key, and compute/encode the digest? I'm inclined to think that the added
application flexibility here is worth forcing that onto the app code (and
crap app code that doesn't generate keys properly get what they deserve).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6411#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs