nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-24 04:13:28 +01:00
Code Issues Packages Projects Releases Wiki Activity

Update control-spec.txt; some minor changes; more thoughts on authentication

Browse Source 
svn:r2665
This commit is contained in:
Nick Mathewson 2004-11-03 19:57:43 +00:00
parent cea9125d71
commit 65b4c6b830
1 changed files with 31 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
doc/control-spec.txt
View File

@ -19,8 +19,8 @@ forward-compatible.
TC is a bidirectional message-based protocol. It assumes an underlying
stream for communication between a controlling process (the "client") and
a Tor process (the "server"). The stream may be implemented via TCP,
TLS-over-TCP, a Unix pipe, or so on. For security, the stream should not be
observable by untrusted parties.
TLS-over-TCP, a Unix-domain socket, or so on. For security, the stream
should not be observable by untrusted parties.
In TC, the client and server send typed variable-length messages to one
another over the underlying stream. By default, all messages from the server
@ -76,14 +76,17 @@ the message.
3.4. GETCONF (Type 0x0003)
Request the value of a configuration variable. The body contains a
nul-terminated string for a configuration key. The server replies with a
CONFVALUE message.
Request the value of a configuration variable. The body contains one or
more nul-terminated strings for configuration keys. The server replies
with a CONFVALUE message.
3.5. CONFVALUE (Type 0x0004)
Sent in response to a GETCONF message; contains a nul-terminated key string
and a nul-terminated value string.
Sent in response to a GETCONF message; contains a list of nul-terminated
key strings followed by nul-terminated value strings.
[XXXX note that you'll get more keys than you expect with things like
loglevel.]
3.6. SETEVENTS (Type 0x0005)
@ -143,8 +146,27 @@ the message.
4. Implementation notes
On Unix, we should use a named pipe on the fs and use filesystem privileges
to authenticate. On Win32, a password/magic cookie may be in order.
There are four ways we could authenticate, for now:
1) Listen on 127.0.0.1; trust all local users.
2) Write a named socket in tor's data-directory or in some other location;
rely on the OS to ensure that only authorized users can open it. (NOTE:
the Linux unix(7) man page suggests that some BSDs don't enforce
authorization.) If the OS has named sockets, and implements
authentication, trust all users who can read Tor's data directory.
3) Write a random magic cookie to the FS in Tor's data-directory; use that
magic cookie for authentication. Trust all users who can read Tor's data
directory.
4) Store a salted-and-hashed passphrase in Tor's configuration. Use the
passphrase for authentication. Trust all users who know the passphrase.
On Win32, our only options are 1, 3, and 4. Since the semantics for 2 and 3
are so similar, I'm recommending that we not support 2, and just always bind
on 127.0.0.1. I've implemented 3 and 4; 1 would be trivial. -NM
-----------
(for emacs)