Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:39:24Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29782Multiple SocksPort is broken, connects to entry node multiple times. Tor = NSA?2020-06-13T15:39:24ZcypherpunksMultiple SocksPort is broken, connects to entry node multiple times. Tor = NSA?What the fuck is going on here?
If I use multiple SocksPort, it connects to entry node multiple times, instead of one time.
So CIA and NSA can analyze my traffic more easily. They also know how many applications I use with Tor.
That's hu...What the fuck is going on here?
If I use multiple SocksPort, it connects to entry node multiple times, instead of one time.
So CIA and NSA can analyze my traffic more easily. They also know how many applications I use with Tor.
That's huge bug. There should be one connection to entry node, but then each socksport should use different middle and exit node. (or maybe use same middle node too?)
You are just helping NSA. Do they own torproject?
Here is how to get the bug:
1. Configure Tor to use multiple SocksPort with IsolateDestAddr flag
2. Start Tor
3. Connect each application to each SocksPort and start doing network activity on all of them.
4. You might get multiple TCP connections to entry node.
5. Each separate TCP connection transmits data from separate SocksPort.
It doesn't happen 100% of time. Sometimes you need to wait or try again to get this bug.
This bug is a design flaw maybe. It lowers privacy and gives zero benefits.
NSA, CIA, can isolate each TCP connection and try to make analysis and correlation. If everything was transmitted on single TCP connection they would need to own entry node to do same thing. If everything was transmitted on single Entry and Middle node (but different Exit node) they would need to own entry and middle node to make this analysis.https://gitlab.torproject.org/legacy/trac/-/issues/23319hs: Memory leak in test hs_descriptor/decode_bad_signature2020-06-13T15:13:01ZDavid Gouletdgoulet@torproject.orghs: Memory leak in test hs_descriptor/decode_bad_signatureTrivial fix.Trivial fix.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23309hs: We need to get rid of a descriptor when entering non-overlap mode2020-06-13T15:12:58ZDavid Gouletdgoulet@torproject.orghs: We need to get rid of a descriptor when entering non-overlap modeFrom the discussion here: https://oniongit.eu/asn/tor/merge_requests/3#note_905
It seems the solution is to set the next descriptor as the current one when entering the non-overlap mode.
This is v3 service side thus affecting upstream ...From the discussion here: https://oniongit.eu/asn/tor/merge_requests/3#note_905
It seems the solution is to set the next descriptor as the current one when entering the non-overlap mode.
This is v3 service side thus affecting upstream code.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23308prop224: Implement note_connection_attempt_succeeded() in the client code2020-06-13T15:12:58ZDavid Gouletdgoulet@torproject.orgprop224: Implement note_connection_attempt_succeeded() in the client code#17242 has gone over many review rounds so implement this once we get it upstream.
This function should do the job that `rend_client_note_connection_attempt_ended()` does that is purging the hsdir request cache.#17242 has gone over many review rounds so implement this once we get it upstream.
This function should do the job that `rend_client_note_connection_attempt_ended()` does that is purging the hsdir request cache.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/23300prop224: General client side issues2020-06-13T15:12:54ZDavid Gouletdgoulet@torproject.orgprop224: General client side issuesThis is a parent ticket for a series of client side issues that have been identified during the review of #17242 and that we felt it would be better to fix in a separate ticket because some include changes to the HS v2 subsystem.This is a parent ticket for a series of client side issues that have been identified during the review of #17242 and that we felt it would be better to fix in a separate ticket because some include changes to the HS v2 subsystem.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/23233Unexpected BUG violation in hsv3 decriptor decoding2020-06-13T15:12:42ZhaxxpopUnexpected BUG violation in hsv3 decriptor decoding
As you can see in hs_descriptor.c
```
/* Find the start of signature. */
sig_start = tor_memstr(encoded_desc, encoded_len, "\n" str_signature);
/* Getting here means the token parsing worked for the signature so if we
* can't ...
As you can see in hs_descriptor.c
```
/* Find the start of signature. */
sig_start = tor_memstr(encoded_desc, encoded_len, "\n" str_signature);
/* Getting here means the token parsing worked for the signature so if we
* can't find the start of the signature, we have a code flow issue. */
if (BUG(!sig_start)) {
goto err;
}
```
str_signature is "signature", so, if you send the "\n signature" (like in the attachment) instead of "\nsignature" tor_memstr will return null and violate `BUG(!sig_start)`
I suggest that we should just remove BUG and let it be `if (!sig_start) {`Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/22979prop224: Add an introduction point onion key in the descriptor2020-06-13T15:11:57ZDavid Gouletdgoulet@torproject.orgprop224: Add an introduction point onion key in the descriptorSo it turns out that this menagerie of keys in prop224 was missing yet one more key in it :D.
To extend to an introduction point, we need its onion key meaning we have to add it to the descriptor. Keep in mind that the client does NOT l...So it turns out that this menagerie of keys in prop224 was missing yet one more key in it :D.
To extend to an introduction point, we need its onion key meaning we have to add it to the descriptor. Keep in mind that the client does NOT lookup the node in its consensus in order not to reveal which consensus it's using and avoid reachability issues with different consensus between service and client.
This goes in two fold. First add an onion key field in the spec and then implement it in an extra commit in #20657 code (which is being reviewed). I would like us to avoid making a branch depending on 8k lines of code from another unmerged ticket.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22810prop224: Make the client/service extend properly to the IP/RP2020-06-13T15:11:13ZDavid Gouletdgoulet@torproject.orgprop224: Make the client/service extend properly to the IP/RPFor a prop224 service to extend to a rendezvous point (RP) or a client to extend to a introduction point (IP), we need two things to change in the tor code.
1) The `extend_info_t` object needs to support a list of "extra" link specifier...For a prop224 service to extend to a rendezvous point (RP) or a client to extend to a introduction point (IP), we need two things to change in the tor code.
1) The `extend_info_t` object needs to support a list of "extra" link specifiers that should be put in the `EXTEND2` cell if present. From proposal 224:
```
The hidden service SHOULD NOT reject any LSTYPE fields which it
doesn't recognize; instead, it should use them verbatim in its EXTEND
request to the rendezvous point.
```
2) The ed25519 identity link specifier (LSTYPE=03, see prop220), needs to be mandatory for both introduction and rendezvous points as detailed in prop224. So we need a way to tell the circuit subsystem that "this EXTEND2 cell is for IP or RP so put the ed25519 id in it".Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22727prop224: Add functions to check for HS v3 support2020-06-13T15:10:42ZDavid Gouletdgoulet@torproject.orgprop224: Add functions to check for HS v3 supportThis is groundwork for prop224.
It simply adds two functions for to nodelist.h that checks for v3 hsdir support (HSDir 3 protover) and ed25519 intro point (HSIntro 4 protover).This is groundwork for prop224.
It simply adds two functions for to nodelist.h that checks for v3 hsdir support (HSDir 3 protover) and ed25519 intro point (HSIntro 4 protover).Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/22726prop224: Ignore unparseable v3 introduction points2020-06-13T15:10:41ZDavid Gouletdgoulet@torproject.orgprop224: Ignore unparseable v3 introduction pointsFor forward compat., we should just ignore unknown introduction points fields in a prop224 descriptor.
This is groundwork for prop224.For forward compat., we should just ignore unknown introduction points fields in a prop224 descriptor.
This is groundwork for prop224.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21980prop224: Implement time period functions2020-06-13T15:07:59ZDavid Gouletdgoulet@torproject.orgprop224: Implement time period functionsTime period functions that we need in order to know where to upload/download the descriptor.Time period functions that we need in order to know where to upload/download the descriptor.Tor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/21979prop224: Load and configure service2020-06-13T15:07:59ZDavid Gouletdgoulet@torproject.orgprop224: Load and configure serviceThis is a much bigger patch implementing a key feature of hidden service. Loading and configuring a service from the torrc file.
A new object is added which is `hs_service_t` representing a v3 service. The `hs_config.[ch]` files are int...This is a much bigger patch implementing a key feature of hidden service. Loading and configuring a service from the torrc file.
A new object is added which is `hs_service_t` representing a v3 service. The `hs_config.[ch]` files are introduced which loads the options and create an `hs_service_t` object out of it.
Like the legacy code, it goes in two steps. First, load the options and validate. Then, load/generate the keys if not in validate mode.
Some refactoring of the legacy code was needed in order to have a central entry point for the configuration of the HS options for both v2 and v3.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21978hs: Decouple adding and validating a service2020-06-13T15:07:58ZDavid Gouletdgoulet@torproject.orghs: Decouple adding and validating a serviceOne commit that splits the `rend_add_service()` function into two functions. One actually adding the service to the global list and the second one to validate the service thus adding a new function: `rend_validate_service()`
We need thi...One commit that splits the `rend_add_service()` function into two functions. One actually adding the service to the global list and the second one to validate the service thus adding a new function: `rend_validate_service()`
We need this for prop224 code that will in two steps validate and then add the service when loading a service from configuration.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21919hs: Change trunnel prop224 cell's namespace2020-06-13T15:07:46ZDavid Gouletdgoulet@torproject.orghs: Change trunnel prop224 cell's namespaceCurrently, the trunnel namespace for hidden service cells (in `src/trunnel/hs/`) is prefixed with `hs_cell_*`. We want to change this for two reasons.
First, if we could have something in the name indicating that it is trunnel, it would...Currently, the trunnel namespace for hidden service cells (in `src/trunnel/hs/`) is prefixed with `hs_cell_*`. We want to change this for two reasons.
First, if we could have something in the name indicating that it is trunnel, it would make it better for code semantic and separation.
Second, we want to create `hs_cells.[ch]` so we can put in there the cell creation/parsing/handling instead of growing `hs_circuit.c` to the "hydra size".
So for the renaming, here are some suggestions:
1. `tr_cell_*`
2. `tr_hs_cell_*`
3. `trunnel_cell_*`
4. `trnl_cell_*`
Considering that an `ESTABLISH_INTRO` or `INTRODUCE1` cell is only for hidden service, probably the `hs` in there is superfluous?Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21895hs: Remove enc-key private key from hs_descriptor.h2020-06-13T15:07:42ZDavid Gouletdgoulet@torproject.orghs: Remove enc-key private key from hs_descriptor.hRemove the curve25519 keypair from `hs_desc_intro_point_t` data structure. Only the public key should be there and the keypair should be on the service side data structure coming in #20657.Remove the curve25519 keypair from `hs_desc_intro_point_t` data structure. Only the public key should be there and the keypair should be on the service side data structure coming in #20657.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21893prop224: Flag a relay that supports HSIntro=4 and HSDir=22020-06-13T15:07:41ZDavid Gouletdgoulet@torproject.orgprop224: Flag a relay that supports HSIntro=4 and HSDir=2Set a flag in `routerstatus_t` to indicate if a relay supports v3 (prop224) introduction or HSDir.
Part of groundwork of prop224 service implementation (#20657)Set a flag in `routerstatus_t` to indicate if a relay supports v3 (prop224) introduction or HSDir.
Part of groundwork of prop224 service implementation (#20657)Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21891hs: Refactoring of some part of the legacy code for prop224 usage2020-06-13T15:07:40ZDavid Gouletdgoulet@torproject.orghs: Refactoring of some part of the legacy code for prop224 usageThis branch contains 4 commits that we need for prop224 service implementation work (#20657).
First commit is a trivial refactor to make a function in rendservice.c public and broader to both HS subsystems (legacy and new).
Second and ...This branch contains 4 commits that we need for prop224 service implementation work (#20657).
First commit is a trivial refactor to make a function in rendservice.c public and broader to both HS subsystems (legacy and new).
Second and third commit are code moving and minor cleanup.
Fourth commit is a bit more involving that is making the pruning rendservice list public so the HS prop224 code can use it later on with #20657 work.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21889hs: Circuitmap changes for prop2242020-06-13T15:07:39ZDavid Gouletdgoulet@torproject.orghs: Circuitmap changes for prop224This is part of the groundwork for service implementation of prop224 (#20657).
First, we need the circuitmap API to use a `circuit_t` instead of `or_circuit_t` so we can use it on the service side which uses `origin_circuit_t`.
Second,...This is part of the groundwork for service implementation of prop224 (#20657).
First, we need the circuitmap API to use a `circuit_t` instead of `or_circuit_t` so we can use it on the service side which uses `origin_circuit_t`.
Second, add a service side API to track service circuits.
Finally, refactor this API so the naming has better semantic.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21888prop224: Groundwork for service implementation2020-06-13T15:07:39ZDavid Gouletdgoulet@torproject.orgprop224: Groundwork for service implementationThis is the parent ticket for a series of patches we want to merge upstream to lay the groundwork for the service implementation (#20657) in order to bring down the number of commits and size of that branch and making review less of a pa...This is the parent ticket for a series of patches we want to merge upstream to lay the groundwork for the service implementation (#20657) in order to bring down the number of commits and size of that branch and making review less of a pain.
I'll set this to 031 milestone if we have time to do it great! but ultimately this is only needed for 032 merge window so no biggy if we don't make it.Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21871prop224: Change descriptor format for legacy encryption key2020-06-13T15:07:37ZDavid Gouletdgoulet@torproject.orgprop224: Change descriptor format for legacy encryption keyIt turns out that we might have miscalculated the legacy feature for introduction point.
Currently, proposal 224 looks like this for legacy encryption keys:
```
Encryption key is specified as follow:
[Exactly once enc-...It turns out that we might have miscalculated the legacy feature for introduction point.
Currently, proposal 224 looks like this for legacy encryption keys:
```
Encryption key is specified as follow:
[Exactly once enc-key per introduction point]
"enc-key" SP "ntor" SP key NL
The key is a base64 encoded curve25519 public key used to encrypt
the introduction request to service.
"enc-key" SP "legacy" NL key NL
Base64 encoded RSA key, wrapped in "----BEGIN RSA PUBLIC
KEY-----" armor, for use with a legacy introduction point as
described in [LEGACY_EST_INTRO] and [LEGACY-INTRODUCE1] below.
```
This doesn't make much sense because this encryption key is used to encrypt the `ENCRYPTED` section of the INTRODUCE1 cell (section 3.2.1. and 3.2.2.). That section can only be decrypted by the service so the introduction point, being legacy or not, doesn't touch it at all, it just passes along the bytes.
So, the descriptor should always contain a ntor key per intro point because we still want the ntor handshake to happen since both client and service do speak the prop224 protocol.
If the intro point is a legacy one, it should also have a "legacy key" which is an extra RSA public key needed in the INTRODUCE1 legacy cell and used by the intro point to relay the cell on the right circuit (used in the ESTABLISH_INTRO):
```
LEGACY_KEY_ID [20 bytes]
[...]
Here, LEGACY_KEY_ID is the hash of the introduction point legacy
encryption key that was included in the hidden service descriptor.
```
In the legacy `ESTABLISH_INTRO`:
```
PK Bob's public key or service key [KL octets]
```
In the current legacy code, the intro point validates that this PK field is an ASN.1 encoded RSA key (`rend_mid_establish_intro_legacy()`).
Fortunately for us, this code is getting release in 030 *but* only be actually used in 032 (#12424).Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org