Thanks Tom and Alec,

I am working on a UX architecture for the Bisq Project []. 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 < <>> 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?



tor-onions mailing list

tor-onions mailing list

Reply via email to