Opened 3 years ago

Last modified 2 years ago

#20022 new defect

Tor should deprecate insecure cookie auth

Reported by: dkg Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-spec needs-analysis tor-controller
Cc: brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

control-spec.txt points out that normal cookie auth represents a security risk for clients.

The Tor daemon should either stop accepting insecure cookie auth entirely, or should log when a client uses insecure cookie auth.

Child Tickets

Change History (10)

comment:1 Changed 3 years ago by dkg

Summary: Tor should deprecated insecure cookie authTor should deprecate insecure cookie auth

comment:2 Changed 3 years ago by atagar

No strong opinion here from me, but for what it's worth SecureCookie auth is a bit trickier for controllers to implement...

https://gitweb.torproject.org/stem.git/tree/stem/connection.py#n743
https://gitweb.torproject.org/stem.git/tree/stem/connection.py#n833

By dropping normal cookie authentication we may encourage some folks to use either password auth (or if they find that annoying, drop authentication altogether).

comment:3 Changed 3 years ago by mcs

Cc: brade mcs added

Tor Launcher and Torbutton do not support SAFECOOKIE. It sounds like something we should fix....

comment:4 Changed 3 years ago by yawning

For what it's worth bulb (the Go controller library) doesn't support COOKIE at all, under the assumption that "COOKIE" authentication exists, but anything modern supports "SAFECOOKIE"..

Any project that finds SAFECOOKIE hard to implement either should use library code that does it for them or be the target of merciless mockery.

Somewhat orthogonal to this, the browser code's treatment of controller auth in general could be improved (eg: #16017).

comment:5 in reply to:  3 Changed 3 years ago by gk

Replying to mcs:

Tor Launcher and Torbutton do not support SAFECOOKIE. It sounds like something we should fix....

Yes, #20026 is the ticket for that.

comment:6 Changed 3 years ago by teor

It's also worth noting that there are situations where security is somewhat irrelevant - such as control sockets on tor test networks. Best we keep some auth methods for that use case.

comment:7 Changed 3 years ago by atagar

As I understand it auth isn't necessary if using a control socket. By using cookie authentication you're proving you have permission to read the cookie file from disk. File-based sockets have similar access controls making cookie auth redundant.

Happy to be corrected if I'm wrong. :)

comment:8 in reply to:  6 Changed 3 years ago by yawning

Replying to teor:

It's also worth noting that there are situations where security is somewhat irrelevant - such as control sockets on tor test networks. Best we keep some auth methods for that use case.

"some auth methods" like NULL, HASHEDPASSWORD, and SAFECOOKIE? If your test network tooling only supports COOKIE auth, that's a problem with the tooling.

SAFECOOKIE was introduced in 0.2.3.13-alpha. I don't see a compelling argument to keep COOKIE around.

comment:9 Changed 3 years ago by nickm

Milestone: Tor: unspecified

comment:10 Changed 2 years ago by nickm

Keywords: needs-spec needs-analysis tor-controller added
Note: See TracTickets for help on using tickets.