Opened 3 weeks ago

Last modified 7 days ago

#30382 accepted defect

Provide control port event for when we are missing v3 client auth for an onion

Reported by: asn Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.4.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, tbb-usability, hs-auth, network-team-roadmap-2019-Q1Q2
Cc: antonela, arthuredelstein, brade, mcs, gk, michael, special, erinn, patrick@…, lunar, linda, dmr Actual Points:
Parent ID: #14389 Points: 6
Reviewer: Sponsor: Sponsor27-must

Description

For TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.

In particular:

1) When Tor fails to decrypt the second layer of desc encryption, we issue the CLIENT_AUTH_NEEDED <onion> <reason> event. Tor does not go to fetch more descs from the hsdir for this onion.

2) At the same time, we store the broken descriptor into the hs cache, with a special flag that says "missing client auth" and hence desc is NULL.

3) When TB intercepts the event it presents the user with a dialogue (#30237) and adds any client auth creds with the commands from #30381.

4) As part of the #30381 commands the descriptor is decrypted.

5) TB issues another SOCKS request which uses the right descriptor and goes forward.

Child Tickets

Change History (10)

comment:1 Changed 3 weeks ago by asn

I was thinking that the CLIENT_AUTH_NEEDED event would also need a reason field so that it can distinguish between client auth is wrong and client auth is missing, so that TB can give better error messages (see #30237).

comment:2 Changed 3 weeks ago by asn

Points: 6
Reviewer: 6

comment:3 Changed 3 weeks ago by dgoulet

Owner: set to dgoulet
Status: newaccepted

comment:4 Changed 2 weeks ago by dgoulet

Sponsor: Sponsor27-must

comment:5 Changed 2 weeks ago by mcs

This all make sense to Kathy and me. One quick question — what will the timing be for:

  1. tor generating a CLIENT_AUTH_NEEDED event
  2. tor failing the SOCKS CONNECT

?

Specifically, I wonder if it will be safe for Tor Browser to assume the control port event will be sent before the browser receives a failure for the CONNECT, or at least to assume that will occur in most cases.

comment:6 in reply to:  5 ; Changed 2 weeks ago by dgoulet

Replying to mcs:

Specifically, I wonder if it will be safe for Tor Browser to assume the control port event will be sent before the browser receives a failure for the CONNECT, or at least to assume that will occur in most cases.

Hmmm... Control port events, when they occur, are queued in a list and then an tor main loop event will send the queued events on the socket.

So, if I'm not mistaken, you will get a connect failure _before_ you get the control port event because tor will return the SOCKS failure before that control port "empty queue" event is triggered.

comment:7 in reply to:  6 Changed 12 days ago by mcs

Replying to dgoulet:

So, if I'm not mistaken, you will get a connect failure _before_ you get the control port event because tor will return the SOCKS failure before that control port "empty queue" event is triggered.

That makes sense and is good to know. I asked because the technique used by Arthur's old v2 auth Torbutton patch from ticket:14389#comment:14 relies on receiving the control port event before the browser receives a connection failure indication via SOCKS. Unfortunately, it seems like we are back to adding a new error code to SOCKS5 or figuring out how to switch the browser to use HTTP CONNECT (which is a large and risky task due to the complexity of Firefox's networking stack and how HTTP CONNECT was implemented there).

comment:8 Changed 12 days ago by asn

ACK. Makes sense.

While it seems like we are moving towards the SOCKS direction, I should mention that comment:52:ticket:14389 also asks for some enhancements to our SOCKS handshake. We should probably oen a new ticket for this. Also, wrt this ticket, we should consider how to use prop#229 for any additional SOCKS error codes.

comment:9 Changed 12 days ago by dgoulet

Lets go with SOCKS5 error extension code! We'll re-use the prop229 and open a new one for only extending error codes!

comment:10 Changed 7 days ago by gaba

Keywords: network-team-roadmap-2019-Q1Q2 added
Note: See TracTickets for help on using tickets.