[tor-bugs] #13667 [Tor]: Prevent port scanning of hidden services

[Tor Bug Tracker & Wiki]

#13667: Prevent port scanning of hidden services
------------------------+------------------------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  major   |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  SponsorR tor-hs 025-backport
Actual Points:          |  Parent ID:
       Points:          |
------------------------+------------------------------------------

Comment (by yawning):

 Replying to [comment:8 dgoulet]:
 > It seems clear here that we can't stop a network scan to finally succeed
 whatever behavior so our best course of actions is to slow down and made
 it as hard as we can for the attacker to scan.

 Indeed.

 > Option '5' scares me a bit in terms of added overhead. Seems like adding
 delay to the bad circuit opens the door to some DoS for which an attacker
 could just open 65534 circuits to the HS with the wrong port and those
 circuits would stay open for an unknown amount of time?... If that would
 be acceptable for some reasons, adding a random delay before sending back
 the reason will also slow down quite a bit the scanner :).

 Yeah, I suggested doing that on the assumption (possibly wrong) that once
 established, keeping circuits around has minimal overhead.  Establishing
 them is not cheap (because crypto), but keeping them around doesn't
 involve work right?

 Right the idea is to try to get them to waste as much time as possible by
 adding randomized delay before the reason (and allowing the attacker to
 send a few cells of payload, once few is reached will also trigger sending
 REASON_DONE).

 The 2nd part of 5 involves not dropping the circuit.  Since we know
 they're up to no good, and have a way to waste their time and feed back
 garbage data into the scanner, we let the attacker "open" as many streams
 as they want using the known "eeevill" circuit, only to delay then close
 the stream down.  (So say, someone starts scanning a HS that only is
 running httpd on a standard port, when their scanner gets to 80, it gets
 the "fake" discard+close behavior.).

 We could add a maximum lifetime to evil portscanning circuits (based on
 number of stream open attempts and time), but all of this may be more
 effort than it's worth.

 > I would go for sending back END_STREAM_REASON_DONE (application closed
 the connection) and DROP the circuit after.

 If doing the full blown "pretend we are there even accepting payload and
 injecting delay" is too expensive, this seems like the best lightweight
 alternative.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13667#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online