Opened 4 years ago

Last modified 2 months ago

#14209 new enhancement

Implement SOCKSPort windows:path for named pipes

Reported by: anon Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, needs-libevent-patches, hard, win32, windows, 040-roadmap-proposed
Cc: mcs, dmr Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


This is identical to #12585 SocksSocket except for Windows users wishing to use Named Pipes in this same manner.

Firefox changes to use this (instead of SocksPort) unknown. See

Child Tickets

Change History (21)

comment:1 Changed 4 years ago by anon

This would allow the use of a pipe name (or one at random?) like "
.\pipe\TorSocks" to connect clients to Tor proxy capability with the additional security controls and performance benefits that Named Pipes bring on the Windows platform.

If using a random pipe name (different from an anonymous pipe!) then the ControlPort GETINFO may be required to discover it.

comment:2 Changed 4 years ago by nickm

Keywords: tor-client added
Milestone: Tor: 0.2.???

comment:3 Changed 4 years ago by anon

per nickm: "there's going to be trouble with the way that libevent uses windows stuff; you'll need to handle the namedpipes in a separate thread, or hack libevent to do so, writing it a new backend, or both."

The right solution is a good backend for libevent to handle this Win pipe IO. the expedient solution is to hand it off to a thread pair.

Also requiring defition: access control syntax, on pipe itself in configuration option. (This user only, etc.)

comment:4 Changed 3 years ago by xeonchen

Severity: Normal

per nickm:

I'd suggest an extra thread and event loop to process Windows handles.
You'll need to communicate with the main thread; look at workqueue.c
to get some idea of how we do that now, though you'd probably want a
different implementation. Avoid sharing structures whenever possible.
To keep as much shared implementation as possible, you might do it like this:

  • enable threadsafe mode when initializing libevent.
  • Add handle-based versions of read_to_buf / flush_buf. Use them as appropriate.
  • Allow a connection_t to optionally have a handle instead of a socket.
  • When constructing the event objects for the handle, do not pass in a file descriptor. Instead, pass a file descriptor of -1.
  • From the worker thread, use event_active() to make those event objects active when the handles are ready for read/write. (This is why libevent needs to be running with thread safety enabled.)
  • Now all you'll need is some way for the main thread to tell the worker thread about new handles, closed handles, and which of the handles should be reading/writing.

comment:5 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:6 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:7 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:8 Changed 2 years ago by nickm

Keywords: needs-libevent-patches hard win32 windows added

comment:10 Changed 12 months ago by arma

The Tor Browser folks, and the Mozilla folks, want Tor to be able to handle this feature, so they can move forward with network sandboxing in the browser side.

comment:11 Changed 12 months ago by arma

Keywords: 035-proposed 036-proposed added

Adding some keywords so this ticket can get triage attention.

I think the simple version (socketpair?) would be fine in the shorter term.

The goal here is that when the Firefox folks think about sandboxing networking on Windows, they don't say "oh, Tor doesn't support that, ok we'll skip that idea".

comment:12 Changed 12 months ago by mcs

Cc: mcs added

comment:13 Changed 12 months ago by teor

Summary: Implement new option SocksNamedPipe for Windows usersImplement SOCKSPort windows:path for named pipes

For unix sockets, Tor currently supports:

SOCKSPort unix:path

So for consistency I suggest we make the new syntax:

SOCKSPort windows:path

comment:14 Changed 11 months ago by nickm

Keywords: 035-roadmap-proposed added; 035-proposed removed

comment:15 Changed 10 months ago by dmr

Cc: dmr added

comment:16 Changed 8 months ago by teor

Keywords: 036-roadmap-proposed added; 035-roadmap-proposed removed

Move likely enhancements from 035-roadmap-proposed to 036-roadmap-proposed

comment:17 Changed 7 months ago by teor

Keywords: 040-roadmap-proposed added; 036-roadmap-proposed removed

0.3.6 is now 0.4.0: changing roadmap keywords

comment:18 Changed 7 months ago by teor

Keywords: 040--roadmap-proposed added

0.3.6 is now 0.4.0: also changing -roadmap to -roadmap-proposed

comment:19 Changed 7 months ago by teor

Keywords: 036-proposed removed


comment:20 Changed 7 months ago by teor

Keywords: 040--roadmap-proposed removed

Oops, second stage

comment:21 Changed 2 months ago by cypherpunks

this will prevent tcp port exhaustion!

Note: See TracTickets for help on using tickets.