Opened 8 years ago

Last modified 13 months ago

#1038 closed defect (Fixed)

Problem facing connecting a Tor client to a Tor hidden server

Reported by: sambuddho Owned by:
Priority: High Milestone:
Component: Core Tor/Tor Version: 0.2.1.17-rc
Severity: Keywords: 2016-bug-retrospective
Cc: sambuddho, karsten, nickm, Sebastian, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

This is with regards to an email exchange that took place few days back on the or-talk mailing list. The anonymous
client connects to the hidden service quite intermittently . However it does sometimes connects (say in 1 in 20 chances).
The client and server are properly configured using default configuration for the client and configuration for the server
which indicates the appropriate directory where the server stores the appropriate files and the appropriate hidden service port
number where service requests are to be directed. I am sure of it since I the client works fine otherwise (when not connecting
anonymously to a non-anonymous service) and so does the server (when being used as a client). Only in some instances is the
client able to communicate with the hidden service (as mentioned earlier).

This is what Roger Dingledine has to say regarding the issue :

"
I think there's a real bug here. I've been playing with it on and off. I
think that when Tor has a rendezvous circuit that it thinks it should
like, and suddenly changes its mind, then it discards that circuit and
starts working on a new one (which is good), but at the same time it
closes the socks stream (which is bad).

Fixing that bug, if it turns out to actually be a bug, would mean that
hidden services are dirt slow when making the initial connection (until
we make Tor itself faster at least), but they're not as flaky as they
currently appear.

--Roger
"

I can send the notices.log and debug.log files from both the client and the hidden service to you as and when needed . They

are too big to fit in here . Let me know if it is needed , and I can send to you those files to appropriate email ids where

you would like them .

Thanks
Sambuddho

[Automatically added by flyspray2trac: Operating System: Other Linux]

Child Tickets

Attachments (2)

how-to-report-inbound-relay-early-cells-01.patch (637 bytes) - added by mttp 3 years ago.
how-to-report-inbound-relay-early-cells-02.patch (336 bytes) - added by mttp 3 years ago.

Download all attachments as: .zip

Change History (21)

comment:1 Changed 8 years ago by karsten

Hi Sambuddho,

the log files might be helpful, but info level should be enough. Can you
make info-level logs from your debug logs, for example with this command:

grep -v " \[debug\] " debug.log > info.log

You might also be able to remove all logs outside a, say, 10-minute
interval around your failed request.

Thanks!
--Karsten

comment:3 Changed 8 years ago by Sebastian

[17:00] <optimist> patch for 1038, http://pastebin.com/d7a8ebc5f still need workaround for current versions of rend points

comment:4 Changed 8 years ago by Noino

Someone had to note : this bug is still present in 0.2.1.18 so-called "stable" release :=(

Contacting hidden services fails 9 times out of 10 (roughly).
Reverting to 0.2.0.35 instantly cured the issue.

It is difficult to overestimate the damage which imprudently releasing that as a stable version will have done;
suggest remove 0.2.1.18 from the main (stable) download page ASAP or even sooner !

comment:5 Changed 8 years ago by Sebastian

No Name: Mistakes happen, had we known about where the hidden service
connection problems come from (by opening a bug report on the matter, for
example), we could have fixed it in the alpha before releasing 0.2.1.18.

Unfortunately, hidden services weren't a top priority, so the occasional
problems were left for later to figure out. It seems that the bug is related
to the number of people running the 0.2.1.x series, so the problem was
difficult to notice when the bug was introduced

comment:6 Changed 8 years ago by arma

I think I fixed it with 2b63fa40e8349e0 (which will be part of 0.2.1.19).

comment:7 Changed 8 years ago by nickm

00:42 < optimist> I want to explain about "if a 0.2.0.x relay was the middle

hop, stuff worked". stuff is explanation from

http://kpvz7ki2v5agwt35.onion/wiki/index.php/Hidden_service_bugs Else they

can't catch these relay_early by HS.

00:49 < optimist> and 0.2.0.x do not downgrade it to cell_relay however. it's

passes it too, it's danger because information leaks.

comment:8 Changed 8 years ago by arma

For posterity, here's my commit message:

The problem is that clients and hidden services are receiving
relay_early cells, and they tear down the circuit.

Hack #1 is for rendezvous points to rewrite relay_early cells to
relay cells. That way there are never any incoming relay_early cells.

Hack #2 is for clients and hidden services to never send a relay_early
cell on an established rendezvous circuit. That works around rendezvous
points that haven't upgraded yet.

Hack #3 is for clients and hidden services to not tear down the circuit
when they receive an inbound relay_early cell. We already refuse extend
cells at clients.

comment:9 follow-up: Changed 8 years ago by arma

There are a variety of partitioning attacks still possible from my patch.

They have to do with sending a relay_early cell and learning about the path
(and the Tor on the other end) from whether it gets through and the client
tears down the circuit.

Hack #1 should stay in; it doesn't hurt anything.

Hack #3 could stay in too, at least until somebody points out why it could
be dangerous to hear an inbound relay_early cell.

Eventually we should take hack #2 out, since currently relays can guess
whether this is a rendezvous point you're establishing based on whether
you stop using relay_early cells before you're at your quota. The
next steps are to 1) have Tor resume sending relay_early cells if
the rendezvous point that's picked is running 0.2.1.19 or later, and
eventually 2) have Tor clients prefer rendezvous points running 0.2.1.19
or later.

comment:10 Changed 8 years ago by arma

Ok. I changed the comments in the code.

Hack #3 is here to stay.

I changed the comment around Hack #2 to say "once 0.2.1.18 isn't used by
relays (and thus not by rendezvous points), we can take it out".

I'm going to close the bug.

comment:11 Changed 8 years ago by arma

flyspray2trac: bug closed.
Fixed in 0.2.1.19

comment:12 Changed 5 years ago by nickm

  • Component changed from Tor Relay to Tor

comment:13 Changed 3 years ago by arma

  • Cc changed from sambuddho,karsten,nickm,Sebastian,arma to sambuddho, karsten, nickm, Sebastian, arma
  • Description modified (diff)

In Tor 0.2.4.23 and 0.2.5.6-alpha, we removed hack #3, because it does turn out to be harmful:
https://blog.torproject.org/blog/tor-security-advisory-relay-early-traffic-confirmation-attack
and because the buggy relays are long gone from the network.

comment:14 Changed 3 years ago by mttp

The log warning message should probably indicate where clients should send reports of inbound relay early cells. I'm hoping the attached patches will help direct those reports to the correct channels.

comment:15 in reply to: ↑ 9 Changed 3 years ago by cypherpunks

Replying to arma:

[...]
Eventually we should take hack #2 out, since currently relays can guess
whether this is a rendezvous point you're establishing based on whether
you stop using relay_early cells before you're at your quota.

Is hack #2 still in? Isn't it actually the case that with or without it, rendezvous circuits are actually identifiable by all involved relays? Either you have some relay_early cells traveling backwards or you don't have enough traveling forward.

comment:16 Changed 3 years ago by cypherpunks

(by "identifiable" I mean "able to be identified as rendezvous circuits")

comment:17 Changed 13 months ago by nickm

  • Keywords 2016-bug-retrospective added

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

comment:18 Changed 13 months ago by nickm

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

comment:19 Changed 13 months ago by nickm

Mark bugs for 2016 bug retrospective based on hand-examination of changelogs for 0.2.5 onwards.

Note: See TracTickets for help on using tickets.