This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Talk:Certificate and Public Key Pinning

From OWASP
Jump to: navigation, search

June 21 2016 Comments

Hi Jeffrey and John,

I am from PKI project team at Symantec, and am reading your OWASP guide about certificate pinning and have a question on this point: what to pin?

https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

In certificate paragraph, it implies that it should be the server’s certificate, not its issuer.

"There is a downside to pinning a certificate. If the site rotates its certificate on a regular basis, then your application would need to be updated regularly. “

The sample code, e.g. Android, however, all use an ICA [from Douglasheld (talk) 10:05, 13 July 2016 (CDT): "Intermediate Certificate Authority"] to pin. I believe pinning ICA is a good balance of flexibility. Is the guide intention to suggest pinning of CA or the server host’s certificate? Thanks,

Ming


Hi Ming,

This is Ricardo Iramar and I'm the one who include the Android pinning example. For your first question there is a specific session for that here https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#What_Should_Be_Pinned.3F. So the author is recommending this: "I would encourage you to pin the subjectPublicKeyInfo because it has the public parameters (such as {e,n} for an RSA public key) and contextual information such as an algorithm and OID." About the Android example you are right. I'm pinning the first intermediate CA certificate as you can saw on the code. I'm doing that because this is the developer.android.com recommendation that you can found here https://developer.android.com/training/articles/security-ssl.html#UnknownCa. IMO what should be pinned is a trade off so that's depend of your case. If you think your keys will rotate you may pin the Intermediate CA certificate so you don't need to change your application. You can also include more than one Intermediate CA certificate in your keystore as a backup in case you decide to get certificates from another CA.

Past Failures

This section is 'further reading' for those interested in surveying the landscape.

Operational considerations

We use certificate pinning very commonly in my organization (yay for us) but we recently hit a problem when we were routinely changing a certificate on a service. The development team for one of the client applications and implemented pinning, but they had not considered what would happen when the certificate changed.

The majority of our clients support 2 pinned certificates at a time, so when we want to change the server cert the process is

1) Configure the new server cert in the client alongside the old one 2) Replace the old cert on the server 3) Configure the old cert from the client

This way we can do the cert rotation usually with no downtime for the client.

The team in question did not do this, which meant they had to have a few minutes of downtime (this is important as we have a demanding SLA) and also it meant that we had to do the change out of office hours to minimize the impact.

So, my suggestion is that we expand this page to include a section on "Operational considerations" that outlines the recommended approach.

Thoughts?

If no-one objects, I will add the new section in a couple of days.

Michael Goodwin (talk) 06:20, 2 April 2015 (CDT)


(I am not sure how to reply to your question so I will do it inline. Let me know the appropriate method).

I absolutely agree that this is a needed section. We have had certificate pinning in for two years and it has been extremely difficult because the teams don't fully grasp the operational implications. Our strategy has been to include the old cert and the new cert. Since our app is a consumer app, I have also lobbied extremely hard to get a 'Your app is out of date and needs to be upgraded' but have not got traction. As a result, every time the certificate changes it's a world of pain since we don't have an effective way to let users know they need to update.

I have many, many thoughts on the operations side and would love to contribute. SteveA

Android example contains code that breaks apps

The Android code example contains a section where it checks that the authtype equals "RSA". F5 recently changed their default authtypes to RSA-DHE. This meant that when we upgraded our F5's in production, all of our Android mobile apps broke. Obviously a big issue.

What is the compelling reason for this line of code:

if (!(null != authType && authType.equalsIgnoreCase("RSA"))) { 

     throw new CertificateException("checkServerTrusted: AuthType is not RSA");
   }

iOS sample is bad

the iOS sample doesn't need to be an entire program; it should be a minimal Objective-C fragment that demonstrates best practices in loading the keys or key fingerprints from a configuration file.

This Objective-C sample diverges pretty badly from the other language examples, which are short and sweet. Douglasheld (talk) 10:34, 17 June 2015 (CDT)


TODO

A flaw in many pinning implementations was pointed out in [1] Does the OWASP sample code address this? Probably worth an explicit mention in the doc somewhere. I don't have time to tackle this now. --TimMorgan (talk) 13:06, 10 March 2016 (CST)

Best practices when running traffic through a CDN

In the modern day customers are allowing CDN vendors to route their HTTPS content and this means the CDN vendors are entrusted with decrypting their traffic. I think this really throws a lot of conventional security wisdom out the window - and it would be nice if a certificate pinning best practice were established and documented here. Douglasheld (talk) 10:07, 13 July 2016 (CDT)

Retrieved from "https://wiki.owasp.org/index.php?title=Talk:Certificate_and_Public_Key_Pinning&oldid=219231"