Pin-up on your Smartphone!

Published: 2015-03-26
Last Updated: 2015-03-26 00:59:17 UTC
by Daniel Wesemann (Version: 1)
8 comment(s)

Yeah, okay, I admit that headline is cheap click bait. Originally, it said "Certificate Pinning on Smartphones". If you are more interested in pin-ups on your smartphone, I fear you'll have to look elsewhere :).

Recently, an email provider that I use changed their Internet-facing services completely. I hadn't seen any announcement that this would happen, and the provider likely thought that since the change was "transparent" to the customer, no announcement was needed. But I'm probably a tad more paranoid than their normal customers, and am watching what my home WiFi/DSL is talking to on the Internet. On that day, some device in my home started speaking IMAPS with an IP address block that I had never seen before. Before I even checked which device it was, I pulled a quick traffic capture, to look at the SSL certificate exchange, where I did recognize the domain name, but not the Certificate Authority. Turns out, as part of the change, the provider had also changed their SSL certificates, and even including the certificate issuer (CA).

And my mobile phone, which happened to be the device doing the talking?  It hadn't even blinked! And had happily synchronized my mail, and sent my IMAP login information across this session, all day long. 

Since I travel often, and am potentially using my phone in less-than-honest locations and nations, it is quite evident that this setup is pretty exposed to a man in the middle attack (MitM). Ironically, the problem would be almost trivial to solve in software, all that is needed is to store the fingerprint of the server certificate locally on the phone, and to stop and warn the user whenever that fingerprint changes. This approach is called "Certificate Pinning" or "Key continuity", and OWASP has a great write-up that explains how it works.

Problem is .. this is only marginally supported in most implementations, and what little support there is, is often limited to HTTPS (web).  In other words, all those billions of smart phones which happily latch onto whatever "known" WiFi or mobile signal is to be had nearby, will just as happily connect to what they think is their mail server, and provide the credentials. And whoever ends up with these credentials, will have access for a while .. or when was the last time YOU changed your IMAP password?

If you wonder how this differs from any other "man in the middle" (MitM) attack ... well, with a MitM in the web browser, the user is actively involved in the connection, and at least stands *some* chance to detect what is going on. With the mobile phone polling for email though, this happens both automatically and very frequently, so even with the phone in the pocket, and a MitM that is only active for five minutes, a breach can occur. And with the pretty much monthly news that some "trusted" certificate authority mistakenly issued a certificate for someone else's service, well, my mobile phone's childishly naïve readiness to talk to strangers definitely isn't good news.

While certificate pinning would not completely eliminate this risk, it certainly would remove the most likely attack scenarios. Some smart phones have add-on "apps" that promise to help with pinning, but in my opinion, the option to "pin" the certificate on email send/receive is a feature that should come as standard part of the native email clients on all Smartphones. Which we probably should be calling Dumbphones or Naïvephones, until they actually do provide this functionality.

If your smartphone has native certificate pinning support on imap/pop/smtp with any provider (not just Chrome/GMail), or you managed to configure it in a way that it does, please share in the comments below.


8 comment(s)


My first IT manager told me "the provider likely thought that since the change was 'transparent' to the customer" means the customer does not know what hit them. Nice diary entry.
AquaMail (Android) supports pinning. After certificate change it won't sync anymore until one takes action.
Another place for this type of "transparent exposure" is TLS SMTP encryption. Many companies will eschew using a webmail-based HTTPS "secure email" portal for TLS SMTP if both sides support it. Even better, many implementations use a self-signed TLS certificate for the encryption, one that is provided by the SMTP gateway vendor and has a 1024-bit key with a 20-year life instead of buying a real one. So you really have no idea who you're connecting with unless you enforce certificate validation. For whatever that is worth nowadays...

One major health plan provider does this automatically for their employees. If the receiving side supports TLS, like Gmail, they use it instead of their "secure email" portal. They even do it automatically! Yes, so if someone typos the recipient's email address domain, the email can go via TLS to an unintended recipient.

"Transparent exposure" = "But it's encrypted!" = "21st Century Emperor's New Clothes"
See the "SSL tracking" feature in AquaMail for Android. Not affiliated, just a fan of the feature.
Certificate pinning is a great idea, but, to be practical security it needs to be integrated into the device's operating system or maybe the IDS/IPS. In the mean time, security conscious users can look for applications that support it.

Speaking of CAs that issue certificates inappropriately, I am beginning to think of actively managing the CAs that are trusted, and therefore, should be used.

If pinned certificates are inspected to see the issuing CA, I think it should be possible to disable all the other CA certificates installed in browsers and middleware that are not currently needed. Then, if the SIEM sees a certificate trust issue event, it would lead to a procedure to review if the CA issuing the certificate should be trusted to be added to the other whitelisted CAs. Maybe whitelisting a new CA could happen automatically if the CA already passed the WebTrust audit process, but that would generate an event that should be reviewed by a security professional.
[quote=comment#33777]"Transparent exposure" = "But it's encrypted!" = "21st Century Emperor's New Clothes"[/quote]

:-) This made me laugh. One of my pet peeves is vendors who, when asked about the security of their cloud or their product (ie, a vendor who recently tried to convince us that caching our internal data in their cloud was "secure") they hold up an SSL certificate like it's Excalibur. "See, we're secure! Yay encryption!" (sigh) And when you point out that then your internal-only data is now stored on their hardware in their network (in the clear) where any of their staff could access it they wanted, they just blink 'n stare...
I see that blink-and-stare from so many vendors nowadays that I think it's something teach in sales school. "Just shut up,blink and stare silently." If they don't deny it, they can't make a verbal commitment that they could then be asked to make part of the contract.

One place certificate pinning can break things is when the company decides to switch certificate vendors. That happened a while ago at a very, very large company when a well-meaning manager decided to switch to a lower cost certificate authority vendor and replaced their server certificates. 100% of their mobile devices suddenly stopped working and it took a while to figure out why because the server people were in a different division than their developers.
My Android phone allows me to selectively disable trusted root certificates. I disable a lot of them and when a site stops working, I re-enable them one at a time. I've only had one site break in the six months I've had the phone.

Diary Archives