- tor-dev - lists.torproject.org

New Proposal - CAA Extensions for the Tor Rendezvous Specification
by Q Misell 08 May '23

08 May '23

Hi all, I've spent some time working on ACME for Tor hidden services (you may have seen discussion of this work on the onion-advisors mailing list). Full details of the project are available at https://e.as207960.net/w4bdyj/AX8Ffqsd Attached is my proposal for a change to the Tor Rendezvous Specification to support the inclusion of CAA records in hidden service descriptors. My fork of Tor implementing publishing these records is available at https://e.as207960.net/w4bdyj/XMN03dmD Thanks, Q ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.

5 6

Suggestions for Arti Example Programs
by Saksham Mittal 08 May '23

08 May '23

Hello there! I was recently selected as a GSoC contributor to help improve Arti by providing example utilities to test drive the APIs. I've come up with a couple ideas in my GSoC proposal and I wanted to share them as well as ask the community if they had any ideas of what projects they may want to see included in examples to help developers use Arti APIs in the future. 1. A download manager in Rust which will download the Tor Browser Bundle through a bridge connection. 2. A simple DNS lookup tool like dig which uses Tor relay to resolve hostnames anonymously, reducing the need to trust a DNS server. (This will use DNS over TLS) 3. A small script to just print out the current connection info on the circuit that had been chosen (like in Tor Browser) and to test relay and bridge connectivity at the user’s end for diagnostic purposes. 4. A bridge reachability monitor using Arti. This tool would hold connections to many obfs4 bridges open and detect when one of them goes down. (More info about this can be found at https://gitlab.torproject.org/tpo/core/arti/-/issues/717) 5. A small proxy server and client which uses just the pluggable transport code to create obfuscated connection between the two (doesn't go through the Tor network, it is just intended to showcase how to setup connections through PTs) I'd be happy to know of any cool ideas you may have to build with Arti that I could work on this summer! Thanks! -Saksham

1 0

Re: [tor-dev] New Proposal - CAA Extensions for the Tor Rendezvous Specification
by Q Misell 27 Apr '23

27 Apr '23

Hi Raph, Whilst I agree that in an ideal world CAs would be irrelevant, we do not live in an ideal world. My proposal is one of many ways that a certificate could be issued to hidden services. Issuing standard TLS certificates to .onion domains allows HTTPS without modification to the browser. This allows non Tor Browsers user agents to access the Tor network via a proxy (SOCKS etc), doing otherwise would require all browsers to understand Tor. It also opens up new opportunities such as payment processing as current PCI DSS requirements do not allow non-standard TLS. Current hidden services with HTTPS such as the BBC already use standard TLS certificates, however the process for these is extremely involved with current CAs. My IETF draft aims to make this a much simpler process via the already well-proven ACME. Thanks, Q ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 27 Apr 2023 at 13:59, Raphaël Fabre <contact(a)fabco.tech> wrote: > Hey > > I've read your proposal, although I'm not sure to grap the totality of it. > I'm Raph the lead dev of this project -> https://e.as207960.net/w4bdyj/YG6dkkyr > > I have a question, since .onion is basically a non ICANN domain name > system, why do you care about using Certificate Authorities ? Could you > instead store the TLS certificates in the name system, as TXT / CERT > records (similar to DANE) ? > > Doing this would allow TOR service providers to not rely on certificate > authorities, control their TLS certificates directly (self signed) and *do > not need at all to renew it*. > > happy to chat further > Raph > > ------- Original Message ------- > Le jeudi 27 avril 2023 à 14:45, Q Misell via tor-dev < > tor-dev(a)lists.torproject.org> a écrit : > > Hi all, > > I've spent some time working on ACME for Tor hidden services (you may have > seen discussion of this work on the onion-advisors mailing list). Full > details of the project are available at https://e.as207960.net/w4bdyj/xqviywZW > <https://e.as207960.net/w4bdyj/yBzJUPTT>. > > Attached is my proposal for a change to the Tor Rendezvous Specification > to support the inclusion of CAA records in hidden service descriptors. > > My fork of Tor implementing publishing these records is available at > https://e.as207960.net/w4bdyj/ItcJLhNd <https://e.as207960.net/w4bdyj/LmAkW3uG>. > > Thanks, > Q > ------------------------------ > > Any statements contained in this email are personal to the author and are > not necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > registered in Wales under № 12417574 > <https://e.as207960.net/w4bdyj/pIFzAYXo>. ICO register №: ZA782876 > <https://e.as207960.net/w4bdyj/pZ2mD5UQ>. UK VAT №: GB378323867. EU VAT > №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: > 522-80-03080. Glauca Digital and the Glauca logo are registered trademarks > in the UK, under № UK00003718474 and № UK00003718468, respectively. > > >

