[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #21537 [Applications/Tor Browser]: Consider ignoring secure cookies for .onion addresses
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs