A tale of two sources: Is TLS *defense* against Man-in-the-Middle, or not?

To cite the important part from the article you refer to:

The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a man-in-the-middle attack.

TLS is used in different use cases. Some of these cases involve a single end-to-end transport of the message, for example by having a client sending a message to a web server which then gets directly processed by the server. TLS successfully protects against man in the middle attacks in this case.

But TLS is also used when multiple hops are involved. In this case the transport is only protected with TLS between these hops but a man in the middle on any of these hops can intercept the unencrypted data. This use case is typical for mail (i.e. SMTP) but you also find it with HTTPS when using a reverse proxy, content delivery network or similar. In these cases TLS provides only hop-by-hop security but not end-to-end security. The latter can be achieved by encrypting the message before transport and decrypting it after the full transport (i.e. all hops) is done. For mail this is usually done with PGP or S/MIME.

Imagine two different scenarios:

Typical/direct calls

You have a client and a server. The client sends a message to the server; the server does something with the request, creates a response, and voids the memory that contained the original request. The request is not forwarded to any other system.

In this case, transport is fine, and is not particularly susceptible to MitM, assuming you have configured your transport layer security correctly. There are a lot of configs you can mess up, but you ought to be able to audit and correct these using a pen test.

Calls that involve three or more parties

You have a client, an application server, and a domain-specific server (e.g. a server that is running banking host middleware). The client sends a message to the application server; the application server parses the messages, authenticates the caller, and forwards a portion of it to the banking host.

In this situation, a message layer security protocol will allow the banking host to trust that the request message was received from the original client intact and unmolested. If you were using transport security, it is possible that the application server did something malicious, since it would have decrypted and re-encrypted the message. With message layer security, you can encrypt or sign portions of the message and pass it along intact.

Using transport security with a trusted middle-man

That being said, if the application server is trusted, the banking host can authenticate the application server (via transport security) if it using client certificates. With this sort of setup you can use transport layer security with the risk of the MitM attack properly mitigated.

The claim is that "transport mode" security is insecure:

"Transport mode is the least secure option and should be avoided."

I would say that you are misreading the document. It doesn't say that transport mode is insecure; it says that it's the least secure option—and, implicitly, among the set of options it's talking about.

You should not consider security as a binary yes/no issue; rather, you should see it in more concrete terms, as a list of the ways that the system could be attacked. In their case, even if transport security is configured as strongly as possible (SSL certificates between each client and the server), there are scenarios where the communication goes through more than one SSL hop (e.g., there's a load-balancing proxy between the client and the endpoint). If any of the servers in that chain is hacked, then the attacker can break both:

1. Confidentiality: The attacker is able to read the contents of the payload.
2. Authenticity: The attacker is able to forge messages that appear as if they come from the client.

Another way of putting it: if you use the system in that configuration, the clients are potentially trusting intermediate servers not to forge messages. It's no more secure than those intermediate servers are.

The other two options they offer are what they call "message security" and "message credential." These options allow the clients to be less trustful of the server:

• In message security mode, the client encrypts every message with a key that the intermediate servers do not have, only the final endpoint. So if an attacker breaks into an intermediate server they can only drop messages (and perhaps not undetectably).
• They don't explain message credential mode well enough that I can understand its security very well. The client doesn't encrypt the messages, so an attacker that breaks into the proxy can definitely read them. The advantage over transport security seems to be that with transport security each hop is authenticated (client authenticates with proxy, proxy authenticates with endpoint), but with message credential the client authenticates to the endpoint. I can't tell if an attacker who breaks into the proxy is able to forge messages, however. (Bad documentation!)

Note that for all three modes there is some scenario where an attacker causes something bad to happen. Again, security isn't a yes/no issue.