I read that developing a security layer on top of communication protocol without any binding between them could cause an issue like MITM attack. I am having a hard time seeing how that could be possible. Can someone shed some light on this?

If there is no binding, can attackers manipulate lower-level layers to bypass the security layer on top of it?

This is one of the sources that seems to suggest it, if I can understand it correctly. https://ui.adsabs.harvard.edu/abs/2012IEITI..95..797S/abstract

  • Your question is too abstract for me. Could you maybe provide an example to illustrate what you're talking about? – Mike Ounsworth Mar 4 at 22:22
  • 1
    If I understand your question properly, then TLS is a security layer on top of the TCP communication protocol. There is no explicit binding between them, and that's fine. – Mike Ounsworth Mar 4 at 22:24
  • This seems like a QUIC-related question, doesn't it? – ximaera Mar 5 at 12:49

Implementing a security layer (TLS) on top of an untrusted communication layer (TCP or UDP) without any binding could only cause problems related to protocol ossification at middleboxes (those being, indeed, MITM devices), leading to potential communication disruptions and possible denial of service for certain groups of users or networks.

This is what the QUIC protocol (the modern TLS/TCP replacement) is being designed against.

But (save for occasional denial of service problems) no other security issues could arise because the underlying communication protocol is meant to be untrusted anyway.

However, the paper you're referring to ("Authentication Binding between SSL/TLS and HTTP") tells quite the opposite: implementing a communication protocol on top of a security layer without proper enforced binding could cause implementation issues. This is called the law of leaky abstractions.

A (somewhat) simpler example of how this could happen in practice is domain fronting:

  1. TLS — the security layer — features a concept of Server Name Indication (SNI) — a token that could be used by a client to tell the TLS server which service exactly they want to reach.

    This concept and a corresponding SSL/TLS extension were developed long time ago and served the purpose of having multiple TLS services, with multiple certificates, available via a single IP-address-and-port tuple. One example where it was strongly needed had been initially shared hosting, but there were also other applications that started to make use of SNI over the years.

  2. There's a matching concept in the HTTP protocol: the server name, transmitted as a value of the "Host" header.

    The TLS server name and HTTP server name are values which come from the same namespace — known as the "Internet domain names" namespace — and in case an HTTP session is established on top of a TLS session, RFC 6066 states that both server names should generally match each other (if there’s no clear purpose and intent by the authors of an implementation to do it the other way).

    However, it's up to the HTTPS server's authors to implement this constraint, as the server name from TLS layer isn't automatically inherited in HTTP session.

  3. A common application layer protocol implementation mistake is to use TLS just for session establishment, forgetting entirely to check that the TLS hostname negotiated before matches what client now provides on the application layer.

    NB: in a large corporate or cloud network it gets even worse, because sometimes the TLS session is terminated on a specific piece of equipment — say, a balancer or a firewall — yet the HTTP session is being terminated far away from that.

    This way, the HTTP server gets no instrument at all to verify that both server names match, and the firewall may omit this check either.

    As a side effect, also not usually meant to be present by the software developers, user can take an arbitrary TLS layer name to reach a Web site they want to access without disclosing their intent in cleartext during TLS session establishment. However, as a matter of fact, there are more side effects of this, and under certain circumstances this mistake in the code — or the infrastructure — may even result in a serious vulnerability.

  4. For instance, when client TLS certificates are used for authentication, an attacker can circumvent the authentication by providing a server name of an adjacent TLS service which doesn't require certificate authentication, and then supplying the host name of a desired application layer service after all the TLS layer checks succeeded.

    Protocol specifications and implementations usually implicitly rely on the TLS server name and the application layer name being the same, and without a proper binding here other security problems could later appear.

| improve this answer | |

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.