[tor-bugs] #7098 [Tor]: Add safe-cookie authentication to Extended ORPort and TransportControlPort

[Tor Bug Tracker & Wiki]

#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