[tor-bugs] #7098 [- Select a component]: 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:       
Component:  - Select a component  |        Version:       
 Keywords:                        |         Parent:  #4773
   Points:                        |   Actualpoints:       
----------------------------------+-----------------------------------------
 Safe-cookie authentication makes sure that the control port is only
 accessed by clients that are aware of a secret cookie.

 We should also protect the Extended ORPort and the
 TransportControlPort in the same way, to make sure that only legit
 pluggable transport proxies can access these ports.

 Looking at control-spec.txt, it seems that the safe-cookie
 authentication protocol follows the protocol format of the control
 port protocol. Also, `control.c:handle_control_authchallenge()` is
 designed specifically for control-port connections and cannot be used
 in other parts of the codebase as it is.

 This leaves us with (at least) three options:

 1) Abstract `handle_control_authchallenge()` a bit, so that it's usable
 by other parts of the codebase too. Modify the code as little as we
 can, and leave it using the control-spec protocol format.

 Pros:
 + We get to use safe-cookie auth in the transport ports, and maybe
 in other ports in the future.
 + Refactoring `handle_control_authchallenge()` will be as easy and
 painless as we can.

 Cons:
 + The safe-cookie authentication protocol will have the format of
 the control port, which will make it look funny when used in
 front of other ports.

 2) Abstract handle_control_authchallenge() so that it can be used as a
 generic local-system authentication mechanism for Tor. This
 involves removing all the control-port stuff from the protocol
 (including the '250' return codes), simplifying the HMAC-SHA256
 static strings, and making a beautiful API for the authentication.

 Pros:
 + We get to use safe-cookie authentication in the transport ports.
 + We get a flexible local-system authentication mechanism that can
 also be used nicely in the future when Tor's architecture becomes
 modular.

 Cons:
 + It will require some aesthetic refactoring of the safe-cookie
 authentication protocol, and writing some spec files.
 + The implementation will be more troublesome than 1).
 + We will need to provide backwards compatibility for the current
 safe-cookie authentication protocol.

 3) Make a new variant of safe-cookie authentication protocol for the
 transport ports. The protocol of the new variant will resemble the
 protocol of the Extended ORPort and the TransportControlPort.

 Next time we need a local-system authentication mechanism, we will
 have to make yet another variant of the safe-cookie authencation
 protocol.

 Pros:
 + We don't get to abstract anything, and we simply copy/paste and
 edit code. We also get to use safe-cookie authenication in
 transport ports.

 Cons:
 + Next time we need a local-system authentication system we will
 need to redo this.

 ----
 I haven't looked at the safe-cookie code enough to decide how easy it
 is to be abstracted, but I'm drifting towards 1) or 2).

 If we agree that safe-cookie authentication is a reasonable protocol
 to protect any future Tor ports (we will have more of them as Tor
 becomes more modular, won't we?), then maybe we should do 2) and
 future-proof ourselves.

 What do you say?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7098>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online