Re: [tor-dev] Interoperation with libp2p
FWIW, I don't think libp2p supports SECIO anymore. In fact the (go) repository has been archived: https://github.com/libp2p/go-libp2p-secio and there is no trace of SECIO in the current (go) implementation of libp2p. On Tue, 7 Dec 2021 at 19:33, Jeff Burdges wrote: > > > > On 7 Dec 2021, at 19:26, Jeff Burdges wrote: > > I advise against allowing any libp2p cruft into tor itself though. > > Among the many reasons. I’d expect libp2p to be a nightmare of downgrade > attacks, given the amount of badly rolled stuff they must still support, > like their dangerous key exchange SECIO built on the legacy curve sep256k1, > but it’ll go deep than that. > > Jeff > ___ > 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] HAROI: Human Readable Authenticated Relay Operator Identifier
Hi, below is a partial proposal draft for human readable relay operator IDs that are authenticated by directory authorities. If there is any interest in implementing something like this I'll complete the draft and submit it via gitlab. kind regards, nusenu # HAROI: Human Readable Authenticated Relay Operator Identifier A HAROI is a DNS FQDN that can be chosen by a relay operator and linked to one or more relays in a verifiable way. The link is authenticated in the sense that it requires some control over the relay and the FQDN (on the DNS or webroot level). A relay can only be linked to a single HAROI. Relays publish their HAROI via their descriptor. Directory authorities verify the link and publish the verification result in their vote. ## Motivation Many tools in the tor ecosystem display at least some relay (operator) information (nickname, ContactInfo, ...), some examples are: - Tor Browser - Relay Search [1] - Onioncircuits by tails [2] - ExoneraTor [3] - allium [4] unfortunatelly there is no authenticated operator ID available, these tools could display, so they might display misleading information, something that has been exploited in the wild for impersonation attacks. There is a value in giving relay operators the possibility to declare an identifier that is globally unique, consistent and can not be easily spoofed by adversaries so they do not become easy victims of impersonation attacks. The tor ecosystem would benefit from an operator ID that can not be spoofed. This proposal is not replacing the relay ContactInfo. ## Design * A HAROI is optional and not mandatory. * A HAROI is verified by directory authorities in one of two ways, depending on the proof type. In the distant future where relays have no RSA1024 keys, Ed25519 proof types are added. * The used proof type can be selected by the relay operator. Successfully verified proofs are cached by directory authorities for 30 days. After 30 days proofs are verified again. Relay operators that want to make use of HAROI can participate without requiring a domain since many free services offer custom free subdomains (example: GitLab or GitHub pages). ## Proof Types Relay operators, that chose to set a HAROI, can select their preferred a proof type. ### uri-rsa This proof type can be verified by fetching the list of relay RSA SHA1 fingerprints from the FQDN via HTTPS using the well-known URI as defined in proposal 326 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/326-tor-relay-well-known-uri-rfc8615.md#well-knowntor-relayrsa-fingerprinttxt Example: if the FQDN is example.com, the url to fetch the list of fingerprints is: https://example.com/.well-known/tor-relay/rsa-fingerprint.txt The TLS certificate used on the webserver must be from a trusted CA and logged in a public certificate transparency log. For N relays using the same FQDN only a single HTTPS GET request is needed. ### dns-rsa This proof type can be verified by performing DNS lookups. To make use of this proof type the DNS zone MUST be DNSSEC signed. The DNS query is constructed by combining the relay's fingerprint and the FQDN: relay-fingerprint. example: relay-fingerprint.example.com value: “we-run-this-tor-relay” relay-fingerprint is the 40 character RSA SHA1 fingerprint of the tor relay. Each relay has its own DNS record, a single TXT record MUST be returned per relay only. content of the TXT record MUST match: "we-run-this-tor-relay” Each relay requires a single DNS lookup (less scalable than the uri-rsa option). ## Relay Configuration Relay operators can specify their identifier via a torrc option. OperatorIdentifier example: OperatorIdentifier example.com dns-rsa ## Length Limit Although DNS FQDNs can be rather long, we limit HAROIs to 40 characters. (As of December 2021 the longest observed HAROI is 28 characters long.) Operators will not be able to specify a HAROI longer than 40 characters in their torrc. Directory authorities refuse to accept them as well. ## Relays Descriptor Changes This proposal defines a new optional descriptor field that is automatically verified and voted on by tor directory authorities. operatorid ## Directory Authorities Directory authorities refuse to accept domains on the public suffix list [5]. XXX TODO ## Security Considerations Relay operators can trick directory authorities into performing DNS lookups and HTTPS GETs on arbitrary domains. Possible solutions: Directory authorities could required PTR+A DNS records on the same domain as the given FQDN for the relays IP address. [1] https://metrics.torproject.org/rs.html [2] https://gitlab.tails.boum.org/tails/onioncircuits [3] https://metrics.torproject.org/exonerator.html [4] https://yui.cat/ [5] https://publicsuffix.org/list/public_suffix_list.dat -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org
Re: [tor-dev] Interoperation with libp2p
> On 7 Dec 2021, at 19:26, Jeff Burdges wrote: > I advise against allowing any libp2p cruft into tor itself though. Among the many reasons. I’d expect libp2p to be a nightmare of downgrade attacks, given the amount of badly rolled stuff they must still support, like their dangerous key exchange SECIO built on the legacy curve sep256k1, but it’ll go deep than that. Jeff ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Interoperation with libp2p
I work on a project that selected libp2p, but only write cryptographic code, not networking code.. I’d caution against using libp2p for anything serious. Protocol Labs always took a pretty sophomoric approach: libp2p managed to be better than ethereum’s but ignored almost everyone working in that space. It devp2p. IPFS might still be inferior to Tahoe LAFS in real terms, especially due to lacking erasure coding. At some point Protocol Labs spun off libp2p, and by then its core devs recognized many of the underlying mistakes. It also benefits from considerable interest but I think our stronger networking people remain unimpressed. It’ always possible to learn from their mistakes of course, but I suspect tor people learned most of those lessons from I2P’s efforts. Now libp2p doing their own scheme for sending their stuff over Tor’s existing streams makes sense. Maybe someone would even pay Tor folk a support contract for the assistance designing that? We've a relatively low bar for grants up to 30k EUR, and more carefully evaluate ones up to 100k EUR, so if any Tor people want to submit a grant for improving the rust libp2p’s Tor usage, then I’ll ask for it to be supported: https://github.com/w3f/General-Grants-Program/ https://github.com/libp2p/rust-libp2p I advise against allowing any libp2p cruft into tor itself though. > On 10 Nov 2021, at 16:26, Mike Mestnik > wrote: > https://gitlab.torproject.org/tpo/core/torspec/-/issues/64 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Accessing Shared Random Values as a Protocol on top of Tor
On 29 Oct (23:56:07), Sebastian Hoffmann wrote: > Hi, > > I'm wondering if I can access the shared random value[1] while > developing a > protocol/application on top of Tor onion services. The application is > still in > early development, but it would be great if I could depend on the shared > random > value. > > If this is not the correct mailing list for this question, I would be > glad if > you could point me to one. You can through the ControlPort with: "GETINFO sr/current" "GETINFO sr/previous" From control-spec.txt: "sr/current" "sr/previous" The current or previous shared random value, as received in the consensus, base-64 encoded. An empty value means that either the consensus has no shared random value, or Tor has no consensus. Cheers! David -- PyBJTQkt8p8BjnK5Ab+oFbVk2ILMK5Ty/Hz4v9WU/+4= signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Gosling onion-to-onion specifications
Hi tor-dev, As part of my work with Blueprint for Free Speech, I recently gave a short presentation during the 2021 state-of-the-onion where we announced Gosling ( see https://youtu.be/mNhIjtXuVzk?t=8155 ). If you missed the talk, the tldr; is that we're developing a specification and reference implementation library for building (onion service based) anonymous+private+secure peer-to-peer applications. Essentially, we're taking what we've learned about onion-to-onion authentication from Ricochet-Refresh, extracting and improving the relevant pieces, and packaging it all in a library that developers can use to build their own anonymous+private+secure peer-to-peer applications. Our hope is that future developers will not need to be tor experts to build these types of applications. Today ,I'm happy to announce that we just made the the gosling repo on Github public! - https://github.com/blueprint-freespeech/gosling Things are little bare-bones at the moment, but the most relevant piece right now is the protocol specification here: - https://github.com/blueprint-freespeech/gosling/blob/main/docs/protocol.md You'll also find some initial prototyping work under the source directory (the pace of development should pick up come 2022). Please go take a look and feel free to respond here with any questions, concerns, criticisms, etc. Thanks! best, -Richard OpenPGP_signature Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Client identification for authenticated onions
On 2021-08-23 20:56, cho8jeiv4aus at paperboats.net wrote: Hi there. I had an idea recently for an onion service to improve the UX of sites that require a login. The site would have two onions: one for those who want to use onion auth and another for those who don't or are still setting it up. A user would first sign in with a username+password on the unauthenticated onion and click a button to generate a certificate associated with their account. Then they would add the public key to their browser and visit the authenticated onion. The application server would then match the pubkey used to authenticate with an account in the database, and log them in automatically. As for your case, you could maybe try client-side TLS certificates. I've had a similar idea for DoS protection. You have two onions, call them "open" and "closed". In the good times, you go to the "open" onion and register. It gives you a client authentication password for "closed" and redirects you there. On subsequent logins, you just go straight to the "closed" onion. (In theory, it's enough to have the key get you to the login screen - it doesn't actually have to replace authentication) Then, when the attack comes, it will take down the "open" onion. However, the "closed" onion is protected by client auth, and can be rate-limited by key. The only thing that would be needed for this is a special version of client authorization that allows the server to see *which* key is connecting, as opposed to "some key but you don't know which for privacy reasons". As an operator, an alternative would be to generate one (authenticated) onion service per user and route them all to the same place with different Host headers, but that seems rather inefficient, and I don't know how well the tor daemon scales up to hundreds of onion services anyway. That's not great for the network. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only
Original Message From: Neel Chauhan Apparently from: tor-dev-boun...@lists.torproject.org To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only Date: Fri, 17 Sep 2021 16:09:43 -0700 > Hi nusenu (and tor-dev@), > > On 2021-09-17 16:02, nusenu wrote: > > it would be great if you could open a MR for the proposal so we can > > always see the latest version and changes > > there. > > (Over time it became unclear what comments have already been addressed > > in the text an which didn't.) > > Done: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/46 Line 102> single directory authority servre [3]. Typo here. > > > kind regards, > > nusenu > > -Neel > ___ > 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] Proposal 335: An authority-only design for MiddleOnly
> ``` > Filename: 335-middle-only-redux.md > Title: An authority-only design for MiddleOnly > Author: Nick Mathewson > Created: 2021-10-08 > Status: Open > ... > > These flags SHOULD be set in a vote whenever `MiddleOnly` is > present, and only when the authority is configured to vote on the > `BadExit` flag. > > * `BadExit` > > These flags SHOULD be cleared in a vote whenever `MiddleOnly` is > present. > > * `Exit` I believe that BadExit is supposed to be given together with Exit, to mark that technically it's possible to exit from this relay, but it is not recommended unless you know what you do. > * `Guard` > * `HSDir` > * `V2Dir` It looks like we don't fear such a relay at Intro? Or it is a sign that this proposal is only a set of quick actions before #334? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A Simple Web of Trust for Tor Relay Operator IDs
(sorry for replying directly before) On 2021-10-03 16:16, nusenu-lists at riseup.net wrote: Hi, I wrote down a spec for a simple web of trust for relay operator IDs: Some comments, in no particular order: Why not just put the keys in directly, or even a magnet link to your latest web of trust? That would remove the need to trust SSL CAs. What problems does this solve, specifically, and how? If I - me personally, not the generic I - wanted to spin up a relay, how would I do that? Would I go on this mailing list and ask random people to sign my relay? If so, it's not very useful. Or would I just run it without any signatures at all? If so, it's not very useful. The basic problem, I think, is the same as for PGP: it's not really clear what you're attesting to when you sign. If I sign a my mate's relay, and then that relay turns out to be dodgy, do I also lose my relay operation privileges? I think that WoT systems have a definite value for preventing Sybil attacks, they are very powerful, and I don't think these issues are insurmountable, but they have to be addressed. If you're going to do it in a "machine-friendly" manner, then I suppose you have to come up with some kind of formalized notion of what trust represents, maybe have some numerical scale so you can define (just as an example) 100 = "I've personally audited the hardware", 70 = "This is an organization I trust", 10 = "I know who this person is, it's not just a fresh hotmail". Or, you can do it in a "human-friendly" manner, where you just write text notes with each trust relationship. That would make it quite useless to parse, but could be useful to give us some information about relays. Now, here's my gut feeling: Instinctively, it seems silly to have the trust relationships denote "this person is a good relay operator" (how would you even quantify that?), and maybe more reasonable to have it denote "I know this guy, he didn't just pop into existence last Thursday". And if you're doing that, it seems like the second approach makes more sense. This clearly suggests some limitations to it, but possibly still useful. Anyway, if you're going to do that, it might also be reasonable to hook into a pre-existing web of trust, like GPG or something. That way, we can encode stuff like "I trust my mate Alice, she isn't a relay operator, she trusts Bob, who is, therefore I transitively trust Bob." This doesn't work great if Alice has to register in the separate Tor Web of Trust thing. (On the other hand, we introduce the problem of someone doing a Sybil by being introduced to random people who will sign literally anything, not being aware of Tor, and then showing up with plausible-looking trust pairs. But maybe that's not such a big problem, because that arguably looks even shadier?) I think this is a very good initiative, anyway. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Accessing Shared Random Values as a Protocol on top of Tor
Hi, I'm wondering if I can access the shared random value[1] while developing a protocol/application on top of Tor onion services. The application is still in early development, but it would be great if I could depend on the shared random value. If this is not the correct mailing list for this question, I would be glad if you could point me to one. --Sebastian [1]: PUB-SHAREDRANDOM in https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Interoperation with libp2p
https://gitlab.torproject.org/tpo/core/torspec/-/issues/64 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A Simple Web of Trust for Tor Relay Operator IDs
While I understand the rationale for proposals such as these and agree there is a problem with malicious relays on the network, I feel that proposals such as these: - Raise the barrier for entry. People that would like to contribute to the network by running a relay or several relays would have this extra administrative burden now - These extra verification steps and collected details nibble-away ones ability to contribute to the network anonymously. - Despite individuals' best intent, systems and processes for collection and aggregation of personal details often have vulnerabilities. These vulnerabilities, when exported could be used to harm the very people the project is designed to protect. Z Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, October 3rd, 2021 at 12:16 PM, nusenu wrote: > Hi, > > I wrote down a spec for a simple web of trust > > for relay operator IDs: > > https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-operator-ids/proposals/ideas/xxx-simple-relay-operator-wot.md#a-simple-web-of-trust-for-tor-relay-operator-ids > > This is related to: > > https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40001 > > https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html > > kind regards, > > nusenu > --- > > https://nusenu.github.io > > 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
