report connection to PT SOCKS proxy separately from OR connection

Right now when acting as a PT client, we don't distinguish between connecting to the SOCKS port of a PT proxy and connecting to the OR that's behind the proxy. This means that we lose some intermediate progress reporting that can help users understand what might be going wrong.

changed milestone to %Tor: 0.4.0.x-final

added 035-roadmap-subtask 035-triaged-in-20180711 component::core tor/tor milestone::Tor: 0.4.0.x-final owner::catalyst parent::28018 priority::medium pt resolution::implemented s8-bootstrap severity::normal socks sponsor::8 status::closed type::enhancement labels

Trac:
Cc: catalyst, mcs, brade to catalyst, mcs, brade, intrigeri

It looks like we might be able to hook in near connection_or_finished_connecting() or connection_proxy_connect(). Right now we call control_event_bootstrap(BOOTSTRAP_STATUS_HANDSHAKE, 0) near the top of connection_or_finished_connecting() before we have begun to talk to the proxy, if any.

Trac:
Cc: catalyst, mcs, brade, intrigeri to catalyst, mcs, brade, intrigeri, rl1987

Trac:
Keywords: N/A deleted, pt, socks added

Trac:
Sponsor: N/A to Sponsor8
Keywords: N/A deleted, s8-bootstrap added

Trac:
Type: defect to enhancement

Move my post-freeze 0.3.5 items to 0.3.6.

Trac:
Milestone: Tor: 0.3.5.x-final to Tor: 0.3.6.x-final

This doesn't seem to have anything to do with #25502 (moved) but rather a change to help with bootstrap status of tor which from the roadmap looks like #28018 (moved).

Trac:
Parent: #25502 (moved) to #28018 (moved)

This depends on some work in #27167 (moved). Otherwise, we would have to add more special cases in control_event_bootstrap() to disambiguate first connection vs application circuit connection.

Replying to catalyst:

Right now when acting as a PT client, we don't distinguish between connecting to the SOCKS port of a PT proxy and connecting to the OR that's behind the proxy.

Not only PT proxies, but also plain Socks4Proxy/Socks5Proxy/HTTPProxy, if I'm not mistaken.

Replying to dcf:

Replying to catalyst:

Right now when acting as a PT client, we don't distinguish between connecting to the SOCKS port of a PT proxy and connecting to the OR that's behind the proxy.

Not only PT proxies, but also plain Socks4Proxy/Socks5Proxy/HTTPProxy, if I'm not mistaken. Yeah, that code doesn't distinguish PT proxies from firewall bypass proxies. I think it's still an improvement to start tracking proxy connection status even if we don't disambiguate for now.

This is slightly related to some of the stuff I'm already working on for S8. Taking over this one.

Trac:
Owner: catalyst to ahf

Tor 0.3.6.x has been renamed to 0.4.0.x.

Trac:
Milestone: Tor: 0.3.6.x-final to Tor: 0.4.0.x-final

In the context of #27239 (moved), I have been reviewing tickets related to the bootstrap status reporting improvements and thinking about how Tor Launcher / Tor Browser will be affected. For this ticket, is the resulting change likely to be the addition of a new bootstrap phase? Or something else?

I'm still looking at how best to do this.

It looks like connection_or_finished_connecting() is called when the TCP connect() succeeds, whether it's directly to a relay or to the TCP listener of a proxy (which could be a PT proxy or a firewall-bypass proxy). It looks like the call control_event_bootstrap(BOOTSTRAP_STATUS_HANDSHAKE, 0) is like many other parts of the bootstrap reporting in that it reports an anticipated next step, even if there might be multiple intermediate unreported steps yet to happen.

It's probably better to report the (TLS?) handshaking when it actually starts to happen, which is probably down in connection_tls_start_handshake().

There already seems to be somewhat of a state machine in connection_or.h already, making connection_or_change_state() a potentially useful place to hook in.

Proxy connections have their own small state machine, with the state variable in the proxy_state field of a connection_t. Currently, connection.c changes that field directly. If we wrap those state changes in a function, that function could publish notifications that we could then use in bootstrap reporting. There aren't many states a proxy connection goes through during connection setup, but maybe it's still enough to improve the bootstrap UX.

In terms of being comprehensible to a non-expert user, we might want to distinguish between firewall-bypass proxies and PT proxies. (I'm still not completely sure how those compose together.)

#28884 (moved) is a related problem.

Replying to catalyst:

#28884 (moved) is a related problem. Also #27167 (moved) will partially solve this, because we notice the state change to OR_CONN_STATE_PROXY_HANDSHAKING. Some intermediate proxy states might not be captured in those patches though.