iOS 7.1 Mail App Encrypting Certain Replies Inappropriately

Encrypted Reply

‘Reply All’ Via iOS 7.1 Mail App


 
We talked recently about Apple mostly fixing one bug related to S/MIME encrypted email messages with their release of iOS 7.1.  Now it appears that they may have another.

Normally when using S/MIME email signing and encryption, the Mail app will indicate a blue lock icon next to any recipient with whom you’ve previously received a signed message and installed their public certificate.  Any recipients for whom you don’t have a certificate installed, and are therefore unable to exchange encrypted mail, are shown in red with an unlock icon next to their name.  It’s perhaps the most visually intuitive S/MIME implementation out there.

If you’ve previously installed a certificate for every recipient on a given message, Mail will indicate that the message is Encrypted at the very top, again accompanied by a blue lock icon.  If there are any recipients on a message for whom you don’t have a certificate, the message will normally drop back to Not Encrypted at the very top and show the red unlock icon.  You would never want to send out a single encrypted message to a group of people such that only certain recipients had the means to decrypt and read it.

At the Connecticut-based healthcare practice where I work, we collaborate with outside technical people all the time.  In day-to-day e-mail exchanges, I’ll frequently receive e-mail messages from third parties where the sender chooses to include or carbon copy our CIO or one of my IT colleagues.  More to the point, someone who doesn’t use S/MIME signing and encryption will send me a message where they carbon copy someone who does use S/MIME.  Often the topic will merit a response, where I begin by hitting Reply All.

The iOS 7.1 Mail screen captured at the top of this article should not be possible.  You’re looking at a Reply All where I have no S/MIME certificate for the To party, but I do for the Cc’d party.  Yet the overall message status at the very top still indicates Encrypted.  If I began a new e-mail message to the very same recipients, the message status would be Not Encrypted.  This inadvertent Encrypted status on Reply Alls to a mixed group of recipients isn’t just a visual problem.  If sent, the reply message actually goes out encrypted as promised, such that only the name in blue will be able to read it.  Red recipients will get an smime.p7m attachment that they can’t do anything with.

Curiously, I’m only able to replicate this problem situation when doing a Reply All from my Microsoft Exchange e-mail account.  I’m unable to duplicate it when replying from Google-hosted IMAP accounts.  I should mention that while I’ve seen it happen from multiple devices running iOS 7.1, the device from which I recreated this scenario is an iPhone 5s that was completely wiped and reloaded after having been upgraded to iOS 7.1.

The work-around, for now, seems to involve avoiding the Reply All button.  If you instead limit yourself to choosing Reply, and then manually add the other recipients back, the message status seems to behave appropriately.  It’s an unfortunate extra bit of work, with the potential to stand in the way of wider S/MIME use in iOS-centric enterprises.

This information has been submitted to Apple on case number 593916475.

Encrypted E-mail Attachments Fixed in iOS 7.1?

Encrypted e-mail message with attachment on iOS 7.1

Signed and encrypted e-mail message.


 
S/MIME (Secure / Multipurpose Internet Mail Extensions) is one of two main methods of securing the content of e-mail messages between sender and receiver, regardless of the networks and servers that the message traverses along the way.  While S/MIME includes other functions, such as message integrity and non-repudiation, we’re going to focus on encryption today.

Where Can I Find It?
Though a small percentage of the general population are aware of how to implement and use S/MIME signing and encryption, the technology itself has been natively supported in most e-mail clients for some time.  Programs that support S/MIME include Microsoft Outlook, Mozilla Thunderbird, Novell Evolution, Apple’s Mac Mail, the iOS Mail App (in iOS 5 and later), and a small number of Android apps.  While perhaps used infrequently in the real world, S/MIME support is ubiquitous to the point that it would be hard to find a situation where it couldn’t be used if desired.

You Said iOS?
And then iOS 7 came along.  We talked here in late September about a problem that plagued Apple’s then-released iOS 7.0.  Incoming e-mail messages that had been created using S/MIME encryption, and which also carried file attachments, would often render those file attachments as pulsating and inaccessible when viewed on iOS 7 devices.  It wasn’t a universal failure, as encrypted messages created using Mac Mail on Mac OS seemed reliable.  Messages created using Microsoft Outlook and then read on iOS 7 – a scenario common in business – were the most prone to exhibiting the pulsating problem.  While the S/MIME attachment issue was brand new with the introduction of iOS 7, it persisted in nearly the same form for the next 5 months and 18 days, as we ran updates 7.0.2 through 7.0.6.

Who Cares?
To put the scope of the S/MIME attachment failure in perspective, my September blog post on the subject has pulled in 4,855 pageviews, representing 28% of the total traffic to this small blog since.  Readers have come from 1,665 networks, including those of well-known companies, government agencies, universities and medical institutions.  They’ve been a geographically diverse bunch, spanning 88 countries, from Andorra to Yemen.

At The Office
Closer to home, Apple’s S/MIME attachment handling problem was one hurdle standing in the way of potential wider adoption at my employer in Connecticut.  Using S/MIME under normal circumstances, I might automatically encrypt every outbound message to recipients with whom I’ve previously exchanged a signed message.  Since iOS 7’s release, however, I began having to make assumptions about whether the recipient might need to view an included attachment from an iOS device, and then send the messages in the clear to accommodate easy reading.  Such a limitation has glaring security issues, of course, and also places too high a burden on non-technical end users.  The technology needs to just work.

Fixed
As of this past Monday, it almost just works.  Following Apple’s release of iOS 7.1 on March 10th, I quickly upgraded an iPhone 4, an iPhone 5s and an iPad 3.  I should probably mention that I updated them using the ‘sync with iTunes’ method, rather than over-the-air.  From these iOS 7.1 devices, I’m now able to read PDF, XLSX and DOCX attachments on S/MIME encrypted messages sent via Outlook 14 / Office 2010.  Almost always.

New Issue
In cursory testing following the iOS 7.1 upgrades, I quickly saw at least three occasions where an attachment on a new encrypted e-mail message appeared to bear the filename of a previously-received attachment.  It was as if the messages were being decrypted to a common cache that isn’t always cleared properly after use.  In these rare instances where the wrong filename was presented for the attachment, opening the attachment was hit-or-miss.  I’ve only seen it happen three times so far, but anything less than 100% reliability doesn’t denote a complete fix.

Possible Resolution
So I called Apple to establish Case ID: 588543752.  The total call lasted 43 minutes, and I was quickly escalated to a Senior Advisor.  He took down my information to pass on to engineering.  Though I thought it unlikely to help at the time, I promised to wipe an iPhone 5s clean, re-apply my configuration profile, and confirm that I could still re-create the problem afterward.  Since wiping the iPhone 5s and setting it up from scratch, I’ve been unable to reproduce any problems with S/MIME encrypted messages bearing attachments.  This may turn out to be one instance where wiping an iOS device following a major upgrade actually does some good.  Stay tuned for more.  It’s never boring.

iOS 7 Mail App Flaw

Pulsating Attachment Problem in iOS 7 Mail App ©Apple Inc.

Pulsating Attachment Problem in iOS 7 Mail App ©Apple Inc.


 
It seems that relatively few people are aware of commonly-available standards and tools for end-to-end e-mail encryption, though more may be interested in this topic in the post-Snowden era in which we now find ourselves.  One of these standards – S/MIME – is natively supported in most e-mail clients, including Microsoft Outlook, Mozilla Thunderbird, Novell Evolution, Apple’s Mac Mail, and the iOS Mail App (in iOS 5 and later).  A small handful of colleagues, business partners and I use S/MIME signing – and encryption where applicable – in our day-to-day e-mail communications.  The fact that iOS has supported S/MIME for awhile makes it fairly seamless to use this technology, whether at our desks or on the go.  That is, until we all upgraded to iOS 7.

Having upgraded our iDevices to iOS 7 on or very shortly after the September 18th launch, we quickly noticed something strange with regard to encrypted e-mail.  We could read the body text of encrypted messages just as before.  Unlike with iOS 6, however, any attachments on these encrypted messages appeared to pulsate rapidly as seen above.  Trying to click on a pulsating attachment either results in nothing, or in the Mail app closing out abruptly.  Though the pulsing is fast enough to make it difficult to discern with the human eye, the attachment icon bearing the file type and name is sometimes interspersed with the word Downloading, the file name and a size that doesn’t seem to increment.  We’ve been unable to open any attachment exhibiting the pulsating behavior.

On Friday, we assumed that this affected all S/MIME attachments received on devices using iOS 7’s native Mail app.  I contacted Apple Support on case number 507281855, and also sent a message to a customer relations e-mail address that I’ve corresponded with in the past.  As we looked into the issue further over the weekend, it appears that e-mail messages created using Microsoft Outlook are most likely to exhibit the pulsating attachment behavior.  For instance, any test encrypted message that I’ve sent from fully-patched installations of Outlook in Office 2003 or 2010 arrive with the pulsating attachment problem on any iPhones and iPads running iOS 7.  When I created similar tests using Mozilla Thunderbird on Linux, two of three recipients received the attachment normally and were able to view it.  Further, any e-mail containing the content attached visibly in-line rather than as a file attachment seems to display fine as well.

So what do we know?  Every S/MIME encrypted message bearing a file attachment and created using Microsoft Outlook from a fully-patched installation of Office 2003 or 2010 exhibits the pulsating attachment problem when viewed on any iOS 7 device.  Encrypted messages with attachments created using Mozilla Thunderbird were readable by some – but not all – recipients using iOS 7 devices.  Encrypted messages sent using Mac Mail on Mac OS typically insert the attachments inline, where the content is viewable without issue.  Long story short, Apple’s Mail App has taken a step backward in iOS 7 where support for encrypted e-mail is concerned.  We can only hope that this is resolved in the next iOS update.

Update:

  • In the first week following this post, it was viewed 374 times from 209 cities in 32 countries.  Readers came from such roles as government (City of Los Angeles, Department of Homeland Security, NASA, and the U.S. Department of Energy), education (Bucknell University, Marquette University, Penn State, UC San Diego and University of California, Irvine) and Apple Inc. offices (Brisbane, Australia; Elk Grove, California; and Zurich).
  • A companion post over at the Apple Support Communities got 615 Views and counting.
  • Apple released iOS 7.0.2 to deal with security issues on the lock screen.  It did not address this problem.

Update 2:

  • Apple released iOS 7.0.3 on October 22nd.  It did not address this problem.

Update 3:

  • Apple released iOS 7.0.4 on November 14th, but did not fix this problem.  Following the upgrade on my iPad, I am not presented PDF attachments at all on S/MIME encrypted messages created via Outlook and sent via Exchange Server or Google-hosted IMAP accounts.  It’s as if they’re not there.  A Microsoft Word .DOC attachment still pulsates rapidly as in the original illustration.  My iPhone, however, shows both file types pulsating.

Update 4: