So this feature sounds similar to an idea discussed before: whitelisting connections to specific onion addresses. I want to think through this idea and its benefits before opening a ticket because it may not be worth it.
Now testing: Oz sandbox restricts app connections to .onion servers only. Useful for @coyproject, Ricochet. Maybe “TLS Guard” wrong name
The feature description is unclear but if all onion addresses are allowed then an attacker can just setup a hidden service and connect to it.
But lets assume some situations where specific addresses can be whitelisted and see if that feature is useful.
(Note: Ricochet is used as an example. Its very securely coded in reality and confirmed so by an audit.)
Threat models:
-
(No address connection restrictions): The container/VM starts off in a clean state and is dedicated to running say Ricochet to connect to some contacts only.
-
A contact is malicious and attacks the IM peer - is then able to extract information from the victim via itself (because it would be whitelisted).
Result: This would happen under the restricted outbound traffic access model anyway.
- (With address restrictions): Ricochet is running in a shared VM with other programs running.
Result: No browsing would be possible in this VM. So no infection/exfiltration would happen but then that’s the same as running a clean Ricochet VM with no restrictions and using it for that purpose only. Restrictions not useful here.
- (No address restrictions) Apparmor/container/sandbox around Ricochet and TBB. TBB is exploited and can only read limited folders that do not include the IM program.
Result: Limited effect of compromise but not due to network restrictions.
- (Address restrictions) Ricochet dedicated VM. Trusted contacts but no Onion client authorization enabled. Hypothetical bug in Ricochet. Malicious HSDir sniffs address and then scans and exploits Ricochet.
Result: I’m actually unsure. This may be a situation where limiting outbound can stop data pilfering. Because its an Onion service anyone can connect so inbound access is still possible. Which could establish bidirectional communication. What I saw when testing was: if a HS with client authentication connected to a non authorized client - bidirectional communication became possible even without authorization becuase the HS initiated contact. This is different though because outbound rather than inbound is restricted.
- Kiosk access. well this only works if users are dumb. With physical access to the machine - this can easily be circumvented.
Code of interest if we decide it worth it: