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

Question

We have recently used a security scanning tool to assess security of an application. It raised a particular configuration as a Medium vulnerability. The claims made in the explanation of the discovered vulnerability don't seem to match with industry standards.

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

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

This quote above comes from this article relating to WCF security:
https://vulncat.hpefod.com/en/detail?id=desc.semantic.dotnet.wcf_misconfiguration_transport_security_enabled#C%23%2fVB.NET%2fASP.NET

The claim here made by HP appears to be that transport layer security, including SSL and TLS, is less secure than message-based security. The article further explicitly states that TLS is susceptible to man-in-the-middle (MITM) attack.

Further research into MITM attacks seems to indicate that the opposite is true: TLS is the preferred way to prevent MITM attack. Resources supporting TLS include:

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

https://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication/477578#477578

Do client certificates provide protection against MITM?

So, the question is:
Is there any merit in the claim, by the HP article, that transport-mode security is to be avoided, for the reasons cited in that article?

UPDATE: To add some context- the use case in our situation is calling a webservice, not a public site.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Quote from your own link:

When using a transport like HTTPS, this mode has the advantage of being efficient in its performance and well understood because of its prevalence on the Internet. 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.

Nonsense.

While "TLS" itself could very well be used in that way, eg. in some P2P protocol where all hosts are trusted for some reason, the overwhelming majority of use cases are end-to-end systems (including HTTPS). The author doesn't seem to know much about this topic.

For Websites, for all we know, HTTPS is sufficient to prevent MITM.