Man-in-the-Middle

A man-in-the-middle (MITM) attack is when an attacker secretly positions themselves between two parties who believe they're communicating directly with each other, and can read, alter, or inject messages in either direction. The defining trick isn't just eavesdropping, it's that both legitimate parties still believe they're talking to each other, not to the attacker sitting in between.

A classic real-world version: connecting to an open Wi-Fi hotspot at a coffee shop, where an attacker on the same network intercepts unencrypted traffic and can read or modify it freely. A more sophisticated version: an attacker presenting a fraudulent certificate that tricks a browser into trusting the attacker's server as if it were the real one, letting the attacker decrypt and re-encrypt traffic in both directions without either side noticing.

The formal model behind it

Danny Dolev and Andrew Yao's 1981 paper gave this problem its standard formal treatment: assume the network itself is fully hostile (an attacker who can observe, modify, delay, drop, or inject any message at will) and then design a protocol that stays secure even under that assumption. This "Dolev-Yao model" set the bar the field still designs against; TLS, DIDComm, and essentially every modern authenticated-encryption scheme are built and analyzed specifically to resist an attacker of exactly this strength, not a weaker one.

The general defense requires two separate properties, and it's a common mistake to think encryption alone provides both: confidentiality (an on-path attacker can't read the content) and authentication (each party can verify who they're actually talking to, so an attacker can't successfully impersonate either side). Encryption without authentication still allows a MITM to establish separate encrypted sessions with each party and relay between them, decrypting and re-encrypting everything along the way, invisible to both legitimate parties.

Where Solidus addresses it

Solidus Relay, a live DIDComm v2 mediator (see that entry), packs every message as an authenticated, encrypted envelope (a JWE) addressed to a specific recipient DID, using keys tied to that DID: an on-path attacker can intercept the envelope but can't decrypt it or forge a response that the intended recipient's software would accept as genuine. That's real, running infrastructure, and it's worth being precise about its actual scope: this covers messaging through Solidus Relay specifically, not every network path Solidus operates. Ordinary TLS secures Solidus's REST APIs, which is standard web infrastructure rather than anything distinctive to Solidus, and it hasn't been separately audited by Solidus either. Neither the underlying didcomm-node library nor Solidus's own mediator code has had an independent security audit, and this runs on public testnet only: there is no mainnet.

Check it yourself

curl https://relay.solidus.network/invite returns a real DIDComm v2 out-of-band invitation, advertising "accept":["didcomm/v2"]. Any conformant DIDComm v2 agent, Credo-TS, Veramo, ACA-Py, can take that invitation and drive the authenticated handshake against it independently, without taking Solidus's word for any of it.