11

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.

  • 5
    To me, it seemed more like the article was advising against the transport mode of WCF because it relies on transport layer security. In the sense, this mode doesn't provide security of its own, but is reliant on correct implementation of security on the transport layer. If someone messes up that implementation or configuration, the connection is left less secure. – katrix Jan 19 '17 at 17:07
  • We looked into that, and discovered this article from MSDN: msdn.microsoft.com/en-us/library/ff648863.aspx That article still refers to HTTPS, which leads to SSL/TLS, which still appears to contradict the idea that TLS prevents MITM. – Dave Swersky Jan 19 '17 at 17:10
  • One other possibility is that ISPs, state actors could still MITM at the hops. For example - security.stackexchange.com/questions/58838/… – katrix Jan 19 '17 at 17:29
  • @katrix I agree that there are other ways to perform MITM attacks. Does this mean that the HP article is correct, or is TLS, while not perfect, still a valid protection against MITM? – Dave Swersky Jan 19 '17 at 17:32
  • It may very well be that, in the context of WCF, TLS is difficult or impossible to implement in a way which provides sufficient protection against a MITM attack. (I honestly have no idea, I know essentially nothing about WCF.) In the general case though there's no reason to avoid TLS; it's proven to be a very effective and well understood way of preventing MITM. – Ajedi32 Jan 19 '17 at 17:34
18

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.

  • 1
    A good example of when this has failed is MUSCULAR. – Xiong Chiamiov Jan 19 '17 at 19:05
  • 2
    This is excellent clarification, thanks! One of our points of contention with the HP article is the claim in the beginning that "transport mode should be avoided." That seems like an over-generalization, at best. The article also seems to imply that message-based security should be used instead of rather than in addition to TLS, which also doesn't seem accurate. – Dave Swersky Jan 19 '17 at 19:13
8

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.

  • Thanks for the clarification- the way I read this is that "both TLS and message would be best, but TLS by itself would be 'good enough' to address MITM." Do I understand correctly? – Dave Swersky Jan 19 '17 at 17:49
  • 1
    @DaveSwersky It depends on what your threat model is, and how TLS is being used. For example, in the "Calls that involve three or more parties" example in the answer above, you definitely would not want to use just TLS if you don't trust the application server. – Ajedi32 Jan 19 '17 at 17:53
5

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.

  • 2
    This is far better than a number of the other answers as it actually addresses the assumptions made in the linked paper. – Jared Smith Jan 20 '17 at 14:20
1

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.

  • That's the part in the HP article that didn't ring true for us. Doesn't seem to jive with all other research. – Dave Swersky Jan 19 '17 at 17:11
  • You sure HTTPS is secure? What about Heartbleed? POODLE attack? SSLStrip? – Azteca Jan 19 '17 at 17:13
  • 1
    @Azteca Let's say, HTTPS with the newest TLS version and proper configuration. And parts of the problems are not TLS problems, but bugs in specific programs working with TLS. – deviantfan Jan 19 '17 at 17:15
  • 1
    @DaveSwersky Think of it this way. If I use HTTPS to connect to a server, but I accept any TLS certificate as valid regardless of whether or not it's signed by a trusted CA (no major browsers actually do this, I'm just using it as an example), I'm still vulnerable to MITM even though I'm technically "using" TLS. So if WCF uses TLS that way, then its implementation of TLS would be insecure. (I'm not saying it does, like I said I know nothing about WCF.) This would not mean however that TLS is "insecure", just WCF's implementation of it. – Ajedi32 Jan 19 '17 at 17:48
  • 2
    @deviantfan Consider two systems. In the first, the message is encrypted by the sender with the recipient's public key. In the second, the message is relayed by several machines (think SMTP) and each link uses transport encryption. Which is more secure? Transport security protects each hop and is only secure if some overlay scheme ensures that the hops are all trusted. Message security only requires you to know a public key known only to the recipient or to share a secret key and is invulnerable to MITMs if symmetric. – David Schwartz Jan 20 '17 at 4:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.