Re: [tor-dev] Information on Pluggable Transports
Yes, there are implementations of PT 2.0 and 2.1 specifications. One of the criteria that we have adopted in the 2.1 specification process is that proposals need to have an implementation available before they can be considered for inclusion in a release of the specification. Tor uses the part of the specification known as the Dispatcher IPC Interface to control a Pluggable Transport provider (known as a dispatcher) running in a separate process. The 2.0 and 2.1 versions of this protocol are compatible. You can find a dispatcher implementation which conforms to the 2.1 specification and is backwards-compatible with the 2.0 Dispatcher IPC Interface specification here: https://github.com/OperatorFoundation/shapeshifter-dispatcher This dispatcher implementation currently provides the obfs2, obfs4, and Shadowsocks transports. At one point, we (Operator Foundation) provided a patch to Tor implementing the 2.0 Dispatcher IPC Interface. You can find the fork here: https://oniongit.eu/nickm/tor/tree/dasyatid-rtt2017 You can find the associated Trac ticket here: https://trac.torproject.org/projects/tor/ticket/21816 Operator Foundation does not currently have any plans to commit additional resources to the Tor patch, but it is there as a starting point if anyone is interested in pursuing the project of updating Tor to conform to the PT 2.0 (and 2.1) protocol. We will be continuing to update the dispatcher implementation to match the specification as it evolves, as well as adding new transports as they are developed. On Mon, Oct 15, 2018 at 4:52 PM teor wrote: > Hi Brandon, > > On 16 Oct 2018, at 02:59, Dr. Brandon Wiley wrote: > > If you are looking for information about Pluggable Transports, the > Pluggable Transports website has up-to-date information: > https://www.pluggabletransports.info/ > > If you want to follow the specification process, drafts and proposal are > available here: > https://github.com/Pluggable-Transports/Pluggable-Transports-spec > > The current stable version of the specification is PT 2.0: > https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/master/releases/pt-2_0.pdf > The current draft of the next version being working on is PT 2.1 draft 1: > https://github.com/Pluggable-Transports/Pluggable-Transports-spec/tree/master/releases/PTSpecV2.1Draft1 > > > Is there any code that implements version 2.0 or 2.1 of these specs? > > Tor currently implements the PT 1.0 specification: > https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/master/releases/pt-1_0.txt > > > T > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Temporary hidden services
Michael Rogers writes: > Hi all, > > The Briar team is working on a way for users to add each other as > contacts by exchanging links without having to meet in person. > > We don't want to include the address of the user's long-term Tor hidden > service in the link, as we assume the link may be observed by an > adversary, who would then be able to use the availability of the hidden > service to tell whether the user was online at any future time. > > We're considering two solutions to this issue. The first is to use a > temporary hidden service that's discarded after, say, 24 hours. The > address of the temporary hidden service is included in the link. This > limits the window during which the user's activity is exposed to an > adversary who observes the link, but it also requires the contact to use > the link before it expires. > > The second solution is to include an ECDH public key in the link, > exchange links with the contact, and derive a hidden service key pair > from the shared secret. The key pair is known to both the user and the > contact. One of them publishes the hidden service, the other connects to > it. They exchange long-term hidden service addresses via the temporary > hidden service, which is then discarded. > > The advantage of the second solution is that the user's link is static - > it doesn't expire and can be shared with any number of contacts. A > different shared secret, and thus a different temporary hidden service, > is used for adding each contact. > > But using a hidden service in such a way that the client connecting to > the service knows the service's private key is clearly a departure from > the normal way of doing things. So before pursuing this idea I wanted to > check whether it's safe, in the sense that the hidden service still > conceals its owner's identity from the client. > Hello Michael, Nick's trick seems like a reasonable way to avoid the issue with both parties knowing the private key. I have a separate question wrt the threat model: It seems to me that adversary in this game can observe the link, and all these stunts are done just for the case where the adversary steals the link (i.e. the temporary ECDH public keys). In that case, given that both Alice and Bob are completely unauthenticated and there is no root trust, how can you ensure that the adversary Eve won't perform the ECDH herself, then connect to the temporary onion service, and steal the long-term onion service link (thereby destroying the secrecy of the long-term onion service for ever, even if the attack is detected in the future through Alice and Bob communicating in an out-of-band way). Are we assuming that Alice and Bob have no common shared-secret in place? Because if they did, then you could use that from the start to encrypt the long-term onion service identifier. If you don't, you could potentially fall into attacks like the one above. Cheers! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Information on Pluggable Transports
If you are looking for information about Pluggable Transports, the Pluggable Transports website has up-to-date information: https://www.pluggabletransports.info/ If you want to follow the specification process, drafts and proposal are available here: https://github.com/Pluggable-Transports/Pluggable-Transports-spec The current stable version of the specification is PT 2.0: https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/master/releases/pt-2_0.pdf The current draft of the next version being working on is PT 2.1 draft 1: https://github.com/Pluggable-Transports/Pluggable-Transports-spec/tree/master/releases/PTSpecV2.1Draft1 Tor currently implements the PT 1.0 specification: https://github.com/Pluggable-Transports/Pluggable-Transports-spec/blob/master/releases/pt-1_0.txt On Sun, Oct 14, 2018 at 9:33 AM Carolin Zöbelein < cont...@carolin-zoebelein.de> wrote: > Hi, > > here you can find the PT and their specifications: > > In general, you can find the source code and specifications here: > https://gitweb.torproject.org/ > > For obfs2, obfs3 and scramblesuit > https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/ > https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/doc > > For obfs4 > https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/ > > https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/doc/obfs4-spec.txt > > For meek > https://gitweb.torproject.org/pluggable-transports/meek.git/tree/ > https://gitweb.torproject.org/pluggable-transports/meek.git/tree/doc > > Also a nice site with explanation is here: > > https://trac.torproject.org/projects/tor/wiki/doc/AChildsGardenOfPluggableTransports > > Best regards, > Carolin > > > Am Sonntag, den 14.10.2018, 19:36 +0530 schrieb Pritam Kadasi: > > Hi all, > > > > i'am currectly working on a project on tor. can you help me to get > > enough resources for Pluggable Transports. > > > > i would like to know more on how obfuscation happens in detail. > > > > thanking you. > > > > Pritam > > ___ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -- > --- > Carolin Zöbelein / Nick: Samdney > PGP: D4A7 35E8 D47F 801F 2CF6 2BA7 927A FD3C DE47 E13B > --- > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [release] CollecTor 1.8.0
Hi, everyone! A new release is available: https://dist.torproject.org/collector/1.8.0/ From the change log: * Medium changes - Properly clean up sanitized web server logs in the recent/ directory when they turn older than three days. * Minor changes - Once more, fix the bug in the tarball-creation script where tarballs are not compressed in a run following an aborted run. - Improve logging to find possible issue with missing server descriptors. - Update directory authority IP addresses in default properties file. This CollecTor release is already deployed on all Tor Metrics CollecTor instances. Please direct comments and questions to the metrics-team mailing list: https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team All the best, Karsten signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
