1. 15 Oct, 2020 1 commit
  2. 07 Oct, 2020 2 commits
  3. 06 Oct, 2020 1 commit
    • Alexander Færøy's avatar
      Expose TOR_PT_OUTBOUND_BIND_ADDRESS_{V4,V6} to Pluggable Transports. · 5f61e19d
      Alexander Færøy authored and David Goulet's avatar David Goulet committed
      This patch adds support for exposing the environment variables
      `TOR_PT_OUTBOUND_BIND_ADDRESS_V4` and `TOR_PT_OUTBOUND_BIND_ADDRESS_V6` to
      Pluggable Transport proccesses. These two values will contain the IPv4
      and IPv6 address that the user have specified in torrc that they wish
      the PT to use for all outgoing IP packets.
      
      It is important to note here that it is up to the indvidual Pluggable
      Transport if they are willing to honor these values or ignore them
      completely.
      
      One can test this feature using the following dummy PT written in POSIX
      shell script:
      
          #!/bin/sh
      
          echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv4: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V4}\""
          echo "LOG SEVERITY=warning MESSAGE=\"Value for IPv6: ${TOR_PT_OUTBOUND_BIND_ADDRESS_V6}\""
      
          while true ; do
              sleep 1
          done
      
      with the following entries in your torrc:
      
          OutboundBindAddressPT 203.0.113.4
          OutboundBindAddress 203.0.113.5
          OutboundBindAddressPT 2001:db8::4
          OutboundBindAddress 2001:db8::5
      
      See: https://bugs.torproject.org/5304
      5f61e19d
  4. 01 Oct, 2020 1 commit
  5. 28 Sep, 2020 1 commit
  6. 23 Sep, 2020 9 commits
  7. 22 Sep, 2020 2 commits
  8. 17 Sep, 2020 3 commits
    • Nick Mathewson's avatar
      Use the correct SIGNED_KEY_TYPE value for signing->link certs · 5d1d7afc
      Nick Mathewson authored
      Our code was using [01] as for the key type of signed->link certs,
      which was incorrect.  The value should be [03], to indicate that the
      value as the SHA256 of an x.509 cert.
      
      Fortunately, nothing cares about this value, so there shouldn't be
      compatibility issues.
      
      Fixes bug 40124; bugfix on 0.2.7.2-alpha.
      5d1d7afc
    • Nick Mathewson's avatar
      Fix wide lines · 22643272
      Nick Mathewson authored
      22643272
    • Nick Mathewson's avatar
      Rename tor_cert_create to tor_cert_create_ed25519 · c92e1926
      Nick Mathewson authored
      This is an automated commit, generated by this command:
      
      ./scripts/maint/rename_c_identifier.py \
              tor_cert_create tor_cert_create_ed25519
      
      It was generated with --no-verify, so it probably breaks some commit hooks.
      The commiter should be sure to fix them up in a subsequent commit.
      c92e1926
  9. 07 Sep, 2020 1 commit
    • George Kadianakis's avatar
      statistics: Properly count all rendezvous cells (avoid undercounting). · 85a1e6c6
      George Kadianakis authored
      tl;dr We were not counting cells flying from the client to the service, but we
      were counting cells flying from the service to the client.
      
      When a rendezvous cell arrives from the client to the RP, the RP forwards it to
      the service.
      
      For this to happen, the cell first passes through command_process_relay_cell()
      which normally does the statistics counting. However because the `rend_circ`
      circuit was not flagged with `circuit_carries_hs_traffic_stats` in
      rend_mid_rendezvous(), the cell is not counted there.
      
      Then the cell goes to circuit_receive_relay_cell() which has a special code
      block based on `rend_splice` specifically for rendezvous cells, and the cell
      gets directly passed to `rend_circ` via a direct call to
      circuit_receive_relay_cell(). The cell never passes through
      command_process_relay_cell() ever again and hence is never counted by our
      rephist module.
      
      The fix here is to flag the `rend_circ` circuit with
      `circuit_carries_hs_traffic_stats` so that the cell is counted as soon as it
      hits command_process_relay_cell().
      
      Furthermore we avoid double-counting cells since the special code block of
      circuit_receive_relay_cell() makes us count rendezvous cells only as they enter
      the RP and not as they exit it.
      
      Fixes #40117.
      85a1e6c6
  10. 25 Aug, 2020 3 commits
  11. 20 Aug, 2020 1 commit
  12. 19 Aug, 2020 2 commits
    • David Goulet's avatar
      relay: Query our cache when deciding for dummy descriptor fetch · 83052372
      David Goulet authored
      
      
      Instead of looking at the "Address" option alone, instead check if we have an
      address in our cache (that is discovered by tor). If not, then it tells us
      that tor does not have an address to work with so we can then ask a directory
      authority for a suggestion.
      
      Related #2178
      
      Signed-off-by: David Goulet's avatarDavid Goulet <dgoulet@torproject.org>
      83052372
    • David Goulet's avatar
      hs: Don't overwrite DoS parameters on circuit with consensus params · f5c9f6d4
      David Goulet authored
      Turns out that the HS DoS defenses parameters were overwritten by the
      consensus parameters everytime a new consensus would arrive.
      
      This means that a service operator can still enable the defenses but as soon
      as the intro point relay would get a new consensus, they would be overwritten.
      And at this commit, the network is entirely disabling DoS defenses.
      
      Fix this by introducing an "explicit" flag that indicate if the
      ESTABLISH_INTRO cell DoS extension set those parameters or not. If set, avoid
      using the consenus at once.
      
      We are not bumping the protover HSIntro value for this because 0.4.2.x series
      is EOL in 1 month and thus 0.4.3.x would be the only series with this bug. We
      are confident that a backport and then upgrade path to the latest 0.4.4.x
      stable coming up soon is enough to mitigate this problem in the coming months.
      
      It avoids the upgrade path on the service side by keeping the requirement for
      protover HSIntro=5.
      
      Fixes #40109
      
      S...
      f5c9f6d4
  13. 14 Aug, 2020 1 commit
  14. 11 Aug, 2020 3 commits
  15. 10 Aug, 2020 1 commit
  16. 05 Aug, 2020 1 commit
    • Nick Mathewson's avatar
      Replace several C identifiers for ticket 18106. · b417594d
      Nick Mathewson authored
      We used to have a single boolean, "FascistFirewall".  Ages ago, in
      tickets #17840 and #9067, we added an improved "ReachableAddresses"
      mechanism.  It's time to rename related identifiers in the code for
      consistency.  This closes #18106.
      
      This is an automated commit, generated by this command:
      
      ./scripts/maint/rename_c_identifier.py \
              fascist_firewall_allows_address reachable_addr_allows \
              fascist_firewall_use_ipv6 reachable_addr_use_ipv6 \
              fascist_firewall_prefer_ipv6_impl reachable_addr_prefer_ipv6_impl \
              fascist_firewall_prefer_ipv6_orport reachable_addr_prefer_ipv6_orport \
              fascist_firewall_prefer_ipv6_dirport reachable_addr_prefer_ipv6_dirport \
              fascist_firewall_allows_address_addr reachable_addr_allows_addr \
              fascist_firewall_allows_address_ap reachable_addr_allows_ap \
              fascist_firewall_allows_base reachable_addr_allows_base \
              fascist_firewall_allows_ri_impl reachable_addr_allows_ri_impl \
              fascist_firewall_allows_rs_impl reachable_addr_allows_rs_impl \
              fascist_firewall_allows_rs reachable_addr_allows_rs \
              fascist_firewall_allows_md_impl reachable_addr_allows_md_impl \
              fascist_firewall_allows_node reachable_addr_allows_node \
              fascist_firewall_allows_dir_server reachable_addr_allows_dir_server \
              fascist_firewall_choose_address_impl reachable_addr_choose_impl \
              fascist_firewall_choose_address reachable_addr_choose \
              fascist_firewall_choose_address_base reachable_addr_choose_base \
              fascist_firewall_choose_address_rs reachable_addr_choose_from_rs \
              fascist_firewall_choose_address_ls reachable_addr_choose_from_ls \
              fascist_firewall_choose_address_node reachable_addr_choose_from_node \
              fascist_firewall_choose_address_dir_server reachable_addr_choose_from_dir_server
      b417594d
  17. 04 Aug, 2020 1 commit
  18. 03 Aug, 2020 2 commits
  19. 01 Aug, 2020 1 commit
  20. 31 Jul, 2020 3 commits