Hi Bjarni,
If the user IP is not used/exposed, how could it serve as a Tor bridge or middle node better than if you install Tor on all your front-end proxies?
That is kind of what I am asking you guys, I am not sure it would - I'm basically experimenting with this because Linus thought it might be a useful tech to get more people involved in the Tor network.
It is exposed as the traffic exits the node, and the Tor traffic would
travel from the front-end over the Pagekite tunnel to the actual relay,
it's just doing so over a tunnel which may carry other stuff as well:
Why would you want to run multiple bridges on one shared IP?
Even with Pagekite, that would be a rare case - you might end up with one IP as a shared "entrance" for multiple nodes, but the exit to the next hop would happen in many different places. The CPU required for the encryption and decryption would be spread over all the "back-ends", so if that were a bottleneck (which it probably isn't) that could be a benefit too.
Having thought about this a bit more, I do think it could be worthwhile for Tor to allow this kind of use-case though (controlling the SNI name), but not specifically for Pagekite. If you can make it such that one can very early at the application layer tell the difference between Tor connections and other TLS connections, it would become possible to host normal SSL web-sites *on the same IPs and ports* as Tor relays. This would mask the Tor input traffic even further.
Assuming IPs continue to become a more scarce resource and SNI becomes more widely supported technology, name-based virtual hosting of SSL sites will eventually become common. If a Tor entry point could be come "just another virtual SSL host", that would allow it to blend in much better.