devopsy.kinsta.cloud

Tag: heartbleed

  • Trust and Computers Make the News

    Trust and Computers Make the News

    The Heartbleed bug in OpenSSL was major news this week.  While you are waiting for sudo apt-get dist-upgrade to run on all your servers, let’s take a minute to reflect on how the SSL trust system works and about the kinds of system relationships that depend on it.

    Just to recap, SSL-based trust derives from a “blessed” certificate authority, and this certificate authority can create other certificates that can be “trusted” as long as their lineage can be traced back to the original authority. In this system the answer to “Should I trust you?” is binary; the answer is either “yes” or “no” based on the certificate chain.

    In the event the certificate authority is compromised, then all of the derivative trusted systems become suspect as well.  Real certificates become indistinguishable from fake certificates and it is no longer possible to know “who or what to trust”.  Absolute all-or-nothing trust is an inherent weakness in certificate based trust and the X.509 based trust system.

    This situation got me thinking about the differences between human trust systems and computing trust systems.  It’s interesting that people take very different approaches to trusting computers as we do with each other.  We rarely can answer the question “Do I trust you?” about another person with a simple “yes” or a “no” answer to cover all scenarios.  Most of the time the answer is “it depends” on what we are trusting another person to do, which is better captured by the concept of trustworthiness.  In human networks you establish trustworthiness based on knowledge that you have about the person, their honesty and their reputation, and information from other people who have had experiences and interactions which are similar to one you are trying to assess.

    SSL doesn’t let us assess the trustworthiness of computers.  It presents a “definitive” trust answer, in which we place too much confidence.  Based on the SSL attestations of websites, we readily hand over our credit cards to strange computers in a way that we wouldn’t do with people.

    There are alternatives to SSL for establishing trust in computing.  For example, Pretty Good Privacy (PGP) is a trust system that operates a bit closer to how humans think about trust in one another, although it requires additional overhead to manage trust systems that are established on a case by case basis.  Moreover, PGP doesn’t necessarily incorporate historical experience akin to the “reliability” parameter of trustworthiness.

    This week’s news highlights the need for accessible and manageable trust systems that provide estimates of trustworthiness somewhere in between the type of trust provided by SSL and case by case managed trust systems like PGP.

  • Programmability in the Network: Stop a Bleeding Heart…

    Programmability in the Network: Stop a Bleeding Heart…

    heartbleedIt is not often the case that a security vulnerability can get the entire Internet talking. And not just the security community on the Internet, but everyone. End-users and IT alike are looking for answers and trying to mitigate Heartbleed. It has its own web site and logo. It’s that big of a deal.

    Many service providers have already patched their systems, but there are a whole lot of sites on the Internet and it’s estimated that a significant number of them are vulnerable.

    Netcraft notes that Heartbleed, based on OpenSSL, “affects around 17% of SSL web servers which use certificates issued by trusted certificate authorities.”  One of the most trusted sources of data regarding web server software in use today, Netcraft’s “most recent SSL Survey found that the heartbeat extension was enabled on 17.5% of SSL sites, accounting for around half a million certificates issued by trusted certificate authorities.”

    But it’s not just server software that may be vulnerable. Any device in the data path that terminates SSL and is based on OpenSSL could be vulnerable. Any “thing” that might use OpenSSL to enable secure communication and accepts connections could be vulnerable. In other words, hearts are bleeding all over the Internet right now, and it could take quite a while for the Internet in general to plug the holes.

    The hole itself is fairly simple – it takes advantage of the mishandling of what seems like an innocuous meta-protocol that runs atop TLS and DTLS that consists of two message types: HeartbeatRequest and HeartbeatResponse. It’s used to “ping” the other party in a secure connection to make sure the peer is alive. It can be used to offset idle times that might otherwise cause the connection to time out.

    It can also, thanks to a missing bounds check on the message structure, arbitrarily and completely silently grab 64 kilobytes of the server’s memory. That memory might include sensitive things like the private key used to encrypt communications or passwords or pieces of critical documents.

    heartbeat-memory

    Whatever might be in memory when the vulnerable software goes to grab it is leaving the building faster than Elvis – and without a trace. There’s no logs, no evidence of the theft, nothing. It’s clean and remotely executable by anyone on the Internet. That may explain the attention it’s currently getting.

    The answer to any vulnerability is ultimately to patch it. Depending on how many servers or systems are impacted, that could take some organizations days – assuming patches are available immediately. In the meantime, the heart is still bleeding and the only way to prevent more information from leaking is to shut off the hose.

    Except it’s not the only way.

    Programmability in the data path can mitigate this, now. Right now. Like in the next five minutes.

    Let’s review programmability in the network for a brief moment: you have, in the data path, a device. That device (or software) is capable of programmatically intercepting, inspecting, and transforming the data that’s traversing it. That means such a system can intercept a request to initiate SSL/TLS traffic, inspect it and, if it finds a request to include Heartbeat support it can reject the connection.

    before-after-heartbleed

    Interestingly, one of the primary motivators of early SDN architectures was the ability to support new or experimental protocols by inserting them into the data path in the network. While that’s a driver for academics, a more realistic driver for businesses is the ability to interact with protocols in flight and “fix” them – especially when the “fix” involves preventing the exploitation of a vulnerability.

    Programmability in the network enables this kind of rapid response to threats. Being able to deploy a solution very quickly to prevent further data leakage provides protection for both the organization and those who interact with its properties (employees, partners and customers). It also offers time for IT to patch and update all impacted systems without remaining vulnerable or taking the drastic step of going completely dark until the situation is resolved.

    By enabling a view of “infrastructure as code”, programmability not only enables a more software-oriented approach to deploying services, but also a software-oriented approach to quickly creating and deploying an appropriate response to emerging threats.

    A devops approach can facilitate this capability, and push protection into the network as code.