{"id":2744,"date":"2016-07-06T13:19:03","date_gmt":"2016-07-06T13:19:03","guid":{"rendered":"https:\/\/www.thesslstore.com\/blog\/?p=2744"},"modified":"2024-05-20T16:19:00","modified_gmt":"2024-05-20T20:19:00","slug":"an-introduction-to-pinning","status":"publish","type":"post","link":"https:\/\/www.thesslstore.com\/blog\/an-introduction-to-pinning\/","title":{"rendered":"SSL Pinning: Definition & Introduction"},"content":{"rendered":"

SSL Pinning & how it can protect you.<\/h2>\n

If you know the term HPKP (HTTP Public Key Pinning), that is a specific implementation of pinning that is frequently used with SSL. Here we will be covering \u201cpinning\u201d in a more general sense. Please note that pinning and HPKP are different, and not everything discussed here is accurate about HPKP. However, this article will still help you understand some of the concepts involved with HPKP. A follow-up article will specifically discuss HPKP, its implementation, and challenges.<\/p>\n

What is Certificate Pinning?<\/strong><\/h2>\n

Pinning is an optional mechanism that can be used to improve the security of a service or site that relies on SSL Certificates. Pinning allows you to specify a cryptographic identity that should be accepted by users visiting your site.<\/p>\n

That sounds complex, but it\u2019s actually pretty simple. Let\u2019s start by breaking down that down:<\/p>\n

A cryptographic identity is a file that can prove the identity of a server\/host through cryptography. An SSL certificate, a public key, and a CSR are all examples of a cryptographic identity. That pin would then tell the client to remember that identity (or identities) and only accept those when establishing future secure connections.<\/p>\n

So, if you wanted to use pinning, you would configure your server (in some situations \u2013 think internal systems \u2013 you may also configure the clients) and specify what you wanted to pin. Browsers and other clients would evaluate the pinned identity on every connection. If any other identity was presented, the client would abort the connection.<\/p>\n

To think big picture: an SSL connection tells the client to make an encrypted connection with any identity matching that host. Pinning tells the client a specific <\/strong>identity they should accept when making a secure connection.<\/p>\n

So, for example, if our site is TheSSLStore.com<\/a><\/strong>, we could pin an identity. When a user visits our site, they would receive the pinned information. On a future visit, their browser would take action if we tried to get the client to use a different identity.<\/p>\n<\/span>\n

What Pinning Protects You From<\/strong><\/h2>\n

One of the inherent risks to the SSL ecosystem is mis-issuance. This is when an unauthorized certificate is issued for a domain\/host you control. This can happen with both public and private PKIs<\/a>, though the public cases are certainly better known.<\/p>\n

Mis-issuance can take multiple forms. In 2011, the Dutch CA DigiNotar was hacked, in what is probably the largest compromise of a public CA. A hacker was able to access their internal systems and issue certificates for any site.\u00a0 This was a total compromise of the CA system because those certificates had inaccurate cryptographic identities and the CA\u2019s issuance systems had been accessed by an unauthorized user.<\/p>\n

More recently, Live.fi, a website operated by Microsoft in Finland, was victim of mis-issuance. In this case, the CA was not at fault for the mis-issuance. The Live.fi service, which offers free webmail, mistakenly allowed a user to register an email address that is whitelisted for SSL certificate approval. This allowed someone without proper authorization to get a certificate for a site they did not own.<\/p>\n

In both these cases, pinning could have protected users of those sites (and in the case of DigiNotar, many of Google\u2019s services were protected as they were early adopters of pinning). When a user\u2019s device encountered the mis-issued certificate, it would compare that to the pinned data, and see that there was a mismatch. They would then be warned or blocked from visiting the site.<\/p>\n

As you can see, mis-issuance is complex. The risk of mis-issuance increases with the profile of your site. A site like gmail.com is much more likely to be attacked than a personal blog. But depending on your threat model, any site may be at risk. State actors have been known to issue fraudulent certificates for a variety of sites, including smaller sites that may have gotten attention for political reasons.<\/p>\n

Some Pins Are Better Than Others<\/strong><\/h2>\n

In practice, there are objectively better choices on what you pin. For example, pinning a leaf certificate (those are the certificates issued to specific domains, like the certificate for \u201cwikipedia.org\u201d) is not a very good choice. That\u2019s because there are a number of situations where you may want, or need, to change your leaf, and some of these situations may be unpredictable or out of your control.<\/p>\n

Returning to our example above about Wikipedia.org; if they had pinned that leaf and then suffered key compromise, they would be in trouble. Remember that pinning is done with a specific<\/strong> identity (be it a certificate, public key, etc, as discussed before). So even if they got another leaf certificate from the same vendor (and it used the same key pair), pinning would view that as the wrong identity.<\/p>\n

Pinning an intermediate certificate gives you more flexibility. If we pinned an intermediate certificate instead of our leaf, we would<\/strong> be able to switch out our leaf with another leaf from that same intermediate. But, if we were using a public CA, they may change their infrastructure without telling us. So when we renew our certificate the next year, we may get a leaf issued from a different intermediate. So that choice has its own unique downsides.<\/p>\n

You can choose to pin multiple identities and back-ups in order to reduce the chance of problems. But pinning best practices are a complicated topic we won\u2019t broach here. Just know that there you should make deliberate choices about what <\/em>you choose to pin.<\/p>\n

In a follow-up post, we will talk about HPKP, an implementation of pinning for use on the internet. The specifics of HPKP work a bit differently \u2013 but it\u2019s conceptually similar. We will talk about the pros and cons, and why you may be better off not pinning at all.<\/p>\n","protected":false},"excerpt":{"rendered":"

SSL Pinning & how it can protect you. If you know the term HPKP (HTTP Public Key Pinning), that is a specific implementation of pinning that is frequently used with…<\/p>\n","protected":false},"author":2,"featured_media":2842,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"

__CONFIG_colors_palette__{\"active_palette\":0,\"config\":{\"colors\":{\"11f38\":{\"name\":\"Main Accent\",\"parent\":-1},\"dd1f9\":{\"name\":\"Main Accent Light\",\"parent\":\"11f38\",\"lock\":{\"lightness\":1}}},\"gradients\":[]},\"palettes\":[{\"name\":\"Default\",\"value\":{\"colors\":{\"11f38\":{\"val\":\"rgb(30, 136, 69)\",\"hsl\":{\"h\":142,\"s\":0.63,\"l\":0.32,\"a\":1}},\"dd1f9\":{\"val\":\"rgba(4, 215, 85, 0.08)\",\"hsl_parent_dependency\":{\"h\":143,\"s\":0.96,\"l\":0.42,\"a\":0.08}}},\"gradients\":[]},\"original\":{\"colors\":{\"11f38\":{\"val\":\"rgb(30, 136, 69)\",\"hsl\":{\"h\":142,\"s\":0.63,\"l\":0.32,\"a\":1}},\"dd1f9\":{\"val\":\"rgba(4, 215, 85, 0.08)\",\"hsl_parent_dependency\":{\"h\":143,\"s\":0.96,\"l\":0.42,\"a\":0.08}}},\"gradients\":[]}}]}__CONFIG_colors_palette__<\/div>
<\/div><\/div><\/path><\/path><\/symbol><\/path><\/path><\/symbol><\/path><\/path><\/symbol><\/svg>\n\t
<\/div>\n\t
\n\t
<\/div>\n\t
\n\t\t
<\/path><\/svg><\/div>\n\t\t
\t\t\t
table of contents<\/div> \t\t<\/div>\n\t<\/div>\n<\/div>
\n\t\t\n\n\t\t
\n\t
<\/div>\n\t
<\/div>\n<\/div>
\n\t\t\t
<\/div>\n\t\t\t
\n\t\t\t\t
SSL Pinning & how it can protect you.<\/a><\/div>
What is Certificate Pinning?<\/a><\/div>
What Pinning Protects You From<\/a><\/div>
Some Pins Are Better Than Others<\/a><\/div><\/div>
<\/div><\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t<\/div>\n<\/div>

SSL Pinning & how it can protect you.<\/h2>

If you know the term HPKP (HTTP Public Key Pinning), that is a specific implementation of pinning that is frequently used with SSL. Here we will be covering \u201cpinning\u201d in a more general sense. Please note that pinning and HPKP are different, and not everything discussed here is accurate about HPKP. However, this article will still help you understand some of the concepts involved with HPKP. A follow-up article will specifically discuss HPKP, its implementation, and challenges.<\/p>

What is Certificate Pinning?<\/strong><\/h2>

Pinning is an optional mechanism that can be used to improve the security of a service or site that relies on SSL Certificates. Pinning allows you to specify a cryptographic identity that should be accepted by users visiting your site.<\/p>

That sounds complex, but it\u2019s actually pretty simple. Let\u2019s start by breaking down that down:<\/p>

A cryptographic identity is a file that can prove the identity of a server\/host through cryptography. An SSL certificate, a public key, and a CSR are all examples of a cryptographic identity. That pin would then tell the client to remember that identity (or identities) and only accept those when establishing future secure connections.<\/p>

So, if you wanted to use pinning, you would configure your server (in some situations \u2013 think internal systems \u2013 you may also configure the clients) and specify what you wanted to pin. Browsers and other clients would evaluate the pinned identity on every connection. If any other identity was presented, the client would abort the connection.<\/p>

To think big picture: an SSL connection tells the client to make an encrypted connection with any identity matching that host. Pinning tells the client a specific <\/strong>identity they should accept when making a secure connection.<\/p>

So, for example, if our site is TheSSLStore.com<\/a><\/strong>, we could pin an identity. When a user visits our site, they would receive the pinned information. On a future visit, their browser would take action if we tried to get the client to use a different identity.<\/p>

[thrive_leads id='12753']<\/p>

What Pinning Protects You From<\/strong><\/h2>

One of the inherent risks to the SSL ecosystem is mis-issuance. This is when an unauthorized certificate is issued for a domain\/host you control. This can happen with both public and private PKIs<\/a>, though the public cases are certainly better known.<\/p>

Mis-issuance can take multiple forms. In 2011, the Dutch CA DigiNotar was hacked, in what is probably the largest compromise of a public CA. A hacker was able to access their internal systems and issue certificates for any site.  This was a total compromise of the CA system because those certificates had inaccurate cryptographic identities and the CA\u2019s issuance systems had been accessed by an unauthorized user.<\/p>

More recently, Live.fi, a website operated by Microsoft in Finland, was victim of mis-issuance. In this case, the CA was not at fault for the mis-issuance. The Live.fi service, which offers free webmail, mistakenly allowed a user to register an email address that is whitelisted for SSL certificate approval. This allowed someone without proper authorization to get a certificate for a site they did not own.<\/p>

In both these cases, pinning could have protected users of those sites (and in the case of DigiNotar, many of Google\u2019s services were protected as they were early adopters of pinning). When a user\u2019s device encountered the mis-issued certificate, it would compare that to the pinned data, and see that there was a mismatch. They would then be warned or blocked from visiting the site.<\/p>

As you can see, mis-issuance is complex. The risk of mis-issuance increases with the profile of your site. A site like gmail.com is much more likely to be attacked than a personal blog. But depending on your threat model, any site may be at risk. State actors have been known to issue fraudulent certificates for a variety of sites, including smaller sites that may have gotten attention for political reasons.<\/p><\/div>

\n\t\n\n\t
\n\t\t
<\/div>