[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [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 | Resolution:
Keywords: secure cookies | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------------------+----------------------------------
Description changed by micah:
Old description:
> 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.
New description:
One of the main problem points with adding onion services to existing web
services has been interaction with secure cookies. Its hard to setup onion
services because you need to enable secure cookies some times (over
regular network+TLS) and disable them other times (over .onion network,
without TLS). Right now you have to make a trade-off: work well with
.onions, or work well with everyone else. This is an unfortunate trade-
off.
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 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.
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#comment:1>
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