Opened 7 years ago
Closed 2 years ago
#1212 closed defect (fixed)
Transport-layer replay prevention
Reported by: | zzz | Owned by: | zzz |
---|---|---|---|
Priority: | minor | Milestone: | 0.9.37 |
Component: | router/transport | Version: | 0.9.11 |
Keywords: | security ntcp ssu docs | Cc: | orignal |
Parent Tickets: | #2199 | Sensitive: | no |
Description
ref:
http://i2p-projekt.i2p/en/docs/transport/ssu
http://i2p-projekt.i2p/en/docs/transport/ntcp
http://zzz.i2p/topics/1577
Replay prevention is particularly important for what Tor calls "probing resistance", where the GFW follows up a connection attempt with one of its own. Also just to prevent other trouble.
NTCP spec doesn't mention it at all.
SSU spec claims we have a bloom filter of IVs but I can find no such code. The only thing I find is a bloom filter (actually hash set) of message IDs, i.e. only for data packets, and since the message ID is the I2NP message ID, doesn't that duplicate the I2NP bloom filter in the router anyway?
Most important is the first packet (called "Session Request" in both protocols). Nothing in the router's I2NP bloom filter will help us here.
To be effective, need either a DecayingHashSet? or a LHMCache. And need to enforce the timestamps beyond the lifetime of the cache or set. Sadly, there's no timestamp in the SessionRequest? in either protocol.
Some of this can't be fixed until NTCP2 but we could implement basic protections now.
Right?
Subtickets
Change History (9)
comment:1 Changed 7 years ago by
Status: | new → accepted |
---|
comment:2 Changed 7 years ago by
NTCP fix for SessionRequest? in 0.9.11-12 76527a672bbf614292c87b4ce89635c0085b04e4
comment:3 Changed 7 years ago by
<zzz> to do it completely right you need a timestamp in the same packet as X… which we don't have in either protocol now.
comment:5 Changed 7 years ago by
Cc: | orignal added |
---|
The implemented changes are not yet documented.
In addition, the Bloom Filter section in SSU has not yet been fixed.
In addition, Message Header section of http://i2p-projekt.i2p/en/docs/spec/ssu does not make clear that retransmissions get a new IV too.
comment:6 Changed 6 years ago by
Keywords: | security ntcp ssu docs added |
---|---|
Milestone: | 0.9.15 |
comment:7 Changed 6 years ago by
<orignal> no reason for NTCP
<orignal> because next message always depends on previous
comment:8 Changed 3 years ago by
Parent Tickets: | → 2199 |
---|
comment:9 Changed 2 years ago by
Milestone: | → 0.9.37 |
---|---|
Resolution: | → fixed |
Status: | accepted → closed |
Testing a NTCP fix using DecayingHashSet? on HXxorHI