I propose a backward-compatible change to the Tor connection
establishment protocol to avoid the use of TLS
renegotiation.
Rather than doing a TLS renegotiation to exchange
certificates and authenticate the original handshake, this
proposal takes an approach similar to Steven Murdoch's
proposal 124, and uses Tor cells to authenticate the
parties' identities once the initial TLS handshake is
finished.
Fix statistics on client numbers by country as seen by bridges that were
broken in 0.2.2.1-alpha. Also switch to reporting full 24-hour intervals
instead of variable 12-to-48-hour intervals.
The old flavored consensus URL format made it harder to decode URLs
based on their prefixes, and didn't take into account our "only give
it to me if it's signed by enough authorities" stuff.
The point of doing SHA256 twice is, generally, is to prevent message
extension attacks where an attacker who knows H(A) can calculate
H(A|B). But for attaching a signature to a document, the attacker
already _knows_ A, so trying to keep them from calculating H(A|B) is
pointless.
"neonomad" pointed out on or-talk that the order is opposite from the
intuitive order. explain why. we chose to fix the spec rather than the
code because there are controllers like torflow that already expect
the current behavior.
A) We were considering a circuit had timed out in the special cases
where we close rendezvous circuits because the final rendezvous
circuit couldn't be built in time.
B) We were looking at the wrong timestamp_created when considering
a timeout.
This code adds a new field to vote on: "params". It consists of a list of
sorted key=int pairs. The output is computed as the median of all the
integers for any key on which anybody voted.
Improved with input from Roger.
Add a "getinfo status/accepted-server-descriptor" controller
command, which is the recommended way for controllers to learn
whether our server descriptor has been successfully received by at
least on directory authority. Un-recommend good-server-descriptor
getinfo and status events until we have a better design for them.
We were triggering a CLOCK_SKEW controller status event whenever
we connect via the v2 connection protocol to any relay that has
a wrong clock. Instead, we should only inform the controller when
it's a trusted authority that claims our clock is wrong. Bugfix
on 0.2.0.20-rc; starts to fix bug 1074. Reported by SwissTorExit.
Specifically, admit that the "newconsensus" event exists, and
status/reachability has secretly been status/reachability-succeeded
all along, but nobody used it so we didn't notice.
This just got a little complicated, since old clients use "clipped
advertised bandwith" and new clients now use "consensus bandwidth" but
fall back to "clipped advertised bandwidth".
