Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:01Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33873client: Send back SOCKS extended error F6 in case of bad hostname2020-06-13T15:53:01ZDavid Gouletdgoulet@torproject.orgclient: Send back SOCKS extended error F6 in case of bad hostnameWith the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoie...With the new awesome TB 9.5a11, the SocksPort `ExtendedErrors` are being handled.
Passing an invalid v3 address that is of the right length in bytes, will send back the `F6` error but not for an invalid address like: `asijdijasdoijqwoieqw.onion`.
Problem is that we only send back the `F6` code if the address was identified, by length, as a v3. We should handle the `BAD_HOSTNAME` error code from `parse_extended_hostname()` and thus send back that extended error.Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33707Swap out onion icon in circuit display with new one2020-06-16T01:12:02ZrichardSwap out onion icon in circuit display with new onerichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/33148hs-v3: Clean cached descriptor(s) on ONION_CLIENT_AUTH_REMOVE2020-06-13T15:50:40ZDavid Gouletdgoulet@torproject.orghs-v3: Clean cached descriptor(s) on ONION_CLIENT_AUTH_REMOVEWhen a client authorization is removed with the control command `ONION_CLIENT_AUTH_REMOVE`, we should also remove the associated descriptor from the cache else the .onion is still accessible even though the credentials have been removed....When a client authorization is removed with the control command `ONION_CLIENT_AUTH_REMOVE`, we should also remove the associated descriptor from the cache else the .onion is still accessible even though the credentials have been removed.
Found by mcs/brade/acat during testing: https://trac.torproject.org/projects/tor/ticket/19757#comment:31Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33139New Identity should remove v3 client auth ephemeral keys2020-06-13T15:50:39ZMark SmithNew Identity should remove v3 client auth ephemeral keysAs discussed in ticket:19757#comment:31 through comment 34, tor should remove all of the ephemeral v3 client authorization keys when a NEWNYM signal is received (new identity).As discussed in ticket:19757#comment:31 through comment 34, tor should remove all of the ephemeral v3 client authorization keys when a NEWNYM signal is received (new identity).Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33035create strings for onion service error pages2020-06-16T01:10:51ZKathleen Bradecreate strings for onion service error pagesFor sponsor 27 O2A4 (Better client-side errors), we need strings that can be localized for each onion service error. There are 7 errors listed in ticket:30090#comment:9.
We are implementing error pages that look like Antonela's desig...For sponsor 27 O2A4 (Better client-side errors), we need strings that can be localized for each onion service error. There are 7 errors listed in ticket:30090#comment:9.
We are implementing error pages that look like Antonela's design at: https://onion-error.glitch.me/
For each of the above errors (XF0-XF6) we need the following strings:
* **Page/tab title** ("Problem loading page" in above design; you can see this when you hover over the tab).
* **Header** (a title; "404 - Onion Not Found" in above design)
* **Short description** (about one line)
* **Long description** (optional; Firefox uses simple HTML for some long descriptions but this may make localization difficult).
* **Learn more URL** (optional)
Note: for XF4 and XF5, users will only see an error page with the above strings if they dismiss the prompt without providing client authorization (see #30237).
Tor specs (includes a description of each error):
* ExtendedErrors: https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1823
* PROP304: https://gitweb.torproject.org/torspec.git/tree/proposals/304-socks5-extending-hs-error-codes.txt
Related browser and UX tickets:
#19251 #30090 #23545
Related tor tickets:
#30382 #32542 #32546
Pili and Antonela -- can you coordinate with the right people to produce the English strings so we can begin the localization process soon?https://gitlab.torproject.org/legacy/trac/-/issues/32709hsv3: Support onionbalance keys when handling INTRO2 cells2020-06-13T15:49:02ZGeorge Kadianakishsv3: Support onionbalance keys when handling INTRO2 cellsWe have encountered a small issue with onionbalance viability for v3s.
While the descriptor cross-certificates are no longer an issue (#29583), there is an issue with the ntor handshake during the INTRODUCE1/INTRODUCE2 handshake between...We have encountered a small issue with onionbalance viability for v3s.
While the descriptor cross-certificates are no longer an issue (#29583), there is an issue with the ntor handshake during the INTRODUCE1/INTRODUCE2 handshake between the client and service.
In particular, as specified in rend-spec-v3.txt [NTOR-WITH-EXTRA-DATA] the subcredential (which includes the onion address) is used as part of the ntor key material to generate end-to-end encryption keys and MAC keys so that the service can communicate with the client:
```
To make an INTRODUCE1 cell, the client must know a public encryption
key B for the hidden service on this introduction circuit. The client
generates a single-use keypair:
x,X = KEYGEN()
and computes:
intro_secret_hs_input = EXP(B,x) | AUTH_KEY | X | B | PROTOID
info = m_hsexpand | subcredential
hs_keys = KDF(intro_secret_hs_input | t_hsenc | info, S_KEY_LEN+MAC_LEN)
ENC_KEY = hs_keys[0:S_KEY_LEN]
MAC_KEY = hs_keys[S_KEY_LEN:S_KEY_LEN+MAC_KEY_LEN]
```
The issue here is that when the client prepares the INTRO1 cell, it uses the subcredential of the frontend OBv3 service, but the INTRO2 cell actually goes to a backend OBv3 instance which has a different subcredential. This causes the backend instance to not be able to verify the MAC of the cell, and generally finish the ntor handshake....Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32667CID 1456199: Resource leak in test_hs_control_store_permanent_creds()2020-06-13T15:48:49ZGeorge KadianakisCID 1456199: Resource leak in test_hs_control_store_permanent_creds()```
** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
________________________________________________________________________________________________________
**...```
** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
________________________________________________________________________________________________________
*** CID 1456199: Resource leaks (RESOURCE_LEAK)
/src/test/test_hs_control.c: 534 in test_hs_control_store_permanent_creds()
528
529 #ifdef _WIN32
530 ret = mkdir(perm_creds_dir);
531 #else
532 ret = mkdir(perm_creds_dir, 0700);
533 #endif
>>> CID 1456199: Resource leaks (RESOURCE_LEAK)
>>> Variable "perm_creds_dir" going out of scope leaks the storage it points to.
534 tt_int_op(ret, OP_EQ, 0);
535
536 get_options_mutable()->ClientOnionAuthDir = perm_creds_dir;
537 }
538
539 tor_free(args);
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32664hs-v3: Segfault in hs_circ_service_get_established_intro_circ()2020-06-13T15:48:48ZDavid Gouletdgoulet@torproject.orghs-v3: Segfault in hs_circ_service_get_established_intro_circ()Reported by atagar on IRC:
```
<+atagar> Looks like stem's jenkins runs are presently failing due to tor segfaults: https://paste.debian.net/plain/1119133
```
The report:
```
...
Dec 02 17:03:09.077 [notice] Configured to measure dire...Reported by atagar on IRC:
```
<+atagar> Looks like stem's jenkins runs are presently failing due to tor segfaults: https://paste.debian.net/plain/1119133
```
The report:
```
...
Dec 02 17:03:09.077 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
Dec 02 17:03:09.085 [warn] Controller gave us config lines that didn't validate: Unknown option 'bombay'. Failing.
Dec 02 17:03:09.085 [warn] Tor is currently configured as a relay and a hidden service. That's not very secure: you should probably run your hidden service in a separate Tor process, at least -- see https://trac.torproject.org/8742
Dec 02 17:03:09.088 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option.
Dec 02 17:03:09.225 [warn] Failed to find node for hop #1 of our path. Discarding this circuit.
============================================================ T= 1575306189
Tor 0.4.3.0-alpha-dev died: Caught signal 11
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x21ceb5)[0x56360d945eb5]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_circ_service_get_established_intro_circ+0x27)[0x56360d8327e7]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_circ_service_get_established_intro_circ+0x27)[0x56360d8327e7]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(hs_service_run_scheduled_events+0x14ff)[0x56360d849ccf]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x72961)[0x56360d79b961]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(+0x762f3)[0x56360d79f2f3]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f6688b925a0]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(do_main_loop+0xe5)[0x56360d79e565]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(tor_run_main+0x122d)[0x56360d78ba2d]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(tor_main+0x3a)[0x56360d7891da]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(main+0x19)[0x56360d788d59]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f66873e72e1]
/srv/jenkins-workspace/workspace/stem-tor-ci/RESULT/tor(_start+0x2a)[0x56360d788daa]
```Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32645Update URL bar onion indicators2020-12-11T13:05:04ZAntonelaantonela@torproject.orgUpdate URL bar onion indicatorsSince FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) t...Since FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) the brand presence of onions in Tor Browser, either for referring to the network or to the onion services.
I'm opening this ticket to discuss the following:
- are we ok following the Firefox approach and removing green icons from the URL bar?
- are we ok unifying the visual anchor for onions and onion routing at the URL bar and also at the circuit display?
- are we ok removing EV label from the URL bar and leave it at the identity doorhanger?
[1]FF70 https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/
[2]CH69 https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html
[*]TB8 https://trac.torproject.org/projects/tor/wiki/org/teams/UxTeam/Misc/OnionSecurityIndicatorrichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/32617spec: Merge prop305 into rend-spec-v3.txt2020-06-13T15:48:38ZDavid Gouletdgoulet@torproject.orgspec: Merge prop305 into rend-spec-v3.txtNow that #30924 was merged, we need to close prop305 and merge it in `rend-spec-v3.txt.Now that #30924 was merged, we need to close prop305 and merge it in `rend-spec-v3.txt.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32563Merge HSv3 spec fixes we found during onionbalance creation2020-06-13T15:48:25ZGeorge KadianakisMerge HSv3 spec fixes we found during onionbalance creationThere are a few issues with the v3 spec that we found out as we were implementing onionbalance. We should merge them.
Examples:
- https://github.com/asn-d6/stem/pull/2#discussion_r348847261
- The MAC description in the descriptor encryp...There are a few issues with the v3 spec that we found out as we were implementing onionbalance. We should merge them.
Examples:
- https://github.com/asn-d6/stem/pull/2#discussion_r348847261
- The MAC description in the descriptor encryption is wrong.Tor: unspecifiedGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/32562Allow ONION_CLIENT_AUTH_ADD credentials to be made permanent2020-06-13T15:48:25ZGeorge KadianakisAllow ONION_CLIENT_AUTH_ADD credentials to be made permanentThe Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.The Permanent flag of ONION_CLIENT_AUTH_ADD is not implemented yet.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32546hs-v3: Report invalid onion address SOCKS5 extended error code2020-06-16T01:10:52ZDavid Gouletdgoulet@torproject.orghs-v3: Report invalid onion address SOCKS5 extended error codeFrom prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.From prop304, continuing on after #30382, add a new error code to indicate invalid address.
This is the little-t tor side of #30022.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32543spec: Merge prop304 into torspec.git in socks-extensions.txt2020-06-13T15:48:21ZDavid Gouletdgoulet@torproject.orgspec: Merge prop304 into torspec.git in socks-extensions.txt#30382 has been merged upstream, prop304 needs to be put in socks-extensions.txt and then `Closed`.#30382 has been merged upstream, prop304 needs to be put in socks-extensions.txt and then `Closed`.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32542hs-v3: Add the 2 missing SOCKS extended errors from prop3042020-06-16T01:10:52ZDavid Gouletdgoulet@torproject.orghs-v3: Add the 2 missing SOCKS extended errors from prop304The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the ...The two missing codes are the intro failure and RP failure.
```
* X'F2' Onion Service Introduction Failed
Client failed to introduce to the service meaning the descriptor was
found but the service is not anymore at the introduction points. The
service has likely changed its descriptor or is not running.
* X'F3' Onion Service Rendezvous Failed
Client failed to rendezvous with the service which means that the client
is unable to finalize the connection.
```Tor: 0.4.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32356hs-v3: Memory leak in rend_client_get_random_intro_impl()2020-06-13T15:47:44ZDavid Gouletdgoulet@torproject.orghs-v3: Memory leak in rend_client_get_random_intro_impl()From coverity report:
```
** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
___________________________________________________________________________________...From coverity report:
```
** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
________________________________________________________________________________________________________
*** CID 1455168: Resource leaks (RESOURCE_LEAK)
/src/feature/rend/rendclient.c: 1061 in rend_client_get_random_intro_impl()
1055 usable_nodes = smartlist_new();
1056 smartlist_add_all(usable_nodes, entry->parsed->intro_nodes);
1057
1058 /* Get service ID so we can use it to query the failure cache. If we fail to
1059 * parse it, this cache entry is no good. */
1060 if (BUG(rend_get_service_id(entry->parsed->pk, service_id) < 0)) {
>>> CID 1455168: Resource leaks (RESOURCE_LEAK)
>>> Variable "usable_nodes" going out of scope leaks the storage it points to.
1061 return NULL;
1062 }
```
Was just introduced couple days ago.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32141single onion v3 IPv6 intro circuit BUG() warnings2020-06-13T15:46:54Zteorsingle onion v3 IPv6 intro circuit BUG() warningsLooks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) fail...Looks like some of our assertions are wrong in single onion IPv6 mode, but chutney still succeeds:
```
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at src/feature/hs/hs_client.c:491. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: Bug: Tor 0.4.3.0-alpha-dev (git-d616214e474084fd): Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at src/feature/hs/hs_client.c:685. Stack trace: (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:491: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
Warning: tor_bug_occurred_: Bug: src/feature/hs/hs_client.c:685: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.3.0-alpha-dev d616214e474084fd) Number: 1
```
https://travis-ci.org/torproject/tor/jobs/599435523#L3431Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32094hs-v3: Stop using ip->circuit_established flag2020-06-13T15:46:39ZDavid Gouletdgoulet@torproject.orghs-v3: Stop using ip->circuit_established flagSince #31548, where we forgot to look if the service intro circuit was established, we rely on `ip->circuit_established` flag to know if we can use the IP (and in many other places as well).
However, this is a bit of a "duplication" of ...Since #31548, where we forgot to look if the service intro circuit was established, we rely on `ip->circuit_established` flag to know if we can use the IP (and in many other places as well).
However, this is a bit of a "duplication" of effort because we have the HS circuitmap that keeps all the intro circuits conveniently indexed by IP auth key.
When a circuit closes or is repurposed, that HS map is cleaned up with `hs_circ_cleanup()` so regardless what caused the circuit to disappear, our map will always be updated properly.
I believe we should stop relying on the `ip->circuit_established` flag so in the future we don't get out of sync with the map by mistake or assume state based solely on this flag. The HS map is the only real valid state we should be looking at for HS circuit state.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32063CID 1454769: Resource leaks in build_establish_intro_dos_extension()2020-06-13T15:46:35ZteorCID 1454769: Resource leaks in build_establish_intro_dos_extension()Caused by #31682, which was a fix to another coverity issue.
```
CID 1454769: Resource leaks (RESOURCE_LEAK)
/src/feature/hs/hs_cell.c: 533 in build_establish_intro_dos_extension()
527 TRUNNEL_DOS...Caused by #31682, which was a fix to another coverity issue.
```
CID 1454769: Resource leaks (RESOURCE_LEAK)
/src/feature/hs/hs_cell.c: 533 in build_establish_intro_dos_extension()
527 TRUNNEL_DOS_PARAM_TYPE_INTRO2_BURST_PER_SEC,
528 service_config->intro_dos_burst_per_sec);
529
530 /* Set the field with the encoded DoS extension. */
531 ret = trn_cell_extension_dos_encoded_len(dos_ext);
532 if (BUG(ret <= 0)) {
CID 1454769: Resource leaks (RESOURCE_LEAK)
Variable "field" going out of scope leaks the storage it points to.
533 return -1;
534 })
```Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/32021hs-v3: Handle rendezvous client circuit build expire properly2020-06-13T15:46:26ZDavid Gouletdgoulet@torproject.orghs-v3: Handle rendezvous client circuit build expire properlyThis is a subtask of the bigger larger problem in #25882.
In `circuit_expire_building()`, we have this code path:
```
if (!(TO_ORIGIN_CIRCUIT(victim)->hs_circ_has_timed_out)) {
switch (victim->purpose) {
case CIRCUIT_PU...This is a subtask of the bigger larger problem in #25882.
In `circuit_expire_building()`, we have this code path:
```
if (!(TO_ORIGIN_CIRCUIT(victim)->hs_circ_has_timed_out)) {
switch (victim->purpose) {
case CIRCUIT_PURPOSE_C_REND_READY:
/* We only want to spare a rend circ if it has been specified in
* an INTRODUCE1 cell sent to a hidden service. A circ's
* pending_final_cpath field is non-NULL iff it is a rend circ
* and we have tried to send an INTRODUCE1 cell specifying it.
* Thus, if the pending_final_cpath field *is* NULL, then we
* want to not spare it. */
if (TO_ORIGIN_CIRCUIT(victim)->build_state &&
TO_ORIGIN_CIRCUIT(victim)->build_state->pending_final_cpath ==
NULL)
break;
```
Basically, this `pending_final_cpath` is only used by v2 which means v3 is not handle in that case.
And that case is: if we want to expire a rendezvous client circuit that is ready but has been waiting for a while on the introduction circuit as in its cookie has been sent in the `INTRODUCE1`, we want to spare it until the intro point client circuit collapses.
Because v3 is not handled in the above, rendezvous circuit will be tagged as timed out with the general cutoff instead of being kept until the intro circuit is ready or times out. And we time out intro circuit being established much later than an established rendezvous circuit for which the `general_cutoff` will be applied on.
Bottom line is that we need a flag within the rendezvous client circuit (probably hs_ident_t?) that its cookie was put in the INTRO1 cell and that we are waiting on the intro side signalling the `circuit_expire_building()` that it should wait more on that circuit.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org