Re: [tor-relays] Delete keys on reboot

[Andreas Krey]

On Wed, 22 Apr 2015 22:56:31 +, CJ Barlow wrote:
> If I run
> 
> rm -f /var/lib/tor/keys/* 2>&1 >> /home/[me]/reboot.txt
> 
> it  doesn't error (as long as I run it with sudo) but it also doesn't do
> anything,

You might do

(ls -lart /var/lib/tor/keys
 echo /var/lib/tor/keys/*
 rm -f /var/lib/tor/keys/*
 ls -lart /var/lib/tor/keys
 ) 2>&1 >> /home/[me]/reboot.txt

too see if it does (and match) anything.

> checking *keys *shows it still contains files.

Sure that those aren't already regenerated keys
from a new tor instance?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Delete keys on reboot

[CJ Barlow]

If I run

rm -f /var/lib/tor/keys/* 2>&1 >> /home/[me]/reboot.txt

it  doesn't error (as long as I run it with sudo) but it also doesn't do
anything, checking *keys *shows it still contains files.

I read the RAM disk tutorial that is linked on the Tor Relay Security page,
what I don't understand is how the keys are created and stored solely in
RAM. When launching tor for the first time (say "sudo apt-get purge Tor"
then "sudo apt-get install Tor") the *keys* folder does not exist. Would I
just mount the whole /var/lib/tor folder in RAM instead or is there a
better way to do it?

On Wed, Apr 22, 2015 at 6:06 AM, Toralf Förster 
wrote:

> On 04/22/2015 06:29 AM, CJ Barlow wrote:
> > @reboot rm -f /var/lib/tor/keys/* && echo "keys gone!" >
> > /home/[me]/reboot.txt 2>&1
>
> What's about
>
> rm -f /var/lib/tor/keys/* 2>&1 >> /home/[me]/reboot.txt
>
> to see the error msg ?
>
> --
> Toralf
> pgp key: 7B1A 07F4 EC82 0F90 D4C2  8936 872A E508 0076 E94E
> --
> "; the past is all dirty and cruel in the modern popular imagination, with
> the exception of the Romans, who are just cruel"
> Ian Mortimer, 2008, "The Time Traveller's Guide to Medieval England"
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Quantum Insert detection for everyone

[David Stainton]

>> TCP injection attacks are not the same as man-in-the-middle
>> attacks... but rather are categorized as man-on-the-side. The
>> difference is important because MoS is *much* cheaper for these
>> various (not just NSA) entities to execute. MoS means you do not
>> have to pwn a route endpoint at the site of your TCP injections...
>> you can inject from almost anywhere as long as you can win the
>> race.
>>
>> I will discuss this point in my write up... and I will write a
>> section specifically for Tor exit relay operators who are
>> interested in using HoneyBadger.
>
> What about the approach of detecting/preventing those attacks at the
> user endpoint. Like enforcing HTTPS-connection (HTTPS-Everywhere) and
> prohibiting/announcing redirects.

Tor users will not be able to detect these attacks on their
infrastructure; hence my message to Tor exit relay operators.

It is possible to add a "prevention" mechanism to HoneyBadger; an
event based firewall ruleset generator made to block TCP injection
attacks as they are happening... yes. This is possible. I could write
that if there was interest from enough people.

Yes... users of the Internet should give up using plain-text protocols
to stay safer. HTTPS-Everywhere and the various other related efforts
by the EFF are all a great help towards keeping people safer.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Quantum Insert detection for everyone

[janulrich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for your reply

David Stainton wrote:
> Yes and no. HTTPS/Onion services prevents successful TCP injection 
> attacks when the attacker doesn't know the key material...
> therefore to make this claim about HTTPS in general seems rather
> sketchy given that many CA's have been pwn'ed (and subpoena'ed?) in
> the past.

Haha, you're right! HTTPS key exchange is broke. Always a good laugh,
though.

> TCP injection attacks are not the same as man-in-the-middle
> attacks... but rather are categorized as man-on-the-side. The
> difference is important because MoS is *much* cheaper for these
> various (not just NSA) entities to execute. MoS means you do not
> have to pwn a route endpoint at the site of your TCP injections...
> you can inject from almost anywhere as long as you can win the
> race.
> 
> I will discuss this point in my write up... and I will write a
> section specifically for Tor exit relay operators who are
> interested in using HoneyBadger.

What about the approach of detecting/preventing those attacks at the
user endpoint. Like enforcing HTTPS-connection (HTTPS-Everywhere) and
prohibiting/announcing redirects.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJVOCTdAAoJEJLecH4ruDZd/OQH/Rairg+tY0CUFDYqz7WiD9O+
87I8/lOGGQ43NnXHfp7D/tkO+L8ZLvVrXIj65x9wx/HfkTk284i6oMD8939CSviO
xUkrXvTzgEk2NB+sQJszxftW3tGknDj6DGPDax+eiQDF7BB+cuWzoV4ufFA1OmGr
08X+eq8IuGbHLwdML6WqgvOicjy0m7ME1kbKLEuat8UzAyeUjCkxXmncAdcqUPZr
Ng8iBS20jDGYv7mAifeKZd/i20oUAiZc7fH9210ZcxVIAHQ2B14RDZN2KlFWFQTY
EiBW4GjLsI5NJs6boYoCtfM+8PYmebo1QT1gkueIXXhkeQ9Vl1TlKI+4OI4IAF0=
=O54P
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Quantum Insert detection for everyone

[David Stainton]

Yes and no. HTTPS/Onion services prevents successful TCP injection
attacks when the attacker doesn't know the key material... therefore
to make this claim about HTTPS in general seems rather sketchy given
that many CA's have been pwn'ed (and subpoena'ed?) in the past.

TCP injection attacks are not the same as man-in-the-middle attacks...
but rather are categorized as man-on-the-side. The difference is
important because MoS is *much* cheaper for these various (not just
NSA) entities to execute. MoS means you do not have to pwn a route
endpoint at the site of your TCP injections... you can inject from
almost anywhere as long as you can win the race.

I will discuss this point in my write up... and I will write a section
specifically for Tor exit relay operators who are interested in using
HoneyBadger.


On Wed, Apr 22, 2015 at 10:16 PM, janulrich  wrote:
> hi,
>
> Am 22.04.2015 um 20:41 schrieb David Stainton:
>> Did you all see this Wired article about Quantum Insert detection?
>>
>> https://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum-insert-hacks
>
> proof me wrong but wouldn't the use of a HTTPS/OnionAddress render this
> attack usesless?
>
> Whats up with the title "researchers uncover method"? Like this would be
> anything new?
> Basically it's the concept of a MITM attack which is a serious threat[1]
> as old as telecommunication itself.
> The only working solution is end to end encrypted communication.
> So why use inefficient and vulnerable "detection tools" to spy on tor users?
>
> humble opinion of a barely frightened tor user.
>
> [1]: Remark: There are sufficient opportunities for MITM attacks. (There
> are still guys out there surfing the web via GSM -broken crypto- on
> their mobiles.)
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Subpoena received

[janulrich]

Am 22.04.2015 um 21:39 schrieb grarpamp:
> Use what your mama gave you... put it on a hidden service.

Great idea: http://tke3zwmd6mnvq6jp.onion/AlistarSecuritySubpoena.pdf
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Quantum Insert detection for everyone

[janulrich]

hi,

Am 22.04.2015 um 20:41 schrieb David Stainton:
> Did you all see this Wired article about Quantum Insert detection?
> 
> https://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum-insert-hacks

proof me wrong but wouldn't the use of a HTTPS/OnionAddress render this
attack usesless?

Whats up with the title "researchers uncover method"? Like this would be
anything new?
Basically it's the concept of a MITM attack which is a serious threat[1]
as old as telecommunication itself.
The only working solution is end to end encrypted communication.
So why use inefficient and vulnerable "detection tools" to spy on tor users?

humble opinion of a barely frightened tor user.

[1]: Remark: There are sufficient opportunities for MITM attacks. (There
are still guys out there surfing the web via GSM -broken crypto- on
their mobiles.)
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] ARM stopped working

[CJ Barlow]

Check the settings of your log rotate as well. If logs are causing the
space issue that will help clear it up.
On Apr 22, 2015 1:37 PM, "Jeffrey Hathaway"  wrote:

> Hello Everyone,
>
> I noticed ARM stopped working for me.  Has anyone seen this before?
>
> Traceback (most recent call last):
>   File "/usr/share/arm/starter.py", line 578, in 
> cli.controller.startTorMonitor(time.time() - initTime)
>   File "/usr/share/arm/cli/controller.py", line 700, in startTorMonitor
> curses.wrapper(drawTorMonitor, startTime)
>   File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
> return func(stdscr, *args, **kwds)
>   File "/usr/share/arm/cli/controller.py", line 720, in drawTorMonitor
> initController(stdscr, startTime)
>   File "/usr/share/arm/cli/controller.py", line 86, in initController
> firstPagePanels.append(cli.logPanel.LogPanel(stdscr, expandedEvents,
> config))
>   File "/usr/share/arm/cli/logPanel.py", line 652, in __init__
> self.reprepopulateEvents()
>   File "/usr/share/arm/cli/logPanel.py", line 696, in reprepopulateEvents
> torEventBacklog = getLogFileEntries(setRunlevels, readLimit, addLimit,
> self._config)
>   File "/usr/share/arm/cli/logPanel.py", line 313, in getLogFileEntries
> eventTimeComp = list(time.strptime(timestamp, "%Y %b %d %H:%M:%S"))
>   File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time
> return _strptime(data_string, format)[0]
>   File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
> (data_string, format))
> ValueError: time data '2012
> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00Apr
> 22 15:23:48' does not match format '%Y %b %d %H:%M:%S'
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] [tor-talk] Quantum Insert detection for everyone

[Mike Perry]

I'm being a jerk and cross-posting to tor-relays, because I want to make
sure that relay operators are aware of the differences in the Snort vs
HoneyBadger approach.

Chris Dagdigian:
> 
> I run a US-based exit node and would be interested in a way to run
> this software without compromising the users exiting my node.
> Looking forward to your additional writeups - especially anything
> geared towards exit nodes and quantum insert detection.

I too look forward to David's writeup!

For what it's worth, I think HoneyBadger is likely to be safer for
exits, more comprehensive, more accurate, less noisy, and more high
performance than a Snort-based solution.

HoneyBadger is focused only on this particular attack and is written in
golang, whereas Snort has tons of rules for everything and is written in
C. This means that HoneyBadger will have a much smaller vulnerability
surface and should be much harder to directly exploit than Snort. Since
we're talking about detecting and capturing attacks from well funded
state/world-class adversaries here (wow, what a world), vulnerability
surface minimization and general memory safety are top priority.

Snort is also vulnerable to tailored attacks designed to flood its logs
and/or avoid detection. Snort is particularly susceptible to missing
stateful attacks designed to subvert its stateless rule-based approach to
detection. Several types of TCP injection attacks that rely on TCP
reassembly will likely fall into this category (type 4 in:
https://honeybadger.readthedocs.org/en/latest/#tcp-injection-attacks).

HoneyBadger also appears to have better logging options than the Snort
rules. David has been in contact with malware researchers who were quite
insistent that to properly analyze 0day, a single evilpacket is very
likely to be insufficient -- context is essential, especially if the
attacker wants to obfuscate the attack or otherwise avoid exploit
extraction.

Hence the need to provide optional full-take and rolling logging options
that make it easier to extract the full TCP stream of a tampered
connection, as well as related concurrent traffic (such as a stream from
a related HTTP redirect to an ephemeral URL). I've been talking with
David about ways to place these logs on a ramdisk or an ephemerally
encrypted partition, so that when detailed logs are needed, they can be
handled as safely as possible.

> >David Stainton 
> >April 22, 2015 at 2:41 PM
> >Greetings,
> >
> >Did you all see this Wired article about Quantum Insert detection?
> >
> >https://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum-insert-hacks
> >
> >These TCP injection attacks are used by various entities around the
> >world (not just NSA!) to target individuals for surveillance or
> >perhaps to add their computers to a botnet for other purposes.
> >
> >If you do not use a VPN or Tor you can run "Quantum Insert" detection
> >on your computer and detect when you receive an attack attempt.
> >However be advised that proper sandboxing is important here because
> >intrusion detection and protocol anylsis tools are notoriously
> >insecure and get pwned all the time.
> >
> >If you are a Tor exit relay operator you have the options of running
> >detection software; However you should not publish the results
> >publicly without mixing in some noise or your published data might
> >make it possible for some adversaries to deanonymize Tor users. If
> >your country has strict telecommunications laws then it might only be
> >legal for you to perform this type of detection if you do not perform
> >logging.
> >
> >For the past several months... in my free time I've been slowly
> >developing a very comprehensive TCP injection attack detection tool
> >called HoneyBadger:
> >
> >https://github.com/david415/HoneyBadger
> >
> >Quantum Insert is a NSA codeword for "TCP injection attack", however
> >either of these terms are too vague. During my research I was able to
> >classify 4 different types of TCP injection attack. When I say that
> >HoneytBadger is comprehensive what I mean is that Honeybadger can
> >detect ALL of these types of TCP injection attack types... I describe
> >them briefly here:
> >
> >https://honeybadger.readthedocs.org/en/latest/
> >
> >Here's the Fox-IT blog post about their Quantum Insert detection software:
> >http://blog.fox-it.com/2015/04/20/deep-dive-into-quantum-insert/
> >
> >I am going to work on writing a much more comprehensive blog post; it
> >will be filled with gory technical details AND it will include
> >information on how to use HoneyBadger. HoneyBadger has optional (off
> >by default) full-take logging which could enable you to capture a
> >zero-day payload from a TCP attack; you should then responsibly
> >disclose to the software vendor or contact a malware analyst to help
> >out!
> >
> >
> >Sincerely,
> >
> >David Stainton

-- 
Mike Perry


signature.asc
Description: Digital signature
___

Re: [tor-relays] ARM stopped working

[Damian Johnson]

Hi Jeffery. Think I've seen that before, and it was due to running out
of disk space so the log file was truncated. Try shutting down tor,
moving the log file aside, clearing up some space (if you're out),
then starting tor back up so you have a fresh log file.

Cheers! -Damian


On Wed, Apr 22, 2015 at 12:37 PM, Jeffrey Hathaway  wrote:
> Hello Everyone,
>
> I noticed ARM stopped working for me.  Has anyone seen this before?
>
> Traceback (most recent call last):
>   File "/usr/share/arm/starter.py", line 578, in 
> cli.controller.startTorMonitor(time.time() - initTime)
>   File "/usr/share/arm/cli/controller.py", line 700, in startTorMonitor
> curses.wrapper(drawTorMonitor, startTime)
>   File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
> return func(stdscr, *args, **kwds)
>   File "/usr/share/arm/cli/controller.py", line 720, in drawTorMonitor
> initController(stdscr, startTime)
>   File "/usr/share/arm/cli/controller.py", line 86, in initController
> firstPagePanels.append(cli.logPanel.LogPanel(stdscr, expandedEvents,
> config))
>   File "/usr/share/arm/cli/logPanel.py", line 652, in __init__
> self.reprepopulateEvents()
>   File "/usr/share/arm/cli/logPanel.py", line 696, in reprepopulateEvents
> torEventBacklog = getLogFileEntries(setRunlevels, readLimit, addLimit,
> self._config)
>   File "/usr/share/arm/cli/logPanel.py", line 313, in getLogFileEntries
> eventTimeComp = list(time.strptime(timestamp, "%Y %b %d %H:%M:%S"))
>   File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time
> return _strptime(data_string, format)[0]
>   File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
> (data_string, format))
> ValueError: time data '2012
> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00Apr
> 22 15:23:48' does not match format '%Y %b %d %H:%M:%S'
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Subpoena received

[grarpamp]

Mega? A dotcom? Really people? Come on, that's soo legacy.
Use what your mama gave you... put it on a hidden service.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] ARM stopped working

[Jeffrey Hathaway]

Hello Everyone,

I noticed ARM stopped working for me.  Has anyone seen this before?

Traceback (most recent call last):
  File "/usr/share/arm/starter.py", line 578, in 
cli.controller.startTorMonitor(time.time() - initTime)
  File "/usr/share/arm/cli/controller.py", line 700, in startTorMonitor
curses.wrapper(drawTorMonitor, startTime)
  File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper
return func(stdscr, *args, **kwds)
  File "/usr/share/arm/cli/controller.py", line 720, in drawTorMonitor
initController(stdscr, startTime)
  File "/usr/share/arm/cli/controller.py", line 86, in initController
firstPagePanels.append(cli.logPanel.LogPanel(stdscr, expandedEvents,
config))
  File "/usr/share/arm/cli/logPanel.py", line 652, in __init__
self.reprepopulateEvents()
  File "/usr/share/arm/cli/logPanel.py", line 696, in reprepopulateEvents
torEventBacklog = getLogFileEntries(setRunlevels, readLimit, addLimit,
self._config)
  File "/usr/share/arm/cli/logPanel.py", line 313, in getLogFileEntries
eventTimeComp = list(time.strptime(timestamp, "%Y %b %d %H:%M:%S"))
  File "/usr/lib/python2.7/_strptime.py", line 467, in _strptime_time
return _strptime(data_string, format)[0]
  File "/usr/lib/python2.7/_strptime.py", line 325, in _strptime
(data_string, format))
ValueError: time data '2012
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00Apr
22 15:23:48' does not match format '%Y %b %d %H:%M:%S'
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Subpoena received

[Richard Johnson]

On 2015-04-20 08:32, Tyler Durden wrote:

Hi
I just wanted to let you know that Washington sent us a subpoena
regarding one of our exit nodes in Romania. They want to know the real
IP behind the Tor Network. I mailed them what Tor is and why I can't
help them in identifying this person. Nevertheless I will give you the
link to the full subpoena. Maybe you guys find it interesting. I will
forward the subpoena to our lawyer as well.


https://mega.co.nz/#!ilIjlZSb!-deirKharWaDtp_UMxhev58E14zeouyoWUbzxeWPvEQ

Greetings




Might you be able to make a copy available at a non-Flash-afflicted tracking 
site, by any chance?  Mega actually works more poorly (Flash-affliction) than 
the typical scripty-crazy 'download' sites.



Richard

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Quantum Insert detection for everyone

[David Stainton]

Greetings,

Did you all see this Wired article about Quantum Insert detection?

https://www.wired.com/2015/04/researchers-uncover-method-detect-nsa-quantum-insert-hacks

These TCP injection attacks are used by various entities around the
world (not just NSA!) to target individuals for surveillance or
perhaps to add their computers to a botnet for other purposes.

If you do not use a VPN or Tor you can run "Quantum Insert" detection
on your computer and detect when you receive an attack attempt.
However be advised that proper sandboxing is important here because
intrusion detection and protocol anylsis tools are notoriously
insecure and get pwned all the time.

If you are a Tor exit relay operator you have the options of running
detection software; However you should not publish the results
publicly without mixing in some noise or your published data might
make it possible for some adversaries to deanonymize Tor users. If
your country has strict telecommunications laws then it might only be
legal for you to perform this type of detection if you do not perform
logging.

For the past several months... in my free time I've been slowly
developing a very comprehensive TCP injection attack detection tool
called HoneyBadger:

https://github.com/david415/HoneyBadger

Quantum Insert is a NSA codeword for "TCP injection attack", however
either of these terms are too vague. During my research I was able to
classify 4 different types of TCP injection attack. When I say that
HoneytBadger is comprehensive what I mean is that Honeybadger can
detect ALL of these types of TCP injection attack types... I describe
them briefly here:

https://honeybadger.readthedocs.org/en/latest/

Here's the Fox-IT blog post about their Quantum Insert detection software:
http://blog.fox-it.com/2015/04/20/deep-dive-into-quantum-insert/

I am going to work on writing a much more comprehensive blog post; it
will be filled with gory technical details AND it will include
information on how to use HoneyBadger. HoneyBadger has optional (off
by default) full-take logging which could enable you to capture a
zero-day payload from a TCP attack; you should then responsibly
disclose to the software vendor or contact a malware analyst to help
out!


Sincerely,

David Stainton
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Subpoena received

[Tyler Durden]

I'm in contact with Moritz and yes we told them from the beginning what
our organization does and what Tor is. We had no problems so far. I'm as
surprised as you guys. Voxility/Alistaro was always very Tor friendly.

On 2015-04-22 19:08, Speak Freely wrote:
> All I can say is reach out to EFF and Moritz.
>
> I am surprised and saddened to hear this.
>
> Have you told your ISP about Tor? Did you tell them in advance of
> setting up the relay what it is, and what it is not?
>
>
> Kind regards,
>
> Matt
> Speak Freely
>
> Tyler Durden:
>> Now Alistaro (our ISP) wants the IPs as well or they will probably shut
>> down the server tomorrow.
>>
>>
>> Well that escalated quickly.
>>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


-- 
Sam Grüneisen - President
Frënn vun der Ënn A.S.B.L.
enn.lu

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Subpoena received

[Speak Freely]

All I can say is reach out to EFF and Moritz.

I am surprised and saddened to hear this.

Have you told your ISP about Tor? Did you tell them in advance of
setting up the relay what it is, and what it is not?


Kind regards,

Matt
Speak Freely

Tyler Durden:
> Now Alistaro (our ISP) wants the IPs as well or they will probably shut
> down the server tomorrow.
> 
> 
> Well that escalated quickly.
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Subpoena received

[Tyler Durden]

Now Alistaro (our ISP) wants the IPs as well or they will probably shut
down the server tomorrow.


Well that escalated quickly.

-- 
Sam Grüneisen - President
Frënn vun der Ënn A.S.B.L.
enn.lu

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Wj%#qpkkn

[Vitalie]

XaLloukkkl


Zp
Eeddpprriioxzlal

Pzjmmp 


--whmllpq,ukInviato dal l cellulare Andropf K-9 Mail.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Delete keys on reboot

[Toralf Förster]

On 04/22/2015 06:29 AM, CJ Barlow wrote:
> @reboot rm -f /var/lib/tor/keys/* && echo "keys gone!" >
> /home/[me]/reboot.txt 2>&1

What's about

rm -f /var/lib/tor/keys/* 2>&1 >> /home/[me]/reboot.txt

to see the error msg ?

-- 
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2  8936 872A E508 0076 E94E
--
"; the past is all dirty and cruel in the modern popular imagination, with the 
exception of the Romans, who are just cruel"
Ian Mortimer, 2008, "The Time Traveller's Guide to Medieval England"
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays