Re: [tor-talk] tor-talk Digest, Vol 77, Issue 9

[Seth David Schoen]

Suhaib Mbarak writes:

> I'm a master student and doing some researches on TOR . I'm using shadow
> simulator; not real tor network; my goal is only to run an experiment and
> from the output of that experiment I can confess my students that Tor
> really : [...]

It seems to me that one useful possibility is to modify the Tor client so
that it outputs logs of the decisions it makes and the actions it takes,
as well as, maybe, the cryptographic secrets that it uses.  For example,
your modified Tor client could print out how it chose a path, and the
actions that it took to build the path, and the actual encryption keys
that it used in communicating with the nodes along the path.

You could then also use a packet sniffer (or some mechanism for packet
capture if your network is totally virtual) to examine the actual
traffic in your simulated network, and, for example, to decrypt it using
the keys that were logged by the modified client, showing exactly what
information can be seen by someone in possession of each secret key, and
conversely which keys are necessary in order to learn which information.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] tor-talk Digest, Vol 77, Issue 9

[Suhaib Mbarak]

Thank you very much for your high response.

I'm a master student and doing some researches on TOR . I'm using shadow
simulator; not real tor network; my goal is only to run an experiment and
from the output of that experiment I can confess my students that Tor
really :


 1-  How the onion circuit was selected. ( or to figure out what was the
circuit selected)

 2-  Can keep the traffic anonymous.(at least through Tor onion circuit)

 3-  All handshakes done at each node on the circuit from entry node till
exit. (e.g encryption and decryption keys used on handshake at each node
including the directory authority server as well).

 4-  If there is away to show student that at each circuit nodes only the
successor and predecessor addresses not the original source or final
destination of the request.


Your help is extremely appreciated.

Thanks and Best Regards,
Suhaib





On 8 June 2017 at 14:37, <tor-talk-requ...@lists.torproject.org> wrote:

> Send tor-talk mailing list submissions to
> tor-talk@lists.torproject.org
>
> 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-requ...@lists.torproject.org
>
> You can reach the person managing the list at
> tor-talk-ow...@lists.torproject.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tor-talk digest..."
>
>
> Today's Topics:
>
>1. Re: "Some Tor Relays, you might want to avoid." (nusenu)
>2. Re: Upcoming Tor releases tomorrow,   to fix Hidden Service
>   remote DoS bugs (Nick Mathewson)
>3. Tor 0.3.1.3-alpha is released (with security fix for  hidden
>   services) (Nick Mathewson)
>4. Tor source code (Suhaib Mbarak)
>5. Re: Tor source code (Sebastian Niehaus)
>6. Re: Tor source code (Seth David Schoen)
>
>
> --
>
> Message: 1
> Date: Thu, 08 Jun 2017 15:24:00 +
> From: nusenu <nusenu-li...@riseup.net>
> To: tor-talk@lists.torproject.org
> Subject: Re: [tor-talk] "Some Tor Relays, you might want to avoid."
> Message-ID: <d4cd9470-fe10-d085-4e87-43f92f870...@riseup.net>
> Content-Type: text/plain; charset="utf-8"
>
> > On 05/09/2017 12:02 PM, nusenu wrote:
> >> I wrote a blog post about relay groups in end-to-end position:
> >
> >> https://medium.com/@nusenu/some-tor-relays-you-might-want-
> to-avoid-5901597ad821
> >
> >
> >
> > Has this any relation with the email subscription
> ornetra...@lists.riseup.net ?
>
> It uses the same data source (onionoo.torproject.org).
>
> > If nobody is aware of this, this is a great email list to subscribe to
> which broadcasts relays
> > with found correlations based on many variables.
>
> Since the email archive is basically unreadable due to the line breaks I
> added a HTML version of these emails. The URL can be found at the bottom
> of each email.
>
> Example: (hardly readable)
> http://xpgylzydxykgdqyg.onion/www/arc/ornetradar/2017-06/msg00033.html
>
> better:
> https://nusenu.github.io/OrNetRadar/2017/06/07/a9
>
>
>
> --
> https://mastodon.social/@nusenu
> https://twitter.com/nusenu_
>
> -- next part --
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 801 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/
> 20170608/0f075c99/attachment-0001.sig>
>
> --
>
> Message: 2
> Date: Thu, 8 Jun 2017 11:24:17 -0400
> From: Nick Mathewson <ni...@freehaven.net>
> To: "tor-talk@lists.torproject.org" <tor-talk@lists.torproject.org>
> Subject: Re: [tor-talk] Upcoming Tor releases tomorrow, to fix Hidden
> Service remote DoS bugs
> Message-ID:
> <CAKDKvuwo1xaeHdB+w0LQvOBq5YqiVFdNFHzbB5Gh5Gte_U=uCQ@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, Jun 7, 2017 at 11:15 AM, Nick Mathewson <ni...@freehaven.net>
> wrote:
> > Hi, all!
> >
> > Tomorrow we'll be putting out new releases in all supported series
> > (0.2.4 through 0.3.1) to fix two vulnerabilities that we have found in
> > the hidden service code. These vulnerabilities allow an attacker to
> > cause a hidden service to crash with an assertion failure.  We believe
> > that is the only impact.  We are tracking these vulnerabilities as
> > TROVE-2017-004 and TROVE-2017

