- tor-dev - lists.torproject.org

Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
by Nathaniel Suchy 24 Oct '18

24 Oct '18

Hi everyone, Cloudflare has added support to TLS 1.3 for encrypted server name indication (SNI). This mailing list post is a high level overview of how meek could take advantage of this in relation to Cloudflare who until just now wasn’t an option for domain fronting. What this means: Effectively domain fronting works by sending a different SNI and host header. CDN providers like Cloudflare started double checking to make governments happy, scratch that line, I mean to protect their customers from fraud and abuse. They seem to of backtracked now. Encrypted SNI means that a firewall or coffee shop owner won’t be able to use SNI to see the real origin of TLS traffic. Why this matters: With the right adjustments for TLS 1.3 and Encrypted SNI support, Cloudflare may be a viable option for Meek. Risks: * Firewall products could always use DPI and block TLS 1.3 altogether. * Firewall products could block all requests with encrypted SNI. Thoughts anyone? References: * https://blog.cloudflare.com/encrypted-sni/ * https://blog.cloudflare.com/esni

4 10

Temporary hidden services
by Michael Rogers 22 Oct '18

22 Oct '18

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. Attacks against the availability of the service (such as uploading a different descriptor) are pointless in this scenario because the client is the only one who would connect to the service anyway. So I'm just interested in attacks against anonymity. Can anyone shed any light on this question? Or is this way of using hidden services too disgusting to even discuss? :-) Thanks, Michael

6 13

Information on Pluggable Transports
by Pritam Kadasi 16 Oct '18

16 Oct '18

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

4 4

[release] CollecTor 1.8.0
by Karsten Loesing 15 Oct '18

15 Oct '18

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

1 0

Re: [tor-dev] Characterizing Tor flows using DPI
by Piyush Kumar Sharma 15 Oct '18

15 Oct '18

Hello all, I have some confusion regarding the characterization of Tor traffic using DPI. I was following the link ( https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/TLSHistory ) and understood that Tor did TLS renogotiation at some point and then discontinued doing it. As an improvement there are basically two handshakes that are done. (i) "outer handshake" which is made to look as real as possible. (ii) "inner handshake" which is actually used to authenticate and exchange "real" certificates. I am just not able to understand as to why we need two handshakes, also why do we need "real" and "fake" certificates. Or if i am missing something, can someone point me to the right resources where i can get the current tor TLS implementation details. Regards Piyush PhD CSE IIITD

2 1

Idea which may or may not of been discussed
by Nathaniel Suchy 13 Oct '18

13 Oct '18

Currently tor traffic uses an TLS handshake hostname like the following: $ sudo tcpdump -An "tcp" | grep "www" listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes .............". ...www.odezz26nvv7jeqz1xghzs.com......................#.!...www.bxbko3qi7vacgwyk4ggulh.com..........6....m.....>...:.........|../* Z....W....X=..6...C../....................................0...0..0.......'....F./0.. *.H........0%1#0!..U....www.b6zazzahl3h3faf4x2.com0...160402000000Z..170317000000Z0'1%0#..U....www.tm3ddrghe22wgqna5u8g.net0..0.. A network observer could run a DNS lookup on the hostnames and see if they are real or not. So my idea would be to register a set of random hostnames which are legitimate and point the IPs somewhere to avoid looking for an NX Domain response and dropping the stream. You could even give each relay a unique subdomain and rotate these every few weeks. This may be expensive to implement but could make blocking Tor traffic with this method harder. Thoughts? Cordially, Nathaniel Suchy

3 2

Orbot 16.0.3-BETA-2 (tor-0.3.4.8) release for testing
by Nathan Freitas 12 Oct '18

12 Oct '18

