Opened 4 years ago

Closed 3 years ago

#10082 closed defect (invalid)

flashproxy-client fails to communicate with connected browser proxies when logging is disabled

Reported by: infinity0 Owned by: dcf
Priority: High Milestone:
Component: Archived/Flashproxy Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

This is reproducible 100% of the time on my Windows XP machine, both with plain flashproxy and obfs-flash-client. In all cases, Process Explorer shows that flashproxy-client.exe has several established incoming TCP connections on port 9000.

Failing cases:

Bridge flashproxy 127.0.0.1:9001
ClientTransportPlugin flashproxy exec App\flashproxy-client --register 127.0.0.1:9001 :9000
Bridge obfs3_flashproxy 127.0.0.1:2334
ClientTransportPlugin obfs3_flashproxy exec App\obfs-flash-client --fp-arg=--register 2334 :9000

Here, Vidalia hangs on "Establishing an encrypted directory connection". The Tor message log sometimes hangs at "Bootstrapped 10%: Finishing handshake with directory server" and sometimes at "Bootstrapped 15%: Establishing an encrypted directory connection", then eventually fails with "1 connections died in state handshaking (TLS) with SSLv2/v3 read server hello A in HANDSHAKE" or "... with SSL state SSLv3 read finished A in HANDSHAKE".

Success cases (removing --unsafe-logging has the same effect):

Bridge flashproxy 127.0.0.1:9001
ClientTransportPlugin flashproxy exec App\flashproxy-client --register -l flashproxy.log 127.0.0.1:9001 :9000
Bridge obfs3_flashproxy 127.0.0.1:2334
ClientTransportPlugin obfs3_flashproxy exec App\obfs-flash-client --fp-arg=--register --fp-arg=-l --fp-arg=flashproxy.log 2334 :9000

This is probably some Python buffering issue. I am going to try to build flashproxy-client with py2exe's unbuffered IO option and see what happens. Possibly also try replacing cases of readlines() into a while True: readline() loop (as man python, section -u suggests).

I am testing using the PTBB I built myself here: https://people.torproject.org/~infinity0/bin/ I built this on WINE, but I've also dropped into it a flashproxy-client.exe / py2exe-flashproxy.zip built directly on the Windows XP machine I am using, and it shows the same behaviour. In both cases I am using flashproxy from commit b9baa31c from my github.

Child Tickets

Change History (5)

comment:1 Changed 4 years ago by infinity0

Using the latest distributed version of the PTBB is fine, however. (And I just realised I don't actually need to have a specific address for Bridge flashproxy lines above. I've also changed obfs3_flashproxy to listen on 9020 to make sure the facilitator doesn't get confused.)

I'm going to try to work out which commit messed things up. Even with the newer commit, not-logging works fine on my Debian GNU/Linux machine.

Last edited 4 years ago by infinity0 (previous) (diff)

comment:2 Changed 4 years ago by infinity0

Actually scratch that, it seems the latest distributed version of the PTBB has the bug as well; it just shows up at "Bootstrapped 50%: Loading relay descriptors." instead of earlier in the process like with my self-built PTBB.

Turning on logging, it still hangs a bit at 50% but completes shortly afterwards. Not turning on logging makes it hang indefinitely - or at least, I ran out of patience waiting for the TLS error.

Anyway, it's the weekend so I'll pause here and do all of the things I mentioned next week.

comment:3 Changed 4 years ago by dcf

Status: newneeds_information

That's interesting behavior. I can totally buy that some py2exe buffer is filling up as flashproxy-client writes to stderr but nothing reads it. Can you reproduce it without using the facilitator, with a proxy you operate yourself?

I suggest that because what you describe is consistent with what happens when a flash proxy dies on you during bootstrapping. Using your own proxy may not create enough log messages to trigger the bug; so you could register manually after connecting with your own proxy (or just add some dummy logging, I guess).

1 connections died in state handshaking (TLS) with SSLv2/v3 read server hello A in HANDSHAKE

This message is consistent with a proxy dying during bootstrapping. Normally flashproxy-client would just switch to a different proxy and tor would try to reconnect. But it seems (and I haven't really investigated this) that Tor is more vulnerable to bridge failure during bootstrapping, and is less likely to try to reconnect to a bridge. That's not something I know for sure, just an impression I've gotten.

The other thing I would try is using five Bridge lines as described in comment:5:ticket:7153. That might cause Tor to think that you actually have separate bridges, so the failure of one during bootstrapping wouldn't cause Tor to conclude that they are all down.

comment:4 in reply to:  2 Changed 4 years ago by dcf

Replying to infinity0:

Turning on logging, it still hangs a bit at 50% but completes shortly afterwards. Not turning on logging makes it hang indefinitely - or at least, I ran out of patience waiting for the TLS error.

Do you think this is #9229? Is this ticket still an issue?

comment:5 Changed 3 years ago by dcf

Resolution: invalid
Status: needs_informationclosed

I'm going to close this. It looks more like either random flash proxy failures or #9229 than anything having to do with logging or a specific version of TBB. It may also be symptomatic of #10993/#11301.

Note: See TracTickets for help on using tickets.