Connection to a hidden service with a RFC 6455 web-socket - advice on risks please
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. 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. I would appreciate if someone could comment: 1) Am I correct in my mental model? 2) Am I perpetrating a security anti-pattern by holding the connection open indeterminately? Thanks in advance.
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 -- http://dropsafe.crypticide.com/aboutalecm
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
On 6 March 2018 at 17:54, Michael Jonker <michael@openpoint.ie> wrote:
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.
At the risk of blowing my own trumpet, I tried writing up suggestions for hardening hidden services to preserve their anonymity: https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-productio... ...although the above was written long before I got seriously into EOTK, and into the amazing benefits of using Unix-domain sockets to connect my webservers and tor-daemons. Aside: the benefits of Unix-domain sockets include: - massively increased resistance to socket-table-filling denial-of-onion-service attacks, and faster recovery times - (probably) lower latency - reduced (but not eliminated) risk of IP metadata leakage of internet address, etc, because less reliance on network addresses But between *that* document, and some of the tech in EOTK, there may be some useful hardening tips for you. - alec -- http://dropsafe.crypticide.com/aboutalecm
Thanks Alec, I am wrapping my head around alot at the moment, yesterday was the first day I had an onion service! I am passing the information and links you have provided back to the Bisq network engineers (this is unfortunately not where I am at). They have asked me to ask here also if, when connected to a hidden service, the circuit becomes "dirty" after default 10 minutes and resets? On 06/03/18 18:55, Alec Muffett wrote:
On 6 March 2018 at 17:54, Michael Jonker <michael@openpoint.ie <mailto:michael@openpoint.ie>> wrote:
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.
At the risk of blowing my own trumpet, I tried writing up suggestions for hardening hidden services to preserve their anonymity:
https://github.com/alecmuffett/the-onion-diaries/blob/master/basic-productio...
...although the above was written long before I got seriously into EOTK, and into the amazing benefits of using Unix-domain sockets to connect my webservers and tor-daemons.
Aside: the benefits of Unix-domain sockets include:
- massively increased resistance to socket-table-filling denial-of-onion-service attacks, and faster recovery times - (probably) lower latency - reduced (but not eliminated) risk of IP metadata leakage of internet address, etc, because less reliance on network addresses
But between *that* document, and some of the tech in EOTK, there may be some useful hardening tips for you.
- alec
-- http://dropsafe.crypticide.com/aboutalecm
_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On Tue, Mar 06, 2018 at 07:27:32PM +0000, Michael Jonker wrote:
They have asked me to ask here also if, when connected to a hidden service, the circuit becomes "dirty" after default 10 minutes and resets?
No, onion services use the opposite logic: once you open a circuit to the onion service, the 10 minute timer starts, and if you open a new stream you *reset* the timer to a fresh 10 minutes. So as long as you keep using it, it will stay open. If 10 minutes pass and you didn't attach a new stream, Tor won't try to put new streams on that circuit in the future (i.e. it will try to open a new one). This 'opposite logic' is actually the same logic that Tor Browser uses for its circuits, since it uses the socks isolation feature where the goal is to separate requests between domains, rather than to separate them between time slots: https://gitweb.torproject.org/tor.git/tree/src/or/circuituse.c#n2713 --Roger
Thanks to all for the wealth of valuable information I have received. I am officially a onion service believer now, and my understanding has grown exponentially! On 06/03/18 19:38, Roger Dingledine wrote:
On Tue, Mar 06, 2018 at 07:27:32PM +0000, Michael Jonker wrote:
They have asked me to ask here also if, when connected to a hidden service, the circuit becomes "dirty" after default 10 minutes and resets? No, onion services use the opposite logic: once you open a circuit to the onion service, the 10 minute timer starts, and if you open a new stream you *reset* the timer to a fresh 10 minutes. So as long as you keep using it, it will stay open.
If 10 minutes pass and you didn't attach a new stream, Tor won't try to put new streams on that circuit in the future (i.e. it will try to open a new one).
This 'opposite logic' is actually the same logic that Tor Browser uses for its circuits, since it uses the socks isolation feature where the goal is to separate requests between domains, rather than to separate them between time slots: https://gitweb.torproject.org/tor.git/tree/src/or/circuituse.c#n2713
--Roger
_______________________________________________ tor-onions mailing list tor-onions@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-onions
On 6 March 2018 at 10:55, Michael Jonker <michael@openpoint.ie> wrote:
2) Am I perpetrating a security anti-pattern by holding the connection open indeterminately?
Unless I'm missing something: no more so leaving a modern web application tab (Facebook, gmail) open indefinitely. Which is to say, WebSockets, Facebook, and Gmail all turn you (the client) into a server. An attacker (which may be the web server you are connected to or which may be an outside party sending messages to you through the server) can choose when and how large a message you will receive. This capability is what makes it particularly difficult to defend against Guard Discovery attacks in Hidden Services, and when you invert the model (where you are the server) it will enable Guard Discovery attacks on you the client. I say this to try to be accurate. I don't say it to discourage you or suggest you shouldn't do this - I think you should. I think it's fantastic that you're working on providing a responsive web experience over a hidden service and I hope to see an awesome deployment or blog post about it in the future. -tom
participants (4)
-
Alec Muffett -
Michael Jonker -
Roger Dingledine -
Tom Ritter