Let’s take a look at some of the more interesting articles that appeared this week on the subject of SSL Certificates and Internet security.

This article, one of many on the topic this week, provides information about the newly-discovered “Shell Shock” bug for Unix and Linux. The bug, targeting the widely used Bash command interpreter, is likely of equal seriousness as the Heartbleed Bug due to the ubiquity of Bash across the Internet. Reporter John Leyden explains, “The vulnerability is present in Bash up to and including version 4.3, and was discovered by Stephane Chazelas. It puts Apache web servers, in particular, at risk of compromise: CGI scripts that use or invoke Bash in any way – including any child processes spawned by the scripts – are vulnerable to remote-code injection. OpenSSH and some DHCP clients are also affected on machines that use Bash. Ubuntu and other Debian-derived systems that use Dash exclusively are not at risk – Dash isn't vulnerable, but busted versions of Bash may well be present on the systems anyway. It's essential you check the shell interpreters you're using, and any Bash packages you have installed, and patch if necessary.” NIST rates the flaw as a “10 out of 10 in terms of severity”.

Chrome, Firefox, Thunderbird, and Seamonkey users are advised to immediately patch their programs due to a serious SSL bug in those browsers. As reported by Zeljka Zorz of Help Net Security, the severity of the bug and the potential for Man-in-the-Middle attacks is supported by the fact that US-CERT released an alert on the topic. "The bug affects all versions of the Mozilla NSS library, and makes it vulnerable to a variant of a signature forgery attack previously published by Daniel Bleichenbacher, Mozilla has explained. "This is due to lenient parsing of ASN.1 values involved in a signature and could lead to the forging of RSA certificates." The Mozilla NSS library in question is often included in third party software, including Linux, Chrome, Google OS, and others. The vulnerability was first reported both by Antoine Delignat-Lavaud, security researcher at Inria Paris in team Prosecco, and the Advanced Threat Research team at Intel Security.

Matthew Green of Slate’s Future Tense talks about Apple’s new iOS 8 feature that allows for encryption of personal data on iPhones. The title of the article teases the notion that Apple is enabling this encryption to snub the US government, but Green goes on to explain that in his opinion this is a fallacy and the real motivation is simply better security for Apple users. The article continues, “…the impact on data raiders is enormous. Even if someone cracks your phone open and attempts to read data directly off of the memory chips, all she’ll see is useless, scrambled junk. Guessing your passcode won’t help her—unless she can also recover the secret numbers that are stored within your phone’s processor. And Apple’s latest generation of phones makes that very difficult. Of course, your would-be data thief could try to get in by exhaustively trying all possible combinations, but according to an iOS security document, Apple also includes protections to slow this attack down. (In the same document, Apple estimates that a 6-digit alphanumeric password could take upward of five years to guess.)”

Green continues, “The encryption on Apple devices is not entirely new with iOS 8. What is new is the amount of data your phone will now encrypt. Apple has extended encryption protections to nearly all the data you produce on a daily basis and will also require you to enter the passcode (or fingerprint) each time you reboot your phone. In addition, if you purchase a recent iPhone (5S, 6, or 6 Plus), Apple will store your keys within a dedicated hardware encryption “co-processor” called the Secure Enclave.”

In possible response to Apple’s latest move to encrypt their smartphones, now Google has followed suit. In this Washington Post story by Craig Timberg, we learn about how new Android devices will be automatically encrypted. Encryption of these devices isn’t new, but never before by default. According to Google spokeswoman Niki Christoff, “For over three years Android has offered encryption, and keys are not stored off of the device, so they cannot be shared with law enforcement. As part of our next Android release, encryption will be enabled by default out of the box, so you won't even have to think about turning it on.”

Timberg adds that, “In June, the Supreme Court ruled that police needed search warrants to gain access to data stored on phones in most circumstances. But that standard is quickly being rendered moot; eventually no form of legal compulsion will suffice to force the unlocking of most smartphones. Privacy advocates are ecstatic about the changes by Apple and Google, and especially about their shift toward making encryption automatic, through default settings, so that users get privacy protections without taking any action on their own.”

This article on Global Legal Post by Dez Derry discusses the recent decision by Google to prioritize sites with SSL in search results. This site is focused on EU lawyers, so Derry focuses on the importance of using SSL Certificates for websites in that particular market. As he explains, “Any honest website without an SSL certificate will see the impact of Google’s update almost immediately, as they decrease the search rankings of those sites. This could be disastrous for law firms who do not upgrade their servers, especially as Google tell us that two million legal searches are made every day in the UK, the firms at the bottom of the pile will miss out on the chance to benefit from those searches.”