Hi All,
Currently there’s an information leak in Tor Browser: it sends referrer headers containing .onion site addresses when the user clicks on a link on the .onion site.
There’s a fix in the works, but we were wondering: Does anyone’s hidden service depend on the referrer header? The currently favoured fix is to stop sending referrers cross-origin (between different .onion sites, and between .onion sites and sites on the internet).
But this may break sites that are set up with multiple .onion addresses and use referrers to check that requests are coming from the parent site. (People sometimes set up different .onion sites to serve different types of content, such as images.)
In general, I would discourage people from using referrers in this way, because they aren’t secure and can be faked.
But does anyone have a compelling use case for cross-origin referrers, or is using them at the moment? We could include a preference if removing them would break too many sites.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
What's the fix in the works? There is a specification being developed to allow sites to opt to remove referers (or opt to let them leak *more* information.) http://www.w3.org/TR/referrer-policy/
(If you're wondering why one would want to leak more information, it's basically to promote HTTPS adoption. One of the things holding back HTTPS adoption is the lack of Referer on a HTTPS->HTTP link, so by removing that constraint, the originating origin can move to HTTPS.)
Firefox supports Referrer Policy as of 36: https://blog.mozilla.org/security/2015/01/21/meta-referrer/ so arguably HS owners have the ability to fix this themselves for users on ESR38.
-tom
On 6 October 2015 at 18:15, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
Hi All,
Currently there’s an information leak in Tor Browser: it sends referrer headers containing .onion site addresses when the user clicks on a link on the .onion site.
There’s a fix in the works, but we were wondering: Does anyone’s hidden service depend on the referrer header? The currently favoured fix is to stop sending referrers cross-origin (between different .onion sites, and between .onion sites and sites on the internet).
But this may break sites that are set up with multiple .onion addresses and use referrers to check that requests are coming from the parent site. (People sometimes set up different .onion sites to serve different types of content, such as images.)
In general, I would discourage people from using referrers in this way, because they aren’t secure and can be faked.
But does anyone have a compelling use case for cross-origin referrers, or is using them at the moment? We could include a preference if removing them would break too many sites.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hey Tom and co,
I am the person who wrote the fix in a hurry 14 months ago (as a stop-gap before FF38 with all its referer goodness was released). Glad it's finally being reviewed!
Here is the patch: https://github.com/diracdeltas/torbutton/pull/1/files Here is the ticket: https://trac.torproject.org/projects/tor/ticket/9623
The patch only clears referer on cross-domain requests involving THS's. So referer will be preserved on http(s)://www.facebookcorewwwi.onion to http(s)://cdn.facebookcorewwwi.onion, for instance. Referer will NOT be sent to http(s)://someotheronion.onion or http://google.com, for instance.
I agree HS owners can do this with CSP1.1 right now (or the old <meta> referrer tags, though i think that was reverted in Firefox?) but it's important enough to prevent leaks that I think the client should handle it.
Cheers, Yan
On 10/6/15 9:57 PM, Tom Ritter wrote:
What's the fix in the works? There is a specification being developed to allow sites to opt to remove referers (or opt to let them leak *more* information.) http://www.w3.org/TR/referrer-policy/
(If you're wondering why one would want to leak more information, it's basically to promote HTTPS adoption. One of the things holding back HTTPS adoption is the lack of Referer on a HTTPS->HTTP link, so by removing that constraint, the originating origin can move to HTTPS.)
Firefox supports Referrer Policy as of 36: https://blog.mozilla.org/security/2015/01/21/meta-referrer/ so arguably HS owners have the ability to fix this themselves for users on ESR38.
-tom
On 6 October 2015 at 18:15, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
Hi All,
Currently there’s an information leak in Tor Browser: it sends referrer headers containing .onion site addresses when the user clicks on a link on the .onion site.
There’s a fix in the works, but we were wondering: Does anyone’s hidden service depend on the referrer header? The currently favoured fix is to stop sending referrers cross-origin (between different .onion sites, and between .onion sites and sites on the internet).
But this may break sites that are set up with multiple .onion addresses and use referrers to check that requests are coming from the parent site. (People sometimes set up different .onion sites to serve different types of content, such as images.)
In general, I would discourage people from using referrers in this way, because they aren’t secure and can be faked.
But does anyone have a compelling use case for cross-origin referrers, or is using them at the moment? We could include a preference if removing them would break too many sites.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
I agree HS owners can do this with CSP1.1 right now (or the old <meta> referrer tags, though i think that was reverted in Firefox?) but it's important enough to prevent leaks that I think the client should handle
it.
I want to emphasize the importance of these measures to HS owners because not everyone using Tor uses it through TBB/Torbutton. Any VPN-based Tor client, or a vanilla browser will still gladly leak Referrer headers.
Conrad
On Tue, Oct 6, 2015 at 7:57 PM, yan yan@torproject.org wrote:
Hey Tom and co,
I am the person who wrote the fix in a hurry 14 months ago (as a stop-gap before FF38 with all its referer goodness was released). Glad it's finally being reviewed!
Here is the patch: https://github.com/diracdeltas/torbutton/pull/1/files Here is the ticket: https://trac.torproject.org/projects/tor/ticket/9623
The patch only clears referer on cross-domain requests involving THS's. So referer will be preserved on http(s)://www.facebookcorewwwi.onion to http(s)://cdn.facebookcorewwwi.onion, for instance. Referer will NOT be sent to http(s)://someotheronion.onion or http://google.com, for instance.
I agree HS owners can do this with CSP1.1 right now (or the old <meta> referrer tags, though i think that was reverted in Firefox?) but it's important enough to prevent leaks that I think the client should handle it.
Cheers, Yan
On 10/6/15 9:57 PM, Tom Ritter wrote:
What's the fix in the works? There is a specification being developed to allow sites to opt to remove referers (or opt to let them leak *more* information.) http://www.w3.org/TR/referrer-policy/
(If you're wondering why one would want to leak more information, it's basically to promote HTTPS adoption. One of the things holding back HTTPS adoption is the lack of Referer on a HTTPS->HTTP link, so by removing that constraint, the originating origin can move to HTTPS.)
Firefox supports Referrer Policy as of 36: https://blog.mozilla.org/security/2015/01/21/meta-referrer/ so arguably HS owners have the ability to fix this themselves for users on ESR38.
-tom
On 6 October 2015 at 18:15, Tim Wilson-Brown - teor teor2345@gmail.com wrote:
Hi All,
Currently there’s an information leak in Tor Browser: it sends referrer headers containing .onion site addresses when the user clicks on a link on the .onion site.
There’s a fix in the works, but we were wondering: Does anyone’s hidden service depend on the referrer header? The currently favoured fix is to stop sending referrers cross-origin (between different .onion sites, and between .onion sites and sites on the internet).
But this may break sites that are set up with multiple .onion addresses and use referrers to check that requests are coming from the parent site. (People sometimes set up different .onion sites to serve different types of content, such as images.)
In general, I would discourage people from using referrers in this way, because they aren’t secure and can be faked.
But does anyone have a compelling use case for cross-origin referrers, or is using them at the moment? We could include a preference if removing them would break too many sites.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Conrad Kramer -
Tim Wilson-Brown - teor -
Tom Ritter -
yan