Three Hops, One Host: Counting Real Privacy Dependencies
A hop count hides shared hosting, one admin account and the same registrar. Build a dependency ledger, grade every row, and see what a shared value joins.
The second hop came up on schedule and your diagram still shows three separate providers. Then the invoices arrive and two of them name the same hosting company, the same registrar holds all three domains, and every account recovers to one mailbox you own. Nothing in the tunnel configuration is broken. The design simply never counted the dependencies that sit underneath the hops, and a hop count describes the path traffic takes rather than the number of parties who could act on it.
The Symptom Shows Up in Billing, Not in Logs
You will not find this in a tunnel log, because the tunnel is doing exactly what you configured. The evidence lives in public records and account settings: whois organisation names that match across endpoints, identical name servers, a shared registrant address, one payment method, one control panel. Each of those is a hint that two layers which are supposed to fail independently may fail together.
None of these hints proves that any single party can read your traffic. What they reduce is the number of independent decisions that must go wrong before two protection layers are compromised by the same event.
Compare the records you can actually see and write down what you compared. Look up the organisation on each endpoint address, list the name servers for each domain, and open the recovery settings for every account in the chain. Where two values match, note whether the match is about ownership, about operations, or only about a reseller front end. Those are different findings, and treating them as one is how a dependency review turns into guesswork.
Draw the Logical Path, Then the Dependency Map
Two diagrams are needed, and most people only draw the first. The logical path shows where each protection layer terminates and what that endpoint can observe. The dependency map shows who operates and administers each of those endpoints, which is an entirely separate set of names.
| Layer to record | Evidence you can collect | What a shared value would mean |
|---|---|---|
| Endpoint operator | Published operator, contract, support contacts | The same party sees two traffic layers |
| Compute and hosting | Address ranges, hosting brands, platform status pages | One administrative action affects two machines |
| Network dependency | Endpoints and transit links near the observation point | Two paths share a segment that could be watched once |
| Management | Control panels, SSH keys, staff with access | One credential compromise crosses both layers |
| Account linkage | Registration records, payment method, recovery mail | Two services can be tied to one identity |
Grade every row instead of filling it in. Known means you saw a record that states it, inferred means one observation supports it without settling it, and unknown means nothing was found. A shared hosting brand is an inference about shared infrastructure, not a statement about a shared customer database. Do not quietly promote an inference into a known fact just because it is convenient for the conclusion you expected.
A blank row is a finding in itself. It tells you which fact would change the decision if you learned it, and that is more useful than another paragraph about what a sophisticated adversary might do.
An AS Number Answers a Routing Question Only
An autonomous system is a routing administration concept, a set of addresses presented to other networks as one coherent routing view. Different AS numbers therefore say nothing definitive about corporate ownership, separate staff or independent legal control. The reverse mistake is just as common: two endpoints in one AS are not automatically a case of one party identifying a specific user.
If you want the numbers, resolve them rather than assuming them. The address below is a placeholder, and the flag asks the tool to label each hop with the AS that announces it.
mtr --aslookup --report --report-cycles 5 203.0.113.9Treat that output as a measurement of routing, not of ownership or of the full traffic path. The access network you start from and the transit dependencies between endpoints are separate questions that the endpoint addresses cannot answer. When a route or a relay choice cannot be observed from where you sit, label it unknown rather than importing a general claim about how a particular network selects paths today. Unobserved is not the same as unobservable, but it is also not evidence.
Name the Observation Before You Name the Risk
Three findings get mixed together in most dependency reviews, and separating them is most of the work. Passive visibility of encrypted traffic is one finding. Shared management access is another, because it implies an action rather than a view. Account linkage is a third, because it connects identities without granting any technical access at all.
The privacy guidance in RFC 6973 gives a workable shape for this: list what each entity learns, then ask how that could be combined with information held elsewhere. Two points on a path observing similar traffic patterns can motivate a correlation concern, but they do not hand you a measured probability that anyone was identified. Write the concern, then write the observation that would confirm it.
Return to a chain of two tunnel services and a rented proxy. If the proxy's management credentials share a recovery account with one tunnel server, a single administrative compromise can cross both boundaries. If the only overlap is that a hosting company runs both machines, the review has to state which powers that company holds and which information stays protected. Same three hops, different finding.
The ledger is not a certificate of anonymity and it never will be. Its value is narrower and more practical: it shows where independence is established, where it is assumed, and which single unknown row would move the decision. Pick that row next, and leave the rest of the diagram alone until you have an answer for it.