Hello,
George Kadianakis wrote:
Nick Mathewson nickm@torproject.org writes:
[ text/plain ] Hi! I thought I'd write this up while it was fresh in my mind. It could be used as an alternative method to the current proposed client authentication mechanism. We could implement both, or just this, or just the other.
My description here will be a bit terser than we'd want in a proper proposal, but I wanted to share it.
This design is based on George Kadianakis's client authentication design; it won't make sense unless you've read it.
OK people,
I have a more mature torspec branch now for your eyes and only. Please see branch `prop224_client_auth_4` in my torspec repo: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_aut...
The changes are based on the feedback and discussion on this thread.
The only real changes from `prop224_client_auth_3` is that it increases the max descriptor size to 50k, and it removes the username/password intro-level authorization.
Please let me know of anything that seems off, or anything that can make the proposal more readable. Otherwise, we should merge this upstream and move forward with fixing the already merged prop224 HSDir code.
Thanks!
It is very good. The hard limit raised to 50k is justified, and excellent to remove the username/password intro-level authorization.
I would like to state, since I seen it in older posts on this thread, that I dislike the idea of generating at client side low entropy ed25519 key pairs based on simple passwords. It may sound simple and good from UX point of view, but we are decreasing the security of a very secure auth scheme with it and enabling an over-the-hand practice that keys come from client to HS and not vice-versa.
My 2 cents here are that keys should always be generated randomly by the HS server, and distributed to clients (I think it's over the hand for the HS server to use keys generated by clients, because the purpose is for the HS server to secure itself against _everyone_ except some users). For this I am thinking of a very simple tool, that reads the auth-client data file in $DataDirectory/ that will just show a table like:
[ADD A CLIENT] HS | client | pubkey | privkey | notes| actions | date [revoke] [change key]
(of course available in console mode also with keyboard shortcuts for commands)
Since we have no real reason to see the privkey of a client ever again at the HS server side (unless the client loses it, but in this case we regenerate fresh keys for security reasons), client privkeys can not be written to disk at HS server side.
For saved authorized clients we display "******" on privkey column. When a client is added, highlight the row with red or something signaling privkey distribution phase and only keep the keys in RAM. After the privkey has been copied and user checked a box with 2 confirmation dialogs that state something like "I have distributed the key to the client and i understand that it will be permanently deleted, and I could need to regenerate the key for this client if he didn't get it." save the pubkey, client name, etc to file and permanently delete the privkey.
If anything happens (client manager app is closed, power failure, reboot, etc.) start over with new key pair. Same when a key for a client needs to change, we only keep the client name from the table and create fresh key following the same protocol.
The client mode of the auth tool will look like:
[ADD An ONION] HS | notes | privkey | actions | date [delete] [change key]
(of course available in console mode also with keyboard shortcuts for commands)
Here the auth tool will only append/modify data from client's torrc.
It's OK to save the privkeys in plain text at client side from my point of view. We could do encryption with a passphrase but it will be annoying: either the auth management tool needs to be a plugin of Tor Browser so that it asks for the passphrase only one time on start / first connection (otherwise is _very_ annoying for UX) - not everyone uses Tor Browser and more important not everyone uses HS for web browsing - maybe it's a ssh server, either the tool itself needs to run in background all the time.