how?
As an additional security measure, B could live behind a firewall that only let connections to Tor nodes. (yup, it might be a PITA to set up.)
Shouldn't be hard to create a script to generate e.g. iptables rules that permit connections to Tor public relays.
The security benefit is a bit marginal, though. The public relay list is basically world-writable.
But that raises another point I'd neglected. On the Tor gateway, you can block access to the public internet by anything other than the Tor process.
The security benefit against maliciousness is iffy, since the most likely route of compromise for a Tor gateway that's been set up with even a little care is the Tor process, but it certainly reduces the chance of accidents.
Bugs can exist even in code most of us would consider trivial. The Tor daemon is definitely not trivial, and the project itself points out that it needs work![1]
Here[2] is "just" container.c from the Tor project. It's one very small part of the project that does fairly simple things any professional developer ought not have much trouble understanding.
It's almost 1600 lines. Are you telling me you can guarantee there are no bugs of potential security significance in that file?
They also want to make Tor even more multithreaded than it already is[3]. Threaded code never has bugs, right?
Any software is a potential attack vector. Tor is no different.
[1] https://www.torproject.org/getinvolved/volunteer.html.en#tor...
[2] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/common/...
[3] https://www.torproject.org/getinvolved/volunteer.html.en#use...
You could probably proof it from anything but business-level error.
Not the OP, and I don't know much about Tor's protocol, but at a guess one might start with deliberately malformed layers of the onion, so you route through a Tor entry node, the outer onion layer is removed, then the packet is forwarded to a Tor relay.
The Tor relay then unwraps the next layer of the onion, but the data within that layer is deliberately malformed to trigger a bug in the Tor code running on that relay.
Ideally you actually place the HSB and TG in different network segments so packets from the HSB must pass through a router to get to the TG and vice-versa, ensuring a compromised HSB has no possibility of sniffing any incriminating broadcast traffic to/from the TG.