[tor-dev] #9623 [Tor Browser]: Referers being sent from hidden service websites

[Conrad Kramer]

> 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 at 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 at 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 at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>>
>>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
>> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151006/2991258e/attachment-0001.html>