Re: [tor-talk] Tor source code

[krishna e bera]

Am 08.06.2017 um 21:16 schrieb Suhaib Mbarak:
> My task goal is to show how Tor works and to proof that it
> relay anonymise user traffic...
> My question is to make sure wether tor source code is open and
> available for public or not?
> In case it is open source and can be modified how it is secure?


In addition to the generally better properties of open source free 
software explained by other folks on the list, the trustworthiness of 
the Tor source/binary packages and the Tor network is improved by:


1) GPG signing packages

https://www.torproject.org/docs/verifying-signatures.html.en


2) making deterministic builds

https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise
https://blog.torproject.org/blog/deterministic-builds-part-two-technical-details


3) adherence by staff to the Tor Social Contract and Ethical Resarch 
Guidelines


https://blog.torproject.org/blog/tor-social-contract
https://blog.torproject.org/blog/ethical-tor-research-guidelines


4) using best practices for cryptography and privacy by design

https://blog.torproject.org/blog/technology-hostile-states-ten-principles-user-protection


Hope this helps.


--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor source code

[Juan Miguel Navarro Martínez]

On 2017-06-08 at 21:16, Suhaib Mbarak wrote:
> My question is to make sure wether tor source code is open and available
> for public or not?
>
If it wasn't then no one would ever use such a software to achieve as
close as 100% anonymity. The moment some part is close sourced, it can
be used to put a backdoor or a "calling home" code which would give the
real IP to whoever was that code intended to receive.

> In case it is open source and can be modified how it is secure?
> 
You should read more about libre and open source software before making
such a question. But to keep it simple:

- The code is open for everyone to compile, modify and redistribute.
- All source code that comes from the official repository (Tor Project
one) has no third-party modification, so the code that you receive
should be as secure as it was developed.
- There are also the binary files released by Tor Project which should
be the product of compiling that same source code.
- Only a program is not secure if you got it from a shady place or you
modified yourself in an insecure way.

And if you think closed source software is more secure then you are
wrong. Not only you nor anyone else can't check if it is secure, you nor
anyone can't modify it (legally) to fix their insecurities until the
developers do so (if they do).

-- 
Juan Miguel Navarro Martínez

GPG Keyfingerprint:
5A91 90D4 CF27 9D52 D62A
BC58 88E2 947F 9BC6 B3CF



signature.asc
Description: OpenPGP digital signature
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor source code

[Seth David Schoen]

By the way, there's an interesting new study

https://www.ieee-security.org/TC/SP2017/papers/84.pdf

that claims that many people believe communications security is "futile"
because of inaccurate mental models of cryptography, and strongly
endorse security through obscurity.

I've been thinking a lot about these results (it's worth reading the
paper) and one way that I've been trying to conceive of it is that the
research showed that many participants thought that the developer of a
security technology must, inherently, always know how to crack or
defeat that technology.  This might be true at a technical level if
encryption always worked like a substitution cipher, where there is no
secret key but knowledge of the details of the cipher is equivalent to
knowing how to crack it, or if public key cryptography didn't exist,
so that many-to-many communications required trusted authorities to
distribute key material.

Participants in that study did not tend to feel that encryption software
ought to be open source because they seemed to believe that the
developer of a security tool inherently, so to speak, knows the code
and can always use that knowledge to break users' security.  In this
model other motivated attackers will gradually also learn the secret
knowledge that they need to break the system, but disclosing technical
details of how it works would be an especially bad idea because it would
greatly speed up the process for the attackers.  (Then security through
obscurity is understood to be the only possible form of security.)

The study suggests that an important challenge for developers of security
systems may be finding a way to communicate how security need not depend
on obscurity, and also need not depend on trusting inventors of security
systems to keep secrets.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor source code

[Seth David Schoen]

Suhaib Mbarak writes:

> Dear all.
> 
> My question is to make sure wether tor source code is open and available
> for public or not?

Yes, it has always been since the beginning of the project.  Currently,
the code is available at

