Can MitM attack be avoided without using a 3rd party?

Question

I'm a little new to this area and have been reading up on Man-in-the-middle attacks. Almost everywhere the solution provided seems to be to use a trusted third party such as a Certification Authority.

Is there any impossibility result that implies that this can't be solved by the two communicating parties on their own? Is there any way to do it without using a CA?

Answer 1

There is no need to use a CA, even with HTTPS. You can simply use a self-signed certificate on the server if you provide the client with a copy or similar (i.e. fingerprint) of this certificate in a secure (tamper proof) way before the client connects to the server so that the client can verify that it talks to the expected server. If the client can not verify the server man in the middle attacks are possible.

The concept of CA signed certificates (i.e. public key infrastructure (PKI)) is only created because sharing a self-signed leaf certificates with all parties does not scale. With CA the browser/OS has a list of trust anchors (root certificates) and can derive the trust to a server certificate based on a trust chain from the trusted root to the leaf certificate. Because of this mechanism only the trusted root CA need to be shared but not every possible server certificate.

Apart from a pre-shared certificate or similar public information (like a SSH server fingerprint) MITM resistant connections can also be established by using a shared secret on both sides. That's the typical case in home Wifi protected with WPA.

Limited protection against MITM is achieved with Trust On First Use (TOFU). In this case the identity of the peer is saved from the first connection and applied to the following connections in the hope that the attacker was not present on the first connection, i.e. that the identity received was the true identity of the expected peer. This is done for example if one accepts a self-signed certificate in HTTPS.

Answer 2

SSH is one example of TOFU (Trust on first use) that does not require a CA (or indeed any third party) to be involved in establishing a trust relationship.

Most Pre-Shared Keys (e.g. as used for WPA in wifi, or used in a VPN solution) can provide some protection against MitM attacks if used correctly, and without needing to establish trust via a CA (or PKI), and without the need to involve cryptographic tokens.

Consider too that MitM can be facilitated by a CA (for example, when a CA is made to issue certificates without carrying out the required checks to validate identity - because of a compromise, legal pressure, or malice), and that using a PKI does not necessarily offer any protection against MitM - it simply establishes that a given token (a key) is reasonably believe to represent a claim (of identity), and poor crypto choices could, for example, nullify any and all of those claims/assertions.

Updated:

As pointed out by @Steffen Ullrich in the comments below, TOFU is susceptible to MitM during the first connection. This could be mitigated (by for example providing some mechanism to validate the host keys being presented). Following that first connection, you are either safe from MitM, or totally exposed.

I had meant to point to TOFU as a different approach to establishing trust (leaving users to figure it out, basically), but Steffen is absolutely correct that TOFU and PKI take a fundamentally different approach to validating identity initially, with TOFU making a design decision to not address the risk of MitM during the first connection - so the two trust models have a different impact on the ability to guard against MitM.

Since the question was about why much MitM litterature mentions PKI, this is a partial answer: of the more common approaches to protecting against MitM, a PKI-based solution provides more protection than other approaches like TOFU.

Answer 3

The client needs some way to verify the server is who it says it is.

There are various ways to verify this:

1. Trust a third-party: HTTPS uses trusted CA. PGP uses web-of-trust to try to join the sender and receiver together.
2. Trust on first use: SSH (by default) will ask the user to trust the server the first time they connect, then SSH will warn the user if the server changes. It's also the way browsers tend to work for self-signed certificates - allowing an 'exception' to be recorded.
3. Pre-share the server's public key via some out-of-bound mechanism, which is the way you are supposed to do SSH and self-signed certificates to be really secure.