Slashdot Mirror

← Back to Stories (view on slashdot.org)

Network Middleware Still Can't Handle TLS Without Breaking Encryption (zdnet.com)

Posted by msmash on from the closer-look dept.

An academic study published last month shows that despite years worth of research into the woeful state of network traffic inspection equipment, vendors are still having issues in shipping appliances that don't irrevocably break TLS encryption for the end user. From a report: Encrypted traffic inspection devices (also known as middleware), either special hardware or sophisticated software, have been used in enterprise networks for more than two decades. System administrators deploy such appliances to create a man-in-the-middle TLS proxy that can look inside HTTPS encrypted traffic, to scan for malware or phishing links or to comply with law enforcement or national security requirements.

[...] In the last decade, security researchers have looked closely at the issue of TLS inspection appliances that break or downgrade encryption. There has been much research on the topic, from research teams from all over the world. But despite years worth of warnings and research, some vendors still fail at keeping the proper security level of a TLS connection when relaying traffic through their equipment/software. Academic research [PDF] published at the end of September by three researchers from Concordia University in Montreal, Canada, shows that network traffic inspection appliances still break TLS security, even today.

8 of 101 comments (clear)

  1. unless its end to end, its going to break by Anonymous Coward · · Score: 5, Insightful

    Having a MITM on purpose is breaking things by design.

    The end user needs to verify that the site they're talking to is the real one, by checking the certificate, but all they get is this stupid cert that was automatically generated by some stupid appliance. No way for the end user to ever know if they've gotten the right website or not.

    Good luck if the appliance itself actually checks for cert validity or not.

    In short, TLS is working as designed.

    1. Re:unless its end to end, its going to break by greenwow · · Score: 3, Insightful

      > What is broken if the user trusts a middlebox?

      Nothing. This is just hyperbole.

      The real question is do you trust cert authorities that have screwed-up in the past or your local IT guys? After we had several employees install malware from what they thought was a safe site since it used HTTPS, we haven't had that happen again after installing a proxy. It's the lesser of two evils.

    2. Re: unless its end to end, its going to break by andymadigan · · Score: 1, Insightful

      Block requests to port 53 outgoing and run your own DNS recursive resolver that will only resolve domains on your whitelist. If your users can get around that then they can probably get around your MITM box, too. My way around a similar MITM was to tunnel SSH over the HTTP proxy.

      Bonus: It takes a lot less hardware to run a DNS resolver than a MITM proxy.

      --
      The right to protest the State is more sacred than the State.
  2. I think the point of certificates and ... by Anonymous Coward · · Score: 5, Insightful

    all that is that you're not supposed to be able to do this. Sounds like it's working as designed.

    1. Re:I think the point of certificates and ... by sexconker · · Score: 4, Insightful

      Correct. Any other stance is just wrong. If you don't trust a host on your network communicating with the outside, then don't allow that to happen at all. If some things must be allowed, then work on a whitelist.

      If you're trying to read encrypted traffic when you are not one of the 2 hosts involved in the encrypted connection, then you are hostile and malevolent - no matter your purported reasoning or intention.

    2. Re:I think the point of certificates and ... by sexconker · · Score: 1, Insightful

      Disagreed. If you don't want shit leaving your network and you move to break encryption, you're still an attacker and you're still breaking encryption.

      I don't care what your reasoning is. I don't care if you OWN the hosts involved. I don't care what you're trying to prevent. By decrypting the traffic on a machine that is not one of the two endpoint hosts that are trying to talk to each other, you are in the wrong.

  3. IDIOTS by Anonymous Coward · · Score: 5, Insightful

    Preventing man in the middle attacks is the fucking point of TLS. Of course you can't perform a man in the middle attack without breaking TLS you morons.

  4. Re: Sigh by viperidaenz · · Score: 2, Insightful

    These MITM proxies only work because they create their own certificates for every domain you visit, signed by their own CA, which is installed as a trusted CA on every corporate machine.
    If the software you use doesn't trust that CA, you'll get notified of the MITM.
    If the software you use records the fingerprint of the host you connect to, you'll be notified of the changed fingerprint when the MITM proxy intercepts the connection, even if the machine trusts the MITM CA.

    They're not magic encryption breaking devices. They simply pose as the remote server and offer their own certificate. They then make another connection to the remote server. The issues come up when the remote server is dodgy. Any trust issues in that connection can't be forwarded on to the client. The proxy needs to decide to accept it or deny it.
    Advances made in browsers to detect these issues aren't always made in the proxies.
    Compromises get made in the configurations of them so a few broken websites will still work - from accepting weak encryption protocols to ignoring name mismatches to not checking for revoked certificates.

    It is actually possible in theory to build a secure MITM HTTPS proxy. In reality they contain bugs and compromises.