[tor-bugs] #33650 [Core Tor/Tor]: Verify that intro2 cell extensions actually work

[Tor Bug Tracker & Wiki]

#33650: Verify that intro2 cell extensions actually work
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:
                                                 |  mikeperry
     Type:  task                                 |         Status:
                                                 |  accepted
 Priority:  Medium                               |      Milestone:
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-dos tor-dos-2020 anonymous-      |  Actual Points:
  credentials research                           |
Parent ID:  #33703                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 I dug pretty deep into the INTRO1/INTRO2 free bytes test. Turns out there
 is a layer of padding that tries to keep the pre-mac intro cell at least
 HS_CELL_INTRODUCE1_MIN_SIZE (246), as well as some optional things that
 are not always present. This tends to add about 100 bytes, give or take,
 of semi-unused slack space.

 In the unit tests, I was able to get 287 additional bytes into an INTRO1,
 and have it parse correctly, before hitting any asserts or errors.

 In the live network, I had to disable sending ipv6 addresses of rend
 points in order to get close to this. But the good news is that
 `hs_get_extend_info_from_lspecs()` on the service side currently ignores
 all link specs other than ipv4, legacy rsa, and ed25519 (which are all
 required). So if the DoS/PoW defense is enabled, we can safely disable
 sending IPv6 RPs and no one will notice.

 With IPv6 link spec sending disabled, I was able to get 253 bytes in
 either the unencrypted or encrypted sections. If I added more fields of
 extensions, that byte count went down. For example, if I used 10 fields in
 an extension, I was only able to send 217 bytes (because of  the nine
 additional type and length specifiers). If I added a single encrypted
 extension field, and a single unencrypted extension field, I was able to
 fit 124 bytes in each extension (for 248 bytes total).

 So we have more room here than 188 bytes. If we trim more unused fields,
 we might be able to slim it down even more?

 See https://github.com/mikeperry-tor/tor/commits/ticket33650-intro-
 smuggle-test for working code.

 No intropoints were harmed in this test. Everything seemed to work fine.

 Are we satisfied with this analysis? Can we close this ticket? Should I
 report to tor-dev at lists?

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