Opened 6 years ago

Closed 2 years ago

#9822 closed defect (fixed)

obfsproxy: Don't read authcookie file for every new connection

Reported by: asn Owned by: asn
Priority: Low Milestone:
Component: Obfuscation/Obfsproxy Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Currently, obfsproxy opens the authcookie file for each new incoming connection:

This is suboptimal, and we can just read the file on startup and keep the authcookie value around during runtime.

Child Tickets

Attachments (1)

0001-Load-ext-cookie-file-at-startup.patch (7.2 KB) - added by joelanders 5 years ago.

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by joelanders

comment:1 Changed 5 years ago by joelanders

New to this, so it was educational to dig around the source.
Seems like obfsproxy should at least check if the cookie file has been modified since last loading it.
I was starting obfsproxy *then* tor, which doesn't work now because tor generates a new cookie on startup (so obfsproxy would have an old cookie).

comment:2 Changed 5 years ago by joelanders

Also, there's some ext_orport and authcookie stuff in do_managed_server(), which I think does nothing. The ext_orport talking is only in external server mode, not managed mode. (right?)

comment:3 Changed 4 years ago by yawning

Priority: normalminor

This will cause mysterious failures on most tor instances currently deployed in the wild due to #15240.

The fix for the tor side bug is in master, but only for releases after I would be hesitant to recommend doing this till the initial stable 0.2.6.x release is the oldest tor people could reasonably be using.

comment:4 Changed 2 years ago by dcf

Resolution: fixed
Severity: Normal
Status: newclosed

This is handled by goptlib now (which still reads the cookie file every time, as a workaround for #15240).

Note: See TracTickets for help on using tickets.