https://gitweb.torproject.org/tor.git

> In case it is open source and can be modified how it is secure?

Open source means that anyone is allowed to make their own changes (and
share those with the public if they want), but there is an official
version from the Tor Project which only official Tor maintainers can
change.  The official Tor maintainers receive suggestions from the public,
but they make the final decision about whether or not other people's
changes can become part of the official version of Tor.

For example, if you wanted to change something, you could make your own
modified version without anyone's permission, but it wouldn't be the
official version.  You would need to ask the maintainers to adopt your
changes if you wanted them to become part of the official version.

There is still an interesting question about whether people could somehow
trick the Tor maintainers into including a change that is actually
detrimental, even though it appears to be useful.  In many ways, the Tor
project relies on public scrutiny to confirm that changes that get
included in the official version are useful and don't introduce problems
or security holes.  There is a fairly broad consensus that this is a
useful way to work, yet I don't think that people are confident that all
of the risk has been mitigated, since there are also security research
projects that show that there are ways of intentionally creating bugs
that are subtle and carefully disguised as useful functionality.

So, there is still a need for ongoing research about how to learn to
detect (whether by human knowledge, by coding standards, by using
different languages or libraries, by creating new software tools, or
by something call formal methods where properties of code are proven) if
people are trying to disguise or hide a bug or vulnerability inside of a
useful contribution.

The Tor Project has actually thought about this issue a lot, if you're
very interested in it... there are probably other resources and
presentations that you could look at that further examine the issue.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor source code

[Sebastian Niehaus]

Am 08.06.2017 um 21:16 schrieb Suhaib Mbarak:
> Dear all.
> 
> My question is to make sure wether tor source code is open and available
> for public or not?

http://lmgtfy.com/?q=tor+project+source+code


> In case it is open source and can be modified how it is secure?

Non sequitor

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Tor source code

[Suhaib Mbarak]

Dear all.

My question is to make sure wether tor source code is open and available
for public or not?
In case it is open source and can be modified how it is secure?

Thanks,
Suhaib Mubarak
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Tor 0.3.1.3-alpha is released (with security fix for hidden services)

[Nick Mathewson]

Hi!  The latest alpha, 0.3.1.3-alpha, is now released. The source is
available on the website, and packages should be available before too
long.  It has a security fix for hidden services, so if you are
running a hidden service, you should upgrade to this version (or to
one of the 7 other versions released today).

This is an alpha release: if you aren't up for finding and reporting
bugs, you should stick with a stable release series.

As usual, I'll be sending alpha announcements here, and stable
announcements to tor-announce.


Changes in version 0.3.1.3-alpha - 2017-06-08
  Tor 0.3.1.3-alpha fixes a pair of bugs that would allow an attacker to
  remotely crash a hidden service with an assertion failure. Anyone
  running a hidden service should upgrade to this version, or to some
  other version with fixes for TROVE-2017-004 and TROVE-2017-005.

  Tor 0.3.1.3-alpha also includes fixes for several key management bugs
  that sometimes made relays unreliable, as well as several other
  bugfixes described below.

  o Major bugfixes (hidden service, relay, security):
- Fix a remotely triggerable assertion failure when a hidden service
  handles a malformed BEGIN cell. Fixes bug 22493, tracked as
  TROVE-2017-004 and as CVE-2017-0375; bugfix on 0.3.0.1-alpha.
- Fix a remotely triggerable assertion failure caused by receiving a
  BEGIN_DIR cell on a hidden service rendezvous circuit. Fixes bug
  22494, tracked as TROVE-2017-005 and CVE-2017-0376; bugfix
  on 0.2.2.1-alpha.

  o Major bugfixes (relay, link handshake):
- When performing the v3 link handshake on a TLS connection, report
  that we have the x509 certificate that we actually used on that
  connection, even if we have changed certificates since that
  connection was first opened. Previously, we would claim to have
  used our most recent x509 link certificate, which would sometimes
  make the link handshake fail. Fixes one case of bug 22460; bugfix
  on 0.2.3.6-alpha.

  o Major bugfixes (relays, key management):
- Regenerate link and authentication certificates whenever the key
  that signs them changes; also, regenerate link certificates
  whenever the signed key changes. Previously, these processes were
  only weakly coupled, and we relays could (for minutes to hours)
  wind up with an inconsistent set of keys and certificates, which
  other relays would not accept. Fixes two cases of bug 22460;
  bugfix on 0.3.0.1-alpha.
- When sending an Ed25519 signing->link certificate in a CERTS cell,
  send the certificate that matches the x509 certificate that we
  used on the TLS connection. Previously, there was a race condition
  if the TLS context rotated after we began the TLS handshake but
  before we sent the CERTS cell. Fixes a case of bug 22460; bugfix
  on 0.3.0.1-alpha.

  o Major bugfixes (torrc, crash):
- Fix a crash bug when using %include in torrc. Fixes bug 22417;
  bugfix on 0.3.1.1-alpha. Patch by Daniel Pinto.

  o Minor features (code style):
- Add "Falls through" comments to our codebase, in order to silence
  GCC 7's -Wimplicit-fallthrough warnings. Patch from Andreas
  Stieger. Closes ticket 22446.

  o Minor features (diagnostic):
- Add logging messages to try to diagnose a rare bug that seems to
  generate RSA->Ed25519 cross-certificates dated in the 1970s. We
  think this is happening because of incorrect system clocks, but
  we'd like to know for certain. Diagnostic for bug 22466.

  o Minor bugfixes (correctness):
- Avoid undefined behavior when parsing IPv6 entries from the geoip6
  file. Fixes bug 22490; bugfix on 0.2.4.6-alpha.

  o Minor bugfixes (directory protocol):
- Check for libzstd >= 1.1, because older versions lack the
  necessary streaming API. Fixes bug 22413; bugfix on 0.3.1.1-alpha.

  o Minor bugfixes (link handshake):
- Lower the lifetime of the RSA->Ed25519 cross-certificate to six
  months, and regenerate it when it is within one month of expiring.
  Previously, we had generated this certificate at startup with a
  ten-year lifetime, but that could lead to weird behavior when Tor
  was started with a grossly inaccurate clock. Mitigates bug 22466;
  mitigation on 0.3.0.1-alpha.

  o Minor bugfixes (storage directories):
- Always check for underflows in the cached storage directory usage.
  If the usage does underflow, re-calculate it. Also, avoid a
  separate underflow when the usage is not known. Fixes bug 22424;
  bugfix on 0.3.1.1-alpha.

  o Minor bugfixes (unit tests):
- The unit tests now pass on systems where localhost is misconfigured
  to some IPv4 address other than 127.0.0.1. Fixes bug 6298; bugfix
  on 0.0.9pre2.

  o Documentation:
- Clarify the manpage for the (deprecated) torify script. Closes
  ticket 6892.
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe 

Re: [tor-talk] Upcoming Tor releases tomorrow, to fix Hidden Service remote DoS bugs

[Nick Mathewson]

On Wed, Jun 7, 2017 at 11:15 AM, Nick Mathewson  wrote:
> Hi, all!
>
> Tomorrow we'll be putting out new releases in all supported series
> (0.2.4 through 0.3.1) to fix two vulnerabilities that we have found in
> the hidden service code. These vulnerabilities allow an attacker to
> cause a hidden service to crash with an assertion failure.  We believe
> that is the only impact.  We are tracking these vulnerabilities as
> TROVE-2017-004 and TROVE-2017-005.
>
> For more information about how we handle security issues in Tor, see
> our draft policy at:
> 
> https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy

These releases are now available from https://dist.torproject.org/ .
They are: 0.2.4.29, 0.2.5.14, 0.2.6.12, 0.2.7.8, 0.2.8.14, 0.2.9.11,
0.3.0.8, and 0.3.1.3-alpha.

It will take a while for the website download page to upgrade, since
the system that updates the website tends to get bogged down when
there are lots of builders running at once.  I'll send out the regular
announcements once the download page is up-to-date, since it tends to
confuse people when I don't wait for that.

If you're running a hidden service, I recommend that you upgrade as
soon as a package is available for your system.

best wishes,
-- 
Nick
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] "Some Tor Relays, you might want to avoid."

[nusenu]

> On 05/09/2017 12:02 PM, nusenu wrote:
>> I wrote a blog post about relay groups in end-to-end position:
> 
>> https://medium.com/@nusenu/some-tor-relays-you-might-want-to-avoid-5901597ad821
> 
> 
> 
> Has this any relation with the email subscription  
> ornetra...@lists.riseup.net ?

It uses the same data source (onionoo.torproject.org).

> If nobody is aware of this, this is a great email list to subscribe to which 
> broadcasts relays
> with found correlations based on many variables.

Since the email archive is basically unreadable due to the line breaks I
added a HTML version of these emails. The URL can be found at the bottom
of each email.

Example: (hardly readable)
http://xpgylzydxykgdqyg.onion/www/arc/ornetradar/2017-06/msg00033.html

better:
https://nusenu.github.io/OrNetRadar/2017/06/07/a9



-- 
https://mastodon.social/@nusenu
https://twitter.com/nusenu_



signature.asc
Description: OpenPGP digital signature
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk