David Goulet [Mon, 5 Jun 2017 15:11:42 +0000 (11:11 -0400)]
TROVE-2017-005: Fix assertion failure in connection_edge_process_relay_cell
On an hidden service rendezvous circuit, a BEGIN_DIR could be sent
(maliciously) which would trigger a tor_assert() because
connection_edge_process_relay_cell() thought that the circuit is an
or_circuit_t but is an origin circuit in reality.
Fixes #22494
Reported-by: Roger Dingledine <arma@torproject.org> Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet [Mon, 5 Jun 2017 13:35:03 +0000 (09:35 -0400)]
TROVE-2017-004: Fix assertion failure in relay_send_end_cell_from_edge_
This fixes an assertion failure in relay_send_end_cell_from_edge_() when an
origin circuit and a cpath_layer = NULL were passed.
A service rendezvous circuit could do such a thing when a malformed BEGIN cell
is received but shouldn't in the first place because the service needs to send
an END cell on the circuit for which it can not do without a cpath_layer.
Fixes #22493
Reported-by: Roger Dingledine <arma@torproject.org> Signed-off-by: David Goulet <dgoulet@torproject.org>
Nick Mathewson [Tue, 6 Jun 2017 15:32:01 +0000 (11:32 -0400)]
Repair the unit test behavior of my fix for 22508.
Apparently, the unit tests relied on being able to make ed->x509
link certs even when they hadn't set any server flags in the
options. So instead of making "client" mean "never generate an
ed->x509 cert", we'll have it mean "it's okay not to generate an
ed->x509 cert".
(Going with a minimal fix here, since this is supposed to be a
stable version.)
Nick Mathewson [Thu, 1 Jun 2017 12:56:10 +0000 (08:56 -0400)]
Repair link_handshake unit tests to mock tor_tls_get_own_cert()
The tests previously assumed that the link handshake code would be
calling get_my_certs() -- when I changed it to call get_own_cert()
instead for the (case 2) 22460 fix, the tests failed, since the tls
connection wasn't really there.
This change makes us start mocking out the tor_tls_get_own_cert()
function too.
It also corrects the behavior of the mock_get_peer_cert() function
-- it should have been returning a newly allocated copy.
Nick Mathewson [Mon, 5 Jun 2017 13:35:55 +0000 (09:35 -0400)]
Make code more clear about own_link_cert safety
It's okay to call add_ed25519_cert with a NULL argument: so,
document that. Also, add a tor_assert_nonfatal() to catch any case
where we have failed to set own_link_cert when conn_in_server_mode.
Nick Mathewson [Thu, 1 Jun 2017 13:26:24 +0000 (09:26 -0400)]
Fix ed25519 link certificate race on tls context rotation
Whenever we rotate our TLS context, we change our Ed25519
Signing->Link certificate. But if we've already started a TLS
connection, then we've already sent the old X509 link certificate,
so the new Ed25519 Signing->Link certificate won't match it.
To fix this, we now store a copy of the Signing->Link certificate
when we initialize the handshake state, and send that certificate
as part of our CERTS cell.
Fixes one case of bug22460; bugfix on 0.3.0.1-alpha.
Nick Mathewson [Wed, 31 May 2017 22:33:38 +0000 (18:33 -0400)]
Bugfix: Regenerate more certificates when appropriate
Previously we could sometimes change our signing key, but not
regenerate the certificates (signing->link and signing->auth) that
were signed with it. Also, we would regularly replace our TLS x.509
link certificate (by rotating our TLS context) but not replace our
signing->link ed25519 certificate. In both cases, the resulting
inconsistency would make other relays reject our link handshakes.
Fixes two cases of bug 22460; bugfix on 0.3.0.1-alpha.
Nick Mathewson [Fri, 26 May 2017 19:45:39 +0000 (15:45 -0400)]
Update the torify.1 manpage
I went into this to fix 6892 and say "we don't do anything for
circuit isolation." But instead I did a fair amount of text-removal
to stop implying that torify does anything more than call torsocks.
projects / thirdparty / tor.git / log
