[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Delivery Status Notification (Delay)



This is an automatically generated Delivery Status Notification.

THIS IS A WARNING MESSAGE ONLY.

YOU DO NOT NEED TO RESEND YOUR MESSAGE.

Delivery to the following recipients has been delayed.

       SKelley@xxxxxxxxxxx



Reporting-MTA: dns;mail.tecedge.net
Received-From-MTA: dns;spammotel.com
Arrival-Date: Thu, 17 Jul 2008 08:56:01 -0400

Final-Recipient: rfc822;SKelley@tecedge.net
Action: delayed
Status: 4.4.7
Will-Retry-Until: Sat, 19 Jul 2008 08:56:01 -0400
X-Display-Name: Stephen Kelley

--- Begin Message ---
At first sight this appears to be an exit node problem but then, as I
read it, you say it occurs with more than one exit node and only at this
"higher" level of throughput.

I can repeat this problem (I could do it yesterday) by opening large amount of circuits between my computer and another exit nodes. Currently, I dont know, if take care, that I connected to many different exit nodes.

Alarm bells are ringing ... to mix streams up like this then streams at
the "higher" throughput would have to be unencrypted clear streams - yes?

I dont think so. I think it is problem on exit node, when he mix together two requests (or say better -responses), then encrypt them and send to clients.

It really looks like normal buffer overflow problem - I can see another responses, which are pending on exit node, but not for me.
 
This would mean that either all tor exits are vulnerable and are mixing
the streams. Or that traffic is being passed wholesale *-unencrypted-*
between nodes (so that nodes other than the exit nodes are doing the
mixing).

I dont think so, as I wrote above.

Sh*ttt.. whatever.. this is a major BUG.

Yes, it is. The worst is, that you dont need anything special to simulate this problem. What you need is two years old notebook and 256kbit upload on internet connection (my case).

Regards,
Marek


--- End Message ---