HTTPS and the modern web.
When the telephone was first invented, it revolutionized communication. This bulky box made it possible for people to speak with each other at long distances. But the early telephones came with a flaw (or a feature if you were the town gossip) that made it possible for anyone in the area to listen in on conversations. Multiple houses typically shared a single line accessible to all others on the line. This was the party line. Privacy didn't exist, but because everyone knew that Mrs. Smith down the street was probably listening, people were careful with what they said. Over time party lines gave way to individual lines that, though not entirely secure, allowed a reasonable degree of privacy.
Today’s internet functions like the old party line, but with one serious gotcha: many people aren't aware of its inherent insecurity. The internet was invented for the distributed exchange of data, a robust system allowing computer nodes to communicate with each other. Security wasn't as great a concern when the system was used exclusively by a handful of scientists who wanted to exchange data.
As internet use grew, so too did the reasons people used it. It became a bold new means of communication, then a place for social engagement, then a full-blown challenge to conventional means of commerce. Somewhere along the way it became part of our everyday lives. All of this growth increased the potential for malicious abuse. Because of its similarity to old party lines, it was relatively easy for people to listen in on the data going back and forth. Networks and networking tools became increasingly sophisticated, making it more difficult for malicious users to spy on network traffic, but a fundamental weakness remained: the Internet is a party line and as your data travels from your computer to the website or server you are visiting, it's possible that people along the way are listening in.
Unlike the old party line telephone, most people using the Internet aren't aware of all the ways their personal data can be stolen. People have learned that the internet is a dangerous place, but they don’t always know what makes it dangerous. They may not realize that Mrs. Smith is listening in. This can lead to a false sense of security and a willingness to send unsecured data flying across the interwebs for any hacker to see.
Fortunately, there are ways to mitigate that risk.
HTTPS and a (more) secure internet
On the old party line telephone, one way to defeat Mrs. Smith’s listening ear and gossiping tongue was to speak in code. It doesn’t matter who is listening in if they can't understand what you are saying. Most Internet traffic travels via HTTP (Hypertext Transfer Protocol). This is the traditional unsecure way of sending data back and forth. If you login to a website that uses HTTP, your username and password are transmitted just the way you typed them and anyone listening in will have your login credentials.
The alternative is to use HTTPS which in many ways is identical to HTTP with one significant difference: the ‘S’ in HTTPS is short for SSL (Secure Socket Layer). With HTTPS, computers talk to each other in code, thwarting malicious attempts to listen in. It's not perfect technology, but in the vast majority of cases, it makes the internet a safer place, removing one major point of potential failure.
SSL encryption works by turning network traffic into a code. When you send your username and password to a website using HTTPS, anyone listening in will only be able to see gibberish. It will be useless data. Meanwhile, the website you are talking to knows how to translate that code so that you can log in safely and securely.
Unlike personal firewalls and antivirus scanners, there isn’t much end users can do to enable HTTPS on websites they visit. Although tools such as HTTPS Everywhere exist, they are far from ideal. The best solution is for websites to use HTTPS for all network traffic.
Many popular websites have already switched to HTTPS. Google, Gmail (including email clients using Gmail), Facebook, Twitter and many others now use HTTPS by default.
HTTPS and the searchable web
In the past, web maintainers were reluctant to use HTTPS unless absolutely necessary due to a perceived negative impact on search engine optimization (SEO). The web exists so that people can find the products and information they need. Search engines exist to help with the hunt. Websites employ many tricks of the trade to be more noticeable to search engine and some people were concerned that HTTPS would undermine those tricks.
All that has changed – and in a big way. For some time, Google has assured web maintainers that HTTPS would not negatively impact ranking. Now, Google has taken that a step further. On August 6, 2014 Google announced that they have begun giving a slight ranking boost to sites running HTTPS and in the future HTTPS may become an increasing factor in getting a ranking boost.
This ought to catch the attention of anyone interested in SEO and a safer web. One way to give your site a boost right now – and avoid falling behind in the future – is to switch to HTTPS. Not only will it help your Google ranking, it will provide a safer browsing experience for your users.
HTTPS and the speedy web
A further benefit to HTTPS adoption is a project by Google known as SPDY (Speedy). SPDY is Google’s attempt to shape HTTP into a protocol designed for the modern web. It won’t change the way you build websites, but it will change the way your web server talks with a user’s web browser.
Google’s goal with SPDY is to provide a protocol that serves up page content securely and quickly. In tests, SPDY’s performance is impressive. Since it is a relatively new protocol, it's not supported by all browsers but most servers supporting SPDY are able to seamlessly use HTTPS for unsupported clients. SPDY is supported by popular web servers including Apache, Nginx and OpenLitespeed.
The key point related to HTTPS is that SPDY only works with SSL. The performance gains of SPDY and the ranking gains of Google are out of reach unless your website runs over HTTPS.
Getting started with HTTPS
Setting up HTTPS requires a little elbow grease, but it's worth the work when it means providing your users with a safer web and better browsing experience. Most web hosts provide detailed instructions on setting up SSL for your site, and the process may vary from host to host. Check your host’s support documents for specific details. Here are some general things to keep in mind.
HTTPS uses SSL to encrypt web traffic which means you will need to obtain an SSL certificate. These certificates allow the client and server to talk to each other in a code familiar to both of them, but not to anyone else. No code is completely unbreakable, but the stronger the code, the harder it is to break (think about the difference between Pig Latin and a Vigenère cipher – Vigenère takes more work to crack) so look for a 2048 bit certificate with at least 128 bit encryption. Using today’s technology, trying to brute force crack a 128-bit key would take millions of years. Safe enough for the average user.
When registering a new domain name, you have many domain registrars to choose from. In the same way, there are many companies – called Certificate Authorities (CA) that offer SSL certificates. DigiCert and PositiveSSL are among the many options, offering 2048 bit certificates with 128 or 256 bit encryption.
Self-signing and the man in the middle
As you search the web for information about HTTPS and SSL certificates, you may come across instructions on self-signed certificates. You should not consider using these. Self-signed certificates are untrustworthy since an independent Certificate Authority (CA) has not verified them. Many browsers will show the user a security warning on self-signed sites, potentially deterring your visitors.
In addition, SSL certificates provided by a CA aid in preventing a special kind of attack known as the man-in-the-middle. Using a man-in-the-middle attack, a malicious user may try to jump between the client and server, tricking the client into thinking the malicious user is the server. If web browsers accepted self-signed certificates, it would be relatively easy to trick a web browser into thinking a malicious user is the intended server. Using a CA certificate eliminates man-in-the-middle attacks by providing a way for the web browser to verify that a server is what it claims to be.
Use only HTTPS in your website
As you implement HTTPS, it is important to keep in mind that secure sites should not mix secure and insecure content. If you run a website over SSL, any content loaded on the site should also be loaded over SSL. Images, scripts, stylesheets and any other content (including API calls) should all be pulled in via HTTPS. Browsers will display a security warning if your site contains mixed content. When unsecured content is loaded in an otherwise encrypted site, it opens a crack in the wall that could potentially be exploited by someone launching a man-in-the-middle attack.
Many websites today load third-party scripts via Google Hosted Libraries. Google makes it possible to load scripts through either HTTP or HTTPS. Their default examples use headless URLs (URLs in which the protocol is not specified, ie, <script src="//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>) which automatically select HTTP or HTTPS depending on how the client is accessing the server.
In the past, the restriction on mixed content kept some web maintainers from adopting HTTPS. With content being pulled in from multiple sources and CDNs, it was difficult to avoid mixed content. In today’s security aware environment, more and more services and CDNs are providing SSL options. Check with your CDN or consider switching to something like Amazon S3 or MaxCDN.
Obtaining an SSL Certificate
Any modern web server will support SSL encryption and configurations differ depending on your server. As mentioned earlier, check with your web host for instructions on loading SSL. If you run your site on a VPS, you may have to do your own configuration. With Apache or Nginx, this is fairly straightforward.
When requesting an SSL certificate, you will first need to generate a private key which will be used to create a Certificate Signing Request (CSR). You will send the CSR to whatever company you are using to generate your SSL Certificate. You will need to keep the private key for use with your SSL Certificate. Certificate Authority DigiCert has an extensive set of instructions for creating the necessary keys on a variety of server types. Briefly and in general, the private key is created from your server’s command line:
openssl genrsa 2048 > example.com.pem
Once you have the key, create the CSR:
openssl req -new -key example.com.pem -out example.com.csr
Send the CSR to the CA you have selected. When ready, they will provide you with your SSL certificate. Put both the certificate and the private key in a secure folder on your server and proceed with server configuration.
Server Setup
Apache’s SSL documentation is thorough and provides the following example for configuring SSL on a virtual host:
LoadModule ssl_module modules/mod_ssl.so
Listen 443
<VirtualHost *:443> ServerName www.example.com SSLEngine on SSLCertificateFile /path/to/example.com.cert SSLCertificateKeyFile /path/to/example.com.pem
</VirtualHost>
Basic configuration under Nginx is similar:
server { listen 443 ssl; ssl_certificate /path/to/example.com.cert; ssl_certificate_key /path/to/example.com.pem; ...
}
If you are moving from unencrypted HTTP to encrypted HTTPS, you will need to remember to set up a 301 redirect. In Apache, this is as easy as adding a redirect rule to your .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
With Nginx, detect HTTP connections by listening for port 80 and redirect all such requests to HTTPS:
server { listen 80; return 301 https://$server_name$request_uri;
}
