I don't think we should ever add a wildcard feature it seems very risky. Even if there are no dangerous Tor HS commands now this may change in the future. The point of a whitelist was to prevent the problem of unforeseen extensions to the protocol having negative security implications.

The safest option is to hardcode the ports needed by any Tor based software we want to support and to only enable this subset of the whitelist when a user explicitly switches on a boolean on the Gateway.

No wildcard feature would almost equal a wontfix for Ricochet (T444), onionshare, and potentially other software (bitcoin, globaleaks, securedrop).

It's not just about the port number. That would be too simple.

See https://gitweb.torproject.org/torspec.git/tree/control-spec.txt and have a look at the syntax of the ADD_ONION Tor control protocol command. The command will be used by Ricochet / onionshare / etc. to create a Tor hidden service without using the file system. I.e. not using /var/lib/tor on the gateway to store the hidden service key.

Example:

ADD_ONION RSA1024:cryptographic-key-long-blob-of-binary-data Port=80,192.168.1.1:8080

I see. Then as long as wildcards can be safely implemented even if something like ; is around it should be OK.

What about the other point about making this part of the whitelist need activation by the user? The idea is for defense in depth so only some of the users would be affected in the unlikely chance there is something instead of all Whonix installations.

HulaHoop (HulaHoop):

What about the other point about making this part of the whitelist
need activation by the user? The idea is for defense in depth so only
some of the users would be affected in the unlikely chance there is
something instead of all Whonix installations.

Yes.

(At time of writing, none of the tickets does argue about allowing
'add_onion *' by default to make onionshare etc. work out of the box.)

A related point is, if adding a Tor hidden service from a compromised
Whonix-Workstation (add_onion) raises more risk than a compromised
Whonix-Workstation without add_onion capability.

After looking at the spec I think the protocol has the ; equivalent CRLF. Carriage Return and Line Feed signifying newline. \n \t \r and \0 ... \377 are treated as C escapes (Section 2 is of interest).

Also relevant is multiline commands support with '+' characters.

I think these could allow combining different commands with negative effects we are trying to block.

Can you please post examples of multi lined commands?

The only generic example I can find:

Command = Keyword OptArguments CRLF / "+" Keyword OptArguments CRLF CmdData

Did you manage to get a non-generic, specific to work? I.e. do you have
an actually working example?

Once we have examples for every cases, we can handle those in the code.

The only example I can find in the spec:

"650" "+" "HS_DESC_CONTENT" SP HSAddress SP DescId SP HsDir CRLF Descriptor CRLF "." CRLF "650" SP "OK" CRLF

but note that the clockskew command uses an escaped +. Understanding the spec is over my head and it would be better to consult TPO directly with these questions and the TAILS guys since they have a shared interest in this.

I tried posting this message to the Tor developer's list yesterday but it was rejected:

Control port filter and wildcards

At the moment we are implementing support for whitelisting wildcards in the controlport filter to support Onionshare and Ricochet.

Does Tor's control protocol actually support something like ; ? If it does, then this would complicate the wildcard feature.

If we whitelisted the wildcard add_onion *, we don't want it to match some hypothetical feature add_onion * ; .... I.e. not add_onion * ; GETINFO address.

(If it was the case, then we would have to limit the wildcard (*) from example SETCONF HiddenServicePort * to exactly one [numeric] argument etc. Or better, correctly parse multi lined commands.)

Rejected? Not signed up for the list or rejected by a human list manager? I'll work on an improved version of the draft.

Posted on tor-dev:
https://lists.torproject.org/pipermail/tor-dev/2016-January/010158.html

Roger said per mail, 'there isn't any ";" support in the control protocol.'