What are the benefits to agencies enabling HTTPS for their websites?

[gbinal]

Discuss away...

[dnesting]

Privacy. Some government content is sensitive, and what we may consider non-sensitive here could be sensitive elsewhere. Consider information on human rights, reproduction, amnesty or even immigration and embassy addresses, and what that may communicate to an oppressive government, employer or family member about the intentions of the person doing the browsing. Rather than try to enumerate all of the possible pieces of content that might be worth encrypting, it's simpler to just make everything HTTPS. This has the further potential of increasing consumption of (contentious) content if people no longer believe it can be monitored.

[dnesting]

Data integrity and authenticity. Some actors may desire to influence or filter content on US .gov sites. This prevents such tampering and makes targeting filtering harder to do. Consider oppressive governments that might want to rewrite contact information. People should feel assured that the content they're viewing is what we intend for them to see.

[willchan]

It's also important to note that supporting both http and https content can, in certain scenarios, weaken the security of the https content. For example, in order to prevent downgrade attacks, we'd like to use HSTS for a domain (and its subdomains). However, if the domain needs to support both http and https, we can't utilize this security feature. I guess this falls under benefits of mandating HTTPS rather than just enabling HTTPS.

[willchan]

Another thing to note about HSTS is that it strengthens the browser authenticity requirement for websites by disabling the click-through option on the interstitials. As @dnesting notes above, authenticity and integrity of government agency websites are important for end users, since certain actors will have vested interests in altering content.

[dnesting]

@willchan I think we'd want to explicitly discourage/forbid agencies from operating independent HTTP and HTTPS sites side-by-side on the same hostname. If they want to run HTTP and HTTPS+HSTS side-by-side, containing identical content, that should be OK from a security standpoint because the HSTS-enabled clients simply won't ever use the HTTP server, and non-HSTS clients are vulnerable to ending up on a fake HTTP site regardless of whether we have a real HTTP site or not. What matters at that point is getting all of the links updated to stop pointing to the HTTP site.

[konklone]

HSTS shouldn't create any reasons for a website to continue hosting an HTTP version of the site that I can think of, other than to respond with a 301 redirect to the HTTPS version.

Older non-HSTS browsers can follow a 301 redirect (and search engines will pick up on that too) from http:// to https://, including for assets linked to via <img> or <script> tags or the like. There may be some services, like APIs used by legacy clients, or weird edge case situations like POSTs over CORS, where a redirect causes trouble, but those are going to be the exception, not the rule (and are addressable with effort).

[konklone]

As for general benefits of HTTPS, I laid out some of them for 18F's blog a couple months back:

• A secure connection. HTTPS guarantees that visitors are connecting to the official website, and not getting a page that's been tampered with — or replaced entirely — by someone else. This protects users from being hijacked or having their information stolen, and protects our government partners from being impersonated or used as a vehicle for attack.
• A private connection. Internet traffic is easily intercepted and easily correlated — there is no such thing as insensitive browsing data. By using HTTPS, a visitor's browsing activity is kept private. Web pages, URLs, cookies, and HTTP headers are all encrypted.
• A fast connection. Encryption allows us to use modern protocols like SPDY, an extension to HTTPS that greatly speeds up website loading. SPDY is widely supported by modern browsers, and used today by Twitter, Google, and Facebook. SPDY requires encryption, and is the basis for the upcoming HTTP/2, which will require encryption to support visitors on modern browsers.

Finally, using HTTPS lets us adhere to search engine best practices, as Google's search algorithms now prefer encrypted websites.

These properties are useful for all of our applications, all of the time — not just when passwords or personal information are involved. By simply deploying HTTPS all of the time, we don't have to engineer a boundary around "sensitive" parts of the application, or judge where those lines should be drawn.

A major point though, which I didn't address much there, is that when your website uses plain HTTP, you allow your visitors' browsers to be used as the world's playground.

• Comcast inserts ads into the websites its customers visit.
• Verizon tracks its customers' browsing activity and uses this data for advertising.
• Anyone with large-scale network access (not just the US) can correlate seemingly innocent data or cookies set by third party services.

When a site uses HTTPS, they protect their visitors from all of the above. As the % of HTTPS on the internet goes up, the less sense it makes for new programs like this to even begin.

Besides the carrots, the sticks are that the bodies that drive the web have come to look extremely unfavorably on plain HTTP traffic:

• IETF: Pervasive internet monitoring is an attack
• W3C (draft): The web should prefer end-to-end HTTPS
• Chrome is working on marking HTTP as non-secure.

New protocols and browser versions are going to ramp up the pressure considerably over the coming years.

I don't feel like this has to be about lecturing or moralizing. The very clear sense on the ground for me is that the web is moving towards making encrypted connections the rule and not the exception. It will only benefit .gov websites from being part of that movement as early as possible.

[dnesting]

@konklone Regarding your comments on HTTP, I am in completely agreement with you. I think there was just a miscommunication on my part there. I see no reason for a full-blown HTTP site to remain around after an HTTPS+HSTS site is available, but a simple service issuing 301s seems reasonable for the non-HSTS clients.

[willchan]

Just to add to @konklone's list of points around the general movement of the Web towards secure origins, a number of popular user agents are taking the stance that certain web features are only to be allowed for secure origins.

[NoahKunin]

Lots of substantive benefits here, but to add a meta-one echoing my comment on #1 : helps with FISMA compliance!

[alex]

To add another point: ubiquitous TLS reduces the scope of audits when compared to websites that attempt to only use TLS for a fraction of traffic (e.g. sites that have HTTPs only for login pages).

[konklone]

I tried to capture much of this on the homepage, though I'm not sure the links to Verizon and Comcast are appropriate for a GSA HTTPS guide. I hope y'all will submit revisions to the homepage that capture anything I missed, or reorganize it to communicate it better.