back to article SSL spy boxes on your network getting you down? But wait, here's an IETF draft to fix that

The Internet Engineering Task Force (IETF) has just put out a new draft for a standard that would enable folks to effectively bypass surveillance equipment on their networks to maintain secure connections. The working draft from three Cisco employees notes that so-called middleboxes – which intercept and decrypt connections – …

  1. Suricou Raven

    Obvious problem here.

    Much as the middlebox interception annoys me, it's usually there for solid legal reasons. So any means which allows for data to be snuck through the box without interception will quickly lead to a requirement to intercept it, which will inevitably break services, which puts us right back to the beginning.

    1. Lee D Silver badge

      Re: Obvious problem here.

      Indeed.

      It is basically a legal requirement for schools to intercept all Internet access and to push local SSL certs so that they can intercept SSL sessions for, e.g. Google queries.

      It's a requirement of things like extremism-detection, etc. but also just basic control of the service.

      Otherwise, quite literally, the children will run riot in any lesson that uses the Internet onto anything they like. Because any SSL session that's unmonitored is basically a proxy for them to get onto everything they like. Which is a breach of basic child protection.

      You can talk until the cows come home about "teacher supervision" etc. but it's impossible to stop a class of 30 rowdy kids with a non-IT teacher from Alt-Tabbing to their favourite proxy service (which change daily, and even include things like the Internet Archive, Google cached pages, etc.) when they're not looking. They are incredibly quick and smart about it and, sure, probably I'd spot most things if I was in the room long enough, but I'm an IT Manager for schools so you'd expect that. The average teacher doesn't stand a chance, especially with mobile devices and a "real" task set to do research on the Internet.

      And no filter in the world would be worth operating if you can't intercept SSL on managed workstations. It would literally never pick up anything but SSL sessions to Amazon AWS, with no hint of what's actually being viewed.

      Nobody suggests that people should be breaking connections on home wireless, guest networks, etc. (which should be filtered appropriately by user / whitelist anyway!) for no reason, but to suggest that totally removing the ability to intercept SSL and whitelist certain certificates on the machines to enable them to wrap connections to an intermediate filter? That just kills government-mandated diligence on the use of school Internet connections. You will quite literally just stop schools using the Internet for such things. Some may say that's no bad thing, but they didn't come from a generation born without knowledge of even Windows Vista, who grew up with technology at their fingertips, who are tapping all screens expecting them to be touch-capable from age 3, and whose schools have millions of pounds of investment in online resources and services for everything from paying your lunch money to checking out your library book to submitting your homework.

      You could quite radically set back advances in education by 20 years or more... that's how long I've been doing IT in schools and Internet access is a basic tool that's been present since the beginning of that.

      "Just whitelist?" I hear you say. Okay. I have FIVE different vendors at the moment who all insist I whitelist the entirety of the Amazon AWS IP ranges (literally a copy-paste of every IP that Amazon says they could end up with). What do you think that does when you then visit any random page that happens to be hosted on those ranges?

      1. Lysenko

        Re: Obvious problem here.

        I have FIVE different vendors at the moment who all insist I whitelist the entirety of the Amazon AWS IP ranges

        Just so I'm clear on this, these are vendors? You pay people for the privilege of receiving BOFH treatment? Is this some sort of central purchase contract foisted upon you from above or are you actually signing up for this directly? If it's the latter, there are some leather clad ladies with whips who might want to make your acquaintance.

        1. Lee D Silver badge

          Re: Obvious problem here.

          Vendors include massive, multi-national educational suppliers, including some government departments in some instances, offering products that we are required to use.

          Don't even go there. IT departments in school do not choose vendors for educational / statutory resources. If we did, things would be very different.

          1. Lysenko

            Re: Obvious problem here.

            OK, so that's "vendor" in the same sense as HMRC being a vendor of taxation services. I just wanted to clarify where the mandate for this was coming from.

      2. Adam 52 Silver badge

        Re: Obvious problem here.

        "I have FIVE different vendors at the moment who all insist I whitelist the entirety of the Amazon AWS IP ranges"

        You should point them at:

        http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html

        And

        http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-eips.html

      3. Random Q Hacker

        Re: Obvious problem here.

        Poor Lee, sounds like your vendors are driving you to madness. Maybe outsourcing basic school functions to the cloud wasn't the best idea after all. Do the kids not eat lunch when AWS is down?

        Whitelist by hostname, demand some consistency from your vendors.

  2. John Smith 19 Gold badge
    Unhappy

    "it works by essentially not trusting said equipment."

    Yes, the days when intermediate nodes could be relied upon not to snoop are long over.

    "middlebox interception annoys me, it's usually there for solid legal reasons. "

    Why?

    I'd say most are

    a)ISP's wanting to snoop traffic with a view to throttling traffic and

    b)Governments wanting to snoop traffic because....

    You have security issues about data leaving your network?

    Don't let it. Either forbid the connection and log the user and workstation who tries and/or do it through a proxy that filters any attempted file transfers.

    1. Anonymous Coward
      Anonymous Coward

      "do it through a proxy that filters any attempted file transfers."

      Which is exactly what the "middlebox" usually is, an "HTTPS proxy" (and other protocols too, if needed) able to look into what's happening in encrypted sessions.

      You may want to control what's getting out and what's getting in. People may attempt to send data out - and the company may be accountable if specific data leaks, or may attempt to being unlawful contents in, and again you may get into trouble - legal or not - for that.

      It may be not nice, but a company may have no other way - unluckily, a proxy able to filter user stupidity doesn't exist yet.

    2. Steve 53

      Re: "it works by essentially not trusting said equipment."

      You wouldn't use this type of box as a Government or ISP, it's obvious that the certs have been resigned if you know where to look (Just a case of checking the CA who signed the cert), and a government will very much struggle to insert a CA into every citizen's device.

      This technology is for corps who have control of the devices on their network (GPO) and are looking to protect themselves against Malware, Dataloss, etc. And that sort of technology is very much going to be needed to meet GDPR.

      1. streaky

        Re: "it works by essentially not trusting said equipment."

        a government will very much struggle to insert a CA into every citizen's device

        It's not that difficult really, literally any root exploit would allow it, or they can force keys onto systems when they pass through customs. I'd assume just as likely they'd force a CA to miss-issue in controlled (targetted) numbers and nobody would notice which is what things like that HPKP are (were - RIP) for and what Expect-CT does absolutely nothing to prevent.

        One assumes in China for example there's a lot of extra root CA keys nobody can explain in operating systems. We've literally had cases of this getting out and hitting the wider world and it taking a long time for anybody to notice.

    3. illiad

      Re: "it works by essentially not trusting said equipment."

      and

      c) websites wanting to stop people by-passing their ads!

    4. Anonymous Coward
      Anonymous Coward

      Re: "it works by essentially not trusting said equipment."

      "I'd say most are.."

      They're not. Most snoopers are used by organisations with a perfectly legitimate and often legally mandated requirement to inspect their own traffic. Yes they're a pain in the arse, but do you honestly think a bank or government department should have no idea what is actually being passed between its own servers?

      "You have security issues about data leaving your network?

      Don't let it"

      Ahaha, right. Must be nice to live in a world where there's only "inside the network" and "outside the network" and where disconnecting all your various networks from one another and from the world is a sane and reasonable approach.

      1. Adam 52 Silver badge

        Re: "it works by essentially not trusting said equipment."

        "And that sort of technology is very much going to be needed to meet GDPR"

        Complete rubbish. Not required at all for GDPR. GDPR requires adequate security. If it's already on the way out when you discover it then you've failed. Only a fool trusts their internal network, a fool who is likely about to have a theft by insider incident.

        "legally mandated requirement to inspect their own traffic."

        I'm not aware of any legal requirements to inspect traffic. Plenty of legal precedent *prohibiting* the inspection of traffic - not least RIPA and HRA - but none that requires it.

        1. Anonymous Coward
          Anonymous Coward

          Re: "it works by essentially not trusting said equipment."

          "Complete rubbish. Not required at all for GDPR. GDPR requires adequate security"

          It says nothing of the sort. GDPR's language is specifically broad and makes no mention of "adequate" in reference to protection except where discussing international arrangements.

          "If it's already on the way out when you discover it then you've failed. "

          Unless your packet inspection finds it and blocks it. Which is one of the principal reasons it's used.

          "I'm not aware of any legal requirements to inspect traffic"

          This doesn't mean they don't exist. Deep-packet inspection is an effective requirement for PCI-DSS, HIPAA and a handful of other regulations, and should be considered a significant option in any serious defence-in-depth approach. Even if you're not inspecting the packets, centralising your TLS infrastructure is a good choice for plenty of architectures.

          "RIPA and HRA"

          Which bits of these acts, exactly, prevent TLS snooping?

          1. Adam 52 Silver badge

            Re: "it works by essentially not trusting said equipment."

            You are aware that PCI-DSS is not a legal requirement? PCI is a club, not a law making body. Primary legislation trumps recommendations. PCI has various levels of certification, as anyone who has actually certified or audited knows...

            Anyway, on to real law:

            RIPA s1(1) "It shall be an offence for a person intentionally and without lawful authority to intercept..." Note a private network is covered if connected to the public Internet. Routine monitoring is *not* acceptable under the associated regulations governing what is lawful.

            The HRA incorporates ECHR Article 8 the right to privacy and family life, and has been confirmed by both the Supreme Court in England and the European Court (Barbulescu) to cover monitoring employee traffic.

            Also Data Protection Act requires any processing of personal data - including communications - to be subject to the usual rules. And the Information Commissioner's code says "it will usually be intrusive to monitor your employees" and "employees have an expectation of privacy".

            You can argue as much as you like, but unfortunately the regulators and judiciary have time and time again disagreed with you. And you know what, I trust the highest judges in Europe to know the law better than a random AC on the Internet who doesn't even know what legislation is.

            1. Anonymous Coward
              Anonymous Coward

              Re: "it works by essentially not trusting said equipment."

              "You are aware that PCI-DSS is not a legal requirement?"

              Except where it is, including a number of US states. Meanwhile HIPAA is a legal requirement, and there are a bunch of other network security standards backed by legislation across the world, including for example the

              "Anyway, on to real law..:"

              You're *grossly* misreading these laws. The HRA's right to privacy is not absolute. RIPA tightly defines what constitutes surveillance, a definition most DPI techs don't meet. More to the point it provides an abundance of exemptions, including consent (e.g. your employment contract) and the prevention of serious crime. Plus there's an entire law in the form of the Lawful Business Practice (Interception of Communications) Regulations 2000, effectively authorising all the practises we're talking about.

              1. streaky

                Re: "it works by essentially not trusting said equipment."

                Lets pretend that RIPA/ICR is supreme to the ECHR if the ECJ decides they're incompatible.

                Untested and legal are not at all the same thing. It's best to just not do if you don't have an ethical sounding lawful excuse. Don't want data escaping? Restrict it to as few people as possible and do due diligence on people and not for nothing - don't allow people to connect to whatever they like. Way more reasonable and reliable than intercepting private comms and worse it's a bit bolting the door after the horse has fucked off with your customer db; who even has time to audit that much data?

                If you let me have access to data and you let me connect to things if I really want to there's nothing stopping me asset stripping that data and you'd never know. Why? Because I'm competent. I don't care how good your systems are so, yeah, what's the use of your system?

  3. sequester
    WTF?

    I don't get it.

    Problem: Network nodes break TLS.

    Proposed solution: Wrap TLS in a *really* dumb transport (no, HTTP, is *not* the solution to your problems, it *is* a problem), make it less efficient, slow it down, and basically give it that mangy "web" smell.

    How does that solve any real problems? It's still TLS, and the snoop boxes will just learn to screw with that as well. All this does is pollute the RFC ecosystem even more with yet another ill-conceived and badly thought out band-aid that nobody needs, and that will eventually spawn the mandatory half-dozen errata and clarification pamphlets. Maybe the encapsulating HTTP connection could be protected too, oh I know, let's use TLS?

    1. Steve 53

      Re: I don't get it.

      Couldn't agree more. Malware is pretty much always delivered over SSL/TLS because the writes know this is a blindspot for many organisations. The SSL/TLS Interception proxies are there to decrypt this and stop the malware. If there is a fallback to ATLS, then the malware will move to the new blindspot created by it, and the middleboxes will shortly follow.

      There is plenty of potential for abuse of this technology, and it doesn't always work very well (CA's need to be distributed, applications pin certificates, breaks client tls auth, etc), but that doesn't make ATLS a sensible option.

      As far as privacy is concerned, the browsers should be placing a massive "Eye of Sauron" icon in the address bar rather than "Secure".

    2. illiad

      Re: I don't get it.

      If you are using a managed network (active directory) and network managed antivirus, it gets more complicated (hey I'm no expert, the network guy does it.. :/) then when FB and twits decide to do some TLS, they(browsers, AV, whatev :( ) all stop authorizing them! Take the PC off domain, there is no problem...

      Even some websites 'on domain' think there is an adblock / virus, etc - take it 'off domain' , no other changes, the same website sees NO problem..

    3. streaky

      Re: I don't get it.

      It really is a solution looking for a problem. It's also not a solution.

  4. DropBear

    Huh?

    I can see an enterprise being able to sneak trusted certificates into their own devices but how exactly does an ISP convince your browser at home - that is not supposed to be under their control in any sense other than using them as a pipe - that you're talking to Google when you're talking to them? And if they can do it why can't absolutely anyone else on the wire? And if anyone can, what exactly is it that HTTPS is supposed to be good for...?

    1. Death_Ninja

      Re: Huh?

      If you are talking about nation state spying, they have compromised/paid for the root certs higher up the chain and are decrypting further down the line - boxes in ISP's or taps on international cables or simply ordering your favourite social media provider to allow them to sniff the unencrypted traffic at the other end.

      Did you not read Snowden?

      1. DropBear

        Re: Huh?

        I asked "how does an ISP", not "how does the NSA". For at least some of us not living in the Land Of The Free they're absolutely not the same thing.

        1. Anonymous Coward
          Anonymous Coward

          Re: Huh?

          Swap GCHQ for NSA then. In fact, its more likely to be GCHQ doing the bidding of the NSA anyway.

          As for your ISP doing it for their own shits and giggles? Unlikely.

          1. DropBear

            Re: Huh?

            You might be surprised, but I'm nowhere near GCHQ either. Like, at all. Not even close. And the point of the whole question about ISPs was precisely that I don't see how they could do that either, except the article seems to think they just can: "Middleboxes can also be used by organizations and ISPs to monitor employees and citizens" So, again - I'd really like to know how my _ISP_ is allegedly able to simply listen in on any HTTPS connection with their magic "middlebox"...

            PS - and no, despite the name it's not Oz either - forget the whole "five eyes" thing, I'm nowhere near it.

  5. foxyshadis

    The history of networking in a nutshell:

    "it's worth noting that security considerations to this approach have yet to be considered: the relevant section is listed as simply "To do.""

    1. Teknogrot

      Re: The history of networking in a nutshell:

      I think we can expand that to the history of tech in general.

  6. Anonymous Coward
    Anonymous Coward

    In my experience

    The legit "snoop" boxes are given the keys to break connections, and in some cases given new keys for the next hop. This is not unusual in corporate environments.

    Regardless of where in the stack TLS is applied, if a device is given the keys then the problem remains. Is this really a problem that needs solving or just a ruse by network vendors to replace all your existing "snoop" boxes with expensive upgrades?

  7. Amos1

    "Not only would this approach make sysadmins' lives easier, ..."

    Clearly the author has never looked at the HTTPS traffic on even a medium-sized business, say a thousand employees. On any given day there are between two and dozens of stops for compromised legit sites serving up malware over HTTPS.

    This proposal just adds another covert channel for malware infiltration and data exfiltration. If you want to make a sysadmin's job hard, get yourself hacked by one of your endpoints and end users.

  8. GnuTzu
    Meh

    Proxy Admins Will Block

    Just as categorization filters label certain sites as "anonymizers", which most proxy admins block, sites that use this kind of thing will also be so categorized. I predict that proxy products will gain features to try to automatically detect this sort of thing--because malware. Where businesses are required to do DLP, as in PCI, you are required to participate in protecting sensitive information--and you have no privacy--let alone a reasonable expectation thereof. (And, it gets really boring seeing emails of executives with attachments of loan applications and such. People, stop using your work email for personal business. When the people that run the World are this stupid, you know we're all doomed.)

    1. J. Cook Silver badge

      Re: Proxy Admins Will Block

      @GnuTzu: And you've just written about 80% of my reply.

      We use transparent proxy servers at my place of employ as well, along with DLP features on our mail gateways; I can guarantee you that it firmly falls under the category of 'network security' rather than 'data snooping'- as the admin of the devices, I nether want or need to know what the browsing habits of my fellow ~1500-2000 co-workers are, nor do I care. What I do care about is if a machine is trying to talk to a CnC server because it's been 0wned, or if someone is trying ti exfiltrate company sensitive data out.

      Our employees know this, because it's part of the information security agreement they have to sign before we give them their network credentials on their second day.

      (and yeah- there are a good number of people that use their work emails for non-work business. We partly tolerate it because most of the offenders don't go overboard with it.)

  9. druck Silver badge

    Poxy Proxy

    A number of proxies will make all TLS connections appear secure, and hide issues with actual site itself, such as having invalid certificate. This can make browsing less safe.

    1. J. Cook Silver badge

      Re: Poxy Proxy

      @druck: those proxies are misconfigured, then. Or they were configured by someone who didn't know better.

  10. Tom Paine
    FAIL

    a standard mechanism for securely passing data through middleboxes without having to screw around with custom root certificate authorities...

    ...stops reading.

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