{5} Accepted, Active Tickets by Owner (Full Description) (111 matches)

The existing GoodBadISP tables need sorting into the new format. All opinions, feedback and communications to that ISP must go in the correct section on ISPCorrespondence page to keep the primary page clean and to the point since it will grow substantially over time.

The new format should be available soon after this ticket is posted as it will be done for the US hosts (good experiences).

The Tor Browser User Manual on ​https://tb-manual.torproject.org/windows/en-US/ needs a section covering

a) where to find the source, b) how it is licensed, and c) where and how to report bugs.

Cheers,

The two text files currently in the doc directory are doc/HACKING and doc/TUNING. The latter is the only one that deals with relay operation, and its subject is oddly specific: increasing the maximum number of file descriptors. If we're going to put critical documentation in the codebase, I think it would also be worthwhile to have a basic hardening guide. It could include suggestions like:

• allowing only public key non-root SSH login
• using a firewall
• keeping your system up-to-date
• not running any other programs (especially networked ones)
• considering hardened or security-focused OS choices

Nick suggested that most of the actual information be contained in referenced links, which I agree with. There's no good reason to duplicate effort when there are, for example, so many good SSH hardening guides.

Let me know what you think, or if you have any contributions. If this is generally considered a good idea, I can start writing a draft.

With enabled HTTPS Everywhere, ​http://www.o2online.de/microsite/o2-netz/live-check/ does not load additional JavaScript from a non-SSL CDN

If DisableNetwork is set to 1 via SETCONF during bootstrapping, Tor sometimes generates spurious errors such as "Network is unreachable". Kathy and I saw this while testing a fix for #11879. We realize this may be difficult to fix due to the internal architecture / concurrency inside Tor.

See #15713 for steps to reproduce (but note that an error does not occur every time). In the log that is attached to #15713 you can see an example:

Apr 17 10:28:10.000 [warn] Problem bootstrapping. Stuck at 25%: Loading networkstatus consensus. (Network is unreachable; NOROUTE; count 1; recommendation warn; host 847B1F850344D7876491A54892F904934E4EB85D at 86.59.21.38:443)

(the error happens right away if it happens at all – no delay).

This problem may cause some Tor Browser users to be a little confused; all they need to do is click "Open Settings" while Tor Browser was starting up and they will sometimes see an error alert.

Nick and I both thought that at least in the past, Tor clients would stop using a relay as their guard, if it loses the Guard flag.

But it looks like the code doesn't do that -- once a relay is your guard, you'll use it in the guard position regardless of whether it has the Guard flag at this moment or not.

This is actually a tricky design decision. In favor of avoiding guards that don't have the guard flag:

• If they get really slow, we can instruct clients to abandon them.
• If a relay gets the guard flag for only a short period of time, it will have only a small number of (dedicated) users using it for the next months.

In favor of using non-Guard guards anyway:

• An attacker can't push you away from your guard by hurting its performance in the eyes of the directory authorities.
• You won't rotate guards as many times.

That "can't push you away" one looks big. What other aspects should we be considering here?

with tor-0.2.6.9 and stem-1.4.1 I run (rarely) into this :

cat ioerror.stderr.old
Exception in thread Event Notifier:
Traceback (most recent call last):
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1758, in get_network_status
    desc_content = self.get_info(query, get_bytes = True)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 414, in wrapped
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 409, in wrapped
    return func(self, *args, **kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1113, in get_info
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1066, in get_info
    stem.response.convert('GETINFO', response)
  File "/usr/lib64/python3.3/site-packages/stem/response/__init__.py", line 135, in convert
    message._parse_message(**kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/response/getinfo.py", line 38, in _parse_message
    raise stem.InvalidArguments('552', 'GETINFO request contained unrecognized keywords: %s\n' % ', '.join(unrecognized_keywords), unrecognized_keywords)
stem.InvalidArguments: GETINFO request contained unrecognized keywords: ns/id/2BCDF9F0BCEFC2A44F7850F92362BA85AA226E1F


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.3/threading.py", line 901, in _bootstrap_inner
    self.run()
  File "/usr/lib64/python3.3/threading.py", line 858, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 882, in _event_loop
    self._handle_event(event_message)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 3480, in _handle_event
    listener(event_message)
  File "./err.py", line 47, in orconn_event
    relay = controller.get_network_status(fingerprint)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 414, in wrapped
    raise exc
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 409, in wrapped
    return func(self, *args, **kwargs)
  File "/usr/lib64/python3.3/site-packages/stem/control.py", line 1761, in get_network_status
    raise stem.DescriptorUnavailable("Tor was unable to provide the descriptor for '%s'" % relay)
stem.DescriptorUnavailable: Tor was unable to provide the descriptor for '2BCDF9F0BCEFC2A44F7850F92362BA85AA226E1F'

while running this script :

$ cat err.py
#!/usr/bin/python3 -u

#   Toralf Foerster
#   Hamburg
#   Germany

# collect data wrt to https://trac.torproject.org/projects/tor/ticket/13603
#

import time
import functools

from stem import ORStatus, ORClosureReason
from stem.control import EventType, Controller


def main():
  class Cnt(object):
    def __init__(self, done=0, closed=0, ioerror=0):
      self.done = done
      self.closed = closed
      self.ioerror = ioerror

  c = Cnt()

  with Controller.from_port(port=9051) as controller:
    controller.authenticate()

    orconn_listener = functools.partial(orconn_event, controller, c)
    controller.add_event_listener(orconn_listener, EventType.ORCONN)

    while True:
      time.sleep(1)

def orconn_event(controller, c, event):
  if event.status == ORStatus.CLOSED:
    c.closed += 1

    if event.reason == ORClosureReason.DONE:
      c.done += 1

    if event.reason == ORClosureReason.IOERROR:
      c.ioerror += 1

      fingerprint = event.endpoint_fingerprint
      print (" %i %i %i %i %s %40s" % (c.closed, c.done, c.ioerror, event.arrived_at, time.ctime(event.arrived_at), fingerprint), end='')
      relay = controller.get_network_status(fingerprint)
      if relay:
        print (" %15s %5i %s %s" % (relay.address, relay.or_port, controller.get_info("ip-to-country/%s" % relay.address, 'unknown'), relay.nickname), end='')
      print ('', flush=True)

if __name__ == '__main__':
  main()

Bug #11236 is caused by translated search engine strings. We should make sure those strings are not translated.

Currently in master we have the following stanza in our .gitlab-ci.yml (from #22891):

update:                                                                                                                                                                                                                           
  script:                                                                                                                                                                                                                         
    - "apt-get install -y --fix-missing git openssh-client"                                                                                                                                                                       
                                                                                                                                                                                                                                  
    # Run ssh-agent (inside the build environment)                                                                                                                                                                                
    - eval $(ssh-agent -s)                                                                                                                                                                                                        
                                                                                                                                                                                                                                  
    # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store                                                                                                                                                       
    - ssh-add <("$DEPLOY_KEY")                                                                                                                                                                                                
                                                                                                                                                                                                                                  
    # For Docker builds disable host key checking. Be aware that by adding that                                                                                                                                                   
    # you are suspectible to man-in-the-middle attacks.                                                                                                                                                                           
    # WARNING: Use this only with the Docker executor, if you use it with shell                                                                                                                                                   
    # you will overwrite your user's SSH config.                                                                                                                                                                                  
    - mkdir -p ~/.ssh                                                                                                                                                                                                             
    - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'                                                                                                                                  
    # In order to properly check the server's host key, assuming you created the                                                                                                                                                  
    # SSH_SERVER_HOSTKEYS variable previously, uncomment the following two lines                                                                                                                                                  
    # instead.                                                                                                                                                                                                                    
    - mkdir -p ~/.ssh                                                                                                                                                                                                             
    - '[[ -f /.dockerenv ]] && echo "$SSH_SERVER_HOSTKEYS" > ~/.ssh/known_hosts'                                                                                                                                                  
    - echo "merging from torgit"                                                                                                                                                                                                  
    - git config --global user.email "labadmin@oniongit.eu"                                                                                                                                                                       
    - git config --global user.name "gitadmin"                                                                                                                                                                                    
    - "mkdir tor"                                                                                                                                                                                                                 
    - "cd tor"                                                                                                                                                                                                                    
    - git clone --bare https://git.torproject.org/tor.git                                                                                                                                                                         
    - git push --mirror git@oniongit.eu:network/tor.git                                                                                                                                                                           

Why are we doing this? Can we put a cronjob on the oniongit.eu server instead? It's pretty weird and frankly unexpected that my personal fork of tor at ​https://gitlab.com/isis/tor is cloning the official tor repo and then trying to mirror it to oniongit.eu. It also has a bunch of other problems:

• The ssh-add line ​is broken, causing CI to fail because it sits there forever waiting for a passphrase.

I was originally going to patch the ssh-add line to instead be [[ -n "${DEPLOY_KEY}" -a -r "$DEPLOY_KEY" ]] && ssh-add "$DEPLOY_KEY" <<<"" but if I fix that, then all the rest of this script would run, so I'm rather glad it's failing on a more innocuous command.

• Even if the ssh-add line weren't broken, this whole thing fails unless it's being run from a fork on oniongit.eu.
• Why is it disabling SSH hostkey checking?!
• Why is it making the ~/.ssh directory twice?
• Why is it assuming that environment variables are set? e.g. $FOO versus ${FOO} or better test -n ${FOO}
• Why is it unconditionally setting (global!) git config options? (I assume to disable the warning that git spits out when you don't have $GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} set, but why would a CI config set them globally instead of just setting the correct environment variables?)
• Why are the mirror URLs hardcoded?
• Why is the git username and email hardcoded?
• Why is any of this even running when I push to ​https://gitlab.com/isis/tor?
• Why is any of this even running when I push anywhere?
• Why is it unconditionally starting an ssh-agent?
• Why is using the existence of a (​deprecated!) /.dockerenv file to determine if we're in a docker container?
• Why is it assuming we're in the correct docker container, when lots of things, especially lots of CI systems, use docker?

I'm sorry if this is all necessary and I'm just not understanding the setup, but it's all just extremely unexpected behaviour from what is supposed to be a CI config file. Further, it's not even doing the same testing as our .travis.yml, but I'll make another ticket for that issue.

Tor increases data usage, and most of the demographics that need Tor the most have very limited data, so please make PTs available for zero-rated services.

For example FreedomPop zero-rates WhatsApp (​https://9to5mac.com/2016/08/17/freedompop-whatsapp-sim-free-iphone/) in 30 countries on a free ($0/month) plan.

A WhatsApp plugable transport would therefor allow users in poverty-stricken, massively oppressed countries to have unlimited free access to information through Tor.

I'm not sure if the component should be Orbot or Tor; the WhatsApp example is for mobile but there is also zero-rating for house internet, or someone might want to use a WhatsApp PT on a desktop/laptop/notebook with conventional Tor, tethered to a smartphone for the zero-rated protocol.

With the service branch in #20657, the current code design has intro points (IPs) per-descriptor meaning intro point objects are indexed inside a descriptor object.

We want to change that to a per-service design for which there is a set of intro points picked by the service which are then assigned to descriptor(s).

The reason to do such a thing is so we expose less IPs overtime thus minimizing the service exposure. Currently, because IPS are per-descriptor, once the descriptor rotates we also rotate IPs which bounds IPs' lifetime to the descriptor lifetime but this is not always true (and should not).

With a per-service design, IPs can live on between descriptors because they rotate at a different rate than the IPs and thus honoring its lifetime.

As my v3 onion service is getting more and more popular, I started to get:

[warn] Possible replay detected! An INTRODUCE2 cell with thesame ENCRYPTED section was seen 32 seconds ago. Dropping cell.

I am inclined to think that this is more like a bug in Tor, maybe due to a race condition, rather than a replay attack.

I also think this is what causes #15618 - dgoulet confirmed that the warning can be reproduced every time a second ESTABLISH_RENDEZVOUS is sent over the same circuit.

This can probably go away if we fix #21084. I am not sure if that should be a parent ticket here or not, please change if you feel like it. I think I still have yawning's tool and notes about how to reproduce #21084.

the Linux 'capabilities' library for allowing non-root users to perform tasks which normally require elevated privileges.

at present the torsocks wrappers have checked for setuid and setgid flags on the binaries it executes and failed closed, throwing an error if this occurs, however there is currently no check to see if the binaries have capabilities applied.

in the case where they do, the LD_PRELOAD set by torsocks is stripped and the program will execute with no warning and without the torsocks wrapper.

as an example of this, the current 'ping' command on my Linux is setcap:

$ getcap which ping /usr/bin/ping = cap_net_raw+ep $ torsocks ping -c 1 torproject.org PING torproject.org (82.195.75.101) 56(84) bytes of data. 64 bytes from 82.195.75.101: icmp_seq=1 ttl=50 time=38.1 ms

​https://projects.archlinux.org/svntogit/packages.git/tree/trunk/iputils.install?h=packages/iputils

We have a branch bug15618_030-testing at ​https://gitweb.torproject.org/user/dgoulet/tor.git that logs a warning when we call more than 2 times circuit has_opened() on a circuit. The patch was made to confirm the theory on #15618 related to a warning we see on relays. While until now I never saw the warning on relay side, I see it quite often on client side.

Based on the log messages, I think this is related to introduction point circuits and not rendezvous circuits as we thought. Basically it happens when we open a 4 hop circuit with last hop X, and immediately we extend that circuit to a 5 hop one with last hop Y, where Y is (I think) the introduction point. I got the warning 2 times in a row and the similarity between them is that they are 5 hop circuits with the last two hops 4 and 5 the same, but different hops 2 and 3.

Dec 25 13:15:15.000 [info] internal circ (length 5, last hop $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7): $A7C411B809D0AA98C4264917BB701ABF17B2181E(open) $B5212DB685A2A0FCFBAE425738E478D12361710D(open) $123F403DA94A74F959B7FE0E5B27FA57EFA12925(open) $1F4105C688E835A56AF3D66C787677B57240FFA2(open) $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7(open)
Dec 25 13:15:15.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard sakujakira ($A7C411B809D0AA98C4264917BB701ABF17B2181E)
Dec 25 13:15:15.000 [info] circuit_send_next_onion_skin(): circuit built!
Dec 25 13:15:15.000 [warn] BLAM. Circuit has_opened() called 3 times.
Dec 25 13:15:15.000 [info] rend_client_introcirc_has_opened(): introcirc is open
Dec 25 13:15:15.000 [info] connection_ap_handshake_attach_circuit(): pending-join circ 3419634369 already here, with intro ack. Stalling. (stream 26 sec old)
Dec 25 13:15:15.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 2404371907 already here (no intro-ack yet on intro 2259155742). (stream 26 sec old)
Dec 25 13:15:15.000 [info] connection_ap_handshake_attach_circuit(): found open intro circ 2259155742 (rend 2404371907); sending introduction. (stream 26 sec old)
Dec 25 13:15:15.000 [info] rend_client_send_introduction(): Sending an INTRODUCE1 cell
Dec 25 13:15:15.000 [info] pathbias_count_use_attempt(): Used circuit 53293 is already in path state use succeeded. Circuit is a Hidden service client: Pending rendezvous point currently open.

Dec 25 13:15:16.000 [info] internal circ (length 5, last hop $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7): $A7C411B809D0AA98C4264917BB701ABF17B2181E(open) $5C01D5518D1F5A071C6F07D1F4630F577AB5B60A(open) $DA9DA02A7B0565DF5F3E961CA911E750072DCBBD(open) $1F4105C688E835A56AF3D66C787677B57240FFA2(open) $D7316BF7FD633DD7474B18C33E1D5FDEB04D26A7(open)
Dec 25 13:15:16.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard sakujakira ($A7C411B809D0AA98C4264917BB701ABF17B2181E)
Dec 25 13:15:16.000 [info] circuit_send_next_onion_skin(): circuit built!
Dec 25 13:15:16.000 [warn] BLAM. Circuit has_opened() called 3 times.
Dec 25 13:15:16.000 [info] rend_client_introcirc_has_opened(): introcirc is open
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): pending-join circ 3419634369 already here, with intro ack. Stalling. (stream 26 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): Intro circ 2259155742 present and awaiting ack (rend 2404371907). Stalling. (stream 26 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): Intro circ 3200472182 present and awaiting ack (rend 4286776399). Stalling. (stream 26 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): ready rend circ 2334828448 already here (no intro-ack yet on intro 4002828471). (stream 27 sec old)
Dec 25 13:15:16.000 [info] connection_ap_handshake_attach_circuit(): found open intro circ 4002828471 (rend 2334828448); sending introduction. (stream 27 sec old)
Dec 25 13:15:16.000 [info] rend_client_send_introduction(): Sending an INTRODUCE1 cell
Dec 25 13:15:16.000 [info] pathbias_count_use_attempt(): Used circuit 53301 is already in path state use succeeded. Circuit is a Hidden service client: Pending rendezvous point currently open.

Here is how we make IPv6 (and other unreachable addresses) work with single-hop client and service connections to intro and rend points. It works for v2 single onion services. We talked about it for v3, but it never made it into the prop224 spec.

Here are the steps:

0. The service chooses and connects to the intro point (possibly using a 3-hop path if it is a single onion service and can't reach it directly)
1. The service always puts IPv4 and IPv6 in its descriptor link specifiers (if they are available in directory documents)
2. If the link specifier has a reachable address, and the service is not a single onion service, a Tor2web client (currently v2 only) can use it to make a direct connection to the intro point
3. Otherwise, the client connects over a 3-hop path via one of its reachable entry nodes

The process for client rendezvous is similar, but if the client knows that the service is a single onion service, it *must* connect to the rend point using a 3-hop path. (Again, this only matters for Tor2web, which is v2 only).

If you look at circuitmux_append_destroy_cell(), it is the one appending a DESTROY cell to the cmux queue and then calls channel_flush_from_first_active_circuit() if no writes are pending that is if the outbuf is empty (also looks at the out queue but that is always empty #23709).

In the case the flush is triggered, the cell is immediately put in the outbuf and written to kernel by libevent which completely bypasses the scheduler. Maybe it is what we want that is go as fast as we can in destroying a circuit? Don't know but it has this effect on the scheduler where the channel is scheduled with a "wants_to_write" event from the connection subsystem and ultimately the channel gets scheduled with nothing in the queue because it is already on the outbuf. For KIST, this is not ideal because KIST should control the flow of data to the kernel.

It seems there are two places we queue cells into a cmux queue: circuitmux_append_destroy_cell() and append_cell_to_circuit_queue(). The latter triggers a "has waiting cells" for the scheduler which is what we want but the former just bypasses it.

I think it should simply trigger that notify to the scheduler instead of flushing it by itself.

Prop224 says:

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.

​https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1689

We should either remove this from the spec, or we should:

• add a similar sentence for client descriptor lspecs
• put unrecognised lspecs in descriptors in client intro EXTEND requests
• put unrecognised lspecs in INTRODUCE cells in service rend EXTEND requests

For TB to be able to alert the user that they need to input their client auth credentials we need an appropriate control port event.

In particular:

1) When Tor fails to decrypt the second layer of desc encryption, we issue the CLIENT_AUTH_NEEDED <onion> <reason> event. Tor does not go to fetch more descs from the hsdir for this onion.

2) At the same time, we store the broken descriptor into the hs cache, with a special flag that says "missing client auth" and hence desc is NULL.

3) When TB intercepts the event it presents the user with a dialogue (#30237) and adds any client auth creds with the commands from #30381.

4) As part of the #30381 commands the descriptor is decrypted.

5) TB issues another SOCKS request which uses the right descriptor and goes forward.

recvmsg() is supported as of now. A full exit should be done here because Torsocks can't handle this inet socket with Tor.

This warning is possible for anything socket trying to connect to a localhost address.

WARNING torsocks[12360]: [connect] Connection to a local address are denied since it might be a TCP DNS query to a local DNS server. Rejecting it for safety reasons. (in tsocks_connect() at connect.c:177)

We should implement a whitelist mechanism so the user can tell which local network is allowed such as localhost.

Multiple issues need FD passing through a Unix socket to work: #8585, #16183

It's maybe possible to support this safely. My intuition is that we might be able to get it work by passing some cookies in the ancillary data so we can recognize the sendmsg() with the recvmsg(). Maybe!?...

Clients should put IPv6 link specifiers in the EXTEND cells to relays they choose from directory documents.

We need to do this in the same releases as #24181, to avoid adding an v3 onion service distinguisher.

What torsocks does: Routes all traffic through Tor.

What it should do: It shoud have an option to route .onion domains through Tor, while normal traffic is not routed through Tor.

Advantages This would allow Mail/XMPP servers to connect to .onion domains, without any configuration hassle.

Original discussion ​http://tor-talk.torproject.narkive.com/j7MtPG5T/torsocks-usewithtor-only-for-onion

For several years everyone was able to post on ​https://blog.torproject.org without enabling JavaScript and other dangerous things.

Observed behaviour: can not post unless slider set to medium or low Expected behaviour: high security supported Steps to reproduce: try to post at ​https://blog.torproject.org with security slider on high

During the meeting in CDMX some of us chatted about the possibility to build and maintain a sort of Tor web docs (like the mozilla web docs [1]).

The idea is to collect all the techniques we use to make websites tor-browser and privacy friendly in a single place. We could also include the reasoning behind doing certain things in pure css vs js. Or why we decide to do things in a certain way.

Some topic that I have been thinking about are:

• Why tor browser is slightly different from Firefox (or another browser)

• Why does my app work differently in tor browser?

• How can I make my app compatible for people that do not use JS?

• Code examples for css and js

• Server side website programming, what to keep in mind...

While all these topics are documented in various articles around the interwebs, I kinda think we (tor community) should own something like this, since it would also help to push forward the idea that the web as we know it needs to change.

Up to now I have always thought this sort of content belonged to the styleguide. Recently I have been thinking that while the individual implementation details of what use in our websites can be included in the styleguide, the reasoning behind those and the general implementations should be put somewhere else.

Also I do not think these topics belong directly to the dev portal, as I tend to think that should be about developing on tor rather than considering how the web works a bit differently when using tor browser. Unless we would rather do a specific section regarding all this in the web portal.

Further things to consider:

• Kevin (on cc) is working on a Tor friendliness scanner tool for websites.
• We see often threads like this [2] on our mailing lists. This one is about how to avoid privacy leaks for onion services, but we might identify more similar best practice tips being discussed.

[1] ​https://developer.mozilla.org/en-US/ [2] ​https://lists.torproject.org/pipermail/tor-onions/2018-August/000295.html

I know this is basically just Debian instructions, but framing this differently could really help for those that don't already know that Raspbian is essentially just Debian underneath.

This could be deferred until after the big website changes.

We have been using Nagios to monitor Onionoo for a few years now, and we recently extended (#28242) or added new Nagios checks (#28271).

We should consider adding even more checks. One year ago we ​discussed what checks that could be, and it seems like this list could still serve as starting point for adding new checks now.

The ultimate direction we want to go is towards an adblock plus model, where people can subscribe to rule feeds that are relevant to them, maintained by third parties. This involves both altering our XML schema to include a 'rulefeed' envelope tag, and adding a bit of UI to add and manage subscription urls.

It also depends upon a few enhancements being completed first. These are in the child ticket list below:

A user (DEplan on #guardianproject) reported that Gibberbot was using his real IP despite Orbot's transproxy being turned on; further research led to the conclusion that recent releases of Android seem to use IPv4-mapped IPv6 adresses for a large portion of connections. For examples, please see ​http://pastebin.com/Z4KDDq40. These connections completely bypass transproxy.

I am not yet sure about the circumstances under which Android employs these addresses.

The problems in finding a solution are that Android usually does not include ip6tables (though Orbot could simply package that) and kernels do usually not include IPv6 netfilter modules. The latter is a major issue, since Orbot can't package modules for every single kernel a user might be running.

As a side note, IPv6 does not support NAT (which is what transproxying is based on).

I'll try to figure out what triggers this behaviour of Android and find possible solutions (using sysctl to disable IPv6 does not solve it).

Behaviour: When closing tor network with big Button and exiting Orbot after tor is "deactivated", privoxy is still running and the Orbot service is not stopped.

Actions:

• Killing Privoxy from shell stops the privoxy process (OK)
• Killing Orbot process simply restarts the process (BAD)

Env:

• Running Orbot v1.0.4.1
• Android Froyo 2.2.1 speedmod kernel
• Samsung Galaxy

I'm using Orbot (v0.2.3.10-alpha-1.0.7-FINAL, on Android ICS v4.0.1) and I can't seem to get the exit node I request. In the Exit and Entrance Node fields I have "{us}" entered, yet sometimes I get IP's outside the US. Yesterday I got a UK ip.

Also, at random (usually after 30 minutes or so) I seem to lose connection to the Tor network without Orbot notifying me. I'm using Pandora from Canada.

Our existing OOS code kills low-priority OR connections. But really, we need to look at all connections that an adversary might be able to create (especially dir and exit connections), or else an adversary will be able to open a bunch of those, and force us to kill as many OR connections as they want.

This problem is the reason that DisableOOSCheck is now on-by-default.

It would be handy if the following roles were split up:

1) The list of IP:Orport:Identity to which every relay should upload every descriptor. 2) The list of IP:Orport:Identity from which caches should expect to find canonical consensuses and descriptors. 3) The list of IP:Orport:Identity from which non-caches should expect to bootstrap consensuses and descriptors. (See 'fallbackdir') 4) The list of keys that must sign a vote or a consensus. 5) The list of IP:Orport:Identity that authorities use when sending and receiving votes.

Splitting roles up in this way would better prepare us for an implementation of prop#257 down the road.

Once upon a time, the tor spec files and proposals were in the Tor tarball, so they clearly were covered under Tor's copyright license (3-clause BSD).

But now they're in their own git repository.

I think maybe they technically have no copyright license now?

We should pick one (I vote cc-by) and try to apply it. This plan could become tricky for proposals, because there are a lot of authors on proposals by now.

Parent ticket for transitioning current and future client versions off the tor network with a minimal amount of pain.

From my prop271 branch:

 * XXXX prop271 this function is used in four ways: picking out guards for
 *   the old (pre-prop271) guard algorithm; picking out guards for circuits;
 *   picking out guards for testing circuits on non-bridgees;
 *   picking out entries when entry guards are disabled.  These options
 *   should be disentangled.

I'm running tor on Gentoo Hardened. The bug exists in 0.2.6.7 and 0.2.7.1-alpha. tor crashes within seconds of starting, before any clients can connect I think.

Jul 14 13:13:07.000 [notice] Tor 0.2.7.1-alpha (git-df76da0f3bfd6897) opening log file.
Jul 14 13:13:07.182 [notice] Tor v0.2.7.1-alpha (git-df76da0f3bfd6897) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1p and Zlib 1.2.8.
Jul 14 13:13:07.182 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 14 13:13:07.182 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jul 14 13:13:07.182 [notice] Read configuration file "/etc/tor/torrc".
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9050
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9056
Jul 14 13:13:07.187 [notice] Opening Socks listener on 127.0.0.1:9055
Jul 14 13:13:07.187 [notice] Opening Control listener on 127.0.0.1:9015
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Jul 14 13:13:07.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Jul 14 13:13:07.000 [notice] Bootstrapped 0%: Starting

