Tweaks to IETF submitted changes.

* Incorporate integrity mention into Goal paragraph more tersely.
* Remove privacy mention from SNI paragraph, since the concern is
  described earlier in the memo ("What HTTPS Doesn't Do"), and is
  now incorporated into the SNI document this paragraph links to.
* Remove description of HTTPS config issues for third party
  content from Mixed Content paragraph. HTTPS resources from third
  parties is no longer "mixed content", and is better handled in
  the guidance. Added a link to the guidance page for Mixed
  Content.
* Edit Security Considerations paragraph on mixed content page to
  describe the issue as "third party content" (since the content
  is no longer mixed) and to emphasize that these considerations
  are not *introduced* by HTTPS, but are rather still present
  under HTTPS (though the situation is much improved).

Author: konklone

pages/index.md

@@ -13,7 +13,7 @@ We encourage your [feedback and suggestions](https://github.com/WhiteHouse/https
 
 ## Goal
 
-All publicly accessible Federal websites and <a class="footnote" name="footnote-source-1"></a>web services [[1]](#footnote-1) only provide service over a secure connection. The strongest privacy protection currently available for public web connections is Hypertext Transfer Protocol Secure (HTTPS). In addition, HTTPS ensures the integrity of the exchanges, making sure that pages and documents cannot be modified when they traverse the network.
+All publicly accessible Federal websites and <a class="footnote" name="footnote-source-1"></a>web services [[1]](#footnote-1) only provide service over a secure connection. The strongest privacy and integrity protection currently available for public web connections is Hypertext Transfer Protocol Secure (HTTPS).
 
 ## Background
 
@@ -49,9 +49,9 @@ HTTPS only guarantees the integrity of the connection between two systems, not t
 
 **Site Performance:** While encryption adds some computational overhead, modern software and hardware can handle this overhead without substantial deleterious impact on server performance or [latency](https://istlsfastyet.com). Websites whose content delivery networks or server software support the SPDY or HTTP/2 protocols, which require HTTPS in some major browsers, may find their site performance substantially improved overall as a result of migrating to HTTPS.
 
-**[Server Name Indication](/sni/):** The Server Name Indication extension to TLS allows for more efficient use of IP addresses when serving multiple domains. However, these technologies are not supported by some legacy clients. Web service owners should evaluate the feasibility of using this technology to improve performance and efficiency. In addition to performance considerations, domains and subdomains may themselves be sensitive -- for example 'depression.foo.gov' -- which SNI does not protect.
+**[Server Name Indication](/sni/):** The Server Name Indication extension to TLS allows for more efficient use of IP addresses when serving multiple domains. However, these technologies are not supported by some legacy clients. Web service owners should evaluate the feasibility of using this technology to improve performance and efficiency.
 
-**Mixed Content:** Websites served over HTTPS need to ensure that all external resources (images, scripts, fonts, iframes, etc.) are also loaded over a secure connection. Modern browsers will refuse to load many insecure resources referenced from within a secure website. When migrating existing websites, this can involve a combination of automated and manual effort to update, replace, or remove references to insecure resources. For some websites, this can be the most time consuming aspect of the migration process. Moreover, poorly-configured HTTPS page elements can pose a security risk to the entire page, in that exploiting a flaw in a third-party HTTPS configuration can allow injection of malicious software into the page.
+**[Mixed Content](/mixed-content/):** Websites served over HTTPS need to ensure that all external resources (images, scripts, fonts, iframes, etc.) are also loaded over a secure connection. Modern browsers will refuse to load many insecure resources referenced from within a secure website. When migrating existing websites, this can involve a combination of automated and manual effort to update, replace, or remove references to insecure resources. For some websites, this can be the most time consuming aspect of the migration process.
 
 **APIs and Services:** Web services that serve primarily non-browser clients, such as web APIs, may require a [more gradual and hands-on migration strategy](/apis/), as not all clients can be expected to be configured for HTTPS connections or to successfully follow redirects.
 

pages/mixed-content.md

@@ -107,6 +107,12 @@ Even with passive content like images, attackers can manipulate what the page lo
 
 When a website is accessible over `http://`, loading other insecure resources does not generate any sort of warning, and so websites operating over plain HTTP often accumulate many of these sub-resources.
 
-## Security considerations for HTTPS mixed content
+## Security considerations for third party content
 
-Even if a page has all page elements loaded over HTTPS, variations in HTTPS configurations could result in security vulnerabilities. For example, if 'foo.gov' loads a page element over HTTPS from 'bar.com' but 'bar.com' is not as fastidious with it's HTTPS/TLS configuration, the page element from 'bar.com' may allow injection of malicious software into the page. For example, if 'bar.com' uses a TLS configuration that is known to be weak, a malicious network adversary may be able to modify or replace the page element to inject software that could read the page contents or, potentially, exploit browser vulnerabilities and accomplish more global access to the client device. Accordingly, just as it's important to regularly evaluate the HTTPS/TLS configuration of US government websites, it will be important to also evaluate the configurations of the domains that serve third-party page elements.
+Incorporating or loading content from third party domains creates an additional attack vector.
+
+Even if a page has all page elements loaded over HTTPS, variations in HTTPS configurations could result in security vulnerabilities. For example, if 'foo.gov' loads a page element over HTTPS from 'bar.com' but 'bar.com' is not as fastidious with it's HTTPS/TLS configuration, the page element from 'bar.com' may allow injection of malicious software into the page.
+
+For example, if 'bar.com' uses a TLS configuration that is known to be weak, a malicious network adversary may be able to modify or replace the page element to inject software that could read the page contents or, potentially, exploit browser vulnerabilities and accomplish more global access to the client device. Accordingly, just as it's important to regularly evaluate the HTTPS/TLS configuration of US government websites, it will be important to also evaluate the configurations of the domains that serve third-party page elements.
+
+Note that this is still a strict improvement over incorporating content third party domains over unencrypted HTTP. Attacks on the privacy, integrity, and security of connections to third party domains over unencrypted HTTP are trivial.