[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 asn):

 Replying to [comment:3 rransom]:
 > Replying to [comment:2 rransom]:
 > > If you can use e.g. a 64-byte file with a 32-byte constant header for
 your protocols, you can use something a little simpler and nicer (perhaps
 using the 32-byte secret from the file as the HMAC key, and putting the
 protocol-identifying and âclient-to-serverâ-versus-âserver-to-clientâ
 static string(s) in the HMAC message).
 >
 > On actual thought, if you put a header in your cookie file, you can just
 use it as a plain client-to-server password.  You wouldn't have to worry
 about breaking other systems that happen to use 32-byte secret keys, and
 the âsafe cookieâ protocol doesn't defend against MITMs anyway.
 >
 > Someone should figure out and specify what security properties these
 protocols actually need.


 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
 + don't leak file contents to potential attackers
 + be resistant to 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?

 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.

 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.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7098#comment:4>
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