Pin-up on your Smartphone!
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.
Comments
Anonymous
Mar 26th 2015
9 years ago
Anonymous
Mar 26th 2015
9 years ago
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"
Anonymous
Mar 26th 2015
9 years ago
Anonymous
Mar 26th 2015
9 years ago
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.
Anonymous
Mar 26th 2015
9 years ago
:-) 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...
Anonymous
Mar 26th 2015
9 years ago
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.
Anonymous
Mar 27th 2015
9 years ago
Anonymous
Mar 27th 2015
9 years ago