You’re probably already familiar with technologies like SSL and TLS. They’re the little green icon in the top left corner of your browser anytime you visit a website with a URL that begins with
https://. They’re most often used to secure sensitive web requests, like checking your bank account balance or purchasing stuff online. HTTPS encrypts the connection between your computer and the server you’re talking to so that nobody can jump in the middle and muck things up.1
Traditionally, the arguments in favor of HTTPS have been for integrity, privacy, and identity. If a message is encrypted by a server before it’s sent to your computer, and its done in such a way that only you can decrypt it, you can have a high level of confidence that the message you receive is the message the server sent (integrity), and that you’re the only one who opened it (privacy). Further still, because of the initial handshake that makes all this possible, you know that the server you’re talking to is the one you want to talk to, and not someone else pretending to be the server (identity). Without HTTPS, there’s a couple of points in the route each request must take that could allow a third-party to intercept, or worse, modify your request or its response as it travels over the open internet.
Before this week, I, like I suspect most people, thought HTTPS was only for requests that needed to be secure. After all, that’s what the “S” in HTTPS stands for. But with GitHub being blocked in India, I realized there’s another, much more universal argument in favor of HTTPS everywhere: censorship.
Whether a corporate firewall or a country-wide block, intercepting and screening an HTTPS-backed website becomes significantly harder. While an ISP or employer could easily stand up a proxy or other firewall to inspect and filter incoming traffic for objectionable content, if that traffic is encrypted, the only datapoint exposed to third parties is the requested domain, not what content you’re requesting from the server.2
Typically, when you make a request to a website, the first step is to convert the human-readable domain name (e.g.,
example.com) to a computer-readable IP address (e.g,
220.127.116.11) by querying your internet provider’s domain server. Think of it like checking the yellow pages for a company’s phone number. But if you’re the internet provider, there’s no reason you can’t instruct your domain server to return no IP address, making it look like the requested domain simply doesn’t exist, or worse, to return a malicious site in its place.
If you want to block a particular piece of content on a website using HTTPS, say a blog post on WordPress.com, your only choice is to poison the DNS entry to block the entire site, as there’s no way to know if the user’s request is for objectionable or innocuous content. This forces a baby-with-the-bathwater choice and is exactly how most internet censorship is implemented today, at least on the state level.3
You’ve probably seen the now-famous Google DNS graffiti when Turkey banned Twitter last year. By instructing your computer to use a public DNS server, rather than your internet service provider’s, that domain look up, the weak link in the request, instead goes to a third-party beyond the state’s control, and the website becomes accessible again.4
HTTPS ensures not only the privacy of the content you request, but also, protects the fact that you’ve requested it. HTTPS isn’t just for online banking and e-commerce. HTTPS is for any website that adds to the public dialog, whether it’s political commentary, how to contact a government official, or just a personal blog.5 If you run a website, especially a government website, even if you never process “sensitive” requests, consider adding HTTPS support and enforcing HTTPS by default.
Ironically, HTTPS is about more than keeping things hidden. It’s about keeping things seen.
For example, without HTTPS, an eavesdropper would see that you were reading
ben.balter.com/2015/01/06/https-all-the-things/. With HTTPS, all they’d see is that you made an encrypted request to
Obviously, a country should have the right to enforce its own social norms, but when such technical implementations are often overinclusive and trivial to bypass by even non-technical users switching protocols, DNS servers, or routing traffic through a proxy or VPN, such ends may be better accomplished by more narrowly tailored, non-technical means. ↩
While it’s possible to block external DNS entirely, or to block certain IPs, this is exponentially more complex for for-profit, privately owned ISPs to implement, quickly becomes a game of whack-a-mole, and will almost undoubtedly be over inclusive, especially where CDNs or shared hosting is involved. ↩
Prior to GitHub, Ben was a member of the inaugural class of Presidential Innovation Fellows where he served as entrepreneur in residence reimagining the role of technology in brokering the relationship between citizens and government. Ben has also served as a Fellow in the Office of the US Chief Information Officer within the Executive Office of the President where he was instrumental in drafting the President’s Digital Strategy and Open Data Policy, on the SoftWare Automation and Technology (SWAT) Team, the White House’s first and only agile development team, and as a New Media Fellow, in the Federal Communications Commission’s Office of the Managing Director. His paper, Towards a More Agile Government was published in the Public Contract Law Journal, arguing that Federal IT Procurement should be more amenable to modern, agile development methods. More about the author →