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.

15 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 Anonymous+Brave+Guy · · Score: 2

      That's a nice ideal, but in a corporate environment you may have legal and regulatory constraints that prohibit you from actually providing end-to-end encryption from inside your network to outside or vice versa, and the kinds of devices we're talking about fit in between. If you're using someone else's computer, for example at work, then you should never assume that your browser is truly end-to-end encrypting a connection to your bank or GMail or whatever. It is common these days for large organisations to operate their own internal CA and add it as a root authority on all of the organisation's devices for exactly this purpose.

      Just to be clear, this doesn't necessarily imply that anything sinister is going on. There are several legitimate and practical reasons to deploy these kinds of tools, which is why it's a problem if they don't work properly and degrade security in the process. In many places, it is also a legal requirement to disclose the possibility rather than doing it covertly. Still, if you want a truly secure and private connection, you should use your own devices obtained from reputable sources, not something managed by your employer or any other third party.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  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: 2

      It's perfectly logical that an intermediary device can decrypt and re-encrypt data with no flaw in the security protocols, if suitable certificates and trust are configured on both the originating device and the intermediary.

      Fucking WRONG.

      Any such intermediary is breaking the protocol by doing that, even if it does so successfully. The protocol is to facilitate END-TO-END encryption between TWO AND ONLY TWO hosts on the network.

      A host in the middle decrypting that traffic for any reason is by definition an attacker.

  3. daqfuq? "still"? by Anonymous Coward · · Score: 2, Funny

    Tautologies are still taugologous? Who could have known???

  4. New definition for middleware? by Nkwe · · Score: 4, Informative

    Encrypted traffic inspection devices (also known as middleware)

    Really? I don't think I have ever heard of middleware used in that context. I have always thought of middleware as a software layer that abstracts something between applications. It seems weird to refer to a hardware device as "middleware".

    1. Re:New definition for middleware? by Quince+alPillan · · Score: 2

      It's the same thing. The software layer just runs on it's own separate networking hardware in between the client and server.

    2. Re:New definition for middleware? by fustakrakich · · Score: 5, Funny

      They probably meant *meddleware*

      --
      “He’s not deformed, he’s just drunk!”
    3. Re:New definition for middleware? by mysidia · · Score: 4, Informative

      I think whoever wrote or proofread the ZDNet article Introduced mistakes, here.

      The phrases "TLS Middleware", "TLS middleware appliances," and "Middleware appliances" appear throughout the article Slashdot linked, BUT
      the paper does not use the word even once. They are called Middleboxes in the study.

  5. 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.

    1. Re:IDIOTS by WaffleMonster · · Score: 2

      Preventing man in the middle attacks is the fucking point of TLS.

      The point of TLS is enforcing trust relationships.

      Of course you can't perform a man in the middle attack without breaking TLS you morons.

      Delegating termination of TLS to something you trust is not an attack. You are confusing middlebox implementation failure with design failure.

      This is no different than delegating your secretary to answer a secure call on your behalf and having them relay relevant information to you.

  6. NEWSFLASH: TLS (finally) works as designed by SLOGEN · · Score: 2

    Nice angle on the story there /.

    --
    SLOGEN [ http://ungdomshus.nu : Sebastian cover music]
  7. 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.