Mike Perry mikeperry@torproject.org writes:
Mike Perry:
Heyo.
We're going to have a meeting to discuss Proposal 291. See this thread: https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html
Ok, we had this meeting. High level (ammended) action items are:
- Use patches in https://trac.torproject.org/projects/tor/ticket/25843 to set NumEntryGuards=2 in torrc, and observe results. Please join us! Stuff we are looking for during testing is on that ticket!
- Merge that patch to make the torrc guard options do what we meant for them to do. Probably backport it.
- Descibe adversary models for our variant proposals from the notes. (Why do we disagree? In Mike's case, my disagreements are because I think each step is an improvement over previous/status quo -- we can decide harder things later and still do better both now and later.)
- Agree on an order of operations for fixes+changes, ideally such that we don't block forever trying to come up with a perfect solution. Things are pretty bad now. All we really need to do is agree on steps to make it better.
<snip>
Concrete things we can do now: #1: ourselves set those guard params to 2 and find bugs. once #3 below is done, encourage others, like on tor-talk, to do it too. #2: enumerate the current situations where we use a guard other than our first guard, especially noting the ones where the attacker can make us use a guard other than our first guard. fix as many as we want to fix. maybe categorize by whether they cause us to mark our first guard as down or not.
OK, I did a bit of #2 yesterday as part of an IRC discussion with Mike and Roger. In particular, I attempted to enumerate the places in our codebase where we mark a guard as unreachable and hence skip it for future circuits.
The key functions here are entry_guard_failed() and entry_guard_chan_failed(). These are called in the following places:
1) circuit_build_failed(): We blame the guard if there was an error during path building when we don't have the first hop open on the circuit yet. We don't blame the guard for errors during path selection.
2) connection_dir_request_failed(): We blame the guard if we fail to connect to a dirserver because of network error.
3) connection_or_about_to_close(): We blame the guard when we are closing an OR connection that started at us but never made it to state open. We do this because otherwise we would keep beating our heads against a broken guard.
4) connection_or_client_learned_peer_id(): We blame the guard when we receive the wrong RSA identity key from the guard during the TLS handshake.
The first 3 cases here seem to handle the cases of network errors and unreachable guards. It's interesting how we have to handle this case in three different places. I wonder if we are missing any other places here.
The last case seems to handle the case of network MITM attacks. I don't see anything wrong with that, since encountering an MITM certainly means that something bad is going on, and also an MITM adversary could also cause one of the first 3 cases.