[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7098 [Tor]: Add safe-cookie authentication to Extended ORPort and TransportControlPort
#7098: Add safe-cookie authentication to Extended ORPort and TransportControlPort
------------------------+---------------------------------------------------
Reporter: asn | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-bridge | Parent: #4773
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by rransom):
Replying to [comment:4 asn]:
> If we are to create a new protocol, maybe we should keep the security
properties of the safe-cookie protocol. That is:
>
> + authenticate client and server based on the contents of a file on the
local filesystem
This is important, but can be done easily by using a secret string stored
in the file as a password.
> + don't leak file contents to potential attackers
> + be resistant to cross-protocol attacks
These features were only important in the control-port safe cookie
protocol because (a) controller implementers had already implemented âsend
the contents of an arbitrary file over a socketâ bugs, and (b) cookie
files were headerless, and thus could be confused with real secret keys
(e.g. Curve25519 or ChaCha or HMAC-SHA-256 keys).
If you put headers on your cookie files, you don't have to use such an
ugly protocol to resist cross-protocol attacks.
> Similarly, we should probably not try to solve the
integrity/confidentiality problem and instead let an SSL layer handle it,
if there is a need.
>
> If we add a header to the cookie file, what do you imagine having in
that header? Maybe the type of cookie; what else?
Include the socket address(es) which a client should consider sending the
cookie to, and possibly an integrity-check field (plain SHA-256 of the
rest of the file? HMAC of the rest of the file with some fixed constant
string?).
> Also, is there a reason for the cookie to be of a specific size, or can
it be the rest of the cookie file after the header? We are going to send
it hashed on the wire anyway.
The reason that the original cookie authentication protocol required the
cookie to be of a specific size (starting sometime late last year) is that
I freaked out at the thought of Vidalia sending someone's secret keys to
whatever socket it connects to, and I didn't think anyone would use
32-byte keys to store real secrets at the time. The reason that the safe
cookie authentication protocol requires the cookie (''and the server
nonce'') to be of a specific size is so that the HMACed âmessageâ strings
would be uniquely parsable as cookie..client_nonce..server_nonce without
having to add length fields (and specify e.g. byte order).
If you still want your protocol to involve an HMAC, you can use the cookie
as the HMAC key instead of including it in the message; in that case, if
you really want to teach clients to read a variable-length cookie (and
presumably a length indication) (while resisting timing attacks on the
parsing gunk) rather than a fixed-length fixed-offset field, you can
indeed use a variable-length cookie.
> As for the protocol we might want to keep the safe-cookie protocol, but
change it aesthetically and make it easier to parse. The safe-cookie
design seems solid and resembles the HTTP digest authentication.
I thought HTTP digest authentication could (optionally?) be bound to (i.e.
authenticate) requests too.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7098#comment:5>
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