We are excited to announce that Ars Technica has made the jump to greater security: we now have HTTPS browsing by default. The switch to encryption will help secure your connection to Ars from eavesdropping by unauthorized parties (emphasis on the "help," since browsing with HTTPS is only one part of a sane defense-in-depth strategy, and lots of browsing metadata is exposed regardless of whether or not you use HTTPS). For most readers, the change will be a transparent one. Browser address bars will show a green SSL/TLS notification, but everything else should remain the same. We hope we've anticipated potential problems, but if you run into any issues, please let us know via this Google form.

It has been a long and winding road to get here, primarily because external assets and services we depend on weren't all ready for HTTPS when we were. Changing the default schema on a complex site like Ars—which is really a mix of static assets and dynamic Web apps, serving over 60 million pages per month to 15 million readers on a distributed bunch of physical and virtual servers—isn’t a trivial endeavor (a big shout out to Scott Helme, who has put together some amazing informational resources and a free reporting service to help sites ease their transition to HTTPS).

Where we go from here

Now that this step is complete, there are other things we’d like to do to push forward our role in advancing the encrypted-by-default Web and to take our SSL/TLS setup from acceptable to exceptional.

First off, we're activating HSTS, or HTTP Strict Transport Security. Setting up HSTS means our servers send a specific header when communicating with your browser that tells your browser to only speak HTTPS to Ars' servers for a configurable length of time. When that length of time has passed, your browser should recheck the HSTS header to see if it should keep only using HTTPS with Ars. HSTS can cause some problems when applied to domains and subdomains (it can sometimes make sites unreachable if you don't take into account all the possible configuration wrinkles when turning it on), so we're initially activating it in production with a very short expiration time. Once we're confident that HSTS doesn't cause anyone any unanticipated problems, we'll ramp the expiration out to max. At that time, we'll also add Ars to the HSTS preload lists, which will tell Chrome and other browsers to use HTTPS by default without being asked.

Another security measure we will be activating is HPKP, or HTTP Public Key Pinning. Key pinning is a method by which a site can tell browsers which certificates the browser should expect the site to serve. If the site shows up with a different certificate—like if the site is the victim of a man-in-the-middle attack or if an attacker obtains fraudulent-but-valid certificates for that site—then browsers will refuse to load the site. Key pinning is complex and potentially dangerous to implement, since doing it wrong can knock your site off the Web; we plan to get it working, but not without rigorous testing and a formal rollout plan.

We don't yet have HTTP/2 in place, but it's on our roadmap. Think of HTTP/2 as the love child of HTTPS and Google's deprecated SPDY protocol—it's the next version of the HTTP protocol and it purports to, among other things, speed up page loads by being smarter about how requests are made from browser to server. It didn't make our initial rollout because implementing it in an Ars-like layer cake of services takes additional planning and testing, but it's going to happen.

Finally, we'll eventually be upgrading our available suite of protocol options to include TLS 1.3-compliant ciphers. It's last on the current list of priorities, but as TLS 1.3 grows in popularity, we'll roll in support for its newer encryption methods.

Mixed content and where to find it

A brief note about the Ars OpenForum: when browsing our long-lived, world-famous forums, you will almost certainly run into mixed content warnings in threads with images. This is an unavoidable issue because a lot of threads include embedded images with non-secure HTTP links instead of HTTPS links, and many of those images are hosted on sites that don't offer HTTPS. When your browser encounters embedded HTTP content on a page that is supposed to be all-HTTPS, it will display a mixed content warning to advise you that the page you're visiting isn't entirely encrypted.

We made the decision to allow mixed content in the forums because the alternative was breaking a vast number of threads with embedded images. There's no need to report mixed content warnings to us when you're on the forums—it's going to happen and that's OK. If you're going to embed images in a forum post, you can avoid mixed content warnings by using an image host that allows HTTPS (Imgur is a good free option, though its mobile app is pretty obnoxious).

Browse smart—browse HTTPSmart!

Before we close, we want to make sure we’re appropriately setting expectations here. Implementing SSL/TLS does not mean your connection to Ars is “secure.” It does not mean others can't see what articles you’re reading. It doesn’t really even mean that you can always be sure when you type “https://arstechnica.com” into the address bar that you’re actually reaching Ars Technica and not a phishing site. The certificate authority system that underlies SSL/TLS is a broken wreck, and the idea that a root CA can always be trusted to vouch for the identity of its customers has proven in practice to be untrue.

Rolling out SSL/TLS is still a good idea for sites that can do it, and an “encrypted-by-default” stance is a good stance to take. Just don’t fall into the trap of believing that “encrypted” means “secure” or that a green address bar means anything other than that your browser is pretty sure you’re probably connected to the site you think you’re connected to.

Stay safe out there, folks.