back to article Are you undermining your web security by checking on it with the wrong tools?

Your antivirus and network protection efforts may actually be undermining network security, a new paper and subsequent US-CERT advisory have warned. The issue comes with the use of HTTPS interception middleboxes and network monitoring products. They are extremely common and are used to check that nothing untoward is going on …

  1. Alister

    Looking at some of the big names shown in the report, it really is a sorry state of affairs.

    Of the 12 appliances tested, only one, from Bluecoat achieves an A rating, and the majority of the others are C or F. The Microsoft one deserves an F--- if such were possible, as it only offers SSLv2 connections, but you expect better from Barracuda, Checkpoint et al.

    I shouldn't be surprised though, as we recently had to remove ECDHE ciphers from some of our servers on an e-commerce site, as the WAF didn't support them, thus weakening the whole environment's security.

    1. Anonymous Coward
      Anonymous Coward

      Bit disappointed

      They never tested Palo Alto's..

      Reports like this are simply to identify how well their implementation works, but they often get misappropriated to sling mud. What it does not do is balance that against the benefits it provides, for example:

      a) is it better have the best SSL/TLS implementation and forgo IPS/IDS/DPI?

      b) Weaken the SSL/TLS but have the visbility and security that IPS/IDS/DPI can provide?

      Finally, not everybody can afford Bluecoat.. So you work with what you have and can afford.

      1. Amos1

        Re: Bit disappointed

        Agreed. They regurgitated some reports on client-side home user products and interpolated it into real data. Right. The reality is that 50% of web traffic is now HTTPS and getting higher each month. Website classification software running at the network level cannot without intercept because, well, the URL is encrypted. If you can go by IP address from a company that does not do intercept you can go anywhere. We see a couple of legitimate websites each day that are infected and the traffic comes in by HTTPS.

        It reads like the Russians wrote that thing. "We need to stop companies and governments from decrypting HTTPS because it detects our tools. Let's get their own agency to write a report saying it's a bad thing."

        It's all a balance. Companies are responsible for the data they hold about others. They need to protect ALL of that data and not worry about the privacy of some individual on their network doing personal stuff. If you don't want your HTTPS traffic decrypted, save it for home.

      2. big_D Silver badge

        Re: Bit disappointed

        I would say, at the moment, if you can't do it properly, don't do it at all!

        These products ARE creating weaknesses in the chain. Yes, inspecting the traffic is important, but not at the cost of opening yourself up to other attacks.

        1. K
          Terminator

          Re: Bit disappointed

          I'd be curious to know if you work in security?

          Out of all the incidents I've been involved with, 90% of them are internal, so visibility is by far the most important tool in any security/awareness situation - normally people doing something stupid rather than malicious, but still! Whilst the issues raised in this report must not be ignored (and will hopefully encourage vendors to up their game) the benefits of what their systems do outweigh the risks they impose - Of course, one a exploit starts attacking these boxes, I will change my mind!

  2. Anonymous Coward
    Pint

    So, uhm...

    "In other words, the user can only be sure that their connection to the interception product is legit, but has no idea whether the rest of the communication – to the web server, over the internet – is secure or has been compromised."

    I think it boils down to a very basic issue once more: understand what the heck you're doing. Most modern operating systems (Windows Server, *BSD and even Linux) provide several tools which you can use to check connections and the state their in. Obviously it is sometimes preferable to do outside checks (like with port scans) but even that can be done by utilizing a second server (for example).

    The main problem? Simple: you have to know what the heck you're doing. You need a basic underlying understanding of the encryption process, how to monitor network connections (I've come across too many people who had no clue how to use tcpdump or netcat for example) and interpret the results.

    And that seems a bit too much for more "modern" companies, time is also money afterall, so they'd rather rely on out-of-the-box ready to use gizmo's like these. Without stopping to think about possible consequences.

    Welcome to the modern world of ICT: where a lot of people stopped to think for themselves, don't bother to try and understand (learn) something new and where you totally rely on what others tell you without questioning nor challenging them.

    PS: Doesn't this same risk apply when your HTTPS connection is using a reverse proxy (as suggested by an article some weeks ago)?

    1. Alister

      Re: So, uhm...

      The main problem? Simple: you have to know what the heck you're doing. You need a basic underlying understanding of the encryption process, how to monitor network connections (I've come across too many people who had no clue how to use tcpdump or netcat for example) and interpret the results.

      And that seems a bit too much for more "modern" companies, time is also money after all, so they'd rather rely on out-of-the-box ready to use gizmo's like these. Without stopping to think about possible consequences.

      I think you have to bear in mind that to achieve PCI-DSS compliance, it is often much easier to use a recognised appliance rather than roll your own monitoring at the server level, most QAs I've come across like to have pretty graphs every month, rather than have to wade through log analysis reports.

      I remember being met by a stunned silence when one QA asked how we had implemented IDP for HTTPS traffic, and we told him how we did it with a roll-your-own setup on an Nginx box.

      1. K
        Pint

        Re: So, uhm...

        I've no issue with roll-your-own, but the benefit of using a commercial solution is they have far more resource and capacity to implement broad IPS/DPS and vulnerability protection.. If you (or your team) have done this, I'd be really interested to know how you manage this process etc :)

        1. Alister

          Re: So, uhm...

          If you (or your team) have done this, I'd be really interested to know how you manage this process etc :)

          We were put in the position that the client wanted a secure environment with WAF / IPS but was too cheap to pay for it.

          So we built a lash up of nginx, naxsi, and fail2ban, with munin to provide some reporting and pretty graphs, as a proxy to our apache servers. HTTPS was decrypted, read, and re-encrypted using the proper certs and ciphers.

          It worked surprisingly well, although I wouldn't say it was as effective or as maintainable as a commercial appliance product would have been.

  3. John Smith 19 Gold badge
    Unhappy

    Sounds like a bunch of companies saw a gap in the market and jumped in

    With software that does the bare minimum of what is required in what is frankly the laziest way possible.

    This is what tends to happen when you start selling products based on you brand names image for quality, rather than actually writing a quality product to do the task.

    One cloaks a s**t product the other way enhances your brand and its reputation.

  4. robert 15

    Might be worth noting in the article that some products have been updated since the paper was written, as the authors mention near the end..

    eg. Fortinet was tested against their 5.4.0 firmware, the vulnerability listed in the paper was fixed in 5.4.1 and they are now at 5.4.4

  5. Gerry 3
    FAIL

    I'm none the wiser

    Perhaps this is intended only for company IT professions rather than ordinary PC users, but I'm none the wiser. El Reg didn't make things clear, e.g. whether it's relevant and what if anything I need to do.

    Similarly, the badssl site is meaningless, as is the USCERT site. The latter is particularly hopeless because its feedback form brings up an Access Denied page and loses all the comments that have been entered, even if cookies are accepted and Ghostery is paused.

    OK, I'm probably just thick, but I can't be the only one.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like