Highlights - Tor 0.3.4.8 / OpenSSL 1.0.2p with dirauth module disabled (not used for client devices) - Updated Obfs4/Meek pluggable transport support and built-in bridges - Simplified (less memory, network & battery intensive) notification with "New Identity" button APKs up here: https://github.com/n8fr8/orbot/releases/tag/16.0.3-BETA-2 https://guardianproject.info/releases/Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullp… (.asc) **** @n8fr8 n8fr8 released this just now Assets 6 Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-armeabi-release.apk 8.77 MB Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-armeabi-release.apk.asc 862 Bytes Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-universal-release.apk 17.8 MB Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-universal-release.apk.asc 862 Bytes Source code (zip) Source code (tar.gz) f06939b (HEAD -> master, tag: 16.0.3-BETA-2-tor-0.3.4.8, public/master, origin/master, origin/HEAD, dev/master) update build 16030020 9d3bd82 udpate default bridges c207a1e update new simpler notification with "new identity" button bcae003 add permission to service manifest a7130ab update to latest tor android 0.3.4.8 a5d1978 update default bridges ffda769 update NDK build script 3349454 update to latest Pluto obfs4proxy builds 048ed9f Merge branch 'master' of github.com:n8fr8/orbot 84e0433 (tag: 16.0.3-BETA-1-tor-0.3.4.8) update version to 16.0.3-BETA-1-tor-0.3.4.8 and build to 16030010 66cc8ad improve service checking for running Tor instance 6bc161b update to Tor 0.3.4.8 0ff8d7c Merge pull request #173 from haghighi-ahmad/patch-1 772e0db Improve Persian translation and fix grammar. 129b55a Merge branch 'master' of github.com:n8fr8/orbot 1bef963 Merge branch 'Unpublished-deprecated_torrc' b2bf3d9 Merge branch 'deprecated_torrc' of https://github.com/Unpublished/orbot into Unpublished-deprecated_torrc 06c343c update launcher web graphic 3433112 update launcher graphics bd61739 update version and constrains library 9a866aa update gradle tooling 31238af update tor to 0.3.4.7 RC

1 0

deb.tpo 0.3.5 repos intentionally empty?
by nusenu 08 Oct '18

08 Oct '18

Hi, the tor 0.3.5.x repos (example [1]) exist since some time but are empty since then, is that intentional? kind regards, nusenu [1] https://deb.torproject.org/torproject.org/dists/tor-experimental-0.3.5.x-st… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

Network team meeting postponed to Tuesday
by Nick Mathewson 08 Oct '18

08 Oct '18

Hi! A lot of people are off on Monday, so we'll try to have our weekly meeting on Tuesday Oct 9, at the regular time. best wishes, -- Nick

1 0

txtorcon 18.3.0
by meejah 06 Oct '18

06 Oct '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hot on the heels of 18.2.0 comes 18.3.0 because I forgot to add the "single_hop=" feature to endpoint-strings: * add `singleHop={true,false}` for endpoint-strings as well You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.3.0 https://github.com/meejah/txtorcon/releases/tag/v18.3.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.3.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.3.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 5601956b3a2452526cd1ea31662696a51ddbf8ed6452633ee464fc1ff275f8b0 dist/txtorcon-18.3.0.tar.gz 8edac3b6d9c633b9182b4e5a2ed3ac86953ed44b9ea230aac3e0708c30b73861 dist/txtorcon-18.3.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlu37ycRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaafaFAf/e4pVR7bL+gDMq2sJVaFVFzsQqPTV2RLi 9e5A7RRfCPfDSPMyJg71I5qnXXY7aXMP5kBOmK1WF7hN06NRrYGuVifWzijogosP l/2KIGp1I6nK77JTNdjPqnSfQ9N+/ZXaXK3ILzlmSiyI3PMaLgPjB0x2JM6NhcfQ pPPKuL9K0bw94slGSTJa29py4yBV4VhAG0qwHEigw3Zwie2iAejk1GwSW9UEhJnp GBDECiaBdgDZZozn43Q9WXoVIcTnsjTBIN9Km3gNgIcn+ZbwH461HKDXvW7yDfsV oZ7thGr5xD9ENErOzWgU52kMOOuo/pM50vAlzJC518iV39deCD1GQA== =6d14 -----END PGP SIGNATURE-----

1 0