1 0

goptlib moved to gitlab.torproject.org
by David Fifield 15 Apr '23

15 Apr '23

I have moved the goptlib repository from git.torproject.org to gitlab.torproject.org. If you want to use it at the new location, change this import: import "git.torproject.org/pluggable-transports/goptlib.git" to this: import "gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/goptlib" and then run `go get` and `go mod tidy`. Here is the issue about moving anti-censorship team projects from git.torproject.org to gitlab.torproject.org generally: https://bugs.torproject.org/tpo/anti-censorship/team/86#note_2823122 The old git.torproject.org URL should continue to work for the time being.

1 0

MSVC compile failure
by Gisle Vanem 21 Mar '23

21 Mar '23

Hello list. Anybody out there? Trying to compile Tor with 'cl' ver. 19.36.32323 from yesterdays 'git master', I got this error in 'src/feature/hs/hs_metrics_entry.c': hs/hs_metrics_entry.c(98,3): error C2099: initializer is not a constant { ^ hs/hs_metrics_entry.c(106,3): error C2099: initializer is not a constant { ^ ---------- This MSVC compiler is rather stupid; it fails to parse that 'static const size_t hs_metrics_circ_build_time_buckets_size' is truly 'const'. No problem with 'clang-cl'. But this patch works: --- a/feature/hs/hs_metrics_entry.c 2023-03-17 18:00:57 +++ b/feature/hs/hs_metrics_entry.c 2023-03-18 13:56:58 @@ -28,8 +28,7 @@ 60000 /* 60s */ }; -static const size_t hs_metrics_circ_build_time_buckets_size = - ARRAY_LENGTH(hs_metrics_circ_build_time_buckets); +#define hs_metrics_circ_build_time_buckets_size ARRAY_LENGTH(hs_metrics_circ_build_time_buckets) ----------------- Just letting you know here. -- --gv

2 3

Cross-user TLS traffic mixing in snowflake-server until 2023-03-13
by David Fifield 15 Mar '23

15 Mar '23

Between 2022-10-01 and 2023-03-13, there was a bug in the software deployed at Snowflake bridges that could cause parts of a user's stream to be overwritten by parts of other users' streams. Though the Snowflake team believes the privacy risks of the bug are minor, we are treating it as a security bug and therefore making this announcement. The fix is already deployed on the server, and no action is required by users. ## The cause The source of the bug was issue https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… and specifically commit https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…, which was intended as a performance optimization to reduce memory allocation during the large influx of Snowflake users in late September 2022. The analysis surrounding the performance improvement incorrectly concluded that certain memory buffers were not reused and therefore did not need to be copied. But in fact, the buffers were reused, with the effect that data meant for one user could be unpredictably overwritten by data for another user. ## The effect There is analysis at issue https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl…. If our understanding of the bug is correct, it did not reveal plaintext data or IP addresses to other users. The Snowflake bridge is a Tor bridge, not an exit relay, so even a catastrophic failure could not leak users' plaintext data or what destinations they were accessing. A Snowflake connection consists of a layered set of protocols, and the bug was in a layer that does not have access to IP addresses or any other persistent identifiers. * IP * TCP * HTTPS (WebSocket) * session/retransmission ← The bug was here * Tor TLS * user data At most, users and proxies would see fragments of other users' Tor TLS streams. We believe the degree of information disclosure is less than what an eavesdropper listening at the Snowflake bridge's HTTPS port would see, which we already believe to be safe. The practical effect, more than a loss of privacy, was excessive retransmissions at the session/retransmission layer, and corrupted TLS data resulting in a terminated connection. ## Remediation We reverted the erroneous commit and added a test to check for the erroneous buffer reuse. We deployed the update to both Snowflake bridges on 2023-03-13. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow… https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowfl… ## Required action No action is required by users. The bug was in code that was only used by the Snowflake server, not proxies or clients. ## Thanks The problem was discovered and first investigated by Haz Æ 41 (https://gitlab.torproject.org/hazae41) and reported on HackerOne: https://hackerone.com/reports/1880610.

1 0

Is Arti expected to have better multi-CPU support than C-tor?
by David Fifield 08 Mar '23

08 Mar '23

Linus Nordberg and I are preparing a submission for FOCI about the special way we run tor on the Snowflake bridge. We run many tor processes with the same identity and onion keys, because otherwise tor being limited to one CPU would be the main bottleneck. I'm writing to fact-check a claim about Arti and how we hope the current complicated procedure will not be needed in the future: The first and most important bottleneck to overcome is the single-threaded nature of the Tor implementation.² A single Tor process is limited to one CPU core: once Tor hits 100% CPU, the performance of the bridge is capped, no matter the speed of the network connection or the number of CPU cores ²We expect that Arti, the in-progress reimplementation of Tor, will be natively multi-threaded, and remove this primary complication. Is this correct? Is a relay that uses a future version of Arti expected to be able to use all its CPU resources? Here is the a draft of the submission. If you have any comments, our submission deadline is 2023-03-15. https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303…

3 3

[CRITICAL] Deep Fingerprinting Traffic Correlation
by silentguard＠dnmx.org 28 Feb '23

28 Feb '23

Hi, I was the one who raised the issue of DeepCorr being able to perform traffic correlation with a high degree of accuracy but it seems like that WTF-PAD which is currently implemented in Tor does defend against the DeepCprr attack. I could be wrong but this seems to be my understanding. The feasability of this attack decreased when W-T (Walkie-Talkie) a half duplex anti-traffic correlation startegy is used. The accuracy with a W-T defense in place is 49% compared to a 90% accuracy with WTF-PAD. Thera There has been a new deep learning attack which is extremely effective against the current implementation of WTF-PAD in Tor. This new attacks is called Deep Fingerprining proposed here : https://arxiv.org/pdf/1801.02265.pdf. Thanks

1 0

[CRITICAL] DeepCorr Traffic Confirmation Attack
by silentguard＠dnmx.org 28 Feb '23

28 Feb '23

Hi, I was just reading a paper on traffic confirmation attacks over here https://arxiv.org/pdf/1808.07285v1.pdf. This attack runs with the help of deep learning algorithm called DeepCorr. This attack can be run in a Five Eyes country or an authoritarian regime like Russia where companies are compelled to cooperate with the government making this attack plausible. The ISP and the website operators are the two endpoints for this attack. This attack was able to achieve a success rate of over 96% which represents a serious threat to Tor users in these regions. The paper also includes some countermeasures on how to defeat this method of traffic confirmation. Thanks.

3 2

A way to connect quickly to a newly-online hidden service?
by Holmes Wilson 23 Feb '23

23 Feb '23

Hi everyone, In the p2p messaging app we're building, Quiet, users exchange some information out-of-band (an onion address) and use that to connect to each other over Tor, as they would for direct messages in Ricochet Refresh or Cwtch. One UX failure we see now is that newly-online hidden services are not available when users first try to connect, so connecting after users have just come online takes unreasonably long (15 minutes or more) and Quiet seems like it's broken. Any thoughts on how to speed up connecting to a newly-online hidden service? One idea we had is to include enough information from the HSDir entry in what peers exchange out-of-band, so that they wouldn't need to rely on finding the HSDir entry. (And if this information became out of date, we could simply encourage users to share information out of band again.) Is there an easy way for us to get this information from Tor on the receiver side and pass it to Tor when connecting? Another idea was to run some service of our own as a fallback, that we knew would always have the latest HSDir entries posted by our users. Is there some straightforward way to hardcode our own HSDir so that Tor would always check it alongside others? If I'm reading the situation wrong or there's some other possibility I'm not thinking of, please let me know! We've definitely observed long delays in onion addresses becoming available, on top of general connection delays, and I'm trying to find a way to improve this situation. Thanks! Holmes

2 1