[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] tor-talk Digest, Vol 52, Issue 53



Grasia

Enviado desde mi iPad

> El may 26, 2015, a las 6:11 PM, tor-talk-request@xxxxxxxxxxxxxxxxxxxx escribiÃ:
> 
> Send tor-talk mailing list submissions to
>    tor-talk@xxxxxxxxxxxxxxxxxxxx
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> or, via email, send a message with subject or body 'help' to
>    tor-talk-request@xxxxxxxxxxxxxxxxxxxx
> 
> You can reach the person managing the list at
>    tor-talk-owner@xxxxxxxxxxxxxxxxxxxx
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tor-talk digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Hola.org routes his vpn traffic over customers like    tor
>      (Apple Apple)
>   2. Re: Hidden Service Scaling Summer of Privacy Project (coderman)
>   3. Re: SOCKS proxy to sit between user and Tor? (l.m)
>   4. Re: SOCKS proxy to sit between user and Tor? (l.m)
>   5. Re: Mailpile SMTorP [ref: nexgen P2P email] (carlo von lynX)
>   6. Confidant Mail, was re:  Mailpile SMTorP (Mike Ingle)
>   7. Re: Mailpile SMTorP [ref: nexgen P2P email] (Jonathan Wilkes)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 26 May 2015 05:08:48 -0700
> From: Apple Apple <djjdjdjdjdjdjd32@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Hola.org routes his vpn traffic over customers
>    like    tor
> Message-ID:
>    <CAAgxajG0FwkdABfNTiujQxgzg7Kw8+iu-+Y0JBjzDfbJJtoiXQ@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
> 
> It is also worth mentioning that VPN operators typically have the ability
> to log who does what and when. This makes it very easy for them to resolve
> abuse complaints and turn over the offending parties to the relevant
> authorities.
> 
> Unfortunately many organizations feel that IP bans are their only option
> when dealing with abuse originating from the Tor network - since there is
> little else that can be done by design.
> 
> And as mentioned earlier it is very easy to pull down a list of current Tor
> nodes and ban all the exits unconditionally - they are not even waiting
> until an incident happens anymore.
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 26 May 2015 12:41:07 -0700
> From: coderman <coderman@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Hidden Service Scaling Summer of Privacy
>    Project
> Message-ID:
>    <CAJVRA1S4bHE8+0hKUj-jL+G0_Pa=LJxAdz3+=QRFCuoZZDQtSw@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=UTF-8
> 
>> On 5/26/15, Donncha O'Cearbhaill <donncha@xxxxxxxxxx> wrote:
>> ...
>> I am interested in hearing from all existing hidden service operators.
> 
> speaking for two,
> 
> 
> 
>> In particular I'd like to understand the use-cases,
> 
> - file distribution
> - "web services", etherpad, ethersheet, webdav
> - XMPP
> - IRC
> - overlay network (tun/tap)
> 
> 
> 
>> priorities
> 
> file distribution and chat.
> 
> 
> 
>> limitations
> 
> fragility; zooko's triangle. (see also namecoin and onion name service
> experiments for bootstrap)
> 
> 
> 
>> There have been anecdotal reports on the Tor
>> bug tracker that hidden services have trouble scaling to more than 100
>> concurrent connections [2]. Is this something that operators here have
>> experienced?
> 
> it would be nice to speak of hidden service establishment rates across
> distinct number of onions, rather than a simple frequency counter.
> specifically, high establishment rates over many onions is the most
> performance intensive use case unless under attack of any myriad
> sort...
> 
> conversely, if in a constrained environment like old computer or small
> device, using only a couple onions, for light traffic is advised.
> 
> 
> 
>> There has also been recent DoS campaigns affecting Tor
>> hidden services which have been challenging to mitigate.
> 
> one word: blowback.
> [ maybe #FreeRedTeam ? gotta make lemonade, sweet sweet lemonade ]
> 
> 
> 
>> In my project I hope to produce a tool which will allow a hidden service
>> to be backed my multiple Tor instances which can be spread across
>> multiple servers and geographical locations.
> 
> in the 50G mirror experiment, even while under volatile network
> conditions, this technique - using many concurrently active onions -
> worked well and kept throughput and availability consistently robust.
> bigsun dist uses 9 onions across three physical hosts, for reference.
> 
> 
> 
>> - Redundant hidden service hosting with no single point of failure.
> 
> #1 useful.
> 
> 
> 
> 
>> - Secure storage of hidden service keys away from the Tor service on
>>   smartcards or HSM's
> 
> #2 useful.
> 
> 
> 
>> - From a security perspective, would you prefer to minimize the
>> software running on the onion service instance servers or minimize
>> connections to the management server which has access to the service keys?
> 
> both, #3 useful.
> 
> 
> 
>> I've anyone has time to share, I'd be very interested in learning about
>> your experiences and current challenges. I'd also be delighted to hear
>> about any other features that may be useful to the HS community.
> 
> this should be a trac, wiki, or doc? :P
> 
> 
> best regards,
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 26 May 2015 18:40:03 -0400
> From: "l.m" <ter.one.leeboi@xxxxxxxx>
> To: "tor-talk" <tor-talk@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [tor-talk] SOCKS proxy to sit between user and Tor?
> Message-ID: <20150526224003.56E45E0488@xxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="UTF-8"
> 
> I'd like to point out that if you decide to use another SOCKS proxy
> you may encounter another problem. Suppose I bypass the port assigned
> to your custom proxy and instead point to the usual tor proxy. This
> might occur if a user manually configures the proxy and cannot tell
> the difference between the two. Most likely it'll fail and they'll
> notice. In a worst case, your blockchain resolves are bypassed and a
> leak occurs. 
> 
> It also raises the question of whether you really want to have a SOCKS
> proxy for both regular firefox and tbb/tor.
> 
> --leeroy
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 26 May 2015 18:45:14 -0400
> From: "l.m" <ter.one.leeboi@xxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] SOCKS proxy to sit between user and Tor?
> Message-ID: <20150526224514.A7701E0488@xxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="UTF-8"
> 
> Of course turning off remote resolves to use a local resolver (free of
> conflicts) also has this downside. Settings persist between tbb launch
> so if remote DNS is turned off and a local resolver is down a leak
> occurs using the system DNS.
> 
> If anything, for the sake of your sanity try to keep everything in the
> plugin.
> 
> On 5/26/2015 at 6:40 PM, "l.m"  wrote:I'd like to point out that if
> you decide to use another SOCKS proxy
> you may encounter another problem. Suppose I bypass the port assigned
> to your custom proxy and instead point to the usual tor proxy. This
> might occur if a user manually configures the proxy and cannot tell
> the difference between the two. Most likely it'll fail and they'll
> notice. In a worst case, your blockchain resolves are bypassed and a
> leak occurs. 
> 
> It also raises the question of whether you really want to have a SOCKS
> proxy for both regular firefox and tbb/tor.
> 
> --leeroy
> 
> -- 
> 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
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 27 May 2015 01:36:33 +0200
> From: carlo von lynX <lynX@xxxxxxxxxxxxxxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Mailpile SMTorP [ref: nexgen P2P email]
> Message-ID: <20150526233633.GA1790@xxxxxxxxxxxxx>
> Content-Type: text/plain; charset=us-ascii
> 
>> On Thu, May 21, 2015 at 12:03:24PM -0700, Yuri wrote:
>> On one hand, Mailpile is after security, which is great. But on the
>> other hand they use node which doesn't sign packages, therefore
> 
> What a shame! Somebody please fix this node thing. I can't
> believe these nodejs enthusiastos are playing around with all 
> kinds of crypto something javascript applications but build 
> on top of a house of cards.
> 
> I still have plenty of criticism for SMTP and the idea of
> doing PGP on top of SMTP but having the server run as a
> hidden service from my own laptop gives this architecture
> quite a legitimacy boost.
> 
> While with a mail system like Pond the few popular servers
> can be deanonymized by confirmation attack, then taken over
> by authorities and subdued to send traffic shaped messages
> back to the users, thus slowly deanonymizing the entire
> social graph of Pond users... SMTorP appears to me to be a
> better idea.
> 
> With both send and reception points on the user's laptop,
> an attacker that wants to inject a traffic shape into the
> Tor network needs to take over the laptop itself. From my
> understanding there is no other place on the network
> where that sort of attack would be successful.
> 
> If that is true, that would be a great progress. Too bad
> that the old problem of both having to be online at the
> same time is re-introduced. We could have started using
> Retroshare over Tor two years ago to achieve the same goal.
> Retroshare looks a little less fancy than Mailpile, but
> it doesn't need any pip or node.
> 
> Also Framstag's sendfile SAFT implementation can be a neat
> quickfix solution. The server is easily pluggable into a
> hidden service and provides for mail-like spooling of 
> messages and native binary file transfers, without all
> the overhead of e-mail.
> 
> 
> -- 
>  E-mail is public! Talk to me in private using Tor.
>  torify telnet loupsycedyglgamf.onion        DON'T SEND ME
>          irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
>         http://loupsycedyglgamf.onion/LynX/    OR FACEBOOGLE
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 26 May 2015 17:50:40 -0700
> From: Mike Ingle <mike@xxxxxxxxxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx, lynX@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [tor-talk] Confidant Mail, was re:  Mailpile SMTorP
> Message-ID: <556514E0.1020205@xxxxxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Confidant Mail is another next-gen mail architecture worth a look. You 
> can access
> servers directly, via exit node, via hidden service, or via I2P. You can 
> have your mail
> hosted on your own server, on someone else's server, or in the 
> Distributed Hash Table.
> In the "server" case there is no limit on attachment size. You do not 
> have to be online at
> the same time as the recipient.
> 
> It's written in Python and uses PyOpenSSL and gnupg encryption. If you 
> are looking for
> next gen email over Tor, look here: https://www.confidantmail.org
> 
> Mike
> 
>> On 5/26/2015 4:36 PM, carlo von lynX wrote:
>>> On Thu, May 21, 2015 at 12:03:24PM -0700, Yuri wrote:
>>> 
>>> On one hand, Mailpile is after security, which is great. But on the
>>> other hand they use node which doesn't sign packages, therefore
>> 
>> What a shame! Somebody please fix this node thing. I can't
>> believe these nodejs enthusiastos are playing around with all 
>> kinds of crypto something javascript applications but build 
>> on top of a house of cards.
>> 
>> I still have plenty of criticism for SMTP and the idea of
>> doing PGP on top of SMTP but having the server run as a
>> hidden service from my own laptop gives this architecture
>> quite a legitimacy boost.
>> 
>> While with a mail system like Pond the few popular servers
>> can be deanonymized by confirmation attack, then taken over
>> by authorities and subdued to send traffic shaped messages
>> back to the users, thus slowly deanonymizing the entire
>> social graph of Pond users... SMTorP appears to me to be a
>> better idea.
>> 
>> With both send and reception points on the user's laptop,
>> an attacker that wants to inject a traffic shape into the
>> Tor network needs to take over the laptop itself. From my
>> understanding there is no other place on the network
>> where that sort of attack would be successful.
>> 
>> If that is true, that would be a great progress. Too bad
>> that the old problem of both having to be online at the
>> same time is re-introduced. We could have started using
>> Retroshare over Tor two years ago to achieve the same goal.
>> Retroshare looks a little less fancy than Mailpile, but
>> it doesn't need any pip or node.
>> 
>> Also Framstag's sendfile SAFT implementation can be a neat
>> quickfix solution. The server is easily pluggable into a
>> hidden service and provides for mail-like spooling of 
>> messages and native binary file transfers, without all
>> the overhead of e-mail.
> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Tue, 26 May 2015 21:10:36 -0400
> From: Jonathan Wilkes <jancsika@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Mailpile SMTorP [ref: nexgen P2P email]
> Message-ID: <5565198C.2000701@xxxxxxxxx>
> Content-Type: text/plain; charset=windows-1252; format=flowed
> 
>> On 05/26/2015 07:36 PM, carlo von lynX wrote:
>>> On Thu, May 21, 2015 at 12:03:24PM -0700, Yuri wrote:
>>> On one hand, Mailpile is after security, which is great. But on the
>>> other hand they use node which doesn't sign packages, therefore
>> What a shame! Somebody please fix this node thing. I can't
>> believe these nodejs enthusiastos are playing around with all
>> kinds of crypto something javascript applications but build
>> on top of a house of cards.
>> 
>> I still have plenty of criticism for SMTP and the idea of
>> doing PGP on top of SMTP but having the server run as a
>> hidden service from my own laptop gives this architecture
>> quite a legitimacy boost.
>> 
>> While with a mail system like Pond the few popular servers
>> can be deanonymized by confirmation attack, then taken over
>> by authorities and subdued to send traffic shaped messages
>> back to the users, thus slowly deanonymizing the entire
>> social graph of Pond users... SMTorP appears to me to be a
>> better idea.
>> 
>> With both send and reception points on the user's laptop,
>> an attacker that wants to inject a traffic shape into the
>> Tor network needs to take over the laptop itself. From my
>> understanding there is no other place on the network
>> where that sort of attack would be successful.
>> 
>> If that is true, that would be a great progress. Too bad
>> that the old problem of both having to be online at the
>> same time is re-introduced. We could have started using
>> Retroshare over Tor two years ago to achieve the same goal.
>> Retroshare looks a little less fancy than Mailpile, but
>> it doesn't need any pip or node.
>> 
>> Also Framstag's sendfile SAFT implementation can be a neat
>> quickfix solution. The server is easily pluggable into a
>> hidden service and provides for mail-like spooling of
>> messages and native binary file transfers, without all
>> the overhead of e-mail.
> 
> What about Bitmessage?
> 
> -Jonathan
> 
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> 
> 
> ------------------------------
> 
> End of tor-talk Digest, Vol 52, Issue 53
> ****************************************
-- 
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