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 06/03/18 17:29, Alec Muffett wrote:
On 6 March 2018 at 16:55, Michael Jonker <michael@openpoint.ie mailto: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
-- http://dropsafe.crypticide.com/aboutalecm
tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions