Re: [tor-bugs] #3460 [Tor Hidden Services]: Replay-detection window for HS INTRODUCE2 cells causes HS reachability failures

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#3460: Replay-detection window for HS INTRODUCE2 cells causes HS reachability
failures
---------------------------------+------------------------------------------
 Reporter:  rransom              |          Owner:  rransom           
     Type:  task                 |         Status:  needs_review      
 Priority:  normal               |      Milestone:  Tor: 0.2.2.x-final
Component:  Tor Hidden Services  |        Version:                    
 Keywords:                       |         Parent:                    
   Points:                       |   Actualpoints:                    
---------------------------------+------------------------------------------

Comment(by rransom):

 Replying to [comment:4 nickm]:
 > Okay, I've got some obvious stuff to sort out in my head before I can
 review this.

 The âservice keyâ is the only long-term identifier of a hidden service.
 In the v2 hidden-service directory protocol, the service key is only used
 to sign HS descriptors.

 The âintroduction keysâ (one for each introduction point) are ephemeral
 keys.  We generate a new introduction key when we launch the introduction-
 point circuit we will use it on; this causes #1307.


 > Stupid questions: What if, after we replace an intro point, we
 accidentally pick the same intro point later on?  What if we stop, then
 restart and pick the same intro point?

 If we generate the same introduction key twice, we're ''way'' more screwed
 than having insufficient replay detection for INTRODUCE cells.  If we
 don't generate the same intro key twice, no one will be able to link the
 old one to the new one (except possibly by sending the same DH public key
 in an INTRODUCE cell to both), even if we pick the same relay.

 (An introduction point is identified at the intro-point relay only by its
 introduction key, not its service key.)

 > Is it just service key rotation that keeps this safe?

 Introduction key rotation keeps this safe.

 > (And am I right in thinking that everybody uses the introduce format
 that include service keys?)

 We don't seem to have an INTRODUCE cell format that includes an identifier
 of the service key (unless an introduction point was created for use in
 the v0 HS directory protocol).  In the current protocols, INTRODUCE cells
 only contain a digest of the introduction key, and it is sent as plaintext
 so that the intro-point relay can route the cell to the correct intro
 point.


 > Also, it seems that this approach has a nasty possibility where I "just"
 make 16K bogus introduce attempts -- I don't need to even do a `g^x`; I
 only need to do the public RSA -- and make you choose a different intro
 point.  Probably I could keep doing this until you're using an intro point
 I like.  Not a terribly cheap attack, but could be worth analyzing.

 It sounds bad -- it could at least censor a service until its intro circs
 die of old age -- but flooding the intro-point relays with CREATE cells
 unrelated to the HS does that too, and is almost as easy.

 Also, one thing I want to achieve (later, not in this branch) partly by
 expiring circuits is to spread the circuit-extension load of a popular HS
 over multiple intro points.  This will involve creating many more intro
 points if a service appears to be popular.  I'm hoping to be able to do
 this by building multiple new intro points when an intro point expires due
 to overuse (with the number of new intro points depending on how early the
 circuit expired).  That and the fact that HSes never put multiple intro
 points on the same relay should make flooding with INTRODUCE2 cells not a
 useful attack.

 > Maybe the right answer is to change only the service key, but keep the
 same introduction points until you would otherwise rotate them?

 You should mean âintroduction keyâ here, because we can't change the
 âservice keyâ for a hidden service.

 I don't think we can reuse a service-side intro-point circuit for any
 other purpose (even as an intro-point circuit with a different
 introduction key) once we have sent the ESTABLISH_INTRODUCE cell.


 > Here's another dumb question: Why take this approach rather than, say,
 just incrementing the window from 30 minutes to 12 hours?

 Merely increasing the replay-detection window increases RAM consumption on
 the HS.  Increasing the window to 12 hours would mean that we keep some
 cells in the replay cache for 24 hours.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3460#comment:5>
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