============================================================ T= 1436875987
(Sandbox) Caught a bad syscall attempt (syscall socket)
/usr/bin/tor(+0x142148)[0x4bb7bc8148]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(socket+0x7)[0x3adc706ea07]
/lib64/libc.so.6(+0xf16a0)[0x3adc70686a0]
/lib64/libc.so.6(__vsyslog_chk+0x3ef)[0x3adc7068aff]
/lib64/libc.so.6(__syslog_chk+0x89)[0x3adc7068df9]
/usr/bin/tor(+0x135bb0)[0x4bb7bbbbb0]
/usr/bin/tor(tor_log+0xd0)[0x4bb7bbc680]
/usr/bin/tor(control_event_bootstrap+0x1e4)[0x4bb7b7ba74]
/usr/bin/tor(do_main_loop+0x84)[0x4bb7abe234]
/usr/bin/tor(tor_main+0x16c5)[0x4bb7ac1225]
/lib64/libc.so.6(__libc_start_main+0x114)[0x3adc6f97134]
/usr/bin/tor(+0x34519)[0x4bb7aba519]

$ uname -r
3.18.9-hardened

This bug has been reported downstream: ​https://bugs.gentoo.org/show_bug.cgi?id=550302. It occurs with the following torrc:

#
# Minimal torrc so tor will work out of the box
#
User tor
PIDFile /var/run/tor/tor.pid
Log notice syslog
Log notice file /var/log/tor/log
DataDirectory /var/lib/tor/data
SandBox 1

SocksPort 9050
SocksPort 9056 IsolateDestAddr IsolateDestPort
SocksPort 9055

ControlPort 9015
CookieAuthentication 1

By commenting out "Sandbox 1" or unsetting it, tor will obviously run without crashing.

We're creating a vote that is invalid, but try to make a consensus anyway like nothing's wrong. Then we fail doing that as described above.

The following bug warnings should probably be protocol warnings, or be caught earlier:

./src/test/fuzz_static_testcases.sh
Running tests for consensus
Feb 16 02:17:26.012 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:30.133 [warn] sr_parse_commit: Bug: SR: Commit algorithm "sha6-256" is not recognized. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:34.625 [warn] commit_decode: Bug: SR: Commit from authority 20EE989200EF98A75102B461DF62F01B2932C0D6 decoded length doesn't match the expected length (36 vs 40). (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Feb 16 02:17:40.758 [warn] commit_decode: Bug: SR: Commit from authority B0F141F4B8CCBCC328572C71E5590BBA19775594 can't be decoded. (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for descriptor
Feb 16 02:18:08.780 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
Running tests for extrainfo
Feb 16 02:18:18.548 [warn] tor_timegm: Bug: Out-of-range argument to tor_timegm (on Tor 0.3.0.3-alpha-dev d633c4757c1392fb)
...

I'm not sure whether we need this in 030, but it would be nice to fix them eventually.

I have a bridge in my recent Tor (post prop#271), and my state file now says:

Guard in=bridges rsa_id=C7BE8154678E7537CCAC60B097D51A8A7EF8BCDF bridge_addr=94.242.249.2:94 sampled_on=2017-05-04T10:39:09 sampled_by=0.3.1.0-alpha-dev unlisted_since=2017-05-11T05:47:41 listed=0 confirmed_on=2017-05-02T01:15:03 confirmed_idx=0 pb_use_attempts=1.000000 pb_use_successes=1.000000 pb_circ_attempts=11.000000 pb_circ_successes=11.000000 pb_successful_circuits_closed=11.000000

The unlisted_since and listed=0 are not surprising, since bridges will never be listed, right? Does that make my Tor do anything I shouldn't want it to do, like throw out the bridge line sooner than I'd want? I think no, because hey if it's in torrc it'll go back in, but maybe throwing out the path bias info early was not what we expect?

When upgrading Briar's Tor binaries from 0.2.9.16 to 0.3.4.8, we noticed a difference in Tor's startup time on older Android phones.

Measuring the startup time of several recent Tor versions revealed an interesting pattern. The time that elapses between starting the Tor process and the creation of the authentication cookie file hasn't changed across versions, but the time between the creation of the cookie file and the response to the AUTHENTICATE command has changed substantially. (Briar sends the AUTHENTICATE command as soon as the cookie file's created.)

I measured five runs of each version on a Motorola Moto G 4G running Android 5.1. Here are the min and max times in seconds for each version:

The min and max have both increased substantially since 0.2.9, and the distribution has widened. This is having a noticeable impact on how long it takes for Briar to connect to contacts when the app's started.

I'll repeat these experiments on Linux x64 to see whether this is Android-specific.

In 0.3.5? we ran a script to automatically add comments to #else and #endif blocks. These comments help us work out how these macros are nested.

But since then, we've added new #else and #endif without the comments.

Should we run the script again in 0.4.1? Should we run it before we branch off each new maint branch? Should we automatically run it before we commit or merge?

I hope nickm has some good feedback on this idea.

By Nov 2016, we have a deliverable to get our route selection much more right than today, and to have it very tested. We should get this done significantly earlier.

https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/SecurityPolicy

In #22948, we discovered that the relay integrity digest was easier to guess than it should be. This makes the following classes of attacks easier:

• sending bandwidth and guessing the integrity digest, and
• modifying cells and manipulating the integrity digest.

Similar to #21449, when we compare versions, we compare the status before the patchlevel, and then compare status tag and SCM information.

But the spec says:

1. The Old Way
...
We compare the elements in order (major, minor, micro, status, patchlevel, cvs)
...
2. The New Way
...
MAJOR, MINOR, MICRO, and PATCHLEVEL are numbers
...
All versions should be distinguishable purely by those four numbers.

The STATUS_TAG is purely informational
...
If we *do* encounter two versions that differ only by status tag, we compare them lexically
...

This doesn't matter much at the moment because we don't use patchlevels.

But we should fix this issue, probably by modifying the spec.

Reported by arma.

We have instructions for releasing tor: ​https://gitweb.torproject.org/tor.git/tree/doc/HACKING/ReleasingTor.md

But we don't have any instructions for deprecating tor.

As far as I can tell, Firefox produces mixed-content warnings on an https page that references resources (images, scripts, etc) via http, even if HTTPS Everywhere can rewrite all of those http URLs to use https. (HTTPS Everywhere does rewrite resource requests, right?)

Ideally, if HTTPS Everywhere successfully rewrites every http request from a page to an https request, the page should not generate a mixed content warning. (Though I'd still like to see some indication that the page was only secure due to HTTPS Everywhere, so I know to report the insecure resources to the site owner.)

When you drag the httpse icon from the urlbar to 'menu_bar.view.toolbars.customize' window you lose the 'menu_bar.tools.https_everywhere' drop down menu content for httpse, though the menu item itself is still there. At that point, the only way to configure httpse is via 'about:addons'. Or of course to restore the icon to the urlbar.

Seems to me the drop down menu content should remain regardless of where the icon is, or is not.

FF 10.0.3 ESR HTTPS-E v2.1