[tbb-bugs] #21537 [Applications/Tor Browser]: Consider ignoring secure cookies for .onion addresses

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Feb 23 15:06:27 UTC 2017


#21537: Consider ignoring secure cookies for .onion addresses
------------------------------------------+------------------------------
     Reporter:  micah                     |      Owner:  tbb-team
         Type:  enhancement               |     Status:  new
     Priority:  Medium                    |  Milestone:
    Component:  Applications/Tor Browser  |    Version:  Tor: unspecified
     Severity:  Normal                    |   Keywords:  secure cookies
Actual Points:                            |  Parent ID:
       Points:                            |   Reviewer:
      Sponsor:                            |
------------------------------------------+------------------------------
 Its hard to setup onion services because you need to enable secure cookies
 some times and disable them other times. Right now you have to make a
 trade-off: work well with .onions, or work well with everyone else. One of
 the main problem points has been secure cookies.

 The idea of "secure cookies" is that they prevent you from leaking your
 cookie information over an insecure connection. There are a lot of ways
 you can leak your cookie info over an insecure connection:

 . dont have hsts setup
 . running an application server that sets the cookie before it redirects
 to https
 . or your server is not setup to redirect everything to https

 Using "secure cookies" allows the application (regardless of how it is
 run, or what intermediaries are in between), to make sure that the browser
 doesn't screw this up. It tells the browser to never submit the cookie
 over plaintext. Many frameworks have this set by default (such as Rails).
 Some applications, such as java/tomcat have as part of the stack the
 cookie setting that happens before that does the redirect to https.

 It is considered a best practice that every web developer is told to do,
 but its a best practice that doesn't work if you want to run an onion
 site. Running an onion site should not force you to violate established
 web application development best practices.

 The "secure cookies" spec is just a "suggestion" to the browser, so TBB is
 free to ignore them, and I think that maybe it should do so for .onion
 sites.

 As an example, if a user goes to https://example.com the first response
 back sends back a cookie with nothing but a session id. If you then login,
 you now have a sessionid that is privileged and associated with your
 account. If you then close that tab, but then realize you needed to do
 something else, so you open a new tab and go to http://example.com (NB: no
 https). If the site did not mark the original cookies as 'secure', then
 the browser will submit in that initial first request the cookie it had
 previously saved and it will send it over the cleartext channel before the
 webserver can redirect to the secured site. With the secure cookies flag
 set, the browser will not send the cookie until the TLS connection is up.
 This doesn't matter if you are going over onion services because the
 connection is already wrapped in TLS, and it also doesn't matter if the
 site has HSTS, because the second visit will go to https by default in
 that scenario.

 So what are the options?

 . Ignore secure cookie flags for .onions
 . Ignore tls verification for onions

 Either one would increase the security properties of onion and non onions,
 unfortunately the second one would not be appreciated by sites that have
 actually paid for a valid .onion cert.

 Pretty much every Rails application suffers with TBB because of this
 problem, I'm pretty sure other frameworks also suffer from this. Fixing
 this would fix a large number of tor problems related to this.

 I'm unsure of the broader implications of this, which is why I wanted to
 open this for discussion.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21537>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tbb-bugs mailing list