Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#3892 closed defect (fixed)

Controlport behavior changed in 0.2.2.32 - CookieAuthentication now required to access control port

Reported by: cypherpunks Owned by:
Priority: Medium Milestone: Tor: 0.2.2.x-final
Component: Core Tor/Tor Version: Tor: 0.2.2.32
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Current and previous versions of the torrc file states that either a HashedControlPassword OR CookieAuthentication may be used to access tor's controlport.

From torrc

## If you enable the controlport, be sure to enable one of these
## authentication methods, to prevent attackers from accessing it.
#HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C
#CookieAuthentication 1

After upgrading from 0.2.1.26 to 0.2.2.32, tor now requires that CookieAuthentication be enabled to access the ControlPort. Upon starting Vidalia after the tor upgrade, an error message was received asking for the location of the authentication cookie even when a HashControlPassword was specified in the torrc file.

Child Tickets

Change History (12)

comment:1 Changed 8 years ago by cypherpunks

This ticket may be a duplicate of #3476
Murble reported similar behavior in 0.2.2.29-beta-1squeeze+1

https://trac.torproject.org/projects/tor/ticket/3476

comment:2 Changed 8 years ago by cypherpunks

Also relevant

From the tor wiki stable and dev manuals on torrc options

https://www.torproject.org/docs/tor-manual.html.en
https://www.torproject.org/docs/tor-manual-dev.html.en

CookieAuthentication 0|1

If this option is set to 1, don’t allow any connections on the control port except when the connecting process knows the contents of a file named "control_auth_cookie", which Tor will create in its data directory. This authentication method should only be used on systems with good filesystem security. (Default: 0)

comment:3 Changed 8 years ago by cypherpunks

It appears that default behavior has indeed changed in 0.2.2.32

Setting CookieAuthentication 0 in torrc resolves the issue.

As of 0.2.2.32 --> (Default: 1)

comment:4 Changed 8 years ago by arma

No, CookieAuthentication in Tor still defaults to 0 in Tor 0.2.2.32.

I wonder if one of your controllers has changed its behavior?

Can you give us more explicit steps to reproduce? I don't understand what you're doing, so I can't guess how it's going wrong.

comment:5 Changed 8 years ago by arma

What platform are you on? The recent Debian packages (after 0.2.2.29-beta) use ControlSocket by default.

comment:6 Changed 8 years ago by cypherpunks

Ubuntu 10.04 LTS

Packages:


tor_0.2.2.32-1~lucid+1_amd64.deb
tor-geoipdb_0.2.2.32-1~lucid+1_all.deb
vidalia_0.2.12-1~lucid1_amd64.deb

from
http://deb.torproject.org/torproject.org/pool/main/

Steps to reproduce:
===================

  1. set HashedControlPassword in torrc
  2. comment out or remove CookieAuthentication from torcc
  3. save torcc
  4. restart tor
  5. start vidalia
  6. watch as vidalia complains that it can't find the location of "control_auth_cookie"

comment:7 Changed 8 years ago by cypherpunks

torcc --> torrc

Sorry, my derp moment for the day

comment:8 in reply to:  4 Changed 8 years ago by arma

Replying to arma:

No, CookieAuthentication in Tor still defaults to 0 in Tor 0.2.2.32.

But on Debian, CookieAuthentication defaults to 1:
https://gitweb.torproject.org/debian/tor.git/blob/debian-0.2.2:/debian/patches/06_add_compile_time_defaults.dpatch

comment:9 Changed 8 years ago by arma

I opened #3898 which I think (once resolved) should resolve this issue. Thanks!

comment:10 Changed 7 years ago by nickm

Resolution: fixed
Status: newclosed

I opened #3898 which I think (once resolved) should resolve this issue. Thanks!

#3898 got fixed three months ago; calling this resolved.

comment:11 Changed 7 years ago by nickm

Keywords: tor-client added

comment:12 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.