[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Tor Double HiddenService w/ Server Level Intercepting Request and Content Anonymization
Hello folk!"Whonix" or "Ubuntu", blocks some unauthorized bad javascript injection, when visiting a compromised HiddenService? Don't you think HiddenServices are no more secure, after the cataclysm, that happend on August 2013? Do you know when the number of HiddenServices will rise again?Marcos (Brasil)
> Date: Wed, 30 Oct 2013 23:39:07 +0000
> From: yo@xxxxxxx
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Tor Double HiddenService w/ Server Level Intercepting Request and Content Anonymization
>
> Hi Anthony.
>
> If the first-in-line server gets compromised then the users using this
> HiddenService have to cross fingers that their privoxy or similar
> anonymizer is well configured.
>
> Because the first server-in-line is the tor node handling the public
> HiddenService declaration and the Tor network as transport network imho
> needs to stay transparent, there is nothing I can imagine that can be done
> apart of intergration of request modification into the HiddenService
> declaration so this personal informations would never leave the Tor network.
>
> But also the actual approach should be capable of injecting a warning into
> the response when personal information is found in the request.Something
> like injecting a div-layer with a warning after the body tag when a
> accept-language tag is found other than 'en'. Expecially when the installed
> server only supports 'en' why sending anything else that changes nothing.Or
> instead the response can be only a warning and no content from the
> HiddenService. But this would force the users to setup a special
> configuration... something I wouldn't like.
>
> But I think the relay isn't the primary target in first place for the
> authorities so risk is acceptable. And if one in the chain gets compromised
> the other will know. A (manual human executed) protocol of changing the
> X-OnionRelay-Auth code for example would prevent that users get through to
> the server even if the proxy will forward the request. This would be well
> paranoid but still the request leaves the Tor network unfiltered and
> unencrypted.
>
> Greetings, Manfred
> Am 30.10.2013 14:26 schrieb "Anthony Papillion" <anthony@xxxxxxxxxxxx>:
>
> > On 10/29/2013 08:48 AM, Manfred Ackermann wrote:
> > > Hi List.
> > >
> > > Sorry to push this up, just wondering if this approach is such stupid
> > that
> > > it's not even worth leaving a related comment to it ;-) Or is it just of
> > no
> > > interest?
> > >
> > > Any comments apriciated.
> >
> > Hello Manfred,
> >
> > Sounds like a fantastic idea. But I think I'm missing something that I'm
> > hoping you can clear me up on. How does this protect the user if the
> > first-in-line server is compromised? So the user connects to HS on
> > computer1 which is compromised. How does your system stop them from
> > being compromised instead of forwarded deeper into the network to
> > computer2?
> >
> > Cheers,
> > Anthony
> >
> >
> > --
> > Anthony Papillion
> > XMPP/Jabber: cajuntechie@xxxxxx
> > OTR Fingerprint: 1515393D53BA593C19E2CD549AE59FB650F82ABC
> > SIP: 17772471988@xxxxxxxxxxxxxxx
> > PGP Key: 0xDC89FF2E
> >
> > --
> > tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> > To unsubscribe or change other settings go to
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> >
> --
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk