[tor-bugs] #28181 [Core Tor/Tor]: spec: Add to pt-spec.txt control messages going back to main process (tor)
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Oct 30 00:26:57 UTC 2018
#28181: spec: Add to pt-spec.txt control messages going back to main process (tor)
-------------------------------------------------+-------------------------
Reporter: dgoulet | Owner: dgoulet
Type: enhancement | Status:
| assigned
Priority: Medium | Milestone: Tor:
| 0.3.6.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-spec, tor-pt, 036-roadmap- | Actual Points:
subtask |
Parent ID: #28180 | Points:
Reviewer: | Sponsor:
| Sponsor8
-------------------------------------------------+-------------------------
Comment (by dcf):
dgoulet posted some info here:
https://lists.torproject.org/pipermail/tor-dev/2018-October/013512.html
> Below is the link to the PT spec patch. It adds the EVENT message that
for now is only used, as you will see, for reporting connection status
message. However, you should see this EVENT message as extendable to
whatever the PT would like to report to Tor that we can think of in the
future:
>
https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket28181_01&id=0814114fb39f9f7ddf16de35f97092ed74ffd1ee
> 3.3.4.1 `CONNECTION` type.
> `CONNECTION <transport> <address> <port>`
> `CONNECTION-ERROR <transport> <ErrorType> [<ErrorMessage>]`
> `CONNECTION-SUCCESS <transport>`
My concern with this design is that it only has in mind BridgeDB-like
transports that work using a single connection to a single IP address. IMO
it's already a misdesign that the `Bridge` line requires an IP address and
port, forcing transport like meek to use a dummy address purely for
syntactical reasons, which leads to other problems (#18611). Imagine a
transport that works by tunneling through UDP DNS requests: what
"connection" can you report? What IP address and port are you "connected"
to, your local DNS resolver? Or what about a transport that muxes across
multiple parallel TCP connections? IMO future transports are increasingly
going to move away from the "one static host, one TCP connection" model.
In the case of meek, there's no single connection nor specific IP address,
because it's a sequence of HTTPS requests to a server identified by domain
name. When a PT `PROXY` is in use, meek-client may not even know the IP
address of the server. We could probably apply come logical hacks and try
and fit messages into this reporting model, for instance by immediately
reporting `CONNECTION meek 0.0.0.3 1` before even touching the network,
then waiting for the first HTTPS request and reporting `CONNECTION-ERROR`
if it fails and `CONNECTION-SUCCESS` if it succeeds. But what if the first
HTTPS connection succeeds and the second fails (perhaps due to a temporary
server 500 error)? We can't send `CONNECTION-ERROR` after sending
`CONNECTION-SUCCESS`.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28181#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list