7

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?

1
  • 4
    SSH does that. The first time you connect to a server, ssh saves the server fingerprint. If the fingerprint ever changes, ssh will complain and you will know something changed. The problem here is being really sure you connected to the intended server on the first time.
    – ThoriumBR
    Mar 14, 2017 at 13:34

3 Answers 3

7

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.

1

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.

3
  • TOFU has no full protection against MITM, i.e. if the attacker is already there on the first connection then the attack will get unnoticed because it is trust on first use. Contrary to this sharing a certificate or similar is trust before first use, i.e. it knows what to expect on first use already. Mar 14, 2017 at 14:34
  • Totally agree - I think one could make a similar point about the CA system (causing a CA to mis-issue a certificate for a given domain, and pinning the mis-issued cert would also allow MitM in a somewhat similar way to the case you mention). I had been trying to point to different trust models than the one underpinning the CA system being used in the real world Mar 14, 2017 at 14:42
  • I don't think that the point one could make would be similar because there is a major design difference: TOFU is by design vulnerable against MITM on first use while systems with pre-shared trust information (i.e. pre-shared certificate, pre-shared trusted CA) are not. Mar 14, 2017 at 14:49
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .