Can the Originating Node Detect who is an 'Exit Node'?

In general the answer is NO! - as long as the route is at least CORES (client, origin, relay, exit, server); however, in that case the R will know both the O and the E. If the route is CORRES or longer, no one Node will ever be able to determine both the origin and the exit.
But the picture is a little brighter than that. Even in the CORES case, although the R will have the IP addresses of both the O and the E, it won't have any way to tell that they're O and E. It doesn't know where it is in the route; all it knows is that it has received a CORES package from one IP address that it's supposed to route to another IP address for money.
And the picture is a little darker than that. A Node can't tell where in the route it is, because its instructions are always at the beginning of the list of Node instructions it receives; but it can tell how long the list is. If the list is four items long, the Node can deduce that it must be O -> R, R -> E, E-> R, R -> O. Therefore, if it's neither the originating Node nor the exit Node, it has to be the single relay Node, which means the two IP addresses it knows are O and E—although since it doesn't know whether the package is coming or going, it doesn't know which is which.
"Well, doesn't that just blow the whole game out of the water?" Not entirely, because it's almost trivial to enhance the Node so that it uses only one relay (to keep costs down), but it adds garbage items to the end of the instruction list before it sends the CORES package. Of course, if a list item isn't intended for you, you can't tell whether it's garbage or not. So that would produce a list of instructions that looked like a long, slow, expensive route, when in reality it was a short, fast, cheap one.
As a matter of fact, by appending garbage to the list, you could even use COES routes, with the origin talking directly to the exit, with the exit none the wiser; but I wouldn't, for several reasons.
Finally, this whole problem stems from the fact that each Node can tell how many items are in the list of instructions. That's by immature design: I should have thought that out a little more carefully. I have, since, thought it out more carefully. The list should look like this:
Length of entire list in bytes, unencrypted+-----------------------------------------------------------------+ | Length of my instruction in bytes, encrypted with my public key | +-----------------------------------------------------------------+ |  My instruction, encrypted | |    with my public key      | +-----------------------------------------------------------------+ | A bunch more data that's encrypted, but not with my public key  | | ...or could be garbage... | +-----------------------------------------------------------------+
I'd pull the encrypted length off, decrypt it, then pull that many more bytes off and decrypt them, using the resultant instruction to figure out what my job was and do it. Then I'd add an unencrypted hunk of random garbage* to the end of the CORES package and send it on down the line, where the next recipient would find that the first thing in the list was a byte length encrypted with his public key.
Once Reversal Mode gets added, this would be an encrypted reversal instruction, rather than a hunk of garbage, so that if the package couldn't be sent on for some reason, it could be returned to the sender so that the sender would know A) why it failed, B) where it failed, and C) who should be paid and how much.
So I have all this in my head (and now in Telegram), but I didn't think of it at the beginning, so at some point we have to make a switch where the CORES package format will become wildly incompatible with the previous version's.
Penetrating an intercepted exit-node packet (either request or response): HTTP, yes. TLS, no. Same as non-MASQ Internet, same for ISP as for any other hacker.
Except!
Sometimes an ISP—generally a government ISP that's part of a repressive regime, or a company controlling its employees' access to the Internet from inside—will force its customers to use a proxy that it provides. The idea is that instead of one unbroken secure connection between client and server, there's a secure connection between client and proxy, and another between proxy and server: but the proxy can penetrate every packet that goes through it.
Now, any decent browser will scream bloody murder at this arrangement, refuse to establish the connection, and warn the user in big letters that he's under attack...unless it's been configured to trust the certificate of the ISP's proxy. In places where this happens, the browsers people use either have already been configured, or the users are instructed to ignore the big-letter warnings and configure them themselves.
In that situation, HTTP isn't safe, and TLS isn't safe either. Nothing is safe, except clandestine MASQ, which will hide end-to-end-encrypted data inside harmless-looking masquerade data.
As for IP addresses, any TCP packet, regardless of what it's carrying, has to have source and destination IP addresses in it, and they can't be spoofed if the sender wants a reply. Any observer will be able to see the IP addresses going into and out of exit Nodes. But the entire philosophy behind MASQ is moving those exit Nodes outside oppressive regimes so that they can't be easily observed.
To anyone who knows what to look for, every non-clandestine MASQ Node (which is all of them, so far) will be lit up like a neon sign. Don't nobody do nothin' dangerous with MASQ; not yet.

FAQ ❓ - Previous

Security

Next - Knowledge Base 🧠

MASQ Network Dynamics

Copy link