[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #33650 [Core Tor/Tor]: Verify that intro2 cell extensions actually work
#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@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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs