Make Servers Stop Rejecting Requests #554
Labels
enhancement
New feature or request
Comments
kauri-hero
moved this from 🆕 New
to 🔖 Awaiting Development (Prioritized)
in MASQ Node v2
masqrauder
pushed a commit
to masqrauder/Node
that referenced
this issue
Dec 20, 2024
…me db txn as where we account inward payments (MASQ-Project#350) * MASQ-ProjectGH-554: rough infrastructure for PaymentAdjuster; almost get first round test running * GH-672: simplifying MASQ-ProjectGH-554, let's go on without the Neighborhood involved for the time being * GH-672: PaymentAdjusterMock and the supertrait with ScannerEtensions implemented for a try * GH-672-with-trait-impl-and-generics: perhaps going in the right direction * GH-672-best-methodology-found: implementation works * GH-672: first version of adjustment implemented * GH-672: finished implementing the main test; not refactored yet * GH-672: payment adjuster refactored; tuning logging; but wanna master features that are missing here * GH-672: some logging integrated * GH-672: fine debug log * GH-672: interim commit * GH-672: interim commit * GH-672: another package of big changes (partly-private msgs; payment adjuster) * GH-672: decent debug log for adjusted payables * GH-672: broadening the adjustment capabilities with gas; rough framework * GH-672: savepoint; before experimenting with early gas_limit computation * GH-672: continuing in implementation of the check for gas availability. * GH-672: some renaming and moving files * GH-672: almost completed but there is a cenceptual error; maybe extra tests for BlockchainInterfaceClandestine should be made first * GH-672: last details; adding tests for untested code from BlockchainInterfaceClandestine * GH-672: almost done; some refactoring ahead * GH-672: heading to auto-review * GH-672: auto review findings * GH-672: refactored scan scheduling code * GH-672: fixing issues from the review; save point before the shift of responsibility of the estimated gas limit from BchI to Chain * GH-672: before connecting the early fetched gas price and the actual gas price used for generating hashed transactions * GH-672: logic redesigned + renaming * GH-672: I believe the first review is answered by now * GH-672: almost all the old code updated; will have to implement the transaction fee calculators * GH-672: before serious changes with PayablePaymentsAgent starts * GH-672-with-agent: saving when getting into troubles with testing * GH-672-with-agent: going in a nice direction; interim commit * GH-672-with-agent: approaching the fixture...this might work well; last vexing situations unhandled meaning there are like 8 failing tests at the moment * GH-672-with-agent: could be called roughly complete; will go with refactoring and knocking off some todos left behind me * GH-672-with-agent: interim commit * GH-672-with-agent: hopefully the last changes before a review * GH-672-with-agent: almost all what I found in my auto-review * GH-672-with-agent: refactored the structure of PayablePaymentsSetupMsg * GH-672-with-agent: formatting * GH-672-wa-no-test-hack: recorder can also record and stop the system from PartalEq missing Actor messages; two of four tests repaired * GH-672-wa-no-test-hack: hurrah, managed to get out of the trap with an agent in Actor msgs even without having to implement Debug, PartialEq and Clone a trait object...this is definitely a lighter version * GH-672-wa-no-test-hack: little modifications in comments * GH-672: first batch of fixed items from the review 3 * GH-672: another batch of fixes * GH-672: refactoring some complicated test concepts for actor_system_factory and adding one test for blockchain_bridge of that kind * GH-672: more refactoring and little changes * GH-672: fixing stuff araound blockchain_interface web3 and its initialization * GH-672: savepoint * GH-672: renaming * GH-672: almost all things done; AgentDigest fully in * GH-672: finished last few missing places * GH-672: reworking comments and found a little mistake * GH-672: match stop condition turned into easier one to use * GH-672: protected payables implemented * GH-672: until now the protected payables were implemented badly; improved design * GH-672: compiling, but many failing tests * GH-672: still fixing tests, but a lot of them passing now * GH-672: halting hard with thoughts about implementation of the build_blockcahin_agent_method * GH-672: blockchain interface onward and backwards move; messy rearrangement; wanna make a savepoint before trying cargo fix * GH-672: all tests good; saving before cargo fix * GH-672: roughly ready code; let's review now * GH-672: renaming in accountant folders * GH-672: reverting some renaming in favor of another branch taking care of this * GH-672: interim commit * GH-672: little fixes and adding more in to some null methods with todos * GH-672: polishing; savepoint before moving get_transaction_receipt to plain_rpc * GH-672: improved details * GH-747: mostly complete, one test still left to be done and some ideas about refactoring arose * GH-747: even more tests needed * GH-747: last todo knocked out * GH-747: db connection options for big_int_db_processor simplified * GH-747: better design for 'other_params()' * GH-747: alias types for easier reading * GH-672: mostly done; just a few details left * GH-672: abondoning enhancement of blockchain interface initializer...leaving as it is * GH-672: unnoticable change for the augly low level tests in actor_system_factory * GH-672: blockchain_bridge_shared_test_simplified * GH-672: ready for review 5 * Revert "GH-747: db connection options for big_int_db_processor simplified" This reverts commit e987841. * GH-747: prepared for new big redesign of the test to watch the transaction roll back at panic for a hard error * GH-747: most of this is over me * GH-747: savepoint before trying to mess with lifetimes hard * GH-747: savepoint before trying to mess with lifetimes hard * GH-747: preparing for mocking BigIntProcessor * GH-747: a lot stabilized...refactoring next?? * GH-747: found the right hierarchy in the code (redesigned to be cleaner and robust)... will have to fix a tougher test and figure out what to do with a manual Debug impl * GH-747: renaming * GH-747: hard work on creating a reliable test tool; yet more of the undone left * GH-747: I'm gonna try to make the test tool more of how an unbiased viewer would expect to see it * GH-747: tools enhanced and some little debrits cleaned up * GH-747: small corrections in text * GH-747-experiment-start-block: before trying to do 'impossible' * GH-672: interim commit * GH-672: finished review 5 * GH-672: review 6 answered * GH-672: fixes in multinode tests * GH-672: little cosmetics * GH-747-experiment-start-block * GH-747-experiment-start-block: interim commit * GH-747-experiment-start-block: since now prepared for all sorts of testing; let's roll up our sleeves * GH-747-experiment-start-block: new procedure for setting start block works first time * GH-757-experiment-start-block: turned out a good idea... completed * GH-747: a dull sketch * GH-747: for both situations, no and some transactions found, start block setting implemented * GH-747: last error handling missing - but added in * GH-747: some small changes * GH-747: working on a more convenient wrapper around the rusqlite transaction; also rephrased a big comment * GH-747: first stage of enhancing the trasnaction wrapper seems done * GH-747: better interface for wrapped transaction * GH-747: interim commit * GH-747: transaction wrapper redesigned successfuly * GH-747: didn't include these accidently * GH-747: builder implemented; interface now doesn't allow misuse of the inner tx wrapper * GH-747: few more comments knocked off * GH-747: transaction wrapper test version polishing * GH-747: new little safety feature implemented * GH-747: small improvements, still working the review * GH-747: and again small impovements, still working the review * GH-747: interim commit * GH-747: more code neatened in big_int_db_processor * GH-747: revamp in receivable (at least I think) * GH-747: revamp of bulky comments * GH-747: interim commit before a big revamp * GH-747: I lost interst in the previous thing but will do files replacement now; save point * GH-747: deleted files mistakely merged in * GH-747: finished before trying master merge * GH-747: finalizing before the review; writing better comments etc * GH-747: more text revamped * GH-747: first bunch of fixes after the 2nd review * GH-747: second big bunch * GH-747: some new minor changes * GH-747: all comments addressed * GH-747: clippy * GH-747: review 2 reaction: revamping text * GH-747: review 2 reaction: another attempt, smaller * bumping version 0.8.0 --------- Co-authored-by: Bert <Bert@Bert.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dan made a mistake.
Before GH-716, we had a stream-key generation method that created stream keys by hashing our public key together with the server host name. This was adjudged insecure, because an exit Node would know the server name, and it had a neighborhood database full of public keys, and it could traverse its database and use each public key in turn to hash with the server name until it found a hash that matched the stream key it had been given; then it would know which originating Node it was serving for.
Dan noticed this vulnerability, but suggested the wrong fix to it. The fix suggested was to generate stream keys without any dependence on public key, so that the exit Node couldn't reverse-engineer it. As a matter of fact, we are now generating stream keys completely at random, with no dependence on anything at all. That worked to eliminate the exit-Node attack, but it caused another problem.
Whenever the browser requests a connection to a server through the MASQ Network, the originating Node computes a stream key for that connection request and compares it to all the stream keys it already knows; if it doesn't already know the newly-computed stream key, it requests the Neighborhood to generate a new route for the stream.
Before GH-716, every browser request to a particular host name would generate the same stream key as every other browser request to that host name, because the stream key was hashed from the host name and public key. That means that all traffic to that host would pass through the same route through the MASQ network.
However, after GH-716, each browser connection request generates its own unique stream key, resulting in a new routing request to the Neighborhood; the Neighborhood may return a route using a different exit Node, which means that the server will get identical session information from two different IP addresses. This is suspicious behavior, which may well cause an attentive server to reject the second request (and perhaps cut off the first connection as well, if it's sufficiently paranoid).
What Dan should have suggested is that the hashing operation stay the same, since it provides convenient stream-key collisions on the originating side that direct connection requests for the same server down the same route to the same exit Node; but the the material being hashed should be modified so that it doesn't entirely consist of things known by the exit Node. For example, instead of hashing in our public key, we could hash in something else: random salt, perhaps, that's generated at bootup time and stored in the Proxy Server.
The text was updated successfully, but these errors were encountered: