Opened 5 years ago

Closed 5 years ago

#11100 closed defect (fixed)

ScrambleSuit session ticket handshake failures

Reported by: yawning Owned by: phw
Priority: Medium Milestone:
Component: Obfuscation/Obfsproxy Version:
Severity: Keywords: ScrambleSuit, SessionTicket
Cc: asn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


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.)

Child Tickets

Attachments (1)

0001-Update-the-keyCreation-time-on-rotation.patch (970 bytes) - added by yawning 5 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 5 years ago by yawning

Got another bridge to test with, and I can consistently reproduce this, so it's not bridge specific.

2014-03-01 08:21:24,944 [DEBUG] Message header: totalLen=144, payloadLen=144, flags=NEW_TICKET
2014-03-01 08:21:24,944 [DEBUG] Storing newly received ticket in `/home/yawning/.tor/pt_state/scramblesuit/session_ticket.yaml'.

[I close after bootstrapping, and go read for a while, come back some time later.]

2014-03-01 09:19:58,402 [DEBUG] Attempting to read master key and ticket from file `/home/yawning/.tor/pt_state/scramblesuit/session_ticket.yaml'.
2014-03-01 09:19:58,402 [DEBUG] Opening `/home/yawning/.tor/pt_state/scramblesuit/session_ticket.yaml' for reading.
2014-03-01 09:19:58,405 [DEBUG] Deleting ticket since it is about to be redeemed.
2014-03-01 09:19:58,405 [DEBUG] Opening `/home/yawning/.tor/pt_state/scramblesuit/session_ticket.yaml' for writing.
2014-03-01 09:19:58,405 [DEBUG] Redeeming stored session ticket.

[snip, Session key derivation is uninteresting]

2014-03-01 09:19:58,406 [DEBUG] Switching to state ST_CONNECTED.
2014-03-01 09:19:58,406 [DEBUG] Send buffer is empty; nothing to flush.
2014-03-01 09:19:58,406 [DEBUG] circ_0x2491c20: upstream: Received 265 bytes.
2014-03-01 09:19:58,406 [DEBUG] Processing 265 bytes of outgoing data.
2014-03-01 09:19:58,407 [DEBUG] Created 1 protocol messages.
2014-03-01 09:19:58,407 [DEBUG] Morphing the last 286-byte packet to 279 bytes by adding 1441 bytes of padding.
2014-03-01 09:19:58,416 [DEBUG] socks_down_0x248cf10: Received 0 bytes.
2014-03-01 09:19:58,417 [DEBUG] circ_0x2491c20: downstream: Received 0 bytes.

[Tor gives up]

Mar 01 09:19:58.000 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Mar 01 09:24:58.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 1; recommendation warn)
Mar 01 09:24:58.000 [warn] 1 connections have failed:
Mar 01 09:24:58.000 [warn]  1 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE

I'll keep trying to reproduce it locally.

comment:2 Changed 5 years ago by yawning

Status: newneeds_review

Ok, that's why this happens. The key creation date isn't actually getting updated so any bridge currently that hits the regeneration interval will rotate the Session Ticket keys on every single attempted handshake.

I was failing to reproduce this locally since my test bridge was never running for long enough to trigger this case.

This along with #11092 justifies a mandatory update of every single ScrambleSuit bridge out there, because "the first Session Ticket Handshake will fail after 5 mins" if the bridge has an uptime > 1 week is unacceptable.

comment:3 Changed 5 years ago by yawning

Cc: asn added

comment:4 Changed 5 years ago by phw

Resolution: fixed
Status: needs_reviewclosed

Fixed in 58797369410cf0b941c38e4eeb2cfd3ac8e82129, thanks. Next time, please write the patch for the ScrambleSuit rather than the obfsproxy repository.

comment:5 Changed 5 years ago by asn

Resolution: fixed
Status: closedreopened

Ehm, I will need an obfsproxy branch to apply this.

Or should I try to apply the scramblesuit commit?

comment:6 in reply to:  5 Changed 5 years ago by phw

Replying to asn:

Ehm, I will need an obfsproxy branch to apply this.

Or should I try to apply the scramblesuit commit?

My plan was to write the next obfsproxy patch once we are done fixing all the ScrambleSuit bugs. In general, the current process is awful and should probably be improved. For example, a clone of obfsproxy does not contain ScrambleSuit's git history. As a result, ScrambleSuit improvements also don't end up on tor-commits (which was pointed out by arma). Anyway, that should probably be addressed in a different ticket.

comment:7 Changed 5 years ago by asn

Resolution: fixed
Status: reopenedclosed

Closing this ticket since it was merged and released in obfsproxy-0.2.7.

thanks everyone

Note: See TracTickets for help on using tickets.