[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #11100 [Obfsproxy]: ScrambleSuit session ticket handshake failures
#11100: ScrambleSuit session ticket handshake failures
-----------------------------------------+---------------------
Reporter: yawning | Owner: phw
Type: defect | Status: new
Priority: normal | Milestone:
Component: Obfsproxy | Version:
Keywords: ScrambleSuit, SessionTicket | Actual Points:
Parent ID: | Points:
-----------------------------------------+---------------------
At first I thought this was an obfsclient problem, but I can get the same
behaviour to happen with obfsproxy.
How to reproduce:
1. Do a UniformDH handshake to obtain a session ticket.
2. Kill tor/obfsproxy
3. Wait 30 mins
4. Try to connect (SessionTicket will be used)
5. The session ticket handshake fails.
Looking at the obfsproxy logs (with the debug level), it is pulling the
previously saved ticket from disk and sending a handshake message after
doing deriving all the keys.
The only "real" bridge I tested against was the one that phw runs
(identifies itself as ScrambleSuit0) that was posted to tor-talk back in
October, since I'm not sufficiently human to solve the BridgeDB captcha,
so this may be a issue with the version of the code that's running on the
bridge, and not something that I will run into in the wild.
When I run a local bridge, I can't reproduce this behaviour either.
(On a side note, obfsproxy does not appear to implement a timeout, it
takes 5 mins for tor to give up, and tor does not appear to retry when a
UniformDH handshake would succeed. From a user's perspective, the UX
isn't great if their ticket happens to expire.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/11100>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs