+
+An **encrypted HTTPS** request protects most things:
+
+
+
+This is the same for all HTTP methods (GET, POST, PUT, etc.). The URL path and query string parameters are encrypted, as are POST bodies.
+
+### What information does HTTPS _not_ protect?
+
+While HTTPS encrypts the entire HTTP request and response, the DNS resolution and connection setup can reveal other information, such as the full domain or subdomain and the originating IP address, as shown above.
+
+Additionally, attackers can still analyze encrypted HTTPS traffic for "side channel" information. This can include the time spent on site, or the relative size of user input.
+
+### How difficult is it to attack an HTTPS connection?
+
+Attacks on HTTPS connections generally fall into 3 categories:
+
+* Compromising the quality of the HTTPS connection, through cryptanalysis or other protocol weaknesses.
+* Compromising the client computer, such as by installing a malicious root certificate into the system or browser trust store.
+* Obtaining a "rogue" certificate trusted by major browsers, generally by manipulating or compromising a certificate authority.
+
+These are all possible, but for most attackers they are very difficult and require significant expense. Importantly, they are all _targeted_ attacks, and are not feasible to execute against any user connecting to any website.
+
+By contrast, plain HTTP connections can be easily intercepted and modified by anyone involved in the network connection, and so attacks can be carried out at large scale and at low cost.
+
+### Why isn't DNSSEC good enough?
+
+[DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) attempts to guarantee that domain names are resolved to correct IP addresses.
+
+However, DNS resolution is just one aspect of securely communicating on the internet. DNSSEC does not fully secure a domain:
+
+* Once DNS resolution is complete, DNSSEC does not ensure the privacy or integrity of communication between a client and the destination IP.
+
+* No major web browsers inform the user when DNSSEC validation fails, limiting its strength and enforceability.
+
+HTTPS guarantees the privacy and integrity of communication between client and server, and web browsers have rigorous and evolving HTTPS enforcement policies.
+
+### How does HTTPS protect against DNS spoofing?
+
+In practice, HTTPS can protect communication with a domain even in the absence of DNSSEC support.
+
+A valid HTTPS certificate shows that the server has demonstrated ownership over the domain to a trusted certificate authority at the time of certificate issuance.
+
+To ensure that an attacker cannot use DNS spoofing to direct the user to a plain `http://` connection where traffic can be intercepted, websites can use [HTTP Strict Transport Security](/hsts/) (HSTS) to instruct browsers to require an HTTPS connection for their domain at all times.
+
+This means that an attacker that successfully spoofs DNS resolution must also create a valid HTTPS connection. This makes DNS spoofing as challenging and expensive as [attacking HTTPS generally](#how-difficult-is-it-to-attack-an-https-connection?).
+
+If the attacker spoofs DNS but doesn't compromise HTTPS, users will receive a notable warning message from their browser that will prevent them from visiting the possibly malicious site. If the site uses HSTS, there will be no option for the visitor to disregard and click through the warning.
+
+HTTPS and HSTS work together to protect a domain against DNS spoofing.
diff --git a/pages/hsts.md b/pages/hsts.md
new file mode 100644
index 0000000..9e8fe88
--- /dev/null
+++ b/pages/hsts.md
@@ -0,0 +1,102 @@
+---
+layout: page
+title: Strict Transport Security
+permalink: /hsts/
+---
+
+**HTTP Strict Transport Security** (HSTS) is a simple and [widely supported](http://caniuse.com/#search=hsts) standard to protect visitors by ensuring that their browsers _always_ connect to a website over HTTPS. HSTS exists to remove the need for the common, insecure practice of redirecting users from `http://` to `https://` URLs.
+
+When a browser knows that a domain has enabled HSTS, it does two things:
+
+* Always uses an `https://` connection, even when clicking on an `http://` link or after typing a domain into the location bar without specifying a protocol.
+* Removes the ability for users to click through warnings about invalid certificates.
+
+A domain instructs browsers that it has enabled HSTS by returning an HTTP header over an HTTPS connection.
+
+In its simplest form, the policy tells a browser to enable HSTS for that exact domain or subdomain, and to remember it for a given number of seconds:
+
+```
+Strict-Transport-Security: max-age=31536000;
+```
+
+In its **strongest and recommended form**, the HSTS policy includes all subdomains, and indicates a willingness to be ["preloaded"](#hsts-preloading) into browsers:
+
+```
+Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
+```
+
+## Background
+
+Strict Transport Security was [proposed in 2009](https://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html), motivated by [Moxie Marlinspike's demonstration](http://www.thoughtcrime.org/software/sslstrip/) of how a hostile network could downgrade visitor connections and exploit insecure redirects. It was quickly adopted by several major web browsers, and [finalized as RFC 6797 in 2012](https://tools.ietf.org/html/rfc6797).
+
+The basic problem that HSTS solves is that even after a website turns on HTTPS, visitors may still end up trying to connect over plain HTTP. For example:
+
+* When a user types "dccode.gov" into the URL bar, browsers default to using `http://`.
+* A user may click on an old link that mistakenly uses an `http://` URL.
+* A user's network may be hostile and actively rewrite `https://` links to `http://`.
+
+Websites that prefer HTTPS will generally still listen for connections over HTTP in order to redirect the user to the HTTPS URL. For example:
+
+```
+$ curl --head http://www.facebook.com
+
+HTTP/1.1 301 Moved Permanently
+Location: https://www.facebook.com/
+```
+
+**This redirect is insecure** and is an opportunity for an attacker to capture information about the visitor (such as cookies from a previous secure session), or to maliciously redirect the user to a phishing site.
+
+This can be addressed by returning a `Strict-Transport-Security` header whenever the user connects securely. For example:
+
+```
+$ curl --head https://www.facebook.com
+
+HTTP/1.1 200 OK
+Strict-Transport-Security: max-age=15552000; preload
+```
+
+This enables HSTS for `www.facebook.com`. While HSTS is in effect, clicking any links to `http://www.facebook.com` will cause the browser to issue a request directly for `https://www.facebook.com`.
+
+In the above example, the browser will remember the HSTS policy for 180 days. The policy is refreshed every time browser sees the header again, so if a user visits `https://www.facebook.com` at least once every 180 days, they'll be indefinitely protected by HSTS.
+
+## HSTS Preloading
+
+Since it's just an HTTP header, HSTS is very easy to add to a domain.
+
+However, to enable HSTS for a domain via the HTTP header, the browser does have to see the header at least once. This means that users are not protected until their first successful secure connection to a given domain.
+
+To solve the "first visit" problem, the Chrome security team created an "HSTS preload list": a [list of domains](https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json) baked into Chrome that get Strict Transport Security enabled automatically, even for the first visit. Firefox and Safari also now use HSTS preload lists that include Chrome's list, as will upcoming versions of Internet Explorer.
+
+The Chrome security team allows any domain to [submit their domain to the list](https://hstspreload.appspot.com/), provided it meets the following requirements:
+
+* HTTPS is enabled on the root domain (e.g. `https://donotcall.gov`), and **all subdomains** (e.g. `https://www.donotcall.gov`).
+* The HSTS policy includes all subdomains, with a long `max-age`, and a `preload` flag to indicate that the domain owner consents to preloading.
+* The website redirects from HTTP to HTTPS, at least on the root domain.
+
+An example of a valid HSTS header for preloading:
+
+```
+Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
+```
+
+While you can't hardcode the entire internet into a big list, the HSTS preload list is a simple, effective mechanism for locking down HTTPS for the near future. As the [web transitions fully to HTTPS](https://w3ctag.github.io/web-https/) over the long-term, and browsers can start phasing out plain HTTP and defaulting to HTTPS, the HSTS preload list (and HSTS itself) may eventually become unnecessary.
+
+## HSTS as a forcing function
+
+Strict Transport Security provides meaningful security benefits to visitors, especially visitors on hostile networks.
+
+However, it's also highly valuable as an organizational forcing function and compliance mechanism.
+
+When a domain owner follows the recommendations in this article and sets an HSTS policy on its base domain with `includeSubDomains` and `preload`, the domain owner is saying _"Every part of our web infrastructure is HTTPS, and always will be."_ — and is giving browsers permission to vigorously enforce that from then onwards.
+
+It's a clear and auditable commitment, and gives anyone overseeing an organization's transition to HTTPS a way of marking domains as "done".
+
+Zooming out even further: it's technically possible to preload HSTS for an entire top-level domain (e.g. ".gov"). No top-level domain has yet done this — but as a comparatively small, centrally managed top-level domain, perhaps someday `.gov` can be the first.
+
+## Resources
+
+* [Browser support for HSTS](http://caniuse.com/#search=hsts)
+* [HSTS web developer documentation](https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security) maintained by the Mozilla community
+* Chrome's [HSTS preload list](https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json), and their [submission form](https://hstspreload.appspot.com/).
+* ["Upgrading HTTPS in Mid-Air"](http://www.internetsociety.org/sites/default/files/01_4_0.pdf) - A paper analyzing the current detailed practice of HSTS and [HTTP Public Key Pinning](https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning), as of November 2014.
+* ["The first .gov domains hardcoded into your browser as all-HTTPS"](https://18f.gsa.gov/2015/02/09/the-first-gov-domains-hardcoded-into-your-browser-as-all-https/), by 18F.
diff --git a/pages/resources.md b/pages/resources.md
new file mode 100644
index 0000000..bccd383
--- /dev/null
+++ b/pages/resources.md
@@ -0,0 +1,45 @@
+---
+layout: page
+title: Resources
+permalink: /resources/
+---
+
+### Articles
+
+* 18F: [Why we use HTTPS for every .gov we make](https://18f.gsa.gov/2014/11/13/why-we-use-https-in-every-gov-website-we-make/)
+* Ben Balter: [Why you should care about HTTPS, even if you have nothing to hide](http://ben.balter.com/2015/01/06/https-all-the-things/)
+* Washington Post: [Federal sites leaked the locations of people seeking AIDS services for years](http://www.washingtonpost.com/blogs/the-switch/wp/2014/11/07/federal-sites-leaked-the-locations-of-people-seeking-aids-services-for-years/)
+* Washington Post: [The federal government’s online privacy watchdog just made its Web site more secure](http://www.washingtonpost.com/blogs/the-switch/wp/2015/03/06/the-federal-governments-online-privacy-watchdog-just-made-its-web-site-more-secure/)
+* Washington Post: [Your browser may soon force you to connect securely to some U.S. government Web sites](http://www.washingtonpost.com/blogs/the-switch/wp/2015/02/11/your-browser-may-soon-force-you-to-connect-securely-to-some-u-s-government-web-sites/)
+* The Hill: [FTC enables default encryption](http://thehill.com/policy/technology/234873-ftc-enables-default-encryption)
+* The Hill: [White House website goes secure](http://thehill.com/policy/technology/235323-white-house-website-goes-secure)
+* 18F: [The first .gov domains hardcoded into your browser as all-HTTPS](https://18f.gsa.gov/2015/02/09/the-first-gov-domains-hardcoded-into-your-browser-as-all-https/)
+* FTC: [Government agencies enable HTTP Strict Transport Security for public websites](http://www.ftc.gov/news-events/blogs/techftc/2015/02/government-agencies-enable-http-strict-transport-security-public)
+* FTC: [FTC.gov is now HTTPS by default](https://www.ftc.gov/news-events/blogs/techftc/2015/03/ftcgov-now-https-default)
+* Fast Company: [The Fight for HTTPS](http://www.fastcompany.com/3036430/the-fight-for-https)
+* E Pluribus Unum: [White House moves WhiteHouse.gov to HTTPS by default, tying privacy to security](http://e-pluribusunum.com/2015/03/11/white-house-moves-whitehouse-gov-to-https-by-default-tying-privacy-to-security/)
+* Motherboard: [Whitehouse.gov Is Now Secure By Default, Signaling a Trend in Government](http://motherboard.vice.com/read/whitehouse-site-is-now-secure-by-default-signaling-a-trend-in-government)
+* NextGov: [WhiteHouse.gov Finally Gets Boosted Encryption](http://www.nextgov.com/cybersecurity/2015/03/white-house-dot-gov-website-use-https-encryption/107223/?oref=river)
+
+
+### Internet standards movement
+
+* The W3C's Technical Architecture Group has found that [the web should actively prefer secure connections](https://w3ctag.github.io/web-https/) and transition entirely to HTTPS.
+* The IETF has said that [pervasive monitoring is an attack](https://datatracker.ietf.org/doc/rfc7258/), and the Internet Architecture Board (the IETF's parent organization) recommends that [new protocols use encryption by default](http://www.internetsociety.org/news/internet-society-commends-internet-architecture-board-recommendation-encryption-default).
+
+### Industry movement
+
+* Google [gives a search ranking boost](http://googlewebmastercentral.blogspot.com/2014/08/https-as-ranking-signal.html) to HTTPS sites.
+* Chrome plans to [mark HTTP as non-secure](https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure).
+* Chrome also plans to [restrict some features to HTTPS sites](https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2LXKVWYkOus), including geolocation.
+* Electronic Freedom Foundation's [HTTPS-Everywhere Project](https://www.eff.org/https-everywhere)
+
+### Standards and tools
+
+[SSL Labs](https://www.ssllabs.com/ssltest/) is a universally referenced HTTPS evaluation and grading tool.
+
+18F has also written [`https-scan`](https://github.com/18F/https-scan), a command line tool which runs one or more domains through several separate small tools:
+
+* [`ssllabs-scan`](https://github.com/ssllabs/ssllabs-scan) - Command line tool for the SSL Labs API. (See its [Terms of Use](https://github.com/ssllabs/ssllabs-scan/blob/master/ssllabs-api-docs.md#terms-and-conditions).)
+* [`mixed-content-scan`](https://github.com/bramus/mixed-content-scan) - Command line tool for walking over a website and scanning for the use of insecure resources.
+* [`site-inspector`](https://github.com/benbalter/site-inspector-ruby) - Scan a domain for various web/HTTP-related properties, including HTTPS support.
diff --git a/resources/news.md b/resources/news.md
deleted file mode 100644
index db97bbe..0000000
--- a/resources/news.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## Related Articles and Blogposts
-
-* [Federal sites leaked the locations of people seeking AIDS services for years](http://www.washingtonpost.com/blogs/the-switch/wp/2014/11/07/federal-sites-leaked-the-locations-of-people-seeking-aids-services-for-years/)
-* [Why we use HTTPS for every .gov we make](https://18f.gsa.gov/2014/11/13/why-we-use-https-in-every-gov-website-we-make/)
-* []()