Add safe-cookie authentication to Extended ORPort and TransportControlPort
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:
- 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.
- 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.
- 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?