Re: [tor-dev] onionoo overload_general_timestamp (prop 328)
Was there a particular motivation for this format change and granularity? And what do you think about changing it to use the -MM-DD hh:mm:ss format for consistency and having a direct human readable format here as well? related: Karsten used to maintain onionoo protocol documentation/changelog and versions: https://metrics.torproject.org/onionoo.html#versions Is that and the 'version' field in onionoo no longer maintained? (since it didn't change with the new fields) Sure, we intend to maintain the version field, and since new fields have been added the protocol version should have been updated. The reason I haven't updated it yet was that I wasn't very pleased that we had to add the overload_ratelimits [1] and overload_fd_exhausted [2] fields in the bandwidth document. We needed to expose these fields, but we also knew these didn't belong to this document. So the idea was to plan a bigger release with a little restructure of the onionoo internals and update the protocol version then. Said this I will update both the timestamp and the protocol version for consistency. Is there a gitlab issue where this is tracked? btw: "DNS timeout reached" can probably be removed from: https://metrics.torproject.org/onionoo.html#details_relay_overload_general_timestamp 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
Re: [tor-dev] AROI
related rC3 presentation: title: Towards a more Trustworthy Tor Network when: 2021-12-28, 17:00 CET where: https://streaming.media.ccc.de/rc3/csh 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
Re: [tor-dev] HAROI -> AROI
to avoid that long name: Human Readable Authenticated Relay Operator Identifier (HAROI) I'm replacing it with the slightly shorter: Authenticated Relay Operator ID (AROI) and use that wording across all OrNetStats pages now: https://nusenu.github.io/OrNetStats/w/misc/families-by-bandwidth.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
Re: [tor-dev] the consequences of deprecating debian alpha repos with every new major branch
looks like someone decided to solve this. apparently there are alpha release repos available now that do not contain branch names https://deb.torproject.org/torproject.org/dists/: [DIR] tor-experimental-bookworm/2021-12-20 22:21- [DIR] tor-experimental-bullseye/2021-12-20 22:21- [DIR] tor-experimental-buster/ 2021-12-20 22:21- [DIR] tor-experimental-focal/ 2021-12-20 22:21- [...] thank you! nusenu -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] HAROI: Human Readable Authenticated Relay Operator Identifier
Hi, Georg Koppen: I think I am confused a bit. So, how does that relate to the contact information sharing specification you propagate? Is your new proposal an additional thing relay operators should implement on top of the that specification? Or should they choose between the two? What shortcoming does your new proposal solve that is not addressed by the other specification and vice versa? On a technical level CIISS proofs [1] and HAROI proofs are the same, the main difference is the integration into tor and the verification of proofs by directory authorities. The proof field in CIISS would eventually become obsolete should HAROIs get implemented in tor, but since the proof is the same, relay operators do not have to setup some new kind of proofs when HAROI is implemented (>1400 relays, >50% exit probability have properly setup their proof already and more will follow soon). The CIISS proof will continue to serve its purpose until HAROI is deployed in tor releases since it naturally takes a long time until all relays run a supported tor version that would support it. The main benefit of HAROI is the central verification of proofs by directory authorities instead of requiring everyone to verify the proofs themselves. This is better for efficiency and will reduce the load on proof endpoints (DNS and webservers). I hope that helps clarifying the relation between HAROI and CIISS proof field. Should you have any more questions do not hesitate to ask. kind regards, nusenu [1] https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#proof -- 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] 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 https://lists.torprojec
Re: [tor-dev] proposal 328: consensus parameters
Nick Mathewson: Every network parameter has a default value; IIUC, unless at least three authorities are voting for some value, everybody will use the default. It's normal for the authorities not to vote for a different value if they all think the default is reasonable. The default for these parameters is in param-spec.txt at https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/param-spec.txt#L194 thank you Nick for explaining this, 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] proposal 328: consensus parameters
Hi, https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overload-report.md For DNS timeouts, the X and Y are consensus parameters (overload_dns_timeout_scale_percent and overload_dns_timeout_period_secs) defined in param-spec.txt. should one be able to find these parameters (overload_dns_timeout_scale_percent and overload_dns_timeout_period_secs) on https://consensus-health.torproject.org/#consensusparams or in https://collector.torproject.org/recent/relay-descriptors/consensuses/ or is this not yet deployed? What are the values of these parameters currently? thanks, 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] prometheus relay label
Hi, when adding MetricsPort support to ansible-relayor I realized that many operators that run more than one tor instance per server will run into an issue because tor's relay prometheus metrics has no identifying label like fingerprint= or similar to tell tor instances appart. The instance= default label can have the same value for all tor instances on a given server so that can not be used. To avoid using nickname (might not be set) the easiest option is probably to use the relay's SHA1 fingerprint or alternatively the IP:ORPort combination which is unique per server but not necessarily globally unique (RFC1918 IPs). Another neat option for operators is to use node_exporter's textfile collector to collect tor's MetricsPort content to avoid having to run an additional webserver for TLS and authentication (because unlike tor's exporter node_exporter comes with TLS and authentication builtin). In that case the suggested solution would be even more needed because in that case relabling via prometheus' scrape config is no longer possible. What do you think about this suggestion? 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
Re: [tor-dev] onionoo overload_general_timestamp (prop 328)
Said this I will update both the timestamp and the protocol version for consistency. thanks, appreciated. 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] onionoo overload_general_timestamp (prop 328)
Hi, in onionoo all timestamps used to be in the format -MM-DD hh:mm:ss Proposal 328 has timestamps in this same format https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overload-report.md The newly added prop328 fields in oninoo appear to break with that convention https://metrics.torproject.org/onionoo.html#details_relay_overload_general_timestamp Here is an example for an onionoo overload_general_timestamp which appears to be at millisecond granularity (the source has a granularity of an hour): 163603800 Was there a particular motivation for this format change and granularity? And what do you think about changing it to use the -MM-DD hh:mm:ss format for consistency and having a direct human readable format here as well? related: Karsten used to maintain onionoo protocol documentation/changelog and versions: https://metrics.torproject.org/onionoo.html#versions Is that and the 'version' field in onionoo no longer maintained? (since it didn't change with the new fields) 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
Re: [tor-dev] A Simple Web of Trust for Tor Relay Operator IDs
current version of the text: https://nusenu.github.io/tor-relay-operator-ids-trust-information/ 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. Since the spec does not mention keys, which keys do you mean? Note that the level of indirection trust information -> operator ID -> relay ID is crucial. Anything that requires to assign trust to individual relays does not really scale well and we trust relays largely by trusting their operators (less on other factors). 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 I've tried to make it more clear now and I've added a second point: a TA asserts that (1) a given operator ID is running relays without malicious intent (2) they have met at least once in a physical setting (not just online) https://github.com/nusenu/tor-relay-operator-ids-trust-information/blob/main/README.md#trust-anchor-ta If I sign a my mate's relay, Note: there is no manual signing and no trust at the individual relay level in the spec. and then that relay turns out to be dodgy, do I also lose my relay operation privileges? No, but you will likely loose people's trust to assert a third parties trust level. So if you were a TA for someone before you probably loose that ability, but it is up to the consumer of trust information to define their rules for which TA to trust and how to respond to TA "errors". Thanks to your input I added support for negative trust configurations: https://nusenu.github.io/tor-relay-operator-ids-trust-information/#negative-trust-configuration 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". currently, by publishing an operator-id (=domain) a TA only claims that "this operator runs relays without malicious intent" and that they met at least once. It does not say anything about the operational security practices of an operator. Having a granularity of 100 steps to denote the trust level is too much in my opinion. Let's keep it simple. 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." I don't think there is much benefit in using existing GPG signatures because signatures on GPG keys only make claims about identities, they do not make any claims about non-malicious relay operator intentions. Malicious operators are willing to go quite far as we see in practice. Finding a poor person who is willing to go to the next GPG key signing event for money is trivial for them I guess. 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
Re: [tor-dev] proposal 328 status
David Goulet: On 29 Oct (22:48:53), nusenu wrote: Hi, I'm wondering if the current version of the text is the latest available version of it or if there is somewhere a newer version that hasn't been pushed yet? https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overload-report.md "Status: Draft" but it is already in released tor versions. It should actually be set to "Closed" now and we need to merge it in dir-spec.txt. "Implemented-In" would also be nice. my understanding of the changelog https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/361/diffs#821ec629171cb3d62b4ce801f8e81e2bbfe9b011_0_1 was that only the "overload-general" line got moved (not all lines from this spec) from the extra-info descriptor to the server descriptor, but this change implies that all lines are now located in the server descriptors? https://gitlab.torproject.org/tpo/core/torspec/-/commit/3424a245774e2ee56115e36cc4f8790fa53067c0#2c338f8c98c902438a74b0f928609906424b356d_30_28 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overload-report.md Has the version field in the "overload-general" line been increase when the semantics for DNS timeouts changed? (the 1 to 1%/10min change) related stem ticket: https://github.com/torproject/stem/issues/91 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] proposal 328 status
Hi, I'm wondering if the current version of the text is the latest available version of it or if there is somewhere a newer version that hasn't been pushed yet? https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/328-relay-overload-report.md "Status: Draft" but it is already in released tor versions. also in the context of this change: https://gitlab.torproject.org/tpo/core/tor/-/issues/40364 the proposal still mentions extra-info documents. thanks, nusenu -- https://nusenu.github.io ___ 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
Hi, thanks for your input. There will be a new iteration of the draft and I will reply to your email again once that is done, as it should cover some of the areas you mentioned. kind regards, nusenu yanma...@cock.li: (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. -- https://nusenu.github.io ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] How do Ed25519 relay IDs look like?
Any opinions? Hm. Every time we've displayed Ed25519 fingerprints so far, we've used base64. I'm not sure that changing it will actually save more confusion than it causes. thanks for the prompt reply. Hm, ok I guess then we have already reached the point of no return where it is too late to come to a common format that can be used everywhere even in places where "/" is not supported. 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
Re: [tor-dev] How do Ed25519 relay IDs look like?
On Tue, Aug 4, 2020 at 6:41 PM nusenu wrote: nusenu: I'll wait until you (Tor developers) decided on the final naming and format Is there any interest to move this topic forward to come to some decision in the near future? (before the end of the month) I don't think that'd be too hard. Here is a short summary of what opinions I observed for this topic (naming and format for Ed25519 identities) so far: Naming proposals for relay Ed25519 identities: 'v2 fingerprints' (Damian) "ed25519 identity" or even just "identity" (nickm) Output format the Ed25519 relay IDs: base64 - 43 characters long (nickm) this is problematic due to the "/" sign (Damian) hex - 64 characters long (Damian) "/" is problematic for DirPort urls, GETINFO commands, etc (Damian) isn't there urlencoding for URLs? (nusenu) base64urlsafe - 43 characters long (nusenu) I hope we can agree to use the same format in all places. How does the decision process looks like in general in the Tor Project? I think right now Tor uses unpadded base64 in most internal formats, but it doesn't actually use those in the user interface anywhere, so we could just use base64urlsafe (per rfc4648 section 5) for the user interface. I would be fine with standardizing that for our API, but I'd want to write a proposal for it first. It wouldn't have to be long. We'd want to describe other places where we currently use regular base64 for 256-bit keys, and say whether we should/shouldn't accept and emit url-safe identifiers there instead. We should specify that there are no spaces, that the padding "=" characters are removed, and that even though the format as given can handle 43*6==258 bits, the last two bits must be set to 0, since these are only 256-bit identifiers. We should also _probably_ specify some canonical encoding for a pair of keys. I've come to the conclusion that since people are used so much to the fact that relay ID's (RSA) never were case sensitive, ed25519 should not be case sensitive either. So I'd propose to use base32 without padding. That would make it 52 chars long. Any opinions? 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] tor Prometheus Metrics Documentation
Hi,
since Neel is working on unix socket support [1] for MetricsPort
I'm preparing to add support for it to relayor.
I don't like to add additional attack surface to a relay but since
tor does not support TLS and basic auth on the MetricsPort I'll likely
install nginx that takes care of TLS and authentication.
If you have any opinion on that I'd also like to hear it.
It would be nice to have a documentation for all tor prometheus metrics
in the man page or on a website, some information can be found at [3] but not
all.
Is there already a complete documentation for tor prometheus metrics data?
Here is an example of how other projects have documented their metrics [5].
I don't know if it is too late for that but it would be great to use the
well known IANA RCODE [4] naming for the DNS return codes
where possible instead of the custom naming.
examples (just guessing):
tor_relay_exit_dns_error_total{... reason="format"}-> FormErr?
tor_relay_exit_dns_error_total{... reason="notexist"} -> NXDomain?
kind regards,
nusenu
[1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/453
[3] https://support.torproject.org/relay-operators/relay-bridge-overloaded/
[4]
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
[5] https://doc.powerdns.com/recursor/metrics.html#metricnames
related feature request:
[2] https://gitlab.torproject.org/tpo/core/tor/-/issues/40194
--
https://nusenu.github.io
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] ed25519_master_id_public_key -> ed25519 id
nusenu: cut -b 33- ed25519_master_id_public_key |base64 hint: don't use this Since cut is line based it will only read until the end of the line but the input file is not a text file - so it will stop reading at random offsets. -- https://nusenu.github.io ___ 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
Hi, has this proposal any implications wrt to making the MiddleOnly feature available to clients (without requiring DA actions)? With ExcludeExitNodes/ExitNodes + ExcludeGuardNodes [1] tor clients basically can get the "MiddleOnly" feature without DA actions, but ExcludeGuardNodes [1] is not there yet. This is why I'm asking. [1] https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/436 ## Generating votes When voting for a relay with the `MiddleOnly` flag, an authority should set all flags indicating that a relay is unusable for a particular purpose, and against all flags indicating that the relay is usable for a particular position. This part was not clear to me, but if I ignore it, the rest makes sense. It is not clear because it says an authority should set _all_ flags to indicate that a relay is unusable for a particular purpose. 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
Re: [tor-dev] ed25519_master_id_public_key -> ed25519 id
Yes, there is! First you verify that the file is really 64 bytes long, and that the first 32 bytes of the file are really "== ed25519v1-public: type0 ==\0\0\0". Having done that, you base64-encode the second 32 bytes of the file, with no "=" padding. thank you for this description, so I can confirm that this: cut -b 33- ed25519_master_id_public_key |base64 gives me the same string as in the file fingerprint-ed25519 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] ed25519_master_id_public_key -> ed25519 id
Hi, given a relay's ed25519_master_id_public_key file, is there a simple way to generate the 43 chars long ed25519 identity string (also found in fingerprint-ed25519)? thanks, nusenu -- https://nusenu.github.io ___ 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
Maybe you would like to open a merge request or post it on tor-dev in its entirety so we can comment? Whatever you prefer. https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/49 -- 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] A Simple Web of Trust for Tor Relay Operator IDs
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
Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only
Hi Neel, 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.) 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
Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only
Sorry, my bad. The ExcludeMiddleNodes did give a good idea for a new feature I already have a MR for: * https://gitlab.torproject.org/tpo/core/tor/-/issues/40466 * https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/436 It's unrelated to this PR, though, and I don't know if it will go in. thanks for these pointers. In case "ExcludeGuardNodes" option is accepted and merged, the documentation should explicitly point out the differences between LimitToMiddleOnlyNodes NodeX vs. ExcludeGuardNodes NodeX + ExcludeExitNodes NodeX thanks, nusenu -- https://nusenu.github.io ___ 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
Neel Chauhan: Also ensure this functionality is available to tor clients via a torrc option like "ExcludeExitNodes" can be used by tor clients as well. The torrc option for clients could be named "LimitToMiddleOnlyNodes" or similar and takes a list of relay fingerprints and can appear multiple times in a torrc (like ExcludeExitNodes). I don't know if torrc options are supposed to go in Proposal documents I agree that the naming of torrc options is not in scope of a proposal, but the fact that the MiddleOnly path selection constraint feature can be used by clients without requiring DirAuth actions probably is. I will try to make sure an "ExcludeMiddleNodes" option (how I would name it) would be included A name "ExcludedMiddleNodes" would suggest the exact opposite of what MiddleOnly actually is for, no? It suggests that the given relays are excluded from the middle position but in fact they should be limited to the middle position. 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
Re: [tor-dev] Proposal 334: A flag to mark Relays as middle-only
Thank you for working on this, I was hoping for such a flag for a long time, great to see that it is happening now. The flag should minimize the ability of the relay to do harm. This means such relays should _not_ be used by tor clients for _any_ other use-case than the second hop position (no HSDir, no fallbackdir, ...). Also ensure this functionality is available to tor clients via a torrc option like "ExcludeExitNodes" can be used by tor clients as well. The torrc option for clients could be named "LimitToMiddleOnlyNodes" or similar and takes a list of relay fingerprints and can appear multiple times in a torrc (like ExcludeExitNodes). If there are conflicting configurations the exclusion should overrule the inclusion of a relay fingerprint. Detected conflicts should cause a log entry. An example for a conflict: MapAddress, EntryNodes, ExitNodes (or any other including option) mentions a relay fingerprint that is also excluded. 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
Re: [tor-dev] descriptor sync finished event after disabling UseMicrodescriptors (stem)
Hi David,
thanks for your reply and confirming that there is no event for this,
so the best option is to make a simple loop and test every few seconds if the
download is completed I guess.
>> I also noticed that fetching takes significantly longer when
>> microdescriptors are disabled temporarily when compared to
>> adding
>> UseMicrodescriptors 0
>> to the torrc file persistently and restarting the tor client.
>
> Maybe simply because server descriptors are much larger than microdesc?
In both cases we fetch the same kind of descriptors.
1) torrc: UseMicrodescriptors 0 -> start tor -> fast to complete descriptor
fetching
2) no torrc change -> start tor -> controller.set_conf('UseMicrodescriptors',
'0') -> slow
Maybe (2) is slower because tor does not start the download directly after
set_conf('UseMicrodescriptors', '0')
is received.
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] descriptor sync finished event after disabling UseMicrodescritors
Hi,
what is the best way to find out when descriptor fetching is completed
after temporarily disabling microdescriptors on a running tor client daemon?
The temporary disabling of microdescriptors is done using this line in a python
script using stem:
controller.set_conf('UseMicrodescriptors', '0')
Is there a better way than to try and re-try after 10 seconds in a loop via
controller.get_server_descriptors() ?
I also noticed that fetching takes significantly longer when microdescriptors
are disabled temporarily when compared to
adding
UseMicrodescriptors 0
to the torrc file persistently and restarting the tor client.
Can I tell tor to "fetch now" directly after
controller.set_conf('UseMicrodescriptors', '0')
via an additional control command?
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
Re: [tor-dev] Resolving TXT records
Jorropo: > Is this expected or I am doing something wrong? Have a look at the documentation of DNSPort: https://2019.www.torproject.org/docs/tor-manual.html.en#DNSPort Tor's DNSPort is rather limited, if you need more I recommend to use an encrypted DNS protocol like DNS-over-TLS or DNS-over-HTTPS and route that over Tor, but be aware that your DNS resolution requests are linkable if you do not establish a new stream and connection for each resolution attempt. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor relay process health data for operators (controlport)
I've put this thread into a new ticket: "provide relay health prometheus metrics via MetricsPort/MetricsSocket" https://gitlab.torproject.org/tpo/core/tor/-/issues/40194 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] new home for trac/CoreTorReleases?
Nick Mathewson: >> in the past >> https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases >> >> used to be the canonical place for tor EoL information. >> Since Trac is no longer used: Is there a new home for this kind of >> information? > > https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases > is the new place. thanks! > Thanks, this is quite helpful! Is it okay if I add links to these > from the wiki page? sure. 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
[tor-dev] new home for trac/CoreTorReleases?
Hi, in the past https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases used to be the canonical place for tor EoL information. Since Trac is no longer used: Is there a new home for this kind of information? @Nick: In the past, before rejecting eol versions you asked about the current state on the tor network, the following new table will now provide you with a list of operators (more precisely ContactInfos) by clicking on the CW column you can get it sorted by consensus weight to find the biggest affected operators running eol releases: https://nusenu.github.io/OrNetStats/#tor-version-distribution-relays https://nusenu.github.io/OrNetStats/#end-of-life-relays-share kind regards, nusenu 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
Re: [tor-dev] proposal for "tor-relay" well-known URI
Nick Mathewson: > This is now proposal 326. Thanks! Please let me know if you have any comments on this proposal: https://github.com/torproject/torspec/blob/master/proposals/326-tor-relay-well-known-uri-rfc8615.md Nathaniel Wesley Filardo (Microsoft Research) left a comment on the github merge request [1]. The goal is to move the IANA registration [2] for "tor-relay" forward after the prop 326 reached the "accepted" status [3] so I'm curious to learn about any showstopper for the accepted status. This proposal is probably a bit different than others since it does not require any implementation in tor's code. kind regards, nusenu [1] https://github.com/torproject/torspec/pull/129#issuecomment-681194660 [2] https://github.com/protocol-registries/well-known-uris/issues/8 [3] https://github.com/torproject/torspec/blob/master/proposals/001-process.txt 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
[tor-dev] proposal for "tor-relay" well-known URI
Hi, I'm submitting this as a proposal according to: https://github.com/torproject/torspec/blob/master/proposals/001-process.txt I made a PR request for you: https://github.com/torproject/torspec/pull/129/files kind regards, nusenu 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
Re: [tor-dev] Can "ExcludeNodes" be used multiple times in torrc?
Damian Johnson: > Hi nusenu, tor's manual says [1]... > > "To split one configuration entry into multiple lines, use a single > backslash character (\) before the end of the line. Comments can be > used in such multiline entries, but they must start at the beginning > of a line." Thank you Damian! Reading the above I didn't expect that you can create a multiline entry without "\" before the end of the line. Now I'll play around to see how this works if a single multiline entry is split across multiple included files. -- https://mastodon.social/@nusenu 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
Re: [tor-dev] Can "ExcludeNodes" be used multiple times in torrc?
Nick Mathewson: > On Mon, Aug 10, 2020 at 6:13 PM nusenu wrote: >> >> Hi, >> >> it is not clear to me whether ExcludeNodes and other similar options >> (ExcludeExitNodes) >> can be used multiple times in a torrc file. >> >> Are all of the lines merged like multiple "MyFamily" lines or >> how does it behave? > > No, only one is recognized. thanks for your reply. Is there any way to comment fingerprints in ExcludeNodes? Since everything after "#" is ignored I guess something like this is not possible since everything after the first fingerprint is a comment? ExcludeNodes \ fingerprint1 # comment \ fingerprint2 # comment \ fingerprint3 # comment -- https://mastodon.social/@nusenu 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
[tor-dev] Can "ExcludeNodes" be used multiple times in torrc?
Hi, it is not clear to me whether ExcludeNodes and other similar options (ExcludeExitNodes) can be used multiple times in a torrc file. Are all of the lines merged like multiple "MyFamily" lines or how does it behave? thanks, nusenu -- https://mastodon.social/@nusenu 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
Re: [tor-dev] IANA well-known URI suffix registration "tor-relay"
Nick Mathewson: > I think as a general idea this is fine. thanks! > I could probably tweak the > format a bit, but there probably isn't a strong need. how would you like to tweak it? I tried to keep it as simple as possible for relay operators to keep adoption trivial. > One thing I'd want to know about though, is current uptake and trends > in uptake. How many relays are currently using this schema? > > I'm happy to say "yes, this is a good thing for family operators to > do" if that will help, but I'd rather that we only standardize > something if it's on track to get used. The ContactInfo spec is used currently by 100 relays (>12% exit probability). The amount of relays using it increased from 44 to 100 after version 1 of the spec got released on 2020-07-21. The well-known URI will be part of version 2. regards, nusenu -- https://mastodon.social/@nusenu 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
Re: [tor-dev] IANA well-known URI suffix registration "tor-relay"
nusenu: > submitted as: > https://github.com/protocol-registries/well-known-uris/issues/8 > > > @nickm and Mike: Mark would like to hear your opinion on it. > https://github.com/protocol-registries/well-known-uris/issues/8#issuecomment-670269951 here is the background story about this https://medium.com/@nusenu/how-malicious-tor-relays-are-exploiting-users-in-2020-part-i-1097575c0cac (specifically section "Better visualizations") -- https://mastodon.social/@nusenu 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
Re: [tor-dev] IANA well-known URI suffix registration "tor-relay"
submitted as: https://github.com/protocol-registries/well-known-uris/issues/8 @nickm and Mike: Mark would like to hear your opinion on it. https://github.com/protocol-registries/well-known-uris/issues/8#issuecomment-670269951 -- https://mastodon.social/@nusenu 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
Re: [tor-dev] How do Ed25519 relay IDs look like?
Damian Johnson: >> I hope we can agree to use the same format in all places. > > Thanks nusenu, that's a great summary. Honestly I doubt that > deprecating RSA keys is on anyone's visible horizon, and by extension > RSA-based fingerprints will remain our canonical identifiers for the > foreseeable future. That is fine. To clarify: I'm _not_ aiming to speed the transition to a RSA1024 free tor world up (that is not my goal here). I'd just like to see a decision on the naming and format that will be used from the point the decision has been made - so I can point to it and use it in the well-known URI submission. If it is clear to you that we will not see a decision on the naming and format in Aug 2020. That is also valuable information for me. -- https://mastodon.social/@nusenu 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
Re: [tor-dev] How do Ed25519 relay IDs look like?
nusenu:
> I'll wait until you (Tor developers) decided on the final naming and format
Is there any interest to move this topic forward to come to some decision
in the near future? (before the end of the month)
Here is a short summary of what opinions I observed for this topic (naming and
format
for Ed25519 identities) so far:
Naming proposals for relay Ed25519 identities:
'v2 fingerprints' (Damian)
"ed25519 identity" or even just "identity" (nickm)
Output format the Ed25519 relay IDs:
base64 - 43 characters long (nickm)
this is problematic due to the "/" sign (Damian)
hex - 64 characters long (Damian)
"/" is problematic for DirPort urls, GETINFO commands, etc (Damian)
isn't there urlencoding for URLs? (nusenu)
base64urlsafe - 43 characters long (nusenu)
I hope we can agree to use the same format in all places.
How does the decision process looks like in general in the Tor Project?
--
https://mastodon.social/@nusenu
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
Re: [tor-dev] How do Ed25519 relay IDs look like?
Damian Johnson: >> Isn't using "fingerprint" not a bit misleading since it is not the output of >> a hash function but the ed25519 master public key itself? > > Hi nusenu, that's fair. We've begun to conflate a couple concepts here... > > * Relay operators, controllers, DirPorts, etc all require a canonical > relay identifier. They don't care how it's derived as long as it's > unique to the relay. > > * Relays publish a public ed25519 key. This is an implementation > detail that isn't of interest to the above populations. > > I'd advise against attempting to rename "fingerprint". That hasn't > gone well for hidden services [1]. But with that aside, relay > identifiers and the representation of ed25519 public keys don't > necessarily need to be one and the same. I'll wait until you (Tor developers) decided on the final naming and format and added a reference https://github.com/nusenu/tor-relay-well-known-uri-spec/commit/949980e72132ba20ca9f687ed8d0e8b43a333834 thanks, nusenu -- https://mastodon.social/@nusenu 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
Re: [tor-dev] How do Ed25519 relay IDs look like?
> First, I'd advise that we call these 'v2 fingerprints' so it's clear > that we intend to substitute these anywhere traditional fingerprints > are used. Isn't using "fingerprint" not a bit misleading since it is not the output of a hash function but the ed25519 master public key itself? > Second, I would advise against truncated base64 identifiers. > Fingerprints are 40 character hex. master-key-ed25519's base64 value > can include slashes (such as > "yp0fwtp4aa/VMyZJGz8vN7Km3zYet1YBZwqZEk1CwHI") which will be > problematic for DirPort urls, GETINFO commands, etc. > > The simplest solution would be to simply hexify these values. This > will raise our fingerprint length from 40 to 64 characters to avoid increasing the length to 64 characters, how about using urlsafe base64 that does not make use of the "/" character? https://tools.ietf.org/html/rfc4648#section-5 https://docs.python.org/3/library/base64.html#base64.urlsafe_b64encode -- https://mastodon.social/@nusenu 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
Re: [tor-dev] How do Ed25519 relay IDs look like?
>> base64 encoding (parts of) the ed25519_master_id_public_key >> file, provides the same output as in master-key-ed25519 descriptor lines >> but I didn't find a spec for that key file to confirm the try and error >> approach >> or a tor command to simply output the ed25519_master_key public key in >> base64 format. I was wondering why the base64 string is 43 characters long for a 32byte Ed25519 key. 32*8/6=42 > I'd like to add such a command great, thanks! > as well as support for using ed25519 > keys in more places in the UI and the control API. maybe add a file similar to the datadir/fingerprint file containing the base64 representation of the Ed25519 public key? maybe datadir/ed25519_identity ? -- https://mastodon.social/@nusenu 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
Re: [tor-dev] IANA well-known URI suffix registration for tor-relay-fingerprints file
I've put together the text, if you have any comments please let me know. I'm planning to submit it soon-ish. https://nusenu.github.io/tor-relay-well-known-uri-spec/ I'll also send it to the tor-relays mailing list. kind regards, nusenu -- https://mastodon.social/@nusenu 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
Re: [tor-dev] How do Ed25519 relay IDs look like?
nusenu: >> The only question that came up was: Will there be two types of relay >> fingerprints >> in the future (Ed25519)? > > I assume the correct proposal for the Ed25519 keys is this: > https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt > > I'm wondering what kind of format is used for a relay's Ed25519 ID in tor? > > The spec says base64: > >>When an ed25519 signature is present, there MAY be a "master-key-ed25519" >>element containing the base64 encoded ed25519 master key as a single >>argument. If it is present, it MUST match the identity key in >>the certificate. > > examples: > grep master-key-ed 2020-07-28-19-05-00-server-descriptors |head -2 > > master-key-ed25519 clT/2GWmTY/qU5TBGaudAIjOUUxUdKhMY/Q5riK6G2E > master-key-ed25519 qDI9PbwtiKzpR9phLnWI99uimdwNW8+l9c7hDoWV9dQ > > Is this the canonical format you use when referring to a relay's Ed25519 > identity? I looked at what stem does in this area [1]. It uses the more accurate name "ed25519_master_key" instead of Ed25519 ID and contains the above mentioned base64 encoded Ed25519 public master key so I assume this is the canonical format since I didn't see any other representation. > What command does a relay operator need to run to find out > his relay's Ed25519 ID on the command line? base64 encoding (parts of) the ed25519_master_id_public_key file, provides the same output as in master-key-ed25519 descriptor lines but I didn't find a spec for that key file to confirm the try and error approach or a tor command to simply output the ed25519_master_key public key in base64 format. kind regards, nusenu [1] https://stem.torproject.org/api/descriptor/server_descriptor.html#stem.descriptor.server_descriptor.RelayDescriptor https://gitweb.torproject.org/torspec.git/tree/cert-spec.txt These are the file paths I would suggest for the well-known registry: .well-known/tor-relay/rsa-fingerprints .well-known/tor-relay/ed25519-pubkeys -- https://mastodon.social/@nusenu 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
[tor-dev] How do Ed25519 relay IDs look like?
> The only question that came up was: Will there be two types of relay > fingerprints > in the future (Ed25519)? I assume the correct proposal for the Ed25519 keys is this: https://gitweb.torproject.org/torspec.git/tree/proposals/220-ecc-id-keys.txt I'm wondering what kind of format is used for a relay's Ed25519 ID in tor? The spec says base64: >When an ed25519 signature is present, there MAY be a "master-key-ed25519" >element containing the base64 encoded ed25519 master key as a single >argument. If it is present, it MUST match the identity key in >the certificate. examples: grep master-key-ed 2020-07-28-19-05-00-server-descriptors |head -2 master-key-ed25519 clT/2GWmTY/qU5TBGaudAIjOUUxUdKhMY/Q5riK6G2E master-key-ed25519 qDI9PbwtiKzpR9phLnWI99uimdwNW8+l9c7hDoWV9dQ Is this the canonical format you use when referring to a relay's Ed25519 identity? (So it is not a hash of the key but the entire public Ed25519 master key of the relay since Ed25519 keys are so short.) What command does a relay operator need to run to find out his relay's Ed25519 ID on the command line? Here is the example for the RSA1024 SHA1 fingerprint: openssl rsa -in keys/secret_id_key -outform DER -RSAPublicKey_out 2> /dev/null| openssl sha1 -r|cut -d" " -f1|sed -e 's/ /,/g' also: Are there any plans to include the Ed25519 IDs in onionoo/Relay Search? What format would you most likely use there? thanks, nusenu These are the filenames I would suggest for the well-known registry: tor-relay-rsa-fingerprints tor-relay-ed25519-pubkeys -- https://mastodon.social/@nusenu 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
[tor-dev] IANA well-known URI suffix registration for tor-relay-fingerprints file
Hi, to reduce the risk of certain kinds of attacks I'm aiming to submit a short spec (like [1]) in accordance with RFC8615 https://tools.ietf.org/html/rfc8615#section-3.1 for the registration of of a suffix for the verifyurl from https://github.com/nusenu/ContactInfo-Information-Sharing-Specification#verifyurl The name I have in mind is: tor-relay-fingerprints The file contains comments (lines starting with #) and relay fingerprints. https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml Let me know if you have any feedback on this and whether you have any opinion on whether you (The Torproject) wants to be the change controller. The only question that came up was: Will there be two types of relay fingerprints in the future (Ed25519)? thanks, nusenu -- https://mastodon.social/@nusenu [1] https://keybase.io/docs/keybase_well_known 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
Re: [tor-dev] DNS-over-HTTPS (DOH) in Firefox/Torbrowser
Georg Koppen: > nusenu: >> Hi, >> >> since Mozilla did tests [0] on DOH [1] in Firefox I was wondering >> if Torbrowser developers have put any thought into that as well? > > Actually, the study did not get done yet. The start date is scheduled > for June 4th, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1446404 > > We'll look at the code in the coming weeks when doing our audit for > ESR60 and we'll follow the Mozilla experiment closely. Right now we > don't have plans to enable DOH in Tor Browser 8. Since we are discussing this topic in the "Support for full DNS resolution and DNSSEC validation" thread, I wanted ask whether there have been any updates on this topic since and how you think about making use of DoH in Tor Browser? I'd be interested to write a design document, but if you see a blocker then we probably shouldn't be putting any resources into it. kind regards, nusenu -- https://mastodon.social/@nusenu 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Christian Hofer: > On Tue, 2020-06-09 at 23:54 +0200, nusenu wrote: >>> However, thinking about it, DNSSEC might be useful for caching DNS >>> records on the client side. >> >> caching has privacy implications and is therefore a risk. >> > > So you are saying that caching is not an option in any case, right? Can > I kindly ask you to elaborate on this? You don't have to write a long > answer. A link pointing me to the answer would be more than enough. I > just want to understand the reason behind this. You can use cache but it must address the linkability risk by scoping the cache usage. With DoH the browser has access to TTL values from DNS records, so caching is somewhat easier for the browser as it used to be. keywords and pointers: unlinkability first party isolation https://www.torproject.org/projects/torbrowser/design/ >> but finding resolvers is probably one of the smaller issues when >> compared to getting >> everything implemented in firefox/tor browser. Current versions do >> not even allow >> to set more than one resolver URL. >> > > I see. Are there any tickets or design proposals I can contribute to? I haven't put my ideas into a specification yet, but it looks like there is a good reason to write a spec now. A next step - before anything else - could be to ask Tor Browser people if there are any DoH plans yet, I did so back in 2018 and will follow up on that right after this email. > Since you have no comments on my suggestion for an alternative > approach, I assume that it is not worth to compare it to DoH, right? to quote my vision: > My vision for DNS privacy in Tor Browser: > Be able to visit a HTTPS website without the exit relay learning what domain > it was > (encrypted DNS + encrypted SNI) This vision somewhat implies the use of DoH, since Firefox requires DoH for ESNI (unless one wants to implement that in an additional Firefox patch). A second good reason for DoH over some other option: DoH is a specified protocol with public implementations and public services/service providers. This helps with resolver diversity, availability and gives us more options when choosing resolvers. kind regards, nusenu -- https://mastodon.social/@nusenu 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
> However, thinking about it, DNSSEC might be useful for caching DNS > records on the client side. caching has privacy implications and is therefore a risk. >> My vision for DNS privacy in Tor Browser: >> Be able to visit a HTTPS website without the exit relay learning what >> domain it was >> (encrypted DNS + encrypted SNI) >> > > Makes sense. Which nameserver are you planning to use, since the used > provider will get all Tor Browser DNS queries? Do you (the Tor project) > plan to host your own DNS resolver(s)? based on statements from Roger about what is the max. acceptable size of a single exit operator in terms of fraction of the network I'd assume that it is somewhat ok to use a single resolver operator for about 5% of the total exit traffic. That means we need at least 20 resolver operators, preferably 30. We could come up with requirements for them (Mozilla's DoH resolver requirements is a start) and make use of public privacy aware DNS resolver operators that meet the requirements. It might also be possible to ask well established exit operators to run DoH endpoints on their resolvers. This would have positive performance implications and increase the number of available DoH servers. but finding resolvers is probably one of the smaller issues when compared to getting everything implemented in firefox/tor browser. Current versions do not even allow to set more than one resolver URL. kind regards, nusenu -- https://mastodon.social/@nusenu 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Christian Hofer: > The thread model is DNS hijacking. Yes, you can prevent DNS hijacking > using DoH if you *trust* the resolver you connect to. However, if you > want to verify authenticity and integrity of DNS responses you need > DNSSEC. Could you elaborate on the use-case since DNS record authenticity is often just a vehicle to bootstrap some other use-case (for example DANE). What higher level use-case do you have in mind where authenticity of DNS entries provides a value for tor / Tor Browser users? What I'm trying to get to: Authentic IP addresses from A/ records are probably of limited value in the context of a tor client since the exit relay has full control over the routing anyway. If the tor clients asks the exit relay to connect to IP A (which is the actual DNSSEC validated IP address) there is nothing that can stop an exit from routing it to some other IP address. That is why I'm trying to get to the bottom of your DNSSEC use-case. To avoid anonymity set reductions I'm also primarily interested in enabled by default designs (in contrast to opt-in) which brings you to the next problems: performance, scaleability and resolver selection. Please don't let me discourage you with my questions, they are not meant to. Just trying to understand and hopefully find some common ground to move forward since I see a rather motivated person and it would be a pity to loose that opportunity. My vision for DNS privacy in Tor Browser: Be able to visit a HTTPS website without the exit relay learning what domain it was (encrypted DNS + encrypted SNI) There are a few issues to solve along that path. kind regards, nusenu 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Christian Hofer: > On Sat, 2020-05-16 at 01:37 +0200, nusenu wrote: >> Alexander Færøy: >>> I wonder if it would make more sense to have an onion-aware >>> DNSSEC-enabled resolver *outside* of the Tor binary and have a way >>> for >>> Tor to query an external tool for DNS lookups. >> >> I'm also in favor of this approach, >> and you can do this today with no code changes to tor at all. >> >> CF demonstrated it even before DoH/RFC8484 was finalized: >> https://blog.cloudflare.com/welcome-hidden-resolver/ >> > > Do you have DNSSEC validation in this approach? That is up to you. If you use a stub resolver that has DNSSEC support (like stubby) you have DNSSEC validation. >> + 1 for DoT and DoH over tor, especially due to the DoH >> implementation that is >> available in firefox (it would still require work on stream isolation >> and caching >> risks to ensure the usual first party isolation). >> In terms of achieving a big improvement on tor browser users in the >> context of DNS >> this would be the most effective path to spend coding resources on in >> my opinion. >> >> > > It seems that Firefox's DoH implementation does not employ DNSSEC > validation, see [2]. They trust CF doing it for them. Be careful here. I'm aware that firefox does not perform DNSSEC validation. I don't think the tor project would enable DNSSEC in Tor Browser without a good use-case or a (future) TLS extensions solving the latency issue. Since DANE for HTTPS does not appear to be a thing and there is no DANE support in firefox I'm also wondering about the specific use-cases for DNSSEC in Tor Browser. > Furthermore, there are privacy concerns about additional metadata > regarding the use of DoH (agent headers, solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1543201 > language settings, solved since https://bugzilla.mozilla.org/show_bug.cgi?id=1544724 > and cookies) I don't think firefox sends cookies in DoH requests. I'm still curious about the underlying threat model and use-cases (my first questions in this thread), since that would help with trying to understand what you are trying to achieve. kind regards, nusenu 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
> Before we go further, can you walk me through the reasons (if you had thought > of it of course) why you didn't use something like libunbound? > > There are side effects of adding DNSSEC client support (with our own > implementation) that we, people maintaining tor, have to become DNSSEC expert > in some ways just to be able to understand what is happening in that code, fix > issues but also possibly implement new features if any. That is where a third > part library like unbound becomes very nice because they are the experts at > providing such features. > > Of course, everytime we have to link to an external library we do it carefully > and with considerations because of the "yet another attack" vector problem. > But adding that much code to support a well known feature like DNSSEC also has > huge implications for tor maintainability and security. > > Finally, something I noticed and made me itch a bit. You hardcoded a lot of > .onions where one appears to be Cloudflare (?) resolver. What are the other > addresses? I worry here because default options are always the one used the > most so I'm concerned here about shipping hardcoded addresses _within_ our C > code. +1 for "don't roll your own DNS(SEC) implementation". There are people that do DNS(SEC) for years, should the torproject really implement and maintain its own custom DNS stub resolver and DNSSEC validator? Also consider that DNS is moving towards DNS encryption protocols (DoT and DoH) and firefox has DoH support that could be made stream isolation aware. Using open protocols will increase the availability of multiple public resolvers speaking that protocol. 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
> To me, extra round-trips over the Tor network in the critical path of > "user clicks and waits for the website to load" are really bad, and > need a really good argument for being there. Given that DNS is only one > piece of the connection -- after all, the exit relay can still route you > somewhere else -- it's hard to see how this case brings enough benefit > to justify the extra round trip(s). > > Ok, with that as a preface, here is an alternative design: the Tor > client sends the hostname to the exit relay, along with a request for > dnssec proofs. The exit relay uses its own dnssec server to convince > itself that its answer is right. Then it returns the IP address in > the CONNECTED cell as it does now, and also it returns a set of dnssec > answers that the client can use to reconstruct the dnssec interaction > and convince itself of the result too. > > This design adds no extra round trips (yay), but it requires a notion of > "dnssec chain stapling" that I think doesn't entirely exist yet. Alex > points me to a long-expired IETF draft from agl on the topic: > https://tools.ietf.org/html/draft-agl-dane-serializechain-01 > and I don't know if there is newer progress. also expired but newer https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ > I would also worry about the overall size of the stapled answers -- if we > add another 50KBytes to every stream interaction in Tor, that's probably > not worth it. Whereas adding another 1KByte could be a great tradeoff. > > Yet another twist here is that it's hard for the client to cache answers, > or to cache intermediate certs in the chain, because changing behavior > based on cached answers can reveal the client's past browsing history. I share your concerns on performance (additional round trips) and caching and I find it also important to note that in the context of tor browser (probably the main use case of tor) encrypted DNS (confidentiality) is more relevant than DNSSEC (integrity), especially as soon as ESNI becomes reality. https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ That will allow for using tor exits without disclosing the visited domain to the exit relay and no more issues with exits with broken DNS. DNSSEC would still be valuable for TLS verification but DANE for https does not appear to be a thing. 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Alexander Færøy: > I wonder if it would make more sense to have an onion-aware > DNSSEC-enabled resolver *outside* of the Tor binary and have a way for > Tor to query an external tool for DNS lookups. I'm also in favor of this approach, and you can do this today with no code changes to tor at all. CF demonstrated it even before DoH/RFC8484 was finalized: https://blog.cloudflare.com/welcome-hidden-resolver/ > Such tool should be > allowed to use Tor itself for transport of the actual queries. One of > the best parts of Tor (in my opinion) is the Pluggable Transport > subsystem. This subsystem allows external developers, researchers, and > hackers to build new technology that benefits users in censored areas > *without* having to alter a single line of C code in tor.git. > > Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to > configure their Tor process to *never* use the built-in DNS subsystem in > Tor, but instead outsource it to an external process that Tor spawns on > startup. This process could use .onion's to reach a > DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up > via DNS. + 1 for DoT and DoH over tor, especially due to the DoH implementation that is available in firefox (it would still require work on stream isolation and caching risks to ensure the usual first party isolation). In terms of achieving a big improvement on tor browser users in the context of DNS this would be the most effective path to spend coding resources on in my opinion. 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
> I can not really say anything about how this design compares to other > approaches, since I don't know how I can setup meaningful test > scenarios to compare them. Do we really need test setups to discuss protocol designs and compare protocols with a common threat model if specs for the protocols are available? > However, I would appreciate if you could > share how to setup such test environments. take your preferred DoT client implementation that supports the strict profile (RFC8310) or your preferred DoH implementation and route it over tor to your resolver of choice. 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
Re: [tor-dev] Support for full DNS resolution and DNSSEC validation
Hi Christian, thanks for your efforts to improve DNS resolution in the tor context. A few general questions: - What is the underlying threat model and what threats you are trying to address in your proposal? - What use case are you aiming for? Do you propose to make use of this DNS resolution in Tor Browser by default? - if so: - Do you do connection re-use to route multiple DNS queries over a single connection? (related: RFC 7766) - How does your proposal (or the user of your proposal - Tor Browser) ensure stream isolation for DNS queries to avoid profiling based on DNS queries? - How do you aim to solve the problems of resolver selection and centralization? if not: - why not just run existing resolver software (i.e. stubby) over tor? - How does your design compare to running existing DNS privacy protocols over tor that do not require any changes to tor? - DoT non-opportunistic mode+DNSSEC validation or - DoH+DNSSEC validation I would also be interesting to see how your design compares to a design like this (aiming for Tor Browser integration and enabled by default, without tor changes): DoH (RFC 8484) enabled in Tor Browser, the vanilla DoH implementation in Firefox slightly changed so it is stream isolation aware (domains are resolved via the same stream that is used to fetch the HTTP content in all cases where the exit policy allows for that). Resolver selection: pre-configured list in Tor Browser (no implementation or proposal exists at this point) > Filename: 317-secure-dns-name-resolution.txt > Title: Improve security aspects of DNS name resolution > Author: Christian Hofer > Created: 21-Mar-2020 > Status: Open > > Overview: > >This document proposes a solution for handling DNS name resolution within >Tor in a secure manner. In order to achieve this the responsibility for >name resolution is moved from the exit relays to the clients. Therefore a >security aware DNS resolver is required that is able to operate using Tor. > DNSResolverNameservers: A list of comma separated nameservers, can be an > IPv4, an IPv6, or an onion address. Should allow means to configure > the > port and supported zones. How is end-to-end encryption / query confidentiality ensured in the case this configuration parameter contains IPv4/IPv6 addresses? > DNSResolverHiddenServiceZones: A list of comma separated hidden service > zones. What are "hidden service zones"? what is the impact of listing them in this config parameter and how is it related to RFC 7686? > DNSResolverTrustAnchors: A list of comma separated trust anchors in DS > record format. https://www.iana.org/dnssec/files Does your design support RFC 5011? > DNSResolverMaxCacheEntries: Specifies the maximum number of cache > entries. Where is the cache located? Is it written to disk? Is the cache stream isolation aware or do you aim to reuse the cache across multiple streams? (which results in correlation issues across streams) > Performance and scalability: > >Since there are no direct changes to the protocol and this is an > alternative >approach for an already existing requirement, there are no performance >issues expected. Additionally, the encoding and decoding of DNS message >handling as well as the verification takes place on the client side. A few remarks regarding performance (DNS resolution response time and subsequent content fetches i.e. HTTPS): - this design increases the network path when the configured resolver is not the exit relay - a design that will not use the exit for resolution will likely have a performance impact on domains that do geoIP based optimizations to allow i.e. HTTP fetches from locations near the exit relay kind regards, nusenu ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Lets give every circuit its own exit IP?
> While I have no skills to implement this, it is a damn good idea! > > Would these be IPv6 addresses? As the ticket says, the idea is to support it for IPv4 and IPv6. In practice big blocks of IPv4 are likely to expensive for most operators but IPv6 addresses basically don't cost anything. https://trac.torproject.org/projects/tor/ticket/26646 -- https://mastodon.social/@nusenu 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
Re: [tor-dev] Lets give every circuit its own exit IP?
Would it help to write a short proposal to move this forward? Would there be someone to actually implement it? According to nickm: "This wouldn't be too hard, actually." [1] As more platforms (i.e. youtube) are more strictly blocking IPs with bad reputation this would be a crucial feature to make the internet more accessible to Tor users. thanks, nusenu [1] https://trac.torproject.org/projects/tor/ticket/3847#comment:6 -- https://mastodon.social/@nusenu 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
Re: [tor-dev] TOR Browser Circuit Selection of Exit Nodes
possibly useful for you: https://gitweb.torproject.org/torspec.git/tree/path-spec.txt https://gitweb.torproject.org/torspec.git/tree/guard-spec.txt -- https://mastodon.social/@nusenu 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
Re: [tor-dev] tor relay process health data for operators (controlport)
nusenu: > Hi, > > every now and then I'm in contact with relay operators > about the "health" of their relays. > Following these 1:1 discussions and the discussion on tor-relays@ > I'd like to rise two issues with you (the developers) with the goal > to help improve relay operations and end user experience in the long term: > > 1) DNS (exits only) tracked as: https://trac.torproject.org/projects/tor/ticket/31290 > 2) tor relay health data tracked as: https://trac.torproject.org/projects/tor/ticket/31291 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] resolving DNS TXT records?
Hi, as far as I can tell there is no way for a tor client to ask an exit to resolve a given TXT record and to provide the answer for it. Just wanted to make sure there is even no hack around that limitation. thanks, nusenu https://gitweb.torproject.org/torspec.git/tree/proposals/219-expanded-dns.txt -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] tor's SOCKS5 extension "RESOLVE"
> I modified exitmap to print the entire response in case the ATYP field is set > to 04 (meaning the > response contains an IPv6 address) but > the response is not any longer and contains only the first 4 bytes of the > IPv6 address. > > Running tor 0.3.5.8. > > Has this bug been fixed in later versions of tor or current master? My assumption was a bit to fast ;) exitmap just reads 10 bytes only: resp = self._recv_all(10) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] tor's SOCKS5 extension "RESOLVE"
> Running tor 0.3.5.8. > > Has this bug been fixed in later versions of tor or current master? moved to trac: https://trac.torproject.org/projects/tor/ticket/31115 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] tor's SOCKS5 extension "RESOLVE"
Thanks this is very useful information.
>>> # Tor defines a new command value, \x0f, that is used for
>> domain
>>> # resolution.
>>>
>>> self._send_all("\x05\xf0\x00\x03%s%s%s" % (chr(domain_len),
>>> domain, "\x00\x00"))
>
> Exitmap uses the SOCKS 5, resolve, DNS command: See page 4 of
> https://www.ietf.org/rfc/rfc1928.txt The SOCKS request is formed as
> follows:
>
> ++-+---+--+--+--+ |VER | CMD | RSV
> | ATYP | DST.ADDR | DST.PORT |
> ++-+---+--+--+--+ | 1 | 1 | X'00'
> | 1 | Variable |2 |
> ++-+---+--+--+--+
so in above python code the values are:
ver = \x05
cmd = \xf0 ("RESOLVE") - custom tor extension not in RFC
rsv = \x00
atyp = \x03 (domain)
dst.addr = domain variable
dst.port = \x00\x00
from https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt#n49
> 2. Name lookup
>
> As an extension to SOCKS4A and SOCKS5, Tor implements a new command
> value, "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command,
> it initiates a remote lookup of the hostname provided as the target
> address in the SOCKS request. The reply is either an error (if the
> address couldn't be resolved) or a success response. In the case of
> success, the address is stored in the portion of the SOCKS response
> reserved for remote IP address.
>
> (We support RESOLVE in SOCKS4 too, even though it is unnecessary.)
>
> For SOCKS5 only, we support reverse resolution with a new command
> value, "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5
> command with an IPv4 address as its target, Tor attempts to find the
> canonical hostname for that IPv4 record, and returns it in the
> "server bound address" portion of the reply. (This command was not
> supported before Tor 0.1.2.2-alpha.)
The spec leaves multiple open questions:
- What does "initiates a remote lookup of the hostname" mean?
The spec could be improved by saying "A" or/and "" DNS lookup is performed.
- There is no information about the response in
torspec.git/tree/socks-extensions.txt at all?
> Resolve can return an IPv4 or IPv6 response, but Exitmap ignores the
> address type, and turns the first 4 bytes of the response into an
> IPv4 address.
I modified exitmap to print the entire response in case the ATYP field is set
to 04 (meaning the
response contains an IPv6 address) but
the response is not any longer and contains only the first 4 bytes of the IPv6
address.
Running tor 0.3.5.8.
Has this bug been fixed in later versions of tor or current master?
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
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
[tor-dev] exitmap/RESOLVE control command limitations
Hi,
I noticed some unexpected answers in exitmap's [1] dnsenum results
and suspected that this has todo with IPv4 vs. IPv6.
First I looked at [2] and found that it only lists IPv4 and hostnames
as possible answers but then I realized that exitmap might not be using
the RESOLVE command?
> def resolve(self, domain):
> """
> Resolve the given domain using Tor's SOCKS resolution extension.
> """
>
> domain_len = len(domain)
> if domain_len > 255:
> raise error.SOCKSv5Error("Domain must not be longer than 255 "
> "characters, but %d given." % domain_len)
>
> # Tor defines a new command value, \x0f, that is used for domain
> # resolution.
>
> self._send_all("\x05\xf0\x00\x03%s%s%s" %
> (chr(domain_len), domain, "\x00\x00"))
>
> resp = self._recv_all(10)
> if resp[:2] != "\x05\x00":
> raise error.SOCKSv5Error("Invalid server response: 0x%s" %
> resp[1].encode("hex"))
>
> return socket.inet_ntoa(resp[4:8])
Does Tor's SOCKS resolution extension support IPv6 answers
or does it only attempt A records?
I'm aiming to resolve a hostname and would like to get
the IPv4 and if available the IPv6 address.
thanks,
nusenu
[1] https://github.com/NullHypothesis/exitmap
[2] https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1349
--
https://twitter.com/nusenu_
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
Re: [tor-dev] Tor exit bridges
juanjo: > Tor relays are public and easily blocked by IP. To connect to Tor > network users where Tor is censored have to use bridges and even PTs. > But, what happens on the exit? Many websites block Tor IPs so using > it to access "clearweb" is not possible. Should we allow and start > using "exit bridges"? In I2P we have not this problem since there is > no central IP list of relays. there is no need to extend to one more hope to achieve this https://lists.torproject.org/pipermail/tor-dev/2018-March/013036.html https://lists.torproject.org/pipermail/tor-relays/2019-May/017273.html -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] tor relay process health data for operators (controlport)
> Thanks for this email. I exporting more metrics on the control port is a > great idea. I wanted to have that for a while Great to hear that so we have a realistic chance it gets actually implemented :) > There are safety questions to ask ourselves here before blindly > exporting many stats. Sure. > Exporting many stats to the control port unfortunately means that all > relay operator can possibly create fancy graphs making non-public graphs and alerts is the goal > and make them public public graphs should result in the rejection of affected relays. I'll be submitting a few to bad-relays@ soon since enn.lu apparently does not care when asked to remove their public stats and xml data. > which, depending on the stat, can be harmful. > > Furthermore, graphing stats can also means that over time the relay > operator stores historical data of everything that happened within the > relay and that can be used in many ways to pull off attacks (ex: > subpoena to access such data base by LE). yes, acceptable / unacceptable retention times and granularity should be defined and documented. I'd propose a max. retention time of two weeks. > The Heartbeat log has a minimum of 30 minutes period but a default of 6 > hours. current tor has no restrictions on Heartbeat granularity, you can ask tor to write the data to the logs every other second by issuing "SIGNAL HEARTBEAT" on the control port. > Whatever stats we would end up exporting, I strongly think that > keeping delays like that is a strong requirement because we would sort > of "bin" those aggregated stats by a "long enough period" instead of > having a very fine grained stream of stats that would make it trivial to > spot spikes down to the minute. 30 or 60 minutes granularity seems reasonable > Some of the stats below are safe in my opinion like the memory usage but > most of them need to be looked at in terms of safety yes please -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] tor relay process health data for operators (controlport)
Hi, every now and then I'm in contact with relay operators about the "health" of their relays. Following these 1:1 discussions and the discussion on tor-relays@ I'd like to rise two issues with you (the developers) with the goal to help improve relay operations and end user experience in the long term: 1) DNS (exits only) 2) tor relay health data 1) DNS -- Current situation: Arthur Edelstein provides public measurements to tor exit relay operators via his page at: https://arthuredelstein.net/exits/ This page is updated once daily. the process to use that data looks like this: - first they watch Arthur's measurement results - if their failure rate is non-zero they try to tweak/improve/change their setup - wait for another 24 hours (next measurement) This is a somewhat suboptimal and slow feedback loop and is probably also less accurate and less valuable data when compared to the data the tor process can provide. Suggestion for improvement: Exposes the following DNS status information via tor's controlport to help debug and detect DNS issues on exit relays: (total numbers since startup) - amount of DNS queries send to the resolver - amount of DNS queries send to the resolver due to a RESOLVE request - DNS queries send to resolver due to a reverse RESOLVE request - amount of queries that did not result in any answer from the resolver - breakdown of number of responses by response code (RCODE) https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6 - max amount of DNS queries send per curcuit If this causes a significant performance impact this feature should be disabled by default. 2) general relay health metrics Compared to other server daemons (webserver, DNS server, ..) tor provides little data for operators to detect operational issues and anomalies. I'd suggest to provide the following stats via the control port: (most of them are already written to logfiles by default but not accessible via the controlport as far as I've seen) - total amount of memory used by the tor process - amount of currently open circuits - circuit handshake stats (TAP / NTor) DoS mitigation stats - amount of circuits killed with too many cells - amount of circuits rejected - marked addresses - amount of connections closed - amount of single hop clients refused - amount of closed/failed circuits broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1402 https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n1994 - amount of closed/failed OR connections broken down by their reason value https://gitweb.torproject.org/torspec.git/tree/control-spec.txt#n2205 If this causes a significant performance impact this feature should be disabled by default. cell stats - extra info cell stats as defined in: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1072 This data should be useful to answer the following questions: - High level questions: Is the tor relay healthy? - is it hitting any resource limits? - is the tor process under unusual load? - why is tor using more memory? - is it slower than usual at handling circuits? - can the DNS resolver handle the amount of DNS queries tor is sending it? This data could help prevent errors from occurring or provide additional data when trying to narrow down issues. When it comes to the question: **Is it "safe" to make this data accessible via the controlport?** I assume it is safe for all information that current versions of tor writes to logfiles or even publishes as part of its extra info descriptor. Should tor provide this or similar data I'm planing to write scripts for operators to make use of that data (for example a munin plugin that connects to tor's controlport). I'm happy to help write updates for control-spec should these features seem reasonable to you. Looking forward to hearing your feedback. nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Onion-Location HTTP header
(just pasting the references from twitter threads, I'm not sure if there is a nice way to view the entire thread and all subthreads without missing any) Alec Muffett: > perhaps it's time that > we stopped trying to hide the fact that we are using Tor? https://twitter.com/sjmurdoch/status/1054797781343330307 https://twitter.com/arthuredelstein/status/1054835301028253696 > the fact that/when traffic > arrives from Tor is virtually unhideable. related https://lists.torproject.org/pipermail/metrics-team/2018-September/000914.html -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] deb.tpo 0.3.5 repos intentionally empty?
Peter Palfrader: >> >> the tor 0.3.5.x repos (example [1]) exist since some time >> but are empty since then, is that intentional? > > All existing 0.3.5.x releases fail to build from source (#27781). thanks for that info. Let's wait for the next release then I guess. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] deb.tpo 0.3.5 repos intentionally empty?
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-stretch/main/binary-amd64/Packages -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] Memory usage on 0.3.4.8
Hi r1610091651, thanks for your report. please add that information and your OS+version to https://trac.torproject.org/projects/tor/ticket/27813 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] routing security handling in the tor network
to underline the relevance of this: one of the most important IP blocks (185.222.100.0/22) on the internet with regards to Tor created route origin authorizations (ROAs) for their prefixes. These prefixes are use by 3 major exit operators (including the biggest exit operator). they make up >15% of the Tor network's exit capacity, which means that we are around 50% RPKI ROA coverage for Tor exit capacity now. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] routing security handling in the tor network
Hi, I looked at the routing security state of the >3k BGP prefixes that make up the tor network [1]. I believe it is important for tor to have a discussion on how the network should deal with relays that will increasingly be only partially reachable due to the increase of RPKI route origin validation (ROV) in big IXPs (AMS-IX to name one). to quote the relevant part from [1]: > “Virtual” Route Origin Validation in the Tor Context > > The are two good reasons why Tor should care about relays located in > RPKI ‘Invalid’ prefixes: > > It will eventually break the “the Tor network is a full mesh” > assumption. Relays in such RPKI ‘invalid’ prefixes with no > alternative valid route will not be reachable from ASes performing > ROV, but the Tor network assumes that every relay can reach every > other relay. When ROV breaks that assumption it is better to exclude > these relays than to keep only partially reachable relays. An RPKI > ‘Invalid’ route might as well be an actual BGP hijacking attempt and > why not stop that? > > The obvious place to enforce ROV for the Tor network would be the Tor > directory authorities that would run RPKI validators and vote for > relays accordingly. At this point this is no more than an idea. There are certainly some challenges and trade-offs when doing ROV from a non-BGP-router perspective, but they are solvable. There is no need to panic - this affects less than 5 relays currently but we should have a discussion and reach some form of consensus on the topic to move forward instead of waiting until it significantly affects reachability. Would be nice to have an initial discussion even before writing a proposal to gather opinions if that would be actually worth doing. kind regards, nusenu [1] https://medium.com/@nusenu/how-vulnerable-is-the-tor-network-to-bgp-hijacking-attacks-56d3b2ebfd92 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] [release] Onionoo 7.0 will be released after September 3, 2018
Hello Karsten, > yesterday we announced Onionoo protocol version 6.2 that we released a > few days before on August 3, 2018. > > One month later, after September 3, 2018, we're going to release Onionoo > protocol version 7.0 does this also mean that there will be no version between these two, to address the regression in 6.2 (#27039) before September? -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] Tor Relay Guide Disagreements
> Going forward I'd propose the following to minimize the fraction and overhead: > > I assume you maintain: > /TorRelayGuide-ptbr > /TorRelayGuide/OpenBSD > /TorRelayGuide/NetBSD > /TorRelayGuide/DragonFlyBSD > > > I'll keep maintaining: > /TorRelayGuide > /TorRelayGuide/DebianUbuntu > /TorRelayGuide/CentOSRHEL > /TorRelayGuide/Fedora > /TorRelayGuide/FreeBSD > /TorRelayGuide/openSUSE /BSDUpdates (I might split that so we can assign that as easily as the rest) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] Tor Relay Guide Disagreements
Hi Vinícius, (moving this discussion to the tor-dev mailing list since this isn't limited to the OpenBSD ticket scope https://trac.torproject.org/projects/tor/ticket/26619#comment:14 ) Vinícius wrote: > you [nusenu] took over /FreeBSD, /BSDUpdates, and /OpenBSD and enabled the > 'read- > only' mode all by yourself without even consulting the original author or > anyone else [...] > is there any particular reason why you enabled the read-only mode on > /FreeBSD, /BSDUpdates, and /OpenBSD? I think this a pretty odd behavior. > I'm sorry. if you do want to own all these pages (and many other more), > please tell us. The Tor Relay Guide wiki page [1] has been 'read-only' pretty much since we launched it, it has been decided a few months ago in [0]. Anyway read-only mode shouldn't affect you personally. Since you are listed on the tor people page I assume you can simply ask for the permissions to edit 'read-only' pages. I'd still ask you to open tickets for changes like your change to the FreeBSD page instead of applying them directly so we can discuss them before applying and to avoid the necessary efforts. On 2018-07-10 I split out the OS specific instructions into their subpages: /DebianUbuntu /FreeBSD ... because of this move content that was previously read-only until then became writable but that wasn't an intentional step. On 2018-08-02 you changed the FreeBSD page [4], here are two lines (examples) of your replacements: my text: change the nickname "myNiceRelay" to a name that you like Change the email address bellow and be aware that it will be published got replaced with: CHANGE THE NICKNAME WRITE YOUR EMAIL ADDRESS I'm not sure I would consider these replacements an improvement since they remove information without giving any reasoning for removing it in the comment. Besides the removal of information this also introduces inconsistency in the torrc file we used so far in the guide. I reverted your change and addressed the issue you brought up (net.inet.ip.random_id ordering, /etc/pkg/FreeBSD.conf modification) and made the content read-only again (like it was until 2018-07-10). > ggus is that page's [/OpenBSD] author and he allowed me to edit the > contents of that > page (the same is also applied to the /FreeBSD page; There has been no comment by ggus on #26619 (/OpenBSD) for a month so I went ahead and assigned it to me, but I'll pull out of that ticket now. https://trac.torproject.org/projects/tor/ticket/26619 ggus didn't create /FreeBSD [3]. > should we always open tickets with suggestions? - sadly it > also sounds extra odd, because when I did open tickets (#27006 and > #27007), a few minutes later you changed contents all by yourself #27006 is about /DragonFlyBSD I've never touched that page? https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/DragonFlyBSD?action=history #27007 was about creating /NetBSD - which you did. I didn't consider my change - where I replaced the ORPort to use 443 (because we used that port everytime that works out of the box on a platform) to be part of the "create the /NetBSD page": https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/NetBSD?action=diff=2 Going forward I'd propose the following to minimize the fraction and overhead: I assume you maintain: /TorRelayGuide-ptbr /TorRelayGuide/OpenBSD /TorRelayGuide/NetBSD /TorRelayGuide/DragonFlyBSD I'll keep maintaining: /TorRelayGuide /TorRelayGuide/DebianUbuntu /TorRelayGuide/CentOSRHEL /TorRelayGuide/Fedora /TorRelayGuide/FreeBSD /TorRelayGuide/openSUSE All pages should be read-only and writable to authorized users/maintainer, but feel free to have the pages you maintain world writable. All non-maintainer changes are expected to go through a ticket. After a timeout of 7 days with no maintainer response the ticket opener might proceed with applying the proposed change. I'll propose a list of requirements for a platform to be listed on the main page. kind regards, nusenu [0] https://trac.torproject.org/projects/tor/ticket/24497 [1] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide [2] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD [3] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?action=history [4] https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/FreeBSD?sfp_email=_mail==diff=2_version=1 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] Could tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)
I pasted that email to trac as https://trac.torproject.org/projects/tor/ticket/26910 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] Could tor drop privileges even earlier? (before trying to access anything on the filesystem beyond its torrc files)
Fedora/CentOS starts the tor service as root and drops privileges to user 'toranon' due to the torrc 'User' parameter by default. Also by default the tor service runs in a SELinux confined domain (tor_t). That means root in that domain can NOT access just any files regardless of DAC filesystem permissions (DAC_OVERRIDE is not granted by default). Which results in the situation that during startup (before privileges are dropped and user is switched to 'toranon') tor can not access the hiddenservicedir without allowing DAC_OVERRIDE or changing filesystem permissions, but it could if at that point privileges were already switched to the user specified in the torrc file. From my point of view the nicest solution would be if tor drops privileges before it accesses anything on the filesystem - which would solve above problem. Would that introduce other problems? Is there a specific reason why tor drops privileges later? (this is about running tor and tor in --verify-config mode) context: https://bugzilla.redhat.com/show_bug.cgi?id=1602171 (I consider this problem solved via the workaround but I'm still interested in the above question) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] restoring 'cypherpunks' trac account with more anti-automation?
Hi, is there any timeline when the cypherpunks trac account will be restored? I would suggest to require _every_ single submission (and maybe even the login itself) by that account to go through the captcha test (not just in case there are to many URLs in the submitted comment) to reduce the vandalism. thanks! -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] lets make 'working DNS' an exit flag requirement
there is a great ticket about solving this problem via self-checks: https://trac.torproject.org/projects/tor/ticket/24014 exits will disable exiting once they realize they fail at doing DNS. I believe it will cover most if not all of current problems, lets check again once this is implemented and deployed. would be nice to have that in tor 0.3.5 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] lets make 'working DNS' an exit flag requirement
>> Would anyone be willing to implement it in tor? > > This would be a feature for scanners, not little-t-tor itself, right? the test would be performed by tor in the dir auth role (like other tests performed by dir auths) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] lets make 'working DNS' an exit flag requirement
Nathaniel Suchy: > I'm going to state my support for it here. I'm not a developer however I > agree all exits should provide DNS from a local resolver (Unbound or > similar) to get the exit flag. just to be clear: the proposal would not require any specific DNS configuration it would simply require the exit to not fail to many DNS resolution attempts. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] lets make 'working DNS' an exit flag requirement
I'd like to see 'working DNS' as a requirement for the exit flag. If there are no major objections and if I'm able to find someone to implement it I'd like to proceed with writing a small proposal. Would anyone be willing to implement it in tor? https://trac.torproject.org/projects/tor/ticket/26691 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] anchors in the Tor Browser design document?
nusenu: > It would be nice if every subsection (i.e. "SPDY and HTTP/2" would have an > anchor > so we can easily link to it) in what trac component would I file this request? "Webpages/Website"? -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] Tor port restriction option was removed
Roger Dingledine: > It looks like around 844 Guard relays are listening on port 443 right now, > out of the 1858 available Guard relays. guard probability for all guards having ORPort on 80 or 443: 45.99% guard probability per ORPort: +-+---+ | or_port | guard_probability | +-+---+ | 443 | 44.4 | |9001 | 39.1 | | 80 | 1.5 | |9002 | 1.3 | |8080 | 1.1 | |8443 | 0.9 | +-+---+ (onionoo data as per 2018-07-05 07:00 UTC) > (*) Actually, before Tor starts attempting to reach Guards, it first > needs to bootstrap the consensus document from either the directory > authorities or the fallback directory servers -- but they have a pretty > similar distribution of ports they listen on. unfortunately onionoo does not have fallbackdir data, so I can't provide the same table as above for fallbacks without creating it myself first -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] documenting reload vs. restart requirements per torrc option
teor: > >> On 3 Jul 2018, at 05:52, nusenu wrote: >> >> Hi, >> >> I like unbound's documentation with this regards, for example they say >> in their man page: >> >>> The interfaces are not changed on a reload (kill -HUP) >>> but only on restart. >> >> Could we add such information to every torrc option in the manual? > > torrc options can be changed by a HUP by default. > There are about 20 torrc options that are documented as exceptions. > Search the man page for "while tor is running." thanks that hint is very useful -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] documenting reload vs. restart requirements per torrc option
Hi, I like unbound's documentation with this regards, for example they say in their man page: > The interfaces are not changed on a reload (kill -HUP) > but only on restart. Could we add such information to every torrc option in the manual? background: In relayor I need to reload/restart tor daemons on configuration changes currently I blindly assume reload is fine, because in most cases it is but it comes with the prices of accepting a certain level of error since not all configuration changes can be applied by reloads. To fix this I'd need to have authoritative information about what changes require restarts vs. reloads. [1] https://unbound.net/documentation/unbound.conf.html -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] man: "IPv6 addresses should be wrapped in square brackets"
grarpamp: > On Sat, Jun 30, 2018 at 5:22 PM, nusenu wrote: >> tor's man page for OutboundBindAddress* options say: >> >>> IPv6 addresses should be wrapped in square brackets >> >> since it does not throw an error without square brackets: >> does it make any difference? >> >> Previously I forgot the square brackets when generating torrc >> files with relayor and I would like to document the impact >> of my bug (if there is any). > > I posting somewhere about normalizing IPv6 address format, > it might have listed the RFC, for which the man page and code was > probably inconsistant. Similar to how fingerprints are a mess. your text does not really answer my question.. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] man: "IPv6 addresses should be wrapped in square brackets"
Hi, tor's man page for OutboundBindAddress* options say: > IPv6 addresses should be wrapped in square brackets since it does not throw an error without square brackets: does it make any difference? Previously I forgot the square brackets when generating torrc files with relayor and I would like to document the impact of my bug (if there is any). thanks, nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] the consequences of deprecating debian alpha repos with every new major branch
Hi, tldr: - more outdated relays (that is a claim I'm making and you could easily proof me wrong by recreating the 0.3.3.x alpha repos and ship 0.3.3.7 in them and see how things evolve after a week or so) - more work for the tpo website maintainer - less happy relay operators [3][4] - more work for repo maintainers? (since a new repo needs to be created) When the tor 0.3.4 alpha repos (deb.torproject.org) first appeared on 2018-05-23 I was about to submit a PR for the website to include it in the sources.list generator [1] on tpo but didn't do it because I wanted to wait for a previous PR to be merged first. The outstanding PR got merged eventually (2018-06-28) but I still did not submit a PR to update the repo generator for 0.3.4.x nonetheless and here is why. Recently I was wondering why are there so many relays running tor version 0.3.3.5-rc? (see OrNetStats or Relay Search) (> 3.2% CW fraction) Then I realized that this was the last version the tor-experimental-0.3.3.x-* repos were shipping before they got abandoned due to the new 0.3.4.x-* repos (I can no longer verify it since they got removed by now). Peter made it clear in the past that the current way to have per-major-version debian alpha repos (i.e. tor-experimental-0.3.4.x-jessie) will not change [2]: > If you can't be bothered to change your sources.list once or twice a > year, then you probably should be running stable. but maybe someone else would be willing to invoke a "ln" commands everytime a new new alpha repo is born. tor-alpha-jessie -> tor-experimental-0.3.4.x-jessie once 0.3.5.x repos are created the link would point to tor-alpha-jessie -> tor-experimental-0.3.5.x-jessie It is my opinion that this will help reduce the amount of relays running outdated versions of tor. It will certainly avoid having to update the tpo website, which isn't a big task and could probably be automated but it isn't done currently. "..but that would cause relay operators to jump from i.e. 0.3.3.x to 0.3.4.x alphas (and break setups)!" Yes, and I think that is better than relays stuck on an older version because the former repo no longer exists and operators still can choose the old repos which will not jump to newer major versions. [1] https://www.torproject.org/docs/debian.html.en#ubuntu [2] https://trac.torproject.org/projects/tor/ticket/14997#comment:3 [3] https://lists.torproject.org/pipermail/tor-relays/2018-June/015549.html [4] https://trac.torproject.org/projects/tor/ticket/26474 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] improving relay guide maintainability
> I am sorry I missed this ticket. I usually merge content as soon as I > notice a ticket. If I miss something, meaning I do not merge it in a few > days, a quick direct email or ping is enough for me to act on it. > This is now merged. I would appreciate a comment or at least a state change on the ticket when a PR is acted upon. I closed the ticket now. -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
[tor-dev] improving relay guide maintainability (was: Re: minor website update request: have the tor-relay guide ready for Ubuntu 18.04)
> From my personal experience, my website update requests (also trivial ones) > take about two months to get committed I've patiently been waiting for the usual 2 months to pass.. I'm considering to remove the relay guide's dependency on https://torproject.org content to improve its maintainability. Is that ok with you? @Alison: is there a timeline for community.tpo? -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] DoH over non-HTTPS onion v3
George Kadianakis: >> this is just a short heads-up. >> >> I'm currently tinkering about how we could >> improve DNS security and privacy for tor clients. My idea write-up is not >> done >> yet but since the IETF DoH WG [1] is proceeding towards their next steps >> I wanted to move now before it might be to late and let you know that I >> might ask them if they want to allow non-HTTPS uris in the case of >> onion v3 addresses (currently HTTPS is required). This might be handy for TB >> in the future. >> If you have objections let me know. >> >> I also reached out to Seth Schoen and asked him about his >> efforts to make onion v3 DV certificates acceptable to the CA/Browser Forum >> (if that is possible then the HTTPS requirement isn't a problem for DoH over >> onion v3). >> > > IIUC, you are trying to persuade the working group that they can use > HTTP v3 onions as DNS resolvers. > > Sounds good to me! Let us know how we can support you with this :) thanks for that kind offer but I think DoH draft authors made some deliberate design decisions that are not in favor of privacy by design or even privacy by default and so I did not even start with the onion v3 topic on the WG ML since the transport layer can not solve all the tracking problems of higher layers (HTTP). In the Tor context you might say - "we can address http layer privacy issues in DoH in Tor Browser" but then you are probably better off just implementing DNS-over-TLS (DoT) which does not come with all the privacy problems of HTTP. If you want to read more about the entire discussion on the DoH WG ML this is the starting point (and it is not limited to this thread): https://mailarchive.ietf.org/arch/msg/doh/vHjITrOMhWSdrozGFe4-eGNMEJc Also: Seth Schoen got back to me regarding Domain Validated HTTPS certificates for onion v3 - and even though it will not happen tomorrow I have hope that it will be possible eventually (which makes my original point - DoH over HTTP (not HTTPS) for onion v3 - unnecessary if everyone can get letsencrypt certs for their onions) -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu 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
Re: [tor-dev] is that the correct URL in the TBB design document?
Georg Koppen: > This should be fixed now, thanks (and visible once the website rebuilds). Thank you for addressing this so timely. btw: It would be nice if every subsection (i.e. "SPDY and HTTP/2" would have an anchor so we can easily link to it). -- https://mastodon.social/@nusenu twitter: @nusenu_ 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
