Why you should care about HTTPS, even if you have nothing to hide

TL;DR: HTTPS ensures not only the privacy of the content you request, but also, protects the fact that you’re even requesting it in the first place. HTTPS isn’t just for secure transactions like online banking and e-commerce. HTTPS is for any website that adds to the public dialog.
3 minute read

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 site 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 site 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 site, the first step is to convert the human-readable domain name (for example, example.com) to a computer-readable IP address (e.g, 93.184.216.34) 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.

To block a particular piece of content on a site 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 site 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 site 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 site, especially a government site, 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.

  1. See, for example, Comcast injecting ads, Verizon tracking mobile customers, and spy agencies scrapping Angry Birds for personal data. ↩

  2. 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 ben.balter.com. ↩

  3. 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. ↩

  4. 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. ↩

  5. Yeah, yeah, yeah, I know. ↩

Originally published January 6, 2015 | View revision history

If you enjoyed this post, you might also enjoy:

benbalter

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world’s largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub’s on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source. Please help improve it.

Edit