Write some platform-dependent code to get the current locale's language/country code from the operating system. (For Linux and Mac, it's in the $LANG environment variable; for Windows, probably somewhere in the Registry. Look at dns_utility for example Registry code.) Search for the country code in a list of non-Free-World countries to set the Free World bit.

Make sure the Node is tunneling TLS proxy requests through HTTP properly using the HTTP CONNECT method.

Also, review the rules for HTTP proxies and make sure the Node is following enough of them.

Add a message for the Proxy Client to send to the Neighborhood, with another inaccessible hostname to add to the list. Have the Neighborhood generate a debug log whenever that message arrives, showing the full list of hostnames now known to be locally inaccessible.

Build an IP-address-to-country-code geolocation database into the SubstratumNode. Use it during startup on the Node's public IP address to identify the Node's country. Print the country to the console as part of the startup message.

Note: this should probably not be an actor.

Add a reasonable hard limit on the number of unreachable nodes in the list. When the list overflows, replace the oldest hostnames with the newest ones. When accepting Gossip, reject nodes with too many unreachables. (Can't just truncate their lists: eventually the lists will be signed and unmodifiable.)

Modify the Neighborhood database and the Gossip protocol to handle and disseminate the country code.

Malefactors should be bannable by IP address, Node public key, and earning wallet.

Bans by IP should be temporary (probably hours) in case the IP is transferred to another user who isn't a malefactor.

Bans by public key and wallet should be theoretically permanent, but truly permanent bans raise the specter of a denial-of-service attack by filling up the database with malefactor bans so that each hop is significantly delayed while the Node looks through its list of bans to see whether the purveyor of the current CORES package is among them. Therefore even public-key and wallet bans should probably be time-limited, although more generously than IP bans.

Create a database table or tables to persist malefactor bans from run to run (don't forget the database migration and CURRENT_SCHEMA_VERSION bump), and provide a facilities in the code for A) easily creating new malefactor bans and B) caching malefactor bans in memory to avoid a database dip every time a CORES package is received.

Don't write code yet to check for or respond to malefactor bans.

Make the Dispatcher listen on port 443 for masquerade HTTPS traffic. When it receives masquerade HTTPS traffic, it should unmask it and send it to either the Hopper or the Neighborhood, as appropriate. When it is given Hopper or Neighborhood traffic to send, it should make a decision about how to send the traffic, and if that decision is for HTTPS masquerade traffic, the traffic should be masked as a believable HTTPS request (probably meaning PUT or POST) and sent to port 443.

Make sure the Dispatcher can tell the difference between incoming masquerade HTTPS traffic for the Hopper or the Neighborhood and incoming real HTTPS traffic for the Proxy Server or Proxy Client.

Note from Dan: The last paragraph here has been overtaken by events. If the request arrives on localhost:80, then it's from a browser or other client; if it arrives on 0.0.0.0:*, then it's from outside.

Overview

DNS is hard coded to port 53, which means if it conflicts with a locally running port, you have to stop the service, or build a docker image. I also dont want to use docker as it makes security management more difficult.

Customizable DNS Server / Port

For security schizos like myself who run local infrastructure like DNSCrypt with lots of caching, the concerns mentioned in https://github.com/MASQ-Project/Node/blob/master/node/docs/PORT_53.md can be completely avoided without needing to disable locally running DNS servers.

Therefore a good solution would be to allow delegation to a different dns server

The handler for RouteQueryMessage (perhaps RouteQueryRequest by the time this card is played) in Neighborhood invokes the Routing Engine to create a route before checking to see if a consuming wallet has been supplied.

Since the only routes that don't require a consuming wallet are Gossip routes, and RouteQueryMessage is never used for Gossip routes (because they're too simple to require it), every route requested by a RouteQueryMessage always requires a consuming wallet, and requiring the presence of a consuming wallet right when the RouteQueryMessage is received would prevent a call to the Routing Engine in cases where the work of the Routing Engine is about to be discarded anyway.

Move the consuming-wallet check from Neighborhood::compose_route_query_response() to Neighborhood::route_query_message(). If there's no consuming wallet, return None directly (with an appropriate error log) instead of calling deeper.

Currently when the MASQ starts, it always runs with entry_dns on and port 53 is listened to by Node.

Design a way to allow a startup parameter to be toggled that will turn off entry_dns and not require Node to listen on port 53, so other software can listen on the port unobstructed.

*Consider removing the entry_dns component, if system wide subversion is never to be a "thing"

Present a log to user to remind them that they will need to proxy network traffic/software to MASQ for privacy routing

ALSO check the daemon to ensure that entry_dns is not starting when daemon is running - there is a chance that this was turned on during some

Command for inspecting processes with MASQNode
macOS
ps -ef | grep MASQNode (includes this command)

window
netstat -ano

List processes listening on port 53:
macOS
lsof -Pn -i :53

We may at some point want to do some time-consuming processing during a panic--for example, if we're holding data in memory that will at some point be written to the database, but a panic occurs before the write is scheduled, we might want to do the writes to the database after the panic occurs but before the program actually halts.

We don't know at this point whether all three operating systems will allow us to run for several seconds during a panic: it seems reasonable that after telling a process to terminate, an OS would keep track of it and forcibly kill it if it didn't die after a short time.

Write a test (suggested project: masq_lib) that involves a struct for which the Drop trait is implemented. Have the Drop handler do something that takes ten or fifteen seconds--something other than just sleeping, since the OS is in charge of sleeping and may deceive us during a panic. Create an instance of the struct and panic; see if the Drop handler is permitted to take all the time it needs, or whether it's interrupted by the OS. (This test may be a little ticklish, since it involves a panic.)

We are pretty sure Linux will wait for at least fifteen seconds; we don't know about macOS or Windows.

The test doesn't need to become a permanent part of the codebase, since it will necessarily suck up lots of test runtime, but the results of the test should be appended to this card for posterity, so that we can come back and look at them after we forget what happens.

winapi v0.2.8
last update 7 years ago

description:
Raw FFI bindings for all of Windows API.

compiler warning: the following packages contain code that will be rejected by a future version of Rust: winapi v0.2.8

Check if this was completed in MASQ-Project/MASQ-Node-issues#617

The Neighborhood should be made reluctant to use the same route multiple times in a small time interval, preferring in extreme cases to incur the overhead of a new route-extension search.

Use the public IP, if available, to obtain the country code from the GLD database. Check the country code against a hard-coded list of non-Free-World countries to see whether we're in the Free World or not, and add that information to our Node Record in the Neighborhood.

With the arrival of MASQ-Project/MASQ-Node-issues#523 we have a very simple mechanism that concerns monitoring pending transactions with regard to the how long is it taking for the transaction to come to completion. Some may stay pending even for a long time.

Now we only call all transactions older 6 hours bad transactions and we mark them with the failure mark - that means we just give all the responsibility over to the user's hands, because no other transaction for the same account can be send now and also the user has to decide what to do to solve the cause of the failure (moreover the hypothetically failed transaction can be later confirmed as successful because we don't really know if it's not going to succeed)

Suggestions:
We probably want to provide the standard functionality, that is, to automatically resent the transaction with higher gas price (increased by some percentage) when we've passed enough long time from the creation of the transaction.

There is another suggestion regarding the way how we should measure the passed time. The straightforward method is just counting with time units; the more sophisticated way is by the number of chain blocks added after the block from moment of sending the transaction.

The latter method requires us to be able to retrieve the current block number which may cause the need of another RPC-JSON call to the blockchain.

Be aware that these issues are linked to pending transactions being in air for a while, quick failures don't fall under these and so, of course, we won't want to retry the failed transaction at least not until we are able to determine the right cause of the failure.

Build a top-level-domain-to-country-code-group service into the SubstratumNode. This will probably be part data and part code. Make the Node capable of accepting a hostname in its RouteQueryMessage. Put a debug log in the Neighborhood that gives a list of acceptable exit-node countries whenever a route to a hostname is constructed.

Note: this probably shouldn't be an actor.

Nothing.

Relates to graceful shutdown, but this card context is around if an active TCP connection is broken between Nodes.

Need to inspect the code to see if this is handled in any way

If the code exists, its likely not being actively used by masq

Modify the startup code to use well-known public DNS servers and well-known websites to tell whether the Node is operating in the Free World or not. Print this information to the console as part of the startup message.

When a reversal-mode CORES package arrives back at the Origin Node, instead of immediately banning the failed Node, first probe it with Ping to make sure it's really dead, and only ban it if it doesn't respond.

If it does respond, give the Node that reported it dead a suspicion point.

(We use banning rather than simple removal because we might in future get Gossip from another Node that does not yet recognize the failed Node as being down, and we don't want it back in our database. Whether it's down or corrupt, in either case its public key should be blacklisted.)

Add the Free World bit to the NeighborhoodConfiguration and modify the Gossip protocol to disseminate it.

from Steve:
when we update the rust-web3 dependency, we will gain the feature to use Infura project secret for auth access.

relates to clandestine mode of using blockchain services

[@steveswing Put a note on this card when the library is released.]

Commit was merged and release recently Jul20

Overview

To make it easy for users, Masq provides a fairly straight forward dns implementation. It is however very detrimental to security, and as such there is a beter path.

Solution (Mid Tier)

Before startup grant MASQNode cap_net_bind_service permissions with:

$> sudo setcap 'cap_net_bind_service=+ep' /bin/masq-node

Solution (Chad Tier)

Because security schizos want to maximize security, i also dont want to grant potentially lethal workaround permissions to the masq node. Therefore a good solution would be to allow evry port to be customizable, as well as the option of using an external dns server.

There is nice chance, I think, that we could ask authors of linefeed library for some corrections that could reflect certain minor bugs we're gonna have to deal with otherwise. There is danger that people will blame us for we haven't fixed bugs in our code.

At this point, I think we have enough information to say that we're dealing with a ghost cursor on Windows, in the simplest cmd in particular. What does it do or when? From my observation, because the cursor is blinking while it's waiting for the input if you enter what you typed just at the moment when the cursor is shown on the screen it will persist there, or in other words that immediate state of him freezes in place although we've already gotten a new blinking cursor on a new line.

You can see more of such frozen cursors in the same time in the terminal, all depends on the timing in which you're executing your supplied strings.

If you scroll far away so that the incriminated place becomes covered behind the boarders of the terminal and when you get back then ghosts of those cursors are gone.

Secondly. This is just an assumption though. I think that handling of the signal Ctrl + c doesn't work. (Maybe of others too - now it's in the phase of testing) I haven't been in a situation where it would; still I think I miss nothing regarding how it's intended to get working in the code thought it isn't.

