Local Development with HTTPS

Encryption is everywhere and for many websites very important. When building a website or application that will require encryption, it’s best to develop in a test environment with encryption available. Developing with HTTPS turns the lights on, and prevents problems. This post is written for web developers and describes the basics of HTTPS and why using it in development is a good idea.

HTTPS, Briefly

HTTP (Hypertext Transfer Protocol) is the mechanism by which a browser communicates with a web server. To transfer data securely, data can be encrypted prior to transmission, and decrypted upon receipt – in both directions. Netscape invented a widely adopted cryptographic protocol to do this, named SSL (Secure Sockets Layer). Using HTTP over SSL yielded HTTPS, sometimes phrased “HTTP Secure”. Browsers are an active party in the cryptography, and often display a lock symbol or use green in the address bar to visually reinforce when HTTPS is in use and has been properly implemented.

Today, SSL is officially deprecated in favor of TLS (Transport Layer Security). This was already set to happen, with the TLS 1.0 specification essentially picking up where SSL 3.1 would have. The dismantling of SSL was accelerated by a vulnerability discovered by Google researchers in 2014. In order to help the public take a critical, emergent security problem seriously, they named the vulnerability POODLE – Padding Oracle On Downgraded Legacy Encryption.

At the time of writing, the most current final TLS specification is version 1.2. Despite being distinct specifications, in practice, the terms TLS and SSL tend to be used interchangeably: SSL/TLS. If somebody asks, “Are you using SSL?”, you had better not be; but if TLS is in-play, you can probably reply, “Yes” and avoid an elaborate explanation.

Certificates, Briefly

A digital identity certificate, still often called “SSL certificate”, provides a guarantee about the authenticity of the server. The certificate proves to the client (usually the browser) that the server (usually the website) to which it is connected is actually operated by the registered owner of that domain name.

To obtain a certificate, a certificate signing request (CSR) must be prepared and submitted to a certificate authority (CA). The request requires demonstration of domain control as well as the public key from a public/private key pair. Currently, a 2048-bit key size is the convention. 1024 is too easy to crack, and 4096 is probably overkill and relatively burdensome on the server. 5 is right out. Armed with the granted certificate and the private key, a server is able to negotiate a trustworthy and encrypted data transfer between itself and a client.

There are different kinds of certificates. An extended validation certificate, EV for short, can be granted by a certificate authority after a more rigorous and expensive validation of the organization and the domain. When an EV certificate is detected, most browsers will display the registered legal name of the validated organization in green in the address bar. The bit-sizes of the symmetric and asymmetric keys involved in encryption determine the strength of encryption. EV certificates do not provide superior encryption, only better validation of the organization controlling the domain.

Why Local HTTPS is a Good Tool

Deploying code that suddenly and unexpectedly breaks things in production is self-evidently bad. Code that may have seemed flawless when examined unencrypted may trigger security warnings when accessed on a secure channel. As a result, in the browser, the trusty lock icon or green bar which makes visitors feel secure may be reduced to a broken lock or caution symbol, which (hopefully) would cause visitors some concern.

Using TLS in a local development stack can expose the coding errors conspiring in the unencrypted depths, enabling developers to prevent such unhappy surprises. You probably can’t wait to get started! Part II of this article will describe in detail how to get HTTPS set up on OS X and Apache.

How to Fix the Problems

If using TLS in your dev environment does coax some problems from the umbra, you’ll want to make some corrections. The solution is likely to be essentially the same for most issues: use https for the scheme anytime possible. To more eloquently consider the problem and the solution, a tangential crash into the vocabulary of the URI will be helpful:

URIs, very briefly

URL (Uniform Resource Locator) is a well-known acronym. All URLs are a subset of the more general URI (Uniform Resource Identifier). A generic URI consists of four main parts:

• Scheme
• Hierarchical Part
• Query (optional)
• Fragment (optional)

Those parts assemble like so:
scheme://hierarchical-part/?query#fragment
It is important to distinguish between a protocol and a scheme. The URI scheme is commonly used to signal the protocol, as known from HTTP and FTP. However, this is not always the case. As an illustration, file:// is a well-recognized scheme, but it is not a protocol. Also, an XML resource may be located using the http or https scheme, but XML does not implement the HTTP protocol.

Solution

Included internal resources are probably already using paths which do not include the scheme, so resources local to the server aren’t a likely source of trouble. Encryption-incompatible code is more likely to raise a paw when code includes external assets – perhaps Google Fonts CSS, a CDN-hosted Javascript library, or a tracking pixel. Many such resources specify the scheme http by default. It is a simple oversight to paste in a URL without thinking about protocols.

One tempting way to allay warnings is to use “protocol-relative” URLs, wherein one would omit the URL scheme. A protocol-relative URL looks like this: src="//domain.com/script.js". The term is attributed to Paul Irish. This is effective; it causes the browser to request the resource over the same protocol that delivered the parent document. However, this practice is now discouraged because of security concerns.

The best method is to always use https:// when including external resources, anytime it is available. There is virtually no harm in a resource being delivered over HTTPS, even if the parent document itself is not encrypted.

How To Set Up SSL/TLS

Read Part II, which will provide step-by-step details about exactly how to set up SSL/TLS on OS X and Apache.