Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2022-06-24T14:13:59Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13155I can use an extend cell to remotely determine whether two relays have a conn...2022-06-24T14:13:59ZRoger DingledineI can use an extend cell to remotely determine whether two relays have a connection openSend an extend cell to relay A, listing the address and identity key of relay B but the wrong port.
Relay A calls `circuit_extend()` for the new cell, which calls `channel_get_for_extend()`, which tries to figure out if there's a canoni...Send an extend cell to relay A, listing the address and identity key of relay B but the wrong port.
Relay A calls `circuit_extend()` for the new cell, which calls `channel_get_for_extend()`, which tries to figure out if there's a canonical connection already established. To do that, it asks
```
if (!channel_is_canonical(chan) &&
channel_is_canonical_is_reliable(chan) &&
!channel_matches_target_addr_for_extend(chan, target_addr)) {
++n_noncanonical;
continue;
}
```
and `channel_matches_target_addr_for_extend()` turns into `channel_tls_matches_target_method()` which basically is
```
return tor_addr_eq(&(tlschan->conn->real_addr), target);
```
It doesn't consider the port. So if there is a canonical channel open, bingo we use it.
But if there isn't one open, then off we go to make one:
```
n_chan = channel_connect_for_circuit(&ec.orport_ipv4.addr,
ec.orport_ipv4.port,
(const char*)ec.node_id);
```
where `ec.orport_ipv4.port` was set from `extend_cell_parse()`, i.e. it came from our extend cell. If we specify the wrong port, that connect attempt will fail. Now we can distinguish, remotely, which situation we're in.https://gitlab.torproject.org/tpo/core/tor/-/issues/29583HSv3: Faulty cross-certs in introduction point keys (allows naive onionbalanc...2022-06-21T16:35:48ZGeorge KadianakisHSv3: Faulty cross-certs in introduction point keys (allows naive onionbalance for v3s)During a discussion with Nick and David, we figured out that we messed up the cross certificates of the introduction point keys in the HSv3 descriptors.
In particular the spec asks to cross-certificate the descriptor signing key using t...During a discussion with Nick and David, we figured out that we messed up the cross certificates of the introduction point keys in the HSv3 descriptors.
In particular the spec asks to cross-certificate the descriptor signing key using the introduction point auth key, but it seems like we are doing it the other way around in the code:
```
desc_ip->auth_key_cert = tor_cert_create(signing_kp,
CERT_TYPE_AUTH_HS_IP_KEY,
&ip->auth_key_kp.pubkey,
nearest_hour,
HS_DESC_CERT_LIFETIME,
CERT_FLAG_INCLUDE_SIGNING_KEY);
```
same goes for the intro point encryption key. However, it seems that the legacy encryption key cross-cert was made properly.
This is very related to the onionbalance for v3 ticket (parent of this) because these two cross-certs certs was exactly what was preventing us from doing the naive onionbalance for v3s.
So here are some steps forward:
a) Figure out if there are any other cases where we have messed up
cross certs in the code. Figure out the precise dangers of the cross certs we messed up.
With David we scanned the HSv3 code and it seems like these two are the only certs we messed up. If we are right, this means that this bug allows some fairly low-severity attacks like `FairPretender` from legacy/trac#15951. We should make sure we know exactly what attacks this opens us up to.
b) We should decide if we want to fix this or not. Fixing this would likely involve making a new descriptor version with the right cross-certs, so that clients can verify both the old version and the new one. It will require some engineering but not too much. If we care about the attacks, we shoul fix it. However, if we don't care about these attacks, we can "not fix it", which will also probably allow us to do naive onionbalance for v3s.
As a side-task that can be done paralelly we should revise and improve the spec when it comes to cross-certs because it's currently quite confusing. We should properly define cross-certs and what they do, and we should also improve the wording in places (e.g. there is bad wording even in `descriptor-signing-key-cert` even tho the code is right), and we should update the spec based on what we decide in this ticket.
I have CCed twim who reported the FairPretender attack in this ticket, and we should think about this more!https://gitlab.torproject.org/tpo/core/tor/-/issues/13444"GhostNode" - support relays that cannot accept incoming connections.2022-06-18T16:20:00ZTrac"GhostNode" - support relays that cannot accept incoming connections.My ISP doesn't offer global IP address(10.10.20.X shared), which I can't help people by setting up middle(nonexit) nodes. Why tor require opening a port!?
What about HiddenService? It can work without opening a port to global, right? So...My ISP doesn't offer global IP address(10.10.20.X shared), which I can't help people by setting up middle(nonexit) nodes. Why tor require opening a port!?
What about HiddenService? It can work without opening a port to global, right? So, how about this idea.
"GhostNode" 1. It doesn't require user to open a port to global(no router setting). 2. It works like a hidden service protocol. Your global IP won't go public.
Client---torBridgeNode===tor2===tor2===tor4-->website or Client---tor1===tor2===tor4-->website
tor1; nonexit tor2; ghost tor4; exit
tor1 ask tor2 to connect tor4. (just like HiddenService did) tor2(GhostNode) make a connection to tor4(exitnode).
**Trac**:
**Username**: ikurua22https://gitlab.torproject.org/tpo/core/tor/-/issues/19074Mark fallback directories down when their key is wrong2022-06-17T18:34:15ZteorMark fallback directories down when their key is wrongarma says that we will happily retry fallback directories with the wrong key fingerprint. We can do two things to fix this:
* mark fallback directories as down when their key fingerprint is wrong
* cancel all pending connections to a fal...arma says that we will happily retry fallback directories with the wrong key fingerprint. We can do two things to fix this:
* mark fallback directories as down when their key fingerprint is wrong
* cancel all pending connections to a fallback with the wrong key (perhaps in legacy/trac#18809) - this should be unlikely with 100 fallbackshttps://gitlab.torproject.org/tpo/core/tor/-/issues/29174Onion service can do self-reachability tests to detect overwhelmed guards2022-06-17T18:15:26ZTracOnion service can do self-reachability tests to detect overwhelmed guardsFor the current Tor protocol, hidden services connect into Tor network only through one Guard node (Vanguard is not running on default).
As a result, all the HS-IntroPoint circuit of the hidden service are all using one guard.
As we all...For the current Tor protocol, hidden services connect into Tor network only through one Guard node (Vanguard is not running on default).
As a result, all the HS-IntroPoint circuit of the hidden service are all using one guard.
As we all know, the HS-IntroPoint is quite special on its cell sequence, so the malicious guard relays can drop all the incoming cells of HS-IntroPoint until the hidden service rebuild its HS-IntroPoint circuit.
And the malicious guard can attack the new circuits again.
Because the incoming cells of HS-IntroPoint circuit (introduce1 cells) are all droped, so the hidden services cannot be accessed by any user, and eclipsed by its Guard relay.
This mater is appearing after reduce the number of guards to one, and if the hidden service not run the vangard, the hidden service has the risk of being eclipsed.
**Trac**:
**Username**: TBD.Chenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18098prop224: Implement tor-genkey tool for offline HS key creation2022-06-17T17:57:10ZDavid Gouletdgoulet@torproject.orgprop224: Implement tor-genkey tool for offline HS key creationWith proposal 224, an operator can choose to keep her master key offline. Currently, tor as a `--keygen` option used for relay keys. Glueing HS key support _will_ be complicated (since it's already not that easy implementation wise).
I ...With proposal 224, an operator can choose to keep her master key offline. Currently, tor as a `--keygen` option used for relay keys. Glueing HS key support _will_ be complicated (since it's already not that easy implementation wise).
I propose we create a separate tool called `tor-genkey` (follows the tor-gencert naming) located in `src/tools` to create keys for different use case. We could ship this tool with our tor package or even as a separate package so people don't need to install the whole tor for just generating keys.
Furthermore, with prop224, an operator choosing to generate her key offline, we will need to create a bunch of blinded keys in advance with the offline master key which would make it much more easier than to glue yet another thing on top of tor cmdline.
Also, revocation of those keys could be a reality at some point in time which that tool could do really well without having a tons of new code in tor.https://gitlab.torproject.org/tpo/core/tor/-/issues/22660Guard against stack smashing attacks in tor with additional compiler options.2022-06-17T17:47:37ZteorGuard against stack smashing attacks in tor with additional compiler options.If we tor with -fstack-check (GCC, it's a no-op in clang[0]), it will protect against stack smashing attacks that jump the stack guard page(s):
```
Recompile all userland code (ld.so, libraries, binaries) with GCC's
"-fstack-check" opt...If we tor with -fstack-check (GCC, it's a no-op in clang[0]), it will protect against stack smashing attacks that jump the stack guard page(s):
```
Recompile all userland code (ld.so, libraries, binaries) with GCC's
"-fstack-check" option, which prevents the stack-pointer from moving
into another memory region without accessing the stack guard-page (it
writes one word to every 4KB page allocated on the stack).
```
III Solutions, https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
"
-fstack-check
Generate code to verify that you do not go beyond the boundary of the stack. You should specify this flag if you are running in an environment with multiple threads, but only rarely need to specify it in a single-threaded environment since stack overflow is automatically detected on nearly all systems if there is only one stack.
Note that this switch does not actually cause checking to be done; the operating system must do that. The switch causes generation of code to ensure that the operating system sees the stack being extended.
"
http://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/Code-Gen-Options.html#Code-Gen-Options
This protects against:
```
- a local-root exploit against ld.so and most SUID-root binaries
(CVE-2017-1000366, CVE-2017-1000379) on amd64 Debian, Ubuntu, Fedora,
CentOS;
```
There are remote attack possibilities mentioned in the paper as well.
We might also want to add:
```
-Wl,-z,noexecstack and -Wl,-z,noexecheap
```
https://www.owasp.org/index.php/C-Based_Toolchain_Hardening#GCC.2FBinutils
[0]: for clsng, we could use -fsanitize=safe-stack instead, but that's more intrusive: https://blog.quarkslab.com/clang-hardening-cheat-sheet.htmlhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17579Split tor-gencert into "make cert" and "sign" portions2022-06-17T16:31:35ZNick MathewsonSplit tor-gencert into "make cert" and "sign" portionsThe only part of tor-gencert that wants to stay offline is the part that actually uses the master identity key to sign the certificate. All the rest of generating the cert could be done online.
If we made those changes, we would allow ...The only part of tor-gencert that wants to stay offline is the part that actually uses the master identity key to sign the certificate. All the rest of generating the cert could be done online.
If we made those changes, we would allow operators to leave their offline gencert setups unmaintained for a very very very long time, which would make it easier to keep master identity keys offline.https://gitlab.torproject.org/tpo/core/tor/-/issues/23061crypto_rand_double() should produce all possible outputs on platforms with 32...2022-06-17T13:46:12Zteorcrypto_rand_double() should produce all possible outputs on platforms with 32-bit intOn 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms i...On 32-bit platforms, crypto_rand_double() only produces 1 in every 2 million possible values between 0 and 1.
This happens because:
* crypto_rand_double() divides a random unsigned int by UINT_MAX
* an unsigned int on 32-bit platforms is 32 bits
* the mantissa on a double is 53 bits
So crypto_rand_double() doesn't fill the lower 21 bits with random values.
This makes the rep_hist_format_hs_stats() noise more predictable on 32-bit platforms.
This fix shouldn't affect the unit tests, because they pass on 64-bit.https://gitlab.torproject.org/tpo/core/tor/-/issues/31507Change the client default to AvoidDiskWrites 1, or otherwise make disk writes...2022-06-17T13:02:48ZteorChange the client default to AvoidDiskWrites 1, or otherwise make disk writes less frequent.Since 2007, we've seen some significant technological changes:
* More devices with batteries
* More devices with SSDs
* Better disk forensics techniques
So it might be a good idea to change the client default to AvoidDiskWrites 1.Since 2007, we've seen some significant technological changes:
* More devices with batteries
* More devices with SSDs
* Better disk forensics techniques
So it might be a good idea to change the client default to AvoidDiskWrites 1.https://gitlab.torproject.org/tpo/core/tor/-/issues/13697Carry entropy across invocations2022-06-17T12:55:06ZNick MathewsonCarry entropy across invocationsWen Tor starts, after seeding the CSPRNG, we should save some of its output to an "entropy" file. On later invocations, we should reseed from that file **in addition to** seeding from the OS, and then replace it with new CSPRNG output.
...Wen Tor starts, after seeding the CSPRNG, we should save some of its output to an "entropy" file. On later invocations, we should reseed from that file **in addition to** seeding from the OS, and then replace it with new CSPRNG output.
This is silly voodoo that might help us out if we're ever in a position where the OS has previously been well seeded but later is not. It can't make things worse, so long as RAND_add() is additive.
It's deferrable; legacy/trac#13696 is more important, assuming a non-broken OS.https://gitlab.torproject.org/tpo/core/tor/-/issues/23357Build with non-Cross-DSO CFI2022-06-16T19:47:13ZTracBuild with non-Cross-DSO CFIControl Flow Integrity is an exploit mitigation. clang/llvm has a CFI implementation that can be used on hardened operating systems like HardenedBSD.
When lld is the compiler, non-Cross-DSO CFI from clang/llvm can be used. I've tested t...Control Flow Integrity is an exploit mitigation. clang/llvm has a CFI implementation that can be used on hardened operating systems like HardenedBSD.
When lld is the compiler, non-Cross-DSO CFI from clang/llvm can be used. I've tested this on HardenedBSD with a very basic configuration.
Attached is a candidate patch for enabling non-Cross-DSO CFI for the core Tor application.
**Trac**:
**Username**: shawn.webbhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26685Add ed25519 id support for the hard-coded fallback and authority lists2022-06-16T16:11:23ZteorAdd ed25519 id support for the hard-coded fallback and authority listsThis is the parent ticket for getting ed25519 id support in Tor's hard-coded directory lists.This is the parent ticket for getting ed25519 id support in Tor's hard-coded directory lists.https://gitlab.torproject.org/tpo/core/tor/-/issues/12500Add an option to upload hidden service descriptors some time after startup2022-06-16T16:05:04ZAndrea ShepardAdd an option to upload hidden service descriptors some time after startuplegacy/trac#4243 is bullshit; it doesn't seem to describe the actual behavior, but what it describes would be the correct thing if it were what we did. We should investigate this and render it sane.
Descriptor upload happens from rend_...legacy/trac#4243 is bullshit; it doesn't seem to describe the actual behavior, but what it describes would be the correct thing if it were what we did. We should investigate this and render it sane.
Descriptor upload happens from rend_consider_services_upload(time_t now) - some things to consider:
1.) Where does now come from? Is this another thing that should use CLOCK_MONOTONIC when available?
2.) Looks like we correctly randomize the upload time for new descriptors:
```
3239 if (!service->next_upload_time) { /* never been uploaded yet */
3240 /* The fixed lower bound of 30 seconds ensures that the descriptor
3241 * is stable before being published. See comment below. */
3242 service->next_upload_time =
3243 now + 30 + crypto_rand_int(2*rendpostperiod);
3244 }
```
...but we make our decision on what to upload based on next_upload_time or desc_is_dirty:
```
3245 if (service->next_upload_time < now ||
3246 (service->desc_is_dirty &&
3247 service->desc_is_dirty < now-30)) {
3248 /* if it's time, or if the directory servers have a wrong service
3249 * descriptor and ours has been stable for 30 seconds, upload a
3250 * new one of each format. */
3251 rend_service_update_descriptor(service);
3252 upload_service_descriptor(service);
3253 }
```
We should look at how desc_is_dirty gets set and make sure this doesn't cause newly created HS descriptors to always be immediately uploaded.https://gitlab.torproject.org/tpo/core/tor/-/issues/15660[feature suggestion] Need signal to totally switch to the new set of circuits2022-06-16T15:24:48Zyurivict271[feature suggestion] Need signal to totally switch to the new set of circuitsCurrently there is the control command
```
SIGNAL NEWNYM
```
which according to specification "switches to clean circuits, so new application requests don't share any circuits with old ones." It however doesn't affect the old connections...Currently there is the control command
```
SIGNAL NEWNYM
```
which according to specification "switches to clean circuits, so new application requests don't share any circuits with old ones." It however doesn't affect the old connections, which still go through the old set of circuits.
There is the legitimate need to completely switch to the new set of circuits, with termination of all old connections.
I am suggesting to add the parameter to NEWNYM signal. It can be a string parameter, to keep it general and explicit. Syntax that will work like NEWNYM but will also terminate old connection could look like this:
```
SIGNAL NEWNYM TERMINATE
```
The old syntax will assume this parameter to be empty, and will work like before.
On the user level, wherever they see the button "New Identity", they will either have another button next to it "New Identity (force-close old connections)", or the yes/no choice "force-close old connections" next to the original button.
My motivation: I had this question before myself, and now I saw somebody else asking it on tor-talk@: "Why my exit node doesn't change when I press 'New Identity' button?"https://gitlab.torproject.org/tpo/core/tor/-/issues/25574Eliminate "silent-drop" side channels in Tor protocol2022-03-22T13:18:08ZMike PerryEliminate "silent-drop" side channels in Tor protocolhttps://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
There are lots of ways to inject data into Tor streams, and this is a vector of attack for guard discovery and confirmation ("DropMark" attack): https://petsymposium.org/2018...https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
There are lots of ways to inject data into Tor streams, and this is a vector of attack for guard discovery and confirmation ("DropMark" attack): https://petsymposium.org/2018/files/papers/issue2/popets-2018-0011.pdf
I have a branch that tries to eliminate a pile of these from a while ago, but it has lots of false positives due to the common occurrence of invalid stream IDs in practice (see legacy/trac#25573). https://gitweb.torproject.org/mikeperry/tor.git/log/?h=timing_sidechannel_fix-squashed1
I think we may want to do legacy/trac#25573 before trying to merge that branch.https://gitlab.torproject.org/tpo/core/tor/-/issues/11458A newer signing cert should innoculate us against older ones?2022-03-22T12:56:35ZRoger DingledineA newer signing cert should innoculate us against older ones?Sometime in the past year or two somebody might have stolen 7 of the 9 active directory signing keys. They don't expire for several months or more.
If the existing directory authorities rotate to new signing keys, that doesn't really ch...Sometime in the past year or two somebody might have stolen 7 of the 9 active directory signing keys. They don't expire for several months or more.
If the existing directory authorities rotate to new signing keys, that doesn't really change the fact that older ones remain valid.
If we change Tor to look at its cached-certs and refuse to believe in a signing key if it's convinced there's a newer one, then we can invalidate older ones by generating newer ones.
That approach wouldn't protect users who are bootstrapping for the first time, but it would protect them if they'd already bootstrapped. Is this a worthwhile improvement?
Note that we'd have to sort out edge cases like legacy/trac#11457 -- basically in this case it would mean that if you ever generate a signing key too far in the future and then also want to go back to an earlier one, you're fucked. But has anybody ever needed to do that?
To tolerate rotation better, we'd want the logic to be something like the suggested fix in legacy/trac#11454: only disbelieve a cert if a) we have a newer one and b) the one we're disbelieving is sufficiently older than now.
We could also think about shipping with a cached-certs file to keep raising the bar as users upgrade.https://gitlab.torproject.org/tpo/core/tor/-/issues/15729Proposal: Hidden Service Revocation2022-03-17T20:06:34ZTracProposal: Hidden Service RevocationFilename: xxx-rend-revoke.txt
Title: Hidden Service Revocation
Author: Nathaniel Johnson
Created: 2015-03-04
Status: Draft
Hidden service operators need to be able to revoke trust in their hidden service
if they know or suspect their hi...Filename: xxx-rend-revoke.txt
Title: Hidden Service Revocation
Author: Nathaniel Johnson
Created: 2015-03-04
Status: Draft
Hidden service operators need to be able to revoke trust in their hidden service
if they know or suspect their hidden service secret key has been compromised.
1. Motivation
A Hidden service operator can determine that the hidden service secret keyis compromised in several ways today. Forensic traces of intrusion may bedetected on the hidden service server, or valid signed descriptors for theservice may be published by someone other than the legitimate operator in atraffic hijacking attack.
Even though it is possible for the operator to detect a hidden service key iscompromised, there is no satisfactory way for a hidden service operator tonotify its users of this fact. The hidden service may displaya message to its users warning of the compromise and directing them to a newsupposedly uncompromised .onion domain, but a user has no way to knowwhether such a message was posted by the legitimate hidden service operatoror a hijacker.
A revocation system where anyone possessing the hidden service secret keycan revoke trust in the key solves this problem.
2. Overview
This revocation system is built on the hidden service directory system. Arevocation takes the form of a hidden service descriptor which provides noway to contact the hidden service (i.e. zero introductory points), andcontains a "revoked" line of the following format
"revoked" NL
[At most once]
If present in a hidden service descriptor which also contains zerointroductory points, indicates that this is a revocation of the hiddenservice.
A hidden service directory which receives a revocation descriptor andverifies its signature should discard any non-revocation descriptors itpossesses for that hidden service, and should propagate the revocationthrough the hidden service directory system as normal.
Crucially, a hidden service directory which possesses a revocationdescriptor for a hidden service and receives a newer, valid descriptor forthat hidden service which is not a revocation descriptor MUST retain therevocation descriptor and MUST discard the newer non-revocation descriptor.This is the only change needed to support this revocation system at abasic level today.
3. Design considerations
3.1 Revocation lifetime
Ideally, a revocation should be permanent. The Tor network wouldideally remember forever that a hidden service has been revoked, andthis would provide the maximum possible protection to the users of thehidden service against imposter services.
However, a permanent (or even just long-lived) revocation in the hiddenservice directories present problems:
1) Increased memory and bandwidth requirements on the Tor networkcompared to a normal hidden service descriptor. For non-malicious use,this may not really be a problem, since once a service is revoked, therewould be only a trickle of requests for updated information about it(from visitors who have not already found out it was revoked). Howeverfor a malicious user who attacks the Tor network by flooding it withhidden service descriptors for fake hidden services, any increasedlifetime of a revocation descriptor over a normal descriptor representsa multiplication of their attack power.
2) For next generation hidden services as described in224-rend-spec-ng.txt, a revocation which lasts longer than one blindedsigning key validity period weakens the privacy protection againstcorrelation which is provided by rotating blinded signing keys. If arevocation were - for any amount of time - not expected to besigned by the current normal blinded signing key for that service, butinstead a separate 'blinded revocation signing key', then users seekingto check the revocation status of that service before visiting wouldhave to make two requests for a hidden service descriptor: one to see ifthere is a revocation descriptor published by that service, and one tosee if there is a normal descriptor published by that service. A malicious hidden service directory (or group of directories) could usethis correlation to determine which hidden service descriptors belong tothe same hidden service between blinded signing key rotations.
Implementing a long-lived hidden service revocation at the client level,a cache of previously seen revoked hidden services for example, woulddisclose the user's browsing history to anyone who examined it, and istherefore not a good solution either.
For these reasons, revocations which last no longer thana normal hidden service descriptor, and which the operator musttherefore constantly broadcast, are the safest option for implementinghidden service revocations.
Short lived revocations have the advantage that the Tor network does notneed to make any hard-and-fast judgement about how long it is worthwhileto remember a hidden service has been revoked, the hidden serviceoperator can make that judgement for themselves and broadcast therevocation for as long the operator feels hijacking and impersonationis a concern.
If the operator is unable to maintain (or fears they will be unable tomaintain) a revocation broadcast for an appropriate amount of time,they can disclose their private key to a 3rd party service who willbroadcast the revocation on the operator's behalf. An operator wouldwant to employ several of these services, since if only one service hadthe private key, and if they were malicious, they could ceasebroadcasting the revocation and instead use the key to set up animpostor service.
Despite these minor difficulties that short-lived revocations impose,they are still a major improvement to the security of the Tor network.
3.2 Side note on the shape of a 3rd party Revocation Broadcast Service
Though it is outside the scope of this specification,I envision these 3rd party key revocation services being simple websiteswhere anyone can upload a hidden service private key and the websitewill broadcast the revocation indefinitely. They could employ simpleabuse-mitigation like CAPCHAs or IP ratelimiting over the clearnet toprevent mass-upload of keys. This should keeps costs low enough thatthese revocations services would operate for free.
4. Implementation
4.1 Basic Support
For the Tor network to support hidden service revocations at a basiclevel, a large proportion of hidden service directories must recognizethat a hidden service descriptor with zero introductory points and able"revoked" line has the special meaning of being a revocation.These hidden service directories must not allow a current unexpiredrevocation descriptor to be replaced by a non-revocation descriptor(so called 'un-revocation'). In all other ways, treatment of arevocation descriptor is identical to treatment of a non-revocationdescriptor for a hidden service.
4.1.1 Steps required to add support
1) Hidden service directories are modified to recognize the formatof a revocation descriptor, and prevent revocation descriptors frombeing superseded by a non-revocation descriptor for the sameservice. Basic support from the core software is achieved!
2) The ability to broadcast revocations is implemented.
5) Expanded revocation capabilities may be added, as describedbelow.
4.2 Expanded Capabilities
4.2.1 Presentation to the user
If an onion proxy that detects the user tried to visit a revokedservice, this information should be presented to the userout-of-band. I.E not in a way that could be mistaken for a hiddenservice which is only temporarily unreachable, or as informationsent by the service. This could be done via a system level popup, ora taskbar notification. The presentation should be stronglydistinguished from a hidden service which is simple unreachable.
4.2.2 Automatic hijacking detection/revocation
Tor hidden service software could have a mode to detect if anotherparty is using the hidden service private key to publish descriptorsfor that service. If the hidden service operator configures it,the Tor hidden service software could immediately begin to broadcastthe revocation for that service.
[Per Donncha's feedback, both of these should probably be delegatedto control software, with tor itself simply exposing an eventwhenever a revoked site is encountered or a new valid descriptoris published, and the external controller will take care of notifyingthe user or detecting if any separate tor node is publishing descriptorsfor the same service.]
5. Future Compatibility with Next Generation Hidden Services
Next generation Tor hidden services require a modifiedrevocation system because the hidden service master secret key is betterprotected, and does not need to be constantly live on the hidden service tornode. The day-to-day operation of the service is carried out by a pre-loadedset of changing subordinate descriptor signing keys, which expire after aset time (25 hours by default). If descriptor signing keys are compromised,they can be used to hijack traffic and impersonate the hidden service,but only until the descriptor signing keys expire. So there is an additionalneed for a way to revoke descriptor signing keys and provide new ones,without permanently revoking trust in the hidden service.
Also, theft of descriptor signing keys should not allow an attacker torevoke the master secret key.
The revocation permissions would looks something like the following.(Blinded signing keys are equivalent to the master secret key forrevocation purposes because if an attacker obtains any blinded signingsecret key, they can mathematically derive the master secret key.)
1) Current descriptor signing key can revoke current descriptor signing key.
2) Master secret key can revoke any descriptor signing key and provide a newdescriptor signing key for that time-period.
3) Master secret key is the only one that can revoke master secret key.
[TODO: Sketch out implementation later]
**Trac**:
**Username**: Nathanielhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20055Remove relays that fail to rotate onion keys from the consensus2022-03-17T20:05:39ZteorRemove relays that fail to rotate onion keys from the consensusOn legacy/trac#7164, a cypherpunks notes that ~40 relays fail to rotate their onion keys. This should be addressed by identifying these relays, and adding them to the DirAuths' AuthDirInvalid or AuthDirReject lists.
First, we need to up...On legacy/trac#7164, a cypherpunks notes that ~40 relays fail to rotate their onion keys. This should be addressed by identifying these relays, and adding them to the DirAuths' AuthDirInvalid or AuthDirReject lists.
First, we need to update torspec/dir-spec.txt to say that relays SHOULD rotate their onion keys every 7 days, and MUST rotate them every N days. (I suggest 14 or 28.)
Then we can modify DocTor to check for relays in the consensus that have had the same onion key for N days. (I think DocTor is the right place for this check.)
This won't catch cases where relays repeat onion keys, but it will suffice to catch the most obvious misconfiguration - a read-only onion key file.https://gitlab.torproject.org/tpo/core/tor/-/issues/33018Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix2022-03-07T23:49:55ZRoger DingledineDir auths using an unsustainable 400+ mbit/s, need to diagnose and fixWe've been having problems establishing a consensus lately. We realized that maatuska was rate limiting to only 10MBytes/s, and asked Linus to bump it up, so he did.
Then today we realized that moria1 was unable to serve dirport answers...We've been having problems establishing a consensus lately. We realized that maatuska was rate limiting to only 10MBytes/s, and asked Linus to bump it up, so he did.
Then today we realized that moria1 was unable to serve dirport answers because it was maxed out at its BandwidthRate of 30MBytes. I raised that to 50MBytes and it stayed maxed out. I have put it back down to 30MBytes so my host doesn't get too upset.
This is not a sustainable situation. We need to figure out what is asking the dir auths for so many bytes, and get it to stop or slow down.
This is a ticket to collect info and to brainstorm ideas.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org