Make the Dispatcher listen on port 80 for masquerade HTTP traffic. When it receives masquerade HTTP traffic, it should unmask it and send it to either the Hopper or the Neighborhood, as appropriate. When it is given Hopper or Neighborhood traffic to send, it should make a decision about how to send the traffic, and if that decision is for HTTP masquerade traffic, the traffic should be masked as a believable HTTP request (probably meaning PUT or POST) and sent to port 80.

Make sure the Dispatcher can tell the difference between incoming masquerade HTTP traffic for the Hopper or the Neighborhood and incoming real HTTP traffic for the Proxy Server or Proxy Client.

Note from Dan: The last paragraph here has been overtaken by events. If the request arrives on localhost:80, then it's from a browser or other client; if it arrives on 0.0.0.0:*, then it's from outside.

--dns-servers should always be an optional parameter, and if it is not specified (but is still needed) it should default to the regular system DNS (for example, 192.168.0.1). Without specific direction, Node should not change the network signature of the machine running it.

SubstratumNode Version
Commit 69f4270

Describe the bug
When starting the Node , and hitting the Consume button, this error is shown:

To Reproduce

1. Delete node.db
2. Start Node
3. Recover Wallet
4. Start Node
5. Enter a descriptor
6. Hit Consume -> Error

** Additional info:
When I hit Serve, no error occurs and the Node can join the neighboorhood which is validated by the diagraph showing bidirectional connections. The Node in Red is the Win10 Node.

Screenshots

Make the Hopper check incoming relay traffic to see if it comes from a Node that's lying about the country it resides in, and ignore the traffic if so. Also, malefactor-ban the source.

VACUUM is a SQLite-specific operation that squeezes deleted space out of database files. It's interesting for two reasons. First, it makes the files consume less disk space; second, it overwrites the deleted space so that it cannot be forensically analyzed by an attacker to recover some or all of the data that was deleted.

VACUUM is not an operation that should be performed whenever anything is deleted from the database: that would be too expensive. However, it should be performed on a reasonably frequent basis to protect the user's privacy and disk space.

Write some code to perform the VACUUM operation periodically, noting that it should not take place while the database is being used for anything else.

Suggestions: One good time to perform a VACUUM operation might be during a Graceful Shutdown (put card number in here). However, it will still be possible for the Node to crash unexpectedly, in which case the database file will be unVACUUMed. Therefore, it might be advisable to VACUUM during bootstrap as well.

Modify the Neighborhood database and the Gossip protocol to handle the dissemination of the unreachable list. Add a set of debug logs to the Gossip acceptor to chronicle the acceptance of Gossip, including the unreachable lists.

Implement protocol-compliant timeouts and retransmissions for PCP, PMP, and IGDP, to handle lost packets.

Make the Neighborhood search for exit nodes in the acceptable countries whenever it constructs a route to a hostname, and choose the actual exit node from that list. (Choose simply and deterministically: always the first, or some globally incrementing integer modulo the list length, or whatever; no complications.)

Reference MASQ-Project/MASQ-Node-issues#190

Rows need to be added to the CONFIG table, and provisions made in PersistentConfiguration, MASQNode-UIv2 and masq, and logic added in the code, to make configurable persistently and at runtime the following values:

Blockchain service URL (node_configurator_standard.rs)
payment_suggested_after_sec
payment_grace_before_ban_sec
permanent_debt_allowed_gwei
balance_to_decrease_from_gwei
balance_decreases_for_sec
unban_when_balance_below_gwei (accountant/mod.rs)
routing_byte_rate
routing_service_rate
exit_byte_rate
exit_service_rate (neighborhood.rs)
payable_scan_interval
receivable_scan_interval
pending_payment_scan_interval (accountant/mod.rs)

Historical note: the names in the code have the word "gwub" in place of the word "gwei" above; "gwub" was an attempt at a humorous combination of "gwei" (gigawei) and "SUB" (the original ERC-20 token used by Substratum). It was weak at best and is of no use now, so these names should be changed to something clearer.

Suggestion: the names of the values in the database (and preferably in the code as well) would be easier to understand if they included the unit of measurement at the end: for example, permanent_debt_allowed_gwei is much easier to understand than routing_byte_rate.

If the meanings of the values in accountant/mod.rs are not clear enough to complete this card, contact Dan for further information.

Note: As a part of this card, we've reseted default values for the three group of parameters by which we de facto eliminated MASQ-Project/MASQ-Node-issues#550. We did so with that effect in mind.

This is continuing a removed card #609 in Node-Issues

Ropsten has long been deprecated.

Consider adding the current testnets for ETH if required (Sepolia)

'Graceful Shutdown'

When one UI shuts down a Node with the shutdown command:

• All other UIs connected to the Node should spontaneously show a message indicating that the Node has shut down. One way to accomplish this would be to make the Node explicitly shut down all its UI connections before it dies, and have the UIs be sensitive to their connections being closed.

• All other UIs connected to the Daemon should spontaneously show a message indicating that the Node has shut down. One way to accomplish this (may already be implemented) is to have the Daemon sense when its child process dies and send a broadcast to all connected UIs.

• When a UI is connected to the Node and the Node shuts down, the UI reconnects to the Daemon. However, in no case should a Node-connected UI display the shutdown message caused by the Node disconnecting, then reconnect to the Daemon and also show the broadcast from the Daemon about the Node shutdown. This may be accomplished either by preventing the Daemon from sending the broadcast to UIs that connect after it senses the Node shutdown (preferable), or by making the UI ignore the Daemon's broadcast if it has already sensed the shutdown (may be quite a bit more difficult to get the sequencing right).

Please support color and bold styles to beautify terminal output. For example, make local node descriptor in Bold font, and colorize INFO, TRACE, DEBUG, ERROR, WARN into blue, green, dark green, red, orange, respectively.

Something like this
https://rust-lang-nursery.github.io/rust-cookbook/cli/ansi_terminal.html

Dan comment 4-Nov:
We probably don't want to bother colorizing the output to the logfiles, because we eventually want to make that output JSON or some other machine-readable format, and colorizing the output would just obfuscate that; but using ANSI color for CLI output is a good idea, and I can imagine a CLI command such as

masq show logs --log-level debug --format colorized-text

that would show logs in real time on the console in text form with ANSI color.

If we want to achieve mass adoption of MASQ, we need to make it very user friendly with convention over configuration in mind.
Forcing the user to find a node descriptor and copy/paste it is a blocker.

Proposed solution is to run some official node descriptors, which will be by default pre-filled in MASQ client. Or alternative solution, is to implement some algorithm that will pre-fill the most suitable Node descriptor to maintain network health or stability or the one that will be fastest for the user.

Build a TlsMasquerader that makes data look like one or more valid TLS ApplicationData packet(s),
and that can reassemble such packets on the other side of a Node-to-Node connection and extract the hidden CORES package.

Make sure that:
A) the TlsMasquerader puts a signature in the masked data so that, when presented with the data, it can tell whether or not it can handle unmasking of that data. (Talk to Dan about how to employ encryption here.) It's important that the TlsMasquerader not assume that it's the only Masquerader in the system.
B) space is left for other TLS Masqueraders as well. Real TLS connections don't consist solely of ApplicationData packets; therefore, as we become more clandestine, we'll have to enhance the existing TLS Masqueraders and add more.

Dan will fill this out.

Make a Jenkins job and supporting automation to download a fresh copy of the IP-to-country-code database after every update (2nd of each month for IP2LOCATION), convert it, and apply it to the next SubstratumNode build automatically.

The supposed response on UiShutdownRequest, where UiShutdownResponse comes in mind, is never being sent actually. We miss this code in this request's handle in Neighborhood. It only exits the process of the Node which is quite brutal. At any rate, UishutdownResponse doesn't figure in the production code.

We will want to go even further with time going (to some last-bye communication with other Nodes before disconnecting) but for now we want to rectify that we don't send a full-valued response message to our UIs. They deserve more :)

Send a UiShutdownResponse from the same handle back to UiGateway. For that you may need to integrate subscribers of NodeToUiMessages in Neighborhood and this also requires a mortification of the BindMessage and of its handle. The following is just a temporal bridge but we also want to make sure that the response make it over to the UiGataway where it must be dispatched over the websocket connection, all in time, before the whole process terminates. So we probably want to sleep a while before we actually call exit_process().

A Neighborhood with only short routes, asked for a long route, should send requests to the nodes at the leaves of its routing tree in an attempt to extend the tree so that it can answer the original request. If a route of sufficient length is found, it is returned immediately, even if other results are still coming in; the other results are fielded and added to the database as well, as they arrive.

When seeking an exit Node for a data route, categorize the target hostname as Free-World or non-Free-World. If non-Free-World, defer to the next method of Terminal Intelligence.

If the target is Free World, select a Free World exit Node from the Neighborhood database.

Note: Use the TLD database to get a country code for the hostname, then the non-Free-World country list to get a Free World bit for the target.

When the Node crashes when it has a bunch of unwritten debts in memory, and they disappear without making it into the database.

We build the Node not to crash, so theoretically crashing shouldn't be that big a concern; but remember, before we play the Graceful Shutdown epic, every Node shutdown is indistinguishable from a crash, because it just stops the process dead. Therefore, presently there's no way to move a Node from the running state to the not-running state without crashing it.

This concern might raise the priority of Graceful Shutdown...

Bert — 09/06/2022
I've invented a concept how we can escape from this threat. There is even a card about it and I keep it back in my head hoping it will be implemented. It would solve a trouble in your named case but also in some other. So it has a potential of a general purpose help structure. Solved by combining an impl of Drop with writing important data to database in the program's post-morte moments. When overally crashing, we still can save the data persistently. We just need a smart wrapper. I've also proved the concept in a spike, if you have doubts.
Dan Wiebe — 09/06/2022
Drop implementations won't work for what we have now. When you kill a process the way we kill it, the operating system simply doesn't schedule its next timeslice. It's removed from the process queue and thrown away without ever getting another chance to run.

Graceful Shutdown is of course the ultimate solution to this problem. An interim solution (at least for Linux and Mac) would be, instead of terminating the process, to send it a SIGTERM signal. We'd have to sense that signal and make sure all the various threads and actors were made properly aware of it. As a matter of fact, that exact functionality will probably be part of Graceful Shutdown.

Currently, when a Node is ordered to shut down, it simply kills its own process. No file handles or TCP/database/WebSockets connections are closed, nothing is gently deallocated, nothing is cleaned up in the database, and no Gossip is sent.

Node shutdown should be much more graceful than this. Pending operations should be completed, handles and connections should be closed, neighbors should be notified, and so on.

Create a set of cards detailing all the various operations that need to be performed in the process of a Graceful Shutdown. Note that #404 and #407 already exist.

Also to be included is #410

One of the things to be considered is the logger: what if the Node wants to shut down just as the logger is rotating the logfiles in a background thread? The logger library provides hooks for this, but the hooks will need to be used.

Suppose Gossip shows up at a clandestine port from a Node we don't already know. This Node could be an attacker trying to A) identify us as a MASQ Node, and B) put our IP address on a government watch list.

Adding this Node to our Neighborhood and sending it CORES packages will absolutely confirm our identity as a MASQ Node, so we don't necessarily want to do that.

Even accepting a connection on a clandestine port, even if we immediately close it, will confirm at least that we have that clandestine port open and may be a Substratum Node. We'd rather not do that either.

Solution: rework the clandestine listeners at a lower level, so that whenever a TCP SYN is received, the Neighborhood is consulted to see if the Node attempting to connect is known by IP address. If so, continue the connection handshake with a SYN-ACK and proceed normally.

If not, ignore the TCP SYN altogether, so that it will look like the clandestine port is not open.

Note: this may require handling 127.0.0.1:80 and 127.0.0.1:443 (loopback ports for the local browser) differently from NIC:80 and NIC:443 (external clandestine ports for CORES traffic).