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.

Register Your Site With The Web Filter Companies

Trend Micro Site Safety Center
Among the many simultaneous technical projects at the Connecticut-based healthcare company where I work, we’ve rolled out a fairly significant medical imaging solution providing mobile and web access for referring physicians and others.  For aesthetics and marketing purposes, we chose to launch this Internet-facing platform using a new dot-com domain name rather than use a subdomain of our existing web presence.  From a technical standpoint, all of this is very straightforward so far.

Recently we began hearing that our new domain name and web site were being blocked by the web filtering products used at two hospitals, one of which may be the most well-known health system in the state.  So I began talking with the technical folks at the first hospital system.  Initially I was told that we’d need to secure the signoff of one of their Department Heads or Vice Presidents in order to get an exception added to their web filter that would allow their users to access our site.  Of course I found it a bit curious that they would trust the algorithms and definition files of a faceless security vendor over the judgement of their rank-and-file staff.  At any rate, they eventually relented and granted the exception.

Meanwhile, it occurred to me that most hospital systems, corporations and schools trust software from companies like Websense, Barracuda and Sophos to properly scrutinize and categorize web content and either block or allow it.  An internal administrator using one of these products typically allows or blocks whole categories of content at a time rather than concern themselves with individual sites.  They might allow news or healthcare categories while blocking access to gambling, pornography or hate speech.  So I decided to go to the source(s), and try to get our new site properly classified.

The following is a list of the web security vendors that I contacted, hyperlinked to the relevant page as of the date that this article was posted.  Feel free to add additional web security vendors as comments.  Bottom line, after launching any new web site, it may be worth a few minutes to contact these services that act as gatekeepers within thousands, perhaps millions of organizations.  And if you hear that your site has been blocked, try to identify the product that is blocking it, and work directly with that security vendor for a resolution.  This effort will have a much wider impact than trying to work with the IT team at every individual institution that can’t access your content.

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.

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.

BitLocker Full Disk Encryption With Windows Server 2012 R2 on VMware ESXi 5.5

BitLocker Logo
In the medical setting in which I work, we have an ethical and a legal obligation to protect patients’ data using a variety of means.  Among the many business processes and technical methods, we include various types of encryption.  When talking about encryption, we’ll often use phrases like, “encrypted in transit” and “encrypted at rest.”  Encrypting content in transit involves technologies like SSL, denoted most obviously when you place an https in front of a web hyperlink in your browser.  But today, as the headline implies, we’ll eventually focus on a particular type of encryption for data at rest, where it’s stored on disk.  But first an overview.

Full Disk Encryption
Generally speaking, full disk encryption is one of my favorite tools.  While a computer running full disk encryption remains in the hands of an authorized user with the appropriate boot-up password, the system is as useful as it would be otherwise, save for a performance toll that is often imperceptible on today’s hardware.  There’s little need to think about manually encrypting specific file content, as everything written to the system is automatically and seamlessly encrypted.  If the system later falls into the hands of an unauthorized user, particularly once it has been powered off, the data is inaccessible for all practical purposes.  When I lost a Lenovo ThinkPad to a residential burglary in 2009, the data on that laptop was the very least of my concerns, thanks to full disk encryption.

Various Implementations
For many Linux distributions, implementing LUKS (Linux Unified Key Setup) disk encryption is as simple as checking an ‘Encrypt’ checkbox during installation.  Your operating system will be encrypted from the beginning, having never written anything other than a small boot partition (containing only the operating system kernel) in unencrypted form.  With Apple FileVault and Microsoft BitLocker, however, disk encryption is configured after the operating system installation is complete.  Today we’ll install Windows Server 2012 R2, and then implement BitLocker after the fact.

Trusted Platform Module
Microsoft’s BitLocker likes to rely on a hardware feature called Trusted Platform Module (TPM) version 1.2 and higher.  It’s not mandatory, but historically it’s been a pain to get along without it.  With Windows Server 2008 R2, for example, servers that didn’t have TPM required that the encryption key be stored on a USB flash drive.  This becomes a problem in today’s data centers, where the majority of servers run atop VMware or a similar virtualization layer.  There’s no way to pass TPM functionality from the underlying physical hardware through to a virtual machine.  The limitation becomes obvious when running VMware’s High Availability (HA) and Distributed Resource Scheduler (DRS) tools, which routinely move virtual machines from one physical host to another at a moment’s notice.  There was one way to get around the requirement to use either a TPM or a USB flash drive with BitLocker in Windows Server 2008 R2, but it required a compromise analogous to taping your house key to the outside of your front door.  Better to use a 3rd-party solution.  Fortunately, with Windows Server 2012 R2, we can implement BitLocker full disk encryption on a virtual server using a boot-up password that’s not stored with the server, and is known only to authorized administrators.  We should note that Windows Server 2012 isn’t supported on VMware ESXi prior to version 5.5.  Finally, let’s get started.

Within The vSphere Client
I’ll begin by defining my new virtual machine on which I plan to install Windows Server 2012 R2.  When given the choice of Guest Operating System, I’ll be sure to sure to select Microsoft Windows Server 2012 (64-bit) from the list.  For today’s example, I’ll use 2 virtual CPU sockets, 8 GB of RAM, the default SCSI controller, and I’ll create two virtual drives, sized 60 GB and 100 GB, for use as an OS and a data partition respectively.  I’ll later set my CD/DVD drive to point to an ISO image of the Windows Server 2012 R2 installation media, and set it to Connect at power on.
VMware vSphere Client
Windows Server 2012 R2 Base Installation
Systems Administrators responsible for the installation, security and support of Windows Server are typically very familiar with performing a vanilla Windows installation.  For the sake of keeping an already long post manageable, I’ll skip the how-to of a basic Windows setup.  On a modern server hardware platform, the whole thing can be performed in about the same amount of time as it takes to read a definitive list of steps.  It’s surprisingly fast when compared with prior versions of Windows.  For purposes of this article, I installed Windows Server 2012 R2 with the GUI console and otherwise default settings.  After that, I installed the VMware Tools, gave the server a desired name, set my timezone, enabled Remote Desktop, installed Windows Updates and set the firewall as desired.  Finally, I created as drive D a basic disk containing an NTFS partition utilizing that 100 GB data drive that I’d defined using the vSphere Client earlier.  Now we have the Windows Server 2012 R2 platform on which we’re ready to configure BitLocker.

Installing the BitLocker Feature

  1. Launch Server Manager from the shortcut near the left end of the Taskbar at the bottom of the screen.
    Server Manager shortcut
  2. From Server Manager, click on Add roles and features.  A Wizard will launch.
  3. Click Next at the Before you begin pane (if shown).
  4. Select Role-based or feature-based installation, followed by Next.
  5. Choose Select a server from the server pool, and then highlight your machine in the list below.  Then click Next.
  6. You’ll be presented with a list of Server Roles, some of which could be active, depending on what you may have chosen to install previously.  Rather than selecting a new role, simply click Next.
  7. Now you’re presented with a list of Features.  Click on the box next to BitLocker Drive Encryption.  A pop-up will reveal a list of additional dependencies which will also be installed.  Click Add Features.
  8. Now back at the wizard, click Next.  If you wish, highlight the checkbox to Restart the destination server automatically if required.  Then click Install.
  9. The install will take a few seconds.  If you didn’t choose an automatic restart, you should manually reboot when prompted.

Group Policy Change
Given that we don’t have TPM support on our virtual machine, we’ll need to make a local Group Policy change to allow using BitLocker without it.  While we’re modifying Group Policy, we’re going to upgrade our cipher strength and make other changes as well.  Though the following steps target our individual machine, similar policy could be applied to an Active Directory organizational unit, or even a whole domain.
Local Group Policy Editor

  1. Navigate to Start > (down arrow) > Run, and launch the following command:
  2. Use the arrow symbols to expand the tree under Local Computer Policy as needed.  You’ll want to navigate to: Computer Configuration \ Administrative Templates \ Windows Components \ BitLocker Drive Encryption.
  3. Select Choose drive encryption method and cipher strength.  Turn the policy to Enabled, and choose the method AES 256-bit.  Hit OK when done.
  4. Now navigate to subfolder \Fixed Data Drives.
  5. Select Enforce drive encryption type on fixed data drives.  Turn the policy to Enabled, and choose the type Full encryption.  OK when done.
  6. Now navigate to BitLocker Drive Encryption \Operating System Drives.
  7. Select Require additional authentication at startup.  Turn the policy to Enabled.  Select Allow BitLocker without a compatible TPM.  Leave the settings below it in their default state, allowed but not required.  Click OK when done.
  8. At the same level in the tree, also select Enforce drive encryption type on operating system drives.  Turn the policy to Enabled, and choose the type Full encryption.  OK when done.

Turning On BitLocker

  1. Launch Control Panel via the Start menu.
  2. Change the view to Large icons if it isn’t already, so that all options are presented.
  3. Launch BitLocker Drive Encryption.
  4. Focusing on our operating system drive first, BitLocker should be off at this point.  Click on the option to Turn on BitLocker.
  5. Your system will run a quick diagnostic check.  When it doesn’t discover a TPM, it will give you two alternatives.  Choose Enter a password.
  6. Enter your desired BitLocker drive encryption password twice, and then click Next.
  7. You’ll be asked to back up your recovery key.  Choose Save to a file, and store it in a network location known to be secure.  It won’t let you save the recovery key to the drive you’re encrypting, nor can you continue without saving it somewhere.
  8. When prompted with the option to Run BitLocker system check, un-check it.  The choice to Start encrypting will appear.  Select it.
  9. A lock & key symbol will pop up on the System Tray near the lower, right-hand corner.  You can double-click on it and monitor your progress.  It took around 7 minutes to encrypt our 60 GB operating system drive, as our underlying hardware and storage environment are relatively recent and robust.
  10. Now, let’s Turn on BitLocker on our data volume.  You may need to click on the down arrow / up arrow over at the right to see the option.  Let’s use the same password as before so as to be consistent.
  11. Save your recovery key to a path known to be secure when prompted, before clicking Next.  Choose to Encrypt entire drive if presented with a choice of what to encrypt.  Then click Next.
  12. Start encrypting.  Our empty 100 GB data volume was encrypted in about 12 minutes.
  13. If your data volume is seen as a removable drive, Turn on auto-unlock so that it comes up with the server.

Subsequent Reboots
Every time that you reboot your server, you’ll have to connect to the console via the vSphere Client and put in your password at the screen shown below, before the server will continue to load the operating system.  While it’s a slight hassle, it’s consistent with the level of effort to reboot any Linux variant on which your OS volume is encrypted.  (Within Windows Server 2012 R2, there’s also an available BitLocker Network Unlock, which is outside the scope of today’s conversation.)
BitLocker Boot Password Prompt
Final Thoughts
Full disk encryption is but one of several layers of security that an organization (or an individual) can use to control access to their data.  Disk encryption is insufficient on its own, of course, without proper access rules, encryption in transit, firewalls, antivirus, security updates and the like.  And disk encryption may be most useful at the endpoints – small desktops, laptops and mobile devices – which are more likely to grow legs and walk than one’s core server infrastructure is.  But in the year 2014, it’s better to be safe than sorry.  Encrypt everything; everywhere.  In transit and at rest.  And with Windows Server 2012 R2 and BitLocker on top of VMware ESXi 5.5, it’s easy enough to do that with our virtual Windows Server assets going forward.
[I briefly referenced BitLocker: How to deploy on Windows Server 2012 and BitLocker Frequently Asked Questions (FAQ) when walking through this process for the first time.]

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.


  • 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: