-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement dynamic loading of Tor Hidden Service Keys #13
Comments
You've filed this issue for whenever Tor implements a control-protocol method of setting private keys for hidden services? Or does such an option already exist? Presumably this could be done with a new option like HiddenServicePrivateKey or something that contained the key data. Would a workaround not be to put the tor config -- or at least the hidden service dir -- in a ramdisk (encrypted, even)? Or in a file wrapped by a FUSE encrypted filesystem? |
Hi Meejah, yes, this ticket is for future reminder about all the projects that will require actions when the Tor ticket will get implemented. The workaround you refer can work only with: The concept was to implement a generic method to load keys via Tor CP into Tor. The pain is that it's required to make a TorCP change proposal, submit it, have review, then implement it., then have it reviewed. |
Wait, i got an idea. What if we make Txtorconn:
That way txtorconn would be able to provide an abstraction layer over the weak handling of TorHS keys, basically using mkfifo (fifo / named pipes) as a filesystem I/O bridge between txtorconn application logic (providing the TorHS key) and Tor binary. So the TorHS private key will never be written to the filesystem in unencrypted format, like tor currently does. What do you think, it's worth experimenting it? |
On unix the standard os module os.mkfifo already does provide the facility to create FIFO: On windows is it possible to use python to create named pipes (windows equivalent of unix fifo): Additionally on Windows named pipes can be created with gnuwin32 utils mkfifo create named pipes: http://gnuwin32.sourceforge.net/packages/coreutils.htm |
Example in using Named Pipes on Windows with Python for Wireshark captures http://wiki.wireshark.org/CaptureSetup/Pipes |
Named pipes using Twisted http://twistedmatrix.com/pipermail/twisted-python/2003-May/004111.html There's also txnamedpipes (for windows only, it looks like). |
That ticket is blocked by defect https://trac.torproject.org/projects/tor/ticket/6044 as reported by meejah |
what's going on is that file_status() returns FN_ERROR on FIFOs, and (even if it didn't) read_file_to_str() uses fstat() to figure out the size beforehand, which for FIFOs is 0. I am working on a patch for this, although I don't have a windows machine so don't know how to make it work there (or maybe it already will!). The "no such file or directory" stuff from the pad is a red herring as that's leftover from other stat or open calls as tor starts up. |
Will provide a windows machine to test integration with Windows Named Pipes both of Tor and Txtorcon patchset |
On Tor there's someone that recently pushed a patch to be reviewed doing that feature for handling TorHs via TorCP: https://trac.torproject.org/projects/tor/ticket/6411#comment:6 |
I think this Tor Project ticket is related to this github issue: Maybe we can together work on the little-t tor code changes... like we did last time! |
Actually, see https://trac.torproject.org/projects/tor/ticket/6411 it seems there is other interest in this, and a patch in-progress to add controller commands to allow applications to directly add hidden-service keys they manage themselves. There would be txtorcon work when 6411 is done: augmenting TorConfig to generate keys and use the new commands to add/remove these hidden services. One open question would be whether it makes sense to have TorConfig.hiddenservices contain both "permanent" and "ephemeral" hidden services, or to have two lists... |
@meejah I think that once the Tor-code to load with Tor CP is Ephemeral itself, TxTorCon shall provide ephemeral support for key too, leaving to the application logic the handling of the key material. |
@fpietrosanti Hopefully generating RSA keys is well understood by this point. The format the WIP code expects is just a Base64 string containing the PKCS#1 style DER encoded private key, which is fairly ubiquitous (It's the text that appears between "-----BEGIN RSA PRIVATE KEY-----" and "-----END RSA PRIVATE KEY-----" with the newlines stripped). As I noted in the bug, there's sample code at https://github.com/yawning/orkey that does this correctly (though Go provides both RSA key generation and an ASN.1 DER encoder as part of the runtime). Open design questions (some mirrored from the tor side bug, though if people are talking here, I might as well ask again):
There's no particular rush from my side, since this missed the 0.2.6.x feature freeze date, and it will be a while before 0.2.7.x. |
See branch https://github.com/meejah/txtorcon/tree/yawning-feature-6411 (yawning-feature-6411) which can be used along with @Yawning's branch for Tor's #6411 (https://trac.torproject.org/projects/tor/ticket/6411) to try all this out. |
@meejah has this feature been merged in txtorcon? As we're now finally considering using it in GlobaLeaks /cc @evilaliv3 |
Yes, you can pass keys directly to a new enough Tor with the The API will likely change slightly in 1.0 as I've unified all the various hidden-service options in that branch. But, nothing drastic. |
Following the implementation of Tor's Ticket https://trac.torproject.org/projects/tor/ticket/5976 this ticket is to implement proper txtorconn functionalities for:
This ticket is also referenced by globaleaks/APAF#27
The text was updated successfully, but these errors were encountered: