On Sunday 02 November 2014 11:52:48 Aymeric Vitte wrote:
> > Yeah I guess we are less "marketing oriented" perhaps even to a fault.
> > Anonabox definitely kicked up more interest than Cloak have done so far.
> I don't know how anonabox did to attract so many people so quickly, I
> guess they ha
On Monday 03 November 2014 08:06:37 CJ wrote:
> hmm, either certificate pinning, or signature check with some gpg key —
> though this might be a bit hard for embedded stuff… ?
> Anyway, having "a way to validate" the update would be necessary.
I guess a certificate check is the best way to protect
On Thursday 06 November 2014 05:41:09 coderman wrote:
> > I will definitely look into this one. This should be quite easy to
> > implement by messing a bit with the firewall tables :)
> > Only problem I see is that to make it useful I think it would have to time
> > out at some point.
> in the pas
On Friday 07 November 2014 17:29:23 Aymeric Vitte wrote:
> And 5 "do not send anything outside", no? Usually you can restrict with
> your ISP box but can you trust it?
> What happens if you connect directly your PC to the Cloak with a cable?
I haven't really decided. The box have a wan as well a
On Friday 07 November 2014 14:18:53 hellekin wrote:
> > - force ssl through Tor, non ssl outside
> *** Is that what you meant? Can you explain why?
I reckon if the multiple WiFi idea is considered the best approach the
"everything through tor" interface should allow HTTP as well as HTTPS, while
thanks for the transparency, nachash! i am putting this conversation
on tor-talk, since my replies are more noise and less dev, and the
details seem to be around Tor use and configuration.
On 11/8/14, Fears No One wrote:
> ... Another regret is that pcaps weren't taken, but we both made
> the mi
On 11/9/14, coderman wrote:
> ...
> Andrea's distribution shows this type of behavior, as i would expect it:
> https://people.torproject.org/~andrea/loldoxbin-logs/analysis/length_distribution.txt
> e.g. send small bits to keep connection active and not closed by
> server side client send timeouts
On 11/7/14, Mirimir wrote:
>> ...
>> "Something to note from that graph: There were lots of very odd layer
>> 7 ddos requests which affected tor performance moreso than anything
>> ... like my TCP buffers weren't even close to max, but I had to mess
>> with the ContrainedSockets options in torrc i
Answering your different emails at once:
- anonathing indiegogo: incredible... you can be sure that these guys
are cheating on the crowdfunding campaign, as far as they can
- configuration: as you say the less needs to be configired, the better,
but I am not sure we will reach a consensus of
On 11/7/14, Öyvind Saether wrote:
> "The BBC understands that the raid represented both a technological
> breakthrough - with police using new techniques to track down the
> physical location of dark net servers ..."
>
> There you have it: An admission that Yes, they really can locate the
> Tor hi
Hi,
I made a query to my index. According to Ahmia.fi's data these sites show
the take down notice:
http://dxwmc6b3mtklq44j.onion/
http://hydrampvvnunildl.onion/
http://exposed36mq3ns23.onion/
http://qbikfpcr4mhqoumm.onion/
http://silkroad6ownowfk.onion/
http://lygnimwoedhioopl.onion/
http://doxb
On 11/9/14, coderman wrote:
> ...
> your ConstrainedSockets experiments are exactly what i would expect to
> see if this technique were used, since reducing socket buffers would
> allow you to have more concurrent connections open (and thus thwart a
> DoS at lower limits).
someone asked, "then wh
On 11/9/14, coderman wrote:
> ...
> all signs point to modified slowloris with a limited set of suspects.
or was it RELAY_EARLY?
https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
you could also use the attack above as "parallel construction" for
min
On Sun, Nov 09, 2014 at 05:31:47AM -0800, coderman wrote:
> On 11/9/14, coderman wrote:
> > ...
> > your ConstrainedSockets experiments are exactly what i would expect to
> > see if this technique were used, since reducing socket buffers would
> > allow you to have more concurrent connections open
Griffin, Matt, Adam, Roger, David, George, Karen, and Jake worked on a
wonderful write up of all the questions and concerns regarding this
Op:
https://blog.torproject.org/blog/thoughts-and-concerns-about-operation-onymous
thank you!
also,
the performance link to doc/TUNING shows it could use mu
> i'm going to laugh if the "technological breakthrough" is a DoS
> slowing Tor enough you restart it. then they watch to see who (serving
> up the appropriate amount of more traffic out than in) just restarted
> Tor.
> all signs point to modified slowloris with a limited set of suspects.
We can n
> Another way to test is for someone to use perfect opsec (wifi, tor,
> bitcoin, etc), and actually run a number of illegal sites and see what
> happens. Then consider some sites may be allowed to live even if
> actionable, or simply won't be taken down if there are no real world
> links to act on.
I understand. No one wants to do that. But they do because that's the
only solution. Changing identities shouldn't lessen anonymity for
https://startpage. I say shouldn't because depending on how you use
the new identity feature it's possible to have existing connections
still open on your old
On Sun, Nov 9, 2014 at 11:08 AM, Andrea Shepard wrote:
> Yes, and that is what it looks like. The strings 'code', 'old' and 'fail' in
> the URLs seen in nachash's logs were also present as top-level directories on
> his site, and he apparently had a 404 redirect to his index page - so a
> buggy c
I didn't judge anyone. I specifically said they have the 'alleged'
owner. I said good riddance to SR2 and it's ilk. Tor isn't an
environment of your freedom. It only ever has the potential to be. You
live in a world where your freedom is an ideal that only exists in
your head. If it did exist, and
Hi everyone,
I'd like to share some advice to operators of hidden services in order
to mitigate the attack family known as "traffic confirmation" attacks.
(I say mitigate because the early implementation of these attacks
are likely trivial enough to be defended against, for now, but will
get much
On Fri, Sep 12, 2014 at 3:51 PM, Fabio Pietrosanti (naif)
wrote:
> about a month ago i wanted to verify if someone is actively crawling
> TorHS that are inside the memory of Tor HS directories.
>
> So, i've setup a small Tor Hidden Service Honeypot at home with unknown,
> unpublished, non-publicly
On Fri, Nov 7, 2014 at 7:22 PM, grarpamp wrote:
> via public papers on locating hidden secvices
> [Trawling TorHS, Sniper]
On the other hand, if you suspect that, and estimate that it can
only succeed after timeframe, simply play shellgame and move
to new HS every timeframe/2. Vanity is your enem
On Sun, Nov 09, 2014 at 08:48:35AM -0800, coderman wrote:
> Griffin, Matt, Adam, Roger, David, George, Karen, and Jake worked on a
> wonderful write up of all the questions and concerns regarding this
> Op:
>
> https://blog.torproject.org/blog/thoughts-and-concerns-about-operation-onymous
>
Than
On 11/9/14, grarpamp wrote:
> ...
> HS operators banding together to compare the above logs is one
> of them. You could conceivably throw the logs/pcaps from many
> relays and onions into a splunk.onion instance and try to mine some
> knowledge out of them that way. Tor is a jointly owned wide are
On Sun, Nov 9, 2014 at 11:48 AM, coderman wrote:
> Op:
> https://blog.torproject.org/blog/thoughts-and-concerns-about-operation-onymous
Bitcoin deanonymization
Ivan Pustogarov et al. have recently been conducting interesting
research on Bitcoin anonymity.
Apparently, there are ways to link transa
On 7 November 2014 20:13, Juan wrote:
> On Fri, 7 Nov 2014 13:04:38 +0200
> Jon Tullett wrote:
>
>> On 7 November 2014 05:39, Juan wrote:
>> > So why would people be tracked in the first place? Are
>> > you saying that the US government nazis track all of US
>> > subjects
27 matches
Mail list logo
