With smartphones, tablets, and other mobile devices assuming equal importance with connected hardware and desktop-based systems as viable ways of gaining access to corporate networks and the internet at large, security professionals are having to devote additional attention to keeping these portable “endpoints” safe – just like any other network resource.
One way of doing this (which has been particularly successful in securing business transactions and online communication) is through the combined use of digital certificates and secure protocols (i.e., rules and mechanisms) for information transmission.
The Importance of Protocols
In today’s IT environment, endpoint devices like tablets and mobile phones share a similar sort of relationship with their network infrastructure as web browsers do to the internet. It’s a client – server link that relies on messages being relayed back and forth between sending and receiving nodes. And it’s this same interplay between sender and receiver that presents potential attackers with an avenue for gaining access to privileged communications.
But it’s also an opportunity for security mechanisms to be put in place, so as to ensure that the connections between clients and servers will always maintain an assured level of confidentiality or integrity. Encryption protocols and the issuing of digital certificates have been instrumental in this.
The main protocol used to secure internet communications is SSL/TLS, or Secure Sockets Layer / Transport Layer Security. This method employs digital certificates to provide authentication and encryption.
When an SSL/TLS connection is made, a client (such as a web browser or mobile app) establishes a link to a server, which responds with its digital SSL certificate. The public encryption key in the web server’s certificate (for example) is used to encrypt traffic to the web site, while the certificate identifies who owns the site.
As an assurance that a certificate is authentic and valid, it’s digitally signed by a root certificate which belongs to a trusted Certificate Authority, or CA. Operating systems, web browsers, and certain online applications maintain lists of trusted CA root certificates, so that they can easily verify certificates which CAs have issued and signed.
For each client – server link up, a connection is only allowed if the certificate being used for authentication and encryption was issued by a Certificate Authority that’s trusted by the operating system, browser, or app. Once the verification is made, all data passing between endpoint and server is encrypted using the server’s public key. Such a connection is considered to be secure. At least, in theory.
The Trouble With CAs
Verification of digital certificates depends on a hierarchy or “chain of trust” involving several parties: The user or endpoint client, the server, its trusted list of Certificate Authorities, and the CAs themselves.
The problem is that these same Certificate Authorities aren’t invulnerable to attack. In the recent past, hackers have broken into a number of CA networks (including DigiNotar and Comodo), and signed faked digital certificates in the names of organizations such as Microsoft, Mozilla Corp., Yahoo Inc., Google Inc.. Facebook, and Twitter.
Once breaches like this are discovered, a crisis of confidence occurs, and establishing trust in a Certificate Authority which has had one or more of its certificates compromised in this way becomes difficult, to say the least.
Besides the Man-in-the-Middle (MitM) type of interception attack perpetrated by malicious hackers on client – server communications using bogus digital certificates, certain legitimate network security measures have the same effect.
HTTPS interception is a network monitoring strategy employed by a number of organizations, which involves substituting a security system’s own digital certificates for the ones being used to encrypt data transmissions. This makes it possible to view fine-grained details of the data traffic on the network. It also makes the enforcement of secure protocols complex and prone to error.
Certificate pinning (also referred to as public key pinning) provides a framework for reducing the tendency to rely on trusting third parties when making security decisions concerning identity. A certificate pinning framework creates an independent “whitelist” defining what a trustworthy digital certificate or encryption key should look like. Security intelligence, knowledge bases, and the history of relationships between applications and organizations or services with proven public keys and digital certificates form the basis of that list.
By referring to the whitelist, a web host or service may be directly identified from its public key or known certificate – without having to look to a third party, for verification. Certificate pinning is backwards-compatible with existing digital certificates, and doesn’t require web sites to modify their existing certificate chains.
The framework provides a layer of defense against MitM attacks that use forged certificates, and certificate pinning is deployed by several of the major IT players. For example, Google’s Chrome browser pins the certificates for Google sites, with only specific certificates signed by the Google Internet Authority regarded as trustworthy. Microsoft has included certificate pinning in its EMET protection tool, with Certificate Trust as a feature that’s enabled by default in Internet Explorer.
Certificate transparency is an additional security measure which allows web browsers to check if a digital certificate which has been presented is the one normally used by a particular web site. A mismatch results in the type of warning occasionally displayed by Google Chrome for example, if a Google page returns a different certificate than the one expected – even if it’s formally valid.
Response Headers and Secure Protocols
Certificates and encryption are all well and good. But security protection needs to be extended to all aspects of the data that’s transmitted across a corporate network, or the internet. Typically, each piece of information sent via the HTTP internet protocol has an associated set of extra or metadata, describing the data packets in more detail.
Security based HTTP response headers are special prefixes added to each HTTP response coming from a web site. There are a number of variants on this, which have a bearing on the certificate / public key pinning debate.
This is the secure HTTP protocol (HTTP Secure) which causes web browsers or other online apps to display a locked padlock symbol, when you visit a web site that uses it. HTTPS is pretty much the baseline level for secure internet data transfer.
HSTS stands for HTTP Strict Transport Security. It’s a policy mechanism which enables web servers to enforce the use of Transport Layer Security (TLS) in a web browser, or any other application that qualifies as a compliant User Agent (or UA). HSTS effectively forces all communication on the endpoint or client side to occur over a secure transport layer, and acts as a hedge against Man-in-the-Middle attacks.
Users of browser extensions or mobile apps of the “HTTPS Everywhere” variety will recognize the effects of HSTS: It forces web connections to sites to use the secure HTTPS, even if the web address is typed in as HTTP.
The HPKP response header allows users to whitelist the fingerprints of specific cryptographic identities (such as public keys or digital certificates). This provides a database that can guard against rogue Certificate Authorities issuing certificates for a site, or trusted Certificate Authorities which have been compromised into issuing fraudulent certificates.
HPKP instructs browsers and endpoints to only connect to a host if it can present a known SSL/TLS public key – or a digital certificate which has been signed by a known key. The software won’t connect to a server or host if the SSL/TLS key has altered in some unexpected way.
The acronym HPKP stands for HTTP Public-Key Pinning – and it’s this response header that’s central to the framework of certificate pinning.
Content Security Policy (CSP)
The Content Security Policy or CSP response header enables a web host to set up a whitelist of sources that any browser accessing the site is allowed to load content from. Browsers and endpoints are provided with clear instructions on the type and behavior of content on the web site.
A well-configured CSP can provide effective defense against attacks like cross-site-scripting (XSS), ad-injecting malware, and other injection attacks.
The Threat of Memory
As with all things in life, there’s a downside to the use of HTTP response headers and public key pinning. For HPKP and certificate pinning in general, one of the biggest issues is the “memory effect”.
Certificate pins (the digital fingerprint database or whitelist of approved certificates and keys) have to remain valid for a set period of time. In turn, each pin is associated with a unique cryptographic identity (public key or certificate) that a web site has to possess, in order to continue being recognized.
If for some reason possession or control of these identities is lost – or if the validity period expires, without the pins being renewed – then the web site will effectively close up shop, as no clients will be able to verify it.
To guard against this, every valid HPKP configuration has to include at least one backup key. In addition, the configuration must at any given time be offering at least one pin which matches the configuration presented to all its previous users.
Certificate Pinning Revisited
A successful certificate pinning strategy must begin with a threat assessment, to determine whether pinning is the ideal solution to address the real threats that a web site may be facing. Implementing the strategy requires an understanding of the uses and applications of HPKP, and of Public Key Infrastructure (PKI) in general.
Having put a framework in place, it then becomes a priority for certificate pinning keys to be safely stored and guarded, with backup keys held in a separate storage location, in case the primary server goes down.
If pinning keys are to be changed periodically, there’s also the need for a carefully planned and executed key rotation schedule which allows users who have had access only to older key sets, or those who are using legacy software and devices, to continue to have access to the web site throughout.
Share this Post