TLS/SSL Failures and Some Thoughts on Cert Pinning (Part 1)

By Chris Crowley

It’s going to happen sooner or later…sooner probably. You’re going to be asked about your company’s mobile app or a mobile app your company wants to install across all mobile devices. They’ll put the request in the “yet another duty as assigned” (YADAA) category/bucket. You look at the network traffic; it’s using TLS so you can’t see the content. Cool, right? Maybe, maybe not. Can an attacker get man in the middle position by tricking users, or by attacking the very root of trust (well, one of the 100 or so root CAs) that is used to sign a TLS server cert? It is a complicated situation and requires a thorough understanding of several systems and protocols to address. I want you to be smart on the subject, so when that YADAA comes your way, you can answer the question knowledgeably and authoritatively. So here you go…read on.

The first installment of this two-part blog post will provide some background on TLS (Transport Layer Security) certificates so you can understand why your mobile apps should implement certificate pinning. In the second part, I’ll discuss a tool that was released recently, called TrustKit, that makes it easy for iOS developers to implement certificate pinning with no change to the iOS app. (No change presumes the URLs to be protected are requested by TLS already). No analogous project exists for Android yet.


TLS provides transport encryption to protect data while in transit over a network, providing confidentiality and integrity protection against untrusted and unknown network nodes. This is a mainstay in our protection of information in transit. In addition to recent attacks against implementations in TLS/SSL, (iOS/OSX goto fail; Heartbleed; Poodle) there are fundamental trust issues within the implementation of TLS. A trusted Certification Authority (CA) is trusted to issue certificates for any resource.

The TLS handshake involves a client verification of the certificate the server provides, then an optional server validation of client certs. In practice, there is no server validation of client certificates, but the spec allows for it.

Screen Shot 2015-11-25 at 8.47.39 AM

Diagram Source:

There are 5 basic items that the client validates during the assessment of the server presented certificate.

  1. Is this certificate current and still valid based on the expiration date in the cert compared to the current system date?
  2. Is this certificate intended for the purpose I’m attempting to use it for? This capability is defined in the certificate. In the case of a client connecting over HTTPS to a server, the certificate must include the specification for identifying a server.
  3. Is this certificate on a revocation list? In practice, we rarely see OCSP (Online Certificate Status Protocol – RFC 6960) a real time query mechanism for certificates, used. The client may have downloaded CRLs stored. The certificate offered may include a query URL.
  4. Is this certificate issued to the resource I’m requesting? If the browser requested, but the certificate was issued to a server named, the browser (or mobile app) shouldn’t allow the connection to proceed.
  5. Is this certificate issued by a certification authority I trust? The certification authority (CA) included with the mobile device or web browser is stored in a structure called a certificate store. The list of trustworthy authorities usually numbers in the tens of CAs up to 100 or more CAs. This means that any of these CAs (companies, organizations, or government entities) could issue a certificate for any server name. In practice, the CA is supposed to vet the requester of a certificate. In practice, the CA is only supposed to issue certificates to trustworthy people who actually represent the organization the certificate is assigned to. In practice, the CA has your personal privacy as its primary concern. In reality, we’ve seen a small number of violations of these practical considerations.

To put this in perspective, iOS 9 trusts 218 CA’s:

$ curl -s | grep '</tr><tr><td>' | wc -l


We’ve seen some attacks in the past related to certificate manipulation. We’ve seen scenarios of complete CA compromises that were used to issue unauthorized certs. We’ve seen CAs tricked into handing out certs. We’ve seen users fail to protect the CA-issued private keys which resulted in unauthorized certificates being issues. Below I cite two reported instances (India CCA and TURKTRUST Inc) where government organizations have issued certificates for servers in an unauthorized fashion. These two are not really a big deal, just for host certificates. Also, many organizations using HTTP proxies will configure CA certs on the client end points, allowing for the transparent interception of HTTPS communication.

We’ve seen theoretical and in the wild attacks against TLS and its related certificate authority infrastructure and organizations. Why, there’s even an RFC “Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)

Some of my favorite failures are below. I like studying failure; it helps us to improve.

2001 : VeriSign issues Microsoft certificates to unauthorized party:

2008 : MD5 Collision Construction allows rouge CA Certs

2009 : TLS Renegotiation attack

2011: Diginotar

2011: Duqu – Code Signing used in malware

2013 : TURKTRUST – Unauthorized certs

2014 : India CCA – Unauthorized Google certs

2014: Heartbleed

2014 : goto fail;

2015 : Microsoft revokes certs associated with

In many of the cases listed above, there was some fundamental component of the protocol or the implementation that undermined integrity of the security. Several of the attacks were entirely fraudulent certificates. You can’t have endpoint protection when there is a broken implementation on the endpoint (like in the Apple goto fail;) or in the server OS (like in Heartbleed). But, we can address the frequent (2001, 2009, 2011, 2013, 2014, 2015) scenario of fraudulent certificates used in networks by requiring our mobile applications to only trust specific certificates we intend for use.

Certificate Pinning

Certificate pinning is the application-specific requirement that some specific certificate or CA be required for a TLS connection, rather than accommodating any of the CAs the phone trusts. This can also be used to remove the user from the negotiation. Certificate pinning is most effective when the user is unable to override it.

For protecting your data, this is a useful thing. Is it foolproof? Certainly not. For example, there’s a tweak available for jailbroken iPhones called SSLKillSwitch ( which is a “Blackbox tool to disable SSL certificate validation – including certificate pinning – within iOS Apps.” Instead of falling victim to the perfect solution fallacy, I recommend developers use certificate pinning to minimize the likelihood of data interception, while acknowledging the reality that a jailbroken or rooted endpoint is not going to provide the same data protection as a non-rooted device.

Cert pinning provides your application with a layer of certificate control that allows you to specify which certificates you’ll accept, substantially limiting the likelihood of unauthorized information disclosure or alteration during network transmission. Another scenario where this may be undesirable is if your organization uses a privately issued CA to introduce a man-in-the-middle (MITM) TLS scenario for data loss protection. Google implements one of the largest certificate pinning instances in the world via its Chrome browser. It addresses this nuance by allowing the private trust store CAs to override pinning, while prohibiting the public trust store to violate pinning. Read more here:

Here’s a simple example of how certificate pinning could help you to protect your organization’s data. A user, alibo, reported to Google Groups that there was a cert error reported by Google Chrome. As it turns out, Google used certificate pinning capability in the Chrome browser to identify unexpected certificates signing certificates for servers in the domain. Read more here: . That is a public example of detecting the DigiNotar compromise.

Stay Tuned…

In my next blog installment I’ll discuss the specific implementation of certificate pinning in iOS applications using TrustKit. Let me know if you found this useful on twitter @CCrowMontance.

-Chris Crowley

P.S. If you like this kind of thing, you really should consider joining me for the SANS Security 575 course on mobile device penetration testing and security in New Orleans in January.  We call the event SANS Security East, and it’s gonna be an awesome event full of great strategies, tactics, techniques, and practical advice on securing your organizations mobile devices!  I hope you can make it!

Winner and Official Answer to Easter Challenge

[Hello, Challenge fans!  Last Friday, we posted a nifty holiday-themed crypto & stego challenge by Chris Andre Dale.  We offer a special thanks to Chris for creating the challenge and for letting us host it.  A whole bunch of people managed to work their way through the challenge and solve it.  But, there were two answers that were particularly noteworthy, and will receive two T-shirts each: a NetWars T-Shirt plus our SANS Pen Test Curriculum T-shirt.

Our  first-place winner, who had the entire correct answer in the shortest time, was Matt Giannetto!  He provided some great code to decipher the message and save the bunny, winning the two T-shirts.  Additionally, we’ll provide a bonus prize (of the two T-shirts) for one of the best write-ups we received, from Thomas Heffron.  His answer was so good, we’ll make it the official answer to the challenge, which follows below.

Thanks again to all who participated!  –Ed.]


By Tom Heffron

Well, how could anyone not spend a few moments for such a noble pursuit? Besides, what would I tell my kids if I didn’t even try?

So, I start by just looking around the ciphertext and noticed the next to last line starts with:

jtgi://ahe.ifglxiflnugbsya.dp/ <– Hmmm… a URL of some sort? A bit of counting characters shows that it has a similar breakdown to: <– which is the URL associated with our fine puzzle maker. Is he involved in this evil crime? Interesting…
What this does tell us is that the cipher does seem to be a character substitution cipher, but may not be a direct one-to-one replacement. This narrows down the universe of possible ciphers, but doesn’t directly reveal the algorithm. (At least, not to me) I’ll keep that in my back pocket for now…
Moving on to the intercepted audio message, I download and play it with my Linux simple audio player. A few moments of listening indicates this audio track is probably a reverse of the true recording. How can I tell? The best way I can explain this is that each word trails _in_ to a hard ending. Most spoken language begins each word with a clear emphasis at the beginning and trails out at the end of the word or syllable.
After some mad searching around my simple media player, I realize it does not have the sufficient effects to play the recording in reverse. A quick Google search for ‘linux play mp3 in reverse‘ delivers a suggestion of Audacity.
Installing that package gave me what I needed with the Effect->Reverse option. Hit play and I hear an interesting (Northern?) European voice reading words that correlate to the NATO phonetic alphabet. (explained at The spoken alphabet writes out to the following string of characters (with a blank space substituted for the spoken ‘break’):
dl dropboxusercontent com u 16108286 kidnappedbunny jpg
and I use some reasonable substitution to turn this into the web URL:
Drop this into my browser and I see an image of the notorious Con Air movie bad guy, Cyrus ‘The Virus’ Grissom, threatening our furry little friend. Call John Cusack! We must stop these villains and save Easter!
Of course, any good SANS Pen Testing Challenge worth their value would not involve an image without the need to check the exif information. Download image and run:

exiftool ./kidnappedbunny.jpg  – which gives me the following bits of interesting information:
Comment : The ciphertext is created using the famous Vigenere cipher, once considered unbreakable. The key to reveal the cleartext is a combination of the a town located at the X Y coordinates where this picture was taken, and the make of the camera.

GPS Position : 60 deg 23′ 28.54″ N, 5 deg 19′ 19.38″ E

Camera Model Name : XcanteliQ
Let’s break this down piece by piece…
Simply dropping the GPS Location into Google Maps takes us to the town of Bergen, Norway. (Aha! Our puzzle maker is looking more suspicious!)
Add ‘bergen’ to the string from the camera model and I get the key: ‘bergenxcanteliq
Now, to learn more about Vigenere Cipher, I consult Google Search again with ‘Vigenere Cipher decryption’. Trying the first listing (why not?!) gives a site that is ready to apply this key against the ciphertext. Inserting the necessary information returns the following cleartext:
congratulations! by successfully deciphering this message you could let the easter police know of the whereabouts of the easter terrorists. the criminals have successfully been apprehended, thanks to you! thanks for your good work, and i hope it was fun. here is the final part of the Easter Challenge:
did you like it? leave a comment and let me know :)
Success! I seemed to have helped save the Easter Bunny! Browsing to the link provided in the cleartext indicated from the comments that I was not the first concerned citizen to help the Easter police. I’ll assume that Mr. Bunny is safe and sound and that the challenge creator was not part of the evil plot!
Thanks to Chris Andre Dale for a fun challenge and to the SANS Pen Testing team for hosting it!
And, finally, to access the password-protected website to get the photo of the safe bunny, you’d enter in a password of the same key (with appropriate case) used to decode the cipher: BergenXcanteliQ  That would reveal the following image:

Easter Challenge – The Mystery of the Missing Easter Bunny

By Chris Andre Dale

The Easter Bunny has been kidnapped, and YOU have to save him! Quickly collect yourself and help save him. Put on your detective hat and start investigating the clues provided.

We managed to intercept a message from the kidnappers.  Unfortunately it seems to be scrambled in some way. We also managed to intercept a ciphered message from one of the criminals and the cipher text below. The cipher text was once considered unbreakable, however newer techniques of cryptoanalysis have proven how to beat it. Listen to the intercepted message from the kidnappers, or attack the cipher message. Your choice.

The intercepted message can be played back here:

The cipher text looks like this:

Dsemvnqwlnmmzvi! Cc jagpbussnpwg tfgzvlroknt mlta cfwjgkr vqu phywl bfx kni Rxutrk Tztydi btsj lh tux asmhfesuygp qf gai Piiuii Zieoqrvlxd. Bxf gioqvkclf aegm ivgtkwfcwlyr fpmd btgxiubpdrw, xsidlw ku cbr! Vhngod nes cfav tlqd jhvv, ide M yutr fv wnl jfv. Xfvv ow geg fvgew xqsx fl xub Gafmic Kxbpckrtb: jtgi://ahe.ifglxiflnugbsya.dp/iryxro-ehneppvwf-xyk-qlpveer-sq-bxf-qzywvki-enlxpz-rvree/

Hva aoh emvm yu? Pvgzr x eozfiyb qoh ckx zb mnbp :)

How will you aid the investigation? Anyone with an interest in cryptanalysis might attack the cipher directly, however the rest of us, along with some Google Fu, may start with the intercepted message.

Good luck! The Easter Bunny depends on you!

The first one to email the answer to  PenTestVideo <at> (yes, that’s the email alias to our team of judges) will win a SANS Pen Test T-Shirt as well as a SANS NetWars T-Shirt!  Please use an e-mail subject of “SAVING THE EASTER BUNNY” for your e-mail at PenTestVideo <at>

Best regards,

Chris Andre Dale

A Most Enigmatic Adventure

Care for a little adventure story?  How about one that is rooted in the history of cryptography, involves an elaborate hack that saved millions of lives, and features a bizarre twist with brain juice at the end?  We have just the tale for you, and it’s all a true story.

Back in August 2012, Josh Wright and I (Ed Skoudis) fulfilled a dream that was two years in the making: a trip to purchase a genuine Enigma machine.  As most of our readers know, the German military used the Enigma machine during World War II to encrypt messages transmitted via telegraph.  Through amazing research and crypto-analytic breakthroughs, Polish, British, and American researchers were able to crack the Enigma machine, pioneering techniques that are still applied today in attacking cryptosystems.  According to Winston Churchill, this breakthrough shortened the war in Europe by at least two years, saving millions of lives.

Josh and I wrote the following presentation to briefly describe Enigma cryptography, discuss the historical importance of cracking it, and to share details of our adventure in obtaining a real Enigma machine.  We were originally going to title our presentation “Sk0d0 & Josh Buy an Enigma,” and present it in the style of that classic of Western Civilization, “Harold and Kumar Go To White Castle.”  But, that strange day, August 16, 2012, something happened that caused us to change the title of the talk.  Without further adieu, here is the slide deck from our talk (click on the image below to see the whole slide deck):

We put together a little movie trailer about our adventure.  Click below to view the movie trailer.

We also did a movie poster based on the original title of the planned adventure.  That poster is here:

If you’d like to see Josh and me present this talk, we did film its debut at SANS Network Security 2012 in September in Caesar’s Palace in Las Vegas.  The film quality and audio is a little rough at spots, but you can watch the whole recorded presentation by clicking on this image:

There is one final point we’d like to emphasize.  The Enigma machine for us is a symbol of something pretty big and pretty profound in our lives.  In the penetration testing business, we hack for a living.  In our classes (such as SANS SEC560 on Network Penetration Testing & Ethical Hacking and SANS SEC575 on Mobile Device Security & Ethical Hacking) and our projects such as NetWars and CyberCity, we analyze how to hack a variety of different kinds of computers, networks, and other infrastructures.  The Enigma machine represents for us a flawed technology, whose owners and operators (the Nazis) were over confident in its security.  Brilliant people worked super hard to hack that technology, and in the process helped defeat a profoundly evil regime and save millions of lives.  The Enigma is important because its unforeseen weaknesses allowed incredible people to hack it to the world a better place.  In our work as security professionals, we should strive for that goal, to have our work used to help make the world a better place.

–Ed Skoudis
SANS Fellow