Thanks Tom and Alec,
I am working on a UX architecture for the Bisq Project [https://bisq.network/]. This is a decentralised P2P crypto / fiat exchange.
The threat model is two-fold:
1) A real time event driven MVC for a GUI front-end to a remote API over TOR hidden service. The client owns the server (it is their personal Bisq instance) , it is not a public web service model.
2) Bisq 's infrastructural backbone runs as a P2P network over TOR network. Clients talk to each other and there are various hidden services providing network resources. I am hoping that websocket can improve network performance.
On 6 March 2018 at 16:55, Michael Jonker <michael@openpoint.ie> wrote:--
I have connected to my hidden service with RFC 6455 web-socket and feel like a kid in a candy store streaming API requests and return data back and forth at good, reliable speeds.
Yay! Good to hear news of new successes. I found websockets a bit messy to approve (it seemed that one of the TBB security plugins got in the way?) but once they were approved, it was fine.
My concern is that I am missing something here.....
My mental model is that, once the connection and http upgrade request is established, TOR sees this as a long running http request and will will not close the circuit or change the route until the either side breaks the connection.
That is my understanding, too.
I would appreciate if someone could comment:
1) Am I correct in my mental model?
I have the same model.
2) Am I perpetrating a security anti-pattern by holding the connection open indeterminately?
I would say 'no', but then you have not stated a threat-model yet. What are you trying to achieve, and what are the capabilities of your threat actors?
-a
_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions