2016: Banner Year for Encryption

Bar graph from Let's Encrypt showing the massive 21 million additional certificates issued between the end of 2015 and the end of 2016.

The Electronic Frontier Foundation (EFF) reported that the number of websites utilizing encryption (HTTPS) to secure the traffic between the browser and the web server. For the first time since the inception of the Internet, the majority (more than half) of internet traffic was encrypted! It did not matter the size: large and small websites have been adopting secure certificates to encrypt their traffic… but why?

A number of factors played out over the past year that lead to this mass migration to encryption. Google announced it would start giving sites a small rank boost if they used encryption (that will likely get stronger as time goes on), web browsers adding visual features that make non-encrypted sites look less secure, increasing pressure from governments, businesses, and the public to secure the net, the addition of some new and advanced browser features that only work on encrypted connections, and the introduction of free programmatic (automated) secure certificates all lead to the massive adoption that occurred throughout the year.

There are still a number of countries, particularly in Asia and the Middle East, that are resisting the adoption of encryption but various organizations are already looking into how they can encourage the holdouts to join in.

Personally I see this as no different than when much of the world, especially those in the east, continued to rely on the old, out-of-date Internet Explorer versions and were eventually pressured to upgrade by Microsoft along with various other organizations through various advertisements and public service announcements (PSAs, but maybe Internet Service Announcements?). They showed just how insecure & slow older browsers are and how much risk is taken by refusing and/or blocking browser upgrades.

PHPMailer Vulnerability

PHP (PHP: Hypertext Preprocessor) Logo

A new Remote Code Execution (RCE) vulnerability has been reported on Christmas but details were only recently released. PHPMailer has already issued a patch (though they are not 100% confident in it), and WordPress (which uses PHPMailer) is considering issuing a security patch for current versions as well.

The vulnerability allows the FROM address, when passed as a variable into into PHPMailer with escaped shell arguments, will be passed to the mail function and allows an attacker to put executable code into the root.’

Note that as of now there are no known working exploits for this. Also note that this exploit may not work on all systems due to different mail functions being used having different arguments available.

Also, as long as the email address passed to the FROM variable is more strictly validated (not allowing the escaped quotes and whitespace in email addresses), it is not an issue. Some feel that the strictness of not following the RFC exactly will prevent valid emails but many point out that it would only block VERY FEW valid emails and argue that the RFC should not allow such characters – most well-known email systems do not allow such characters anyway.

The code that I write always validates the email using the filter_var function (which is strict and prevents the issue from occuring). I checked Gravity Forms and they also use the filer_var function. I don’t know about JetPack. It is also likely that, if they have not already, CloudFlare and WP Engine will add an input filter for this.

If you are using a custom build of PHPMailer in any extensions/add-ons or external code is is HIGHLY RECOMMENDED that you upgrade to PHPMailer version 5.2.18 or newer which has escaping added to the FROM address.