Consider ignoring secure cookies for .onion addresses

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.