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

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



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-request@xxxxxxxxxxxxxxxxxxxx> wrote:

> 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: "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 +0000
> From: nusenu <nusenu-lists@xxxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] "Some Tor Relays, you might want to avoid."
> Message-ID: <d4cd9470-fe10-d085-4e87-43f92f8701db@xxxxxxxxxx>
> 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
> ornetradar@xxxxxxxxxxxxxxxx ?
>
> 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 <nickm@xxxxxxxxxxxxx>
> To: "tor-talk@xxxxxxxxxxxxxxxxxxxx" <tor-talk@xxxxxxxxxxxxxxxxxxxx>
> 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 <nickm@xxxxxxxxxxxxx>
> 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/Net
> workTeam/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
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 8 Jun 2017 13:04:33 -0400
> From: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
> To: "tor-talk@xxxxxxxxxxxxxxxxxxxx" <tor-talk@xxxxxxxxxxxxxxxxxxxx>
> Subject: [tor-talk] Tor 0.3.1.3-alpha is released (with security fix
>         for     hidden services)
> Message-ID:
>         <CAKDKvuyiWDBRN+tHudL-ixJmxvEZwr-NM5uOZZ4jRHyxxP3cvg@xxxxxxx
> ail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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.
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 8 Jun 2017 14:16:33 -0500
> From: Suhaib Mbarak <suhaib.omari@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: [tor-talk] Tor source code
> Message-ID:
>         <CAL+9+aae0a1aNeQnEcED8P00doE4Gb15Z=Yt3HOEt-iUxDCYAA@mail.
> gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> 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
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 8 Jun 2017 21:22:56 +0200
> From: Sebastian Niehaus <sebastian.niehaus@xxxxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Tor source code
> Message-ID: <271cb5bb-c5cc-d430-f696-308575816d62@xxxxxxxxx>
> Content-Type: text/plain; charset=utf-8
>
> 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
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 8 Jun 2017 12:37:27 -0700
> From: Seth David Schoen <schoen@xxxxxxx>
> To: tor-talk@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-talk] Tor source code
> Message-ID: <20170608193727.GB2963@demorgan>
> Content-Type: text/plain; charset=us-ascii
>
> 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  <schoen@xxxxxxx>
> 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
>
>
> ------------------------------
>
> 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 77, Issue 9
> ***************************************
>
-- 
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