Do this now: Update your iOS device straightaway, and your Mac when an update comes. It couldn't be easier: in iOS, go to Settings, click General, and then Software Update. You'll need to be on WiFi. The whole process takes 5-7 minutes and temporarily requires a shade over 1GB of free space on your device for scratch storage.
The vulnerability was in an open-source component of iOS (and OS X, and potentially other platforms). My point is not to make snide assertions about open source— I agree that many eyes make for a more secure product, and the solidity of Linux attests to that. But it's no panacea, as mistakes can still be made and persist, as this demonstrates ...as does the 14-month-old WebView Android vulnerability that made the news in the past few days. In this newest case the flaw is very easy to see even if, like me, you’re no expert in C-like languages or encryption. But somehow it got overlooked, including by the compilers that one would have hoped would have caught such a visible issue.
From what I’ve read, seems the code involved is a fork of the OpenSSL encryption module. I’ve not yet seen an analysis of whether it may have propagated beyond iOS/OS X. You can bet that many eyes are looking into that right now.
As I understand it: in this vulnerability, a man-in-the-middle attacker possessing an encryption certificate signed by a trusted Certificate Authority could potentially intercept an encryption handshake between a user and a secure service or website, and under some circumstances the mechanisms that would detect such an attack would be short-circuited, allowing the MITM to eavesdrop or maybe impersonate the remote party.
A Workaround
Patch or no patch, one way around vulnerabilities of this sort is to tunnel past the attacker using a virtual private network that authenticates by some unrelated mechanism. Typically, once a VPN client is set up on your computer, tablet or phone, you can connect to it most any time, and it establishes an encrypted tunnel and routes some or all your traffic into that tunnel so nearby eavesdroppers can’t make sense of it.
Using a VPN routinely is not a bad idea for those, like me, who frequently rely on public hotspots in hotels, planes and other venues… including in untrustworthy countries. A bonus is that a VPN also evades firewall blocks for things like Voice-over-Internet and (in some countries) social media. Of course, one must have their eyes open about the local rules for utilizing such services… It’s one thing if your hotel blocks VoIP to maximize its in-room-phone revenues, but VoIP is flat illegal in many Middle East countries (for example). Fortunately, if you’re on a VPN, no one between you and your VPN service can detect what you’re doing, at least not easily.
Also, when you’re connected via a VPN, it appears to the services you connect-to that you are connecting from the geographic location of your VPN’s endpoint. That’s great for accessing your subscriptions to things like Netflix and Hulu when you’re traveling beyond copyright enforcement borders.
Commercial VPN services are plentiful, cheap and easy to use. It’s also easy to set up your own: Here at Jordan Manor we have three: two (PPTP and ssh-forwarding) running on Linux on a little Raspberry Pi per the instructions at http://unvexed.blogspot.com/2012/08/how-to-set-up-real-encrypted-vpn.html and http://unvexed.blogspot.com/2012/08/how-to-use-raspberry-pi-as-secure-web.html and then a third kind (L2TP) running on an elderly Mac enjoying a second life running OS X Server.
Although some firewall situations block VPNs as well, having a choice of VPNs maximizes the chance one will get through. And running your own VPN means blocking strategies based on the IP addresses of known commercial VPN services won’t work. Corollary: if you successfully run your own VPN in a situation where commercial VPNs are routinely blocked, don’t blab about it, and resist the temptation to run “check my IP address” utilities on the web when using your VPN, as these can serve as honeypots that database the IP addresses of likely VPN services, which can result in their being blacklisted.
(Meanwhile, blocking strategies based on the port numbers commonly used by VPN services can sometimes be evaded by routing your VPN through non-standard ports ordinarily utilized for other services less likely to be blocked, though that’s often not possible since port assignments are often baked in the pudding of most operating systems and clients. Of the three VPN implementations I run here, only the ssh-forwarding approach is amenable to that dodge.)
