Talk:Certificate and Public Key Pinning

Past Failures

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

• Governments Want/Require Interception
  • Certified Lies: Detecting and Defeating Government Interception Attacks Against SSL, cryptome.org/ssl-mitm.pdf
  • http://www.dailymail.co.uk/indiahome/indianews/article-2126277/No-secrets-Blackberry-Security-services-intercept-data-government-gets-way-messenger-service.html
• Governments Engage in Interception
  • http://www.thetechherald.com/articles/Tunisian-government-harvesting-usernames-and-passwords/12429/
• Vendors Provide Interception Taps
  • http://www.cisco.com/web/about/security/intelligence/LI-3GPP.html
• Governments Use Interception Taps
  • https://www.eff.org/nsa-spying
• Mobile Interception is Patented
  • Lawful interception for targets in a proxy mobile internet protocol network, http://www.google.com/patents/EP2332309A1
• Handset manufactures add trusted roots
  • http://gaurangkp.wordpress.com/tag/nokias-man-in-the-middle-attack/
• Carriers can add trusted roots
  • No reference yet, but http://www.theregister.co.uk/2011/12/15/carrier_iq_privacy_latest/
• CAs can become compromised
  • http://isc.sans.edu/diary.html?storyid=11500
• Researchers created Rogue CAs
  • http://www.win.tue.nl/hashclash/rogue-ca/
• Researchers collided certificates on existing CA certificates
  • http://www.win.tue.nl/~bdeweger/CollidingCertificates/ddl-full.pdf
• DNS can become compromised
  • http://forums.theregister.co.uk/forum/2/2011/09/05/dns_hijack_service_updated/
• Physical plant can become compromised
  • http://www.pcworld.com/article/119851/paris_hilton_victim_of_tmobiles_web_flaws.html
• Its easy to set up an AP or Base Station (Chris Paget's IMSI Catcher)
  • http://www.wired.com/threatlevel/2010/07/intercepting-cell-phone-calls/
• Can't trust some CAs – they will sell you out and issue subordinate CAs for money
  • http://www.net-security.org/secworld.php?id=12369
  • http://www.zdnet.com/trustwave-sold-root-certificate-for-surveillance-3040095011/
• Can't trust some browsers – they will sell you out and elide their responsibility
  • https://bugzilla.mozilla.org/show_bug.cgi?id=724929
• Can't trust some browsers – they include questionable certificates out of the box
  • https://bugzilla.mozilla.org/show_bug.cgi?id=542689
• Can't override some browser's CA list
  • http://my.opera.com/community/forums/topic.dml?id=1580452
• Can't override OS's CA list (burned into ROM)
  • http://support.google.com/android/bin/answer.py?hl=en&answer=1649774
• CRL/OCSP does not work as expected/intended
  • http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html
  • https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
• User will break it too (not just bad guys)
  • http://www.esecurityplanet.com/mobile-security/hacker-bypasses-apples-ios-in-app-purchases.html
  • http://www.h-online.com/security/news/item/Apps-for-Windows-8-easily-hacked-1767839.html
• Interception proxies add additional risk
  • http://blog.cryptographyengineering.com/2012/03/how-do-interception-proxies-fail.html
• HTTPS is broken
  • http://www.thoughtcrime.org/software/sslstrip/
• PKI is broken
  • www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
• The Internet is Broken :)
  • http://blog.cryptographyengineering.com/2012/02/how-to-fix-internet.html

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");
   }