Coder Social home page Coder Social logo

gsa / https Goto Github PK

View Code? Open in Web Editor NEW
246.0 52.0 86.0 5.45 MB

The HTTPS-Only Standard for federal domains (M-15-13), and implementation guidance.

Home Page: https://https.cio.gov

License: Other

Ruby 0.12% HTML 6.75% Python 83.97% JavaScript 1.74% SCSS 7.42%

https's Introduction

HTTPS Everywhere for the U.S. Government

The American people expect government websites to be secure and their interactions with those websites to be private.

This site contains a web-friendly version of the White House Office of Management and Budget memorandum M-15-13, "A Policy to Require Secure Connections across Federal Websites and Web Services", and provides technical guidance and best practices to assist in its implementation.

Read the policy.

Please open an issue to leave feedback or suggestions. Pull requests are welcome to pages other than the homepage, which shows the final policy and is not subject to change through GitHub.

Thank You For Your Feedback

This policy was open for public comment before its finalization. It received numerous comments whose thoughtfulness and feedback improved the final policy.

You can see what changed between the proposal and the final policy in pull request #108.

The homepage of this site is the final policy. The other pages on https.cio.gov are open for contribution at any time, and are intended to be resources for agencies implementing the HTTPS policy.

Developing on the site locally

If you're using this repository to run the site locally, instructions follow below.

Dependencies:

  • Node 6+ to install USWDS and dependencies
  • Ruby and bundler to install / run Jekyll
First-time setup
  1. npm install to install the USWDS, and Gulp dependencies.
  2. npm install -g gulp to let you use the gulp CLI directly.
  3. bundle install to install Jekyll.
Running the app

If you'll be editing the Sass/CSS:

  • gulp watch

To run the app:

  • bundle exec jekyll serve

Public domain

This project is in the worldwide public domain. As stated in CONTRIBUTING:

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

https's People

Contributors

adelevie avatar alex avatar anand-bhat avatar bandrzej avatar bknowles avatar brodygov avatar cbartlett avatar dstufft avatar elucify avatar gbinal avatar h-m-f-t avatar harlanyu avatar inetbiz avatar jjediny avatar josephlhall avatar jsha avatar konklone avatar lachellel avatar mathiasbynens avatar mattbrundage avatar mlazzeri avatar mlissner avatar nacin avatar noahkunin avatar plinss avatar prayagverma avatar thecapacity avatar thekaveman avatar titanous avatar willchan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

https's Issues

+1 on behalf of Google Chrome

Google has long sought to provide secure web communications with Hypertext Transfer Protocol Secure (HTTPS), and is committed to offering HTTPS for increasingly more of its services. We support a safe web ecosystem.

In this vein, Google strongly supports the White House’s proposed “HTTPS-Only Standard” to provide people — throughout the United States and the world — exclusively secure access to U.S. Government services. When interacting with the government, whether for taxes, immigration, Social Security, voter registration, healthcare, or any other public service, people have a critical need for the information they send and receive to be confidential and untampered. HTTPS is the minimum requirement for achieving this, and Google is pleased to see the White House recognize this need.

The proposal also further highlights the need for the entire web to meet this minimum standard, as the World Wide Web Consortium’s Technical Architecture Group recently highlighted as a finding: https://www.w3.org/2001/tag/doc/web-https:

"Over the last 25 years, the Web has grown into a platform for much of the world’s communication, whether it be information sharing, community building, commerce, education, social networking, or underpinning applications.

In meeting these needs, the Web’s trustworthiness has become critical to its success. If a person cannot trust that they are communicating with the party they intend, they can’t use the Web to shop safely; if they cannot be assured that Web-delivered news isn’t modified in transit, they won’t trust it as much. If someone cannot be assured that they’re talking only to the intended recipients, they might avoid social networking."

This proposal is an important way for the United States Government to help protect the privacy and security of citizens on the web and lead the way in the digital world.

More emphasis on integrity?

Standardizing on HTTPS only is great, but I imagine one common reaction by some agencies will be, "we only serve static content, so there are minimal privacy issues." While serving up static content can have some privacy implications (e.g. looking up medical information from the CDC), an under-appreciated benefit of HTTPS is that it ensures the integrity of information in transit. It's conceivable that an adversary would want to tamper with content being served. For example, a potentially hostile country could silently modify published US policy when viewed by their citizens. In a less extreme example, an ISP could inject additional content (such as ads) into a page, causing users to think that agencies added or endorsed that content.

While some agencies already use technology to ensure integrity (in particular, GPO's cryptographic signing of PDFs comes to mind), HTTPS transparently and automatically adds another layer of protection.

Ways to Help Agencies

This issue is for brainstorming ways to help agencies implement a proposed requirement to enable HTTPS.

Recommend making sites available over Tor Onion (Hidden) Services

As you yourself state:

IP addresses and destination domain names are not encrypted during communication. Even encrypted traffic can reveal some information indirectly, such as time spent on site, or the size of requested resources or submitted information.

Tor enables users to browse sites anonymously, to keep secret the fact that they're browsing (as examples) health care, the GAO, OSHA Whistleblowers, or the SEC. Clearly browsing any one of these sites may be a telling act to (e.g.) an employer that should be treated as sensitive.

Making these sites available over Onion Services provides even stronger protection for users than merely using Tor, as their traffic is end-to-end authenticated and never leaves the Tor Network. (Onion services are also, more commonly, called 'Hidden Services' but in this case, the identity of the server is not intended to be hidden.) Facebook recently made a Onion Service available for example.

It would be a wonderful gesture, on top of this already excellent proposal, to recommend that agencies consider if the mere act of browsing their site may be sensitive information and make themselves accessible via a Tor Onion Service.

Plan for updating technical configuration/best practices

I think it's great that this proposal is so specific about e.g. encouraging ECDHE, discouraging RC4, etc. But I worry that for many agencies this will be set-and-forget: if someone comes up with an attack on TLS1.0 or AES 128 is no longer considered sufficient in 2016, what would the plan be to upgrade any agencies that already implemented TLS1.0? My suspicion is that they wouldn't do it on their own accord.

HTTP/2

Take advantage of the speed of SPDY and (soon) HTTP/2.

Refer them to istlsfastyet.com for a reference of which servers and CDNs support SPDY and HTTP/2.

Secure-to-origin for CDNs

Where CDNs are used to provide HTTPS, the connection from the CDN to the origin server should also be protected with HTTPS, and authenticated by the CDN when making that connection. CDNs vary in their support of secure-to-origin, so this should be one of the questions asked when evaluating a CDN.

Applicability to non-executive branch websites?

First, kudos for this proposal. An extra benefit I see arising merely from its existence is encouraging state and local government agencies to also go HTTPS-only.

Here's my (no doubt naive) question: if this proposal gets approved and implemented, would it automatically apply to non-executive branch websites (house.gov, loc.gov, supremecourt.gov, etc.)? Or would those agencies currently be free to ignore HTTPS if they so chose? What about public .mil sites?

+1 from X-Lab.

Proactively ensuring the integrity and privacy of our communications is an increasingly important issue. HTTPS would go a long way toward ensuring that, at least in transit, we can be relatively certain that the information we access (and the data we pass back and forth) will remain private. Certainly, there is far more still to be done, but this would be an incredible leap forward.

--Sascha Meinrath
Founder & Director
X-Lab

Outstanding!

Sorely needed! So happy to see the WH engage on this, really meaningful!

Akamai

What resources can we provide to an agency who is using Akamai for their HTTPS? Configuration? Procurement vehicle advice?

+1 from the W3C TAG

The W3C Technical Architecture Group (TAG) (@w3ctag) is happy to see that the United States government is considering the requirement of encryption and authentication (through use of HTTPS) on all publicly-accessible government Web sites. Doing so will increase the security of people who interact with the government and encourage adoption of a more secure Web, as we documented in the “Securing the Web” finding.

A government requirement sends a strong message that encryption and authentication are necessary for Web security, and will encourage government vendors to embrace providing secure services. As has been noted elsewhere, the incremental cost of doing so falling; thanks to efforts like this, we expect it to continue to drop. While good government needs to be cost-conscious, it should not come at the cost of security.

We note also that where facilities are moved from an http: URL to an https: URL, a redirections should be set up so that existing links do not break. There is ongoing work within the W3C to make this transition easier, and we encourage interested parties to contribute to the WebAppSec Working Group and elsewhere.

Tim Berners-Lee, @timbl (Chair)
Daniel Appelquist, @torgo (Chair)
Peter Linss, @plinss (Chair)
Yves Lafon, @ylafon
Travis Leithead, @travisleithead
Mark Nottingham, @mnot
Alex Russell, @slightlyoff
Yan Zhu, @diracdeltas

Very excited to see this proposal

I'm thrilled to see this proposal! People deserve secure and private access to government documents. The bulk of industry has already shifted -- or is in the process of shifting -- to HTTPS, and the U.S. government should not lag behind. I look forward to downloading my 2016 tax documents over HTTPS instead of HTTP.

Migrating an API to HTTPS

Publish a page about migrating an API that has an HTTP user base to HTTPS.

Offhand, I think the outline is:

  • Establish the HTTPS endpoint, with HSTS enabled.
  • Update the documentation to only use the HTTPS endpoint, and to explicitly recommend migrating.
  • Announce the transition plan, loudly.
  • Begin clear analytics for HTTP vs HTTPS traffic.
  • Update 1st party API clients and applications.
  • Go around to 3rd party clients and file bugs and pull requests.
  • Contact major integrators, if known, directly and tell them to use the HTTPS endpoint.
  • After a time, refer to the built-up analytics, assess two reasonable deadlines: a short blackout, and a final cutover.
  • Contact people the analytics shows still using the HTTP endpoint and tell them the deadlines.
  • Do the short blackout and see what complaints it sends your way.
  • If no complaints, fantastic! Try a longer blackout. Still no complaints? Time for a cutover, and you're done.
  • If complaints, refer the complainants to your public warnings and deadline, and do the cutover on the deadline day.

A few things to bear in mind:

  • Some (though not all) clients will follow redirects.
  • HSTS will only affect supporting clients, and I've never seen a non-browser client implement HSTS.
  • This also means the domain (if a second-level domain) can be freely submitted to the browser preload list, or if it's a subdomain it need not halt the submission of its parent second-level domain.
  • Eventually you just have to pull the trigger.

cc @GUI @handlers

Moved main branch from gh-pages to master

Just a notice for contributors: since we're no longer using GitHub Pages, I've moved the main branch back to master, and deleted gh-pages. Please submit PRs to that branch from now on.

If you've already got a local branch forked off gh-pages, it should PR against master without issue, since master is a fast-forward from gh-pages.

Additional technical concepts

The other major factors to consider when deploying HTTPS.

  • Forward secrecy (and dhparam strength)
  • Server Name Indication
  • SHA-1 vs SHA-2
  • Avoid RC4
  • Don't support SSLv3, support TLSv1.2 (and TLSv1.0)
  • Revocation and OCSP stapling
  • ECDSA certificates
  • TLS_FALLBACK_SCSV (downgrade protection)
  • Public key pinning (still experimental)
  • Session tickets and IDs

I think Strict Transport is worthy of its own page, as is HTTP/2 + SPDY.

Build out background material

Note language from digital government strategy

Search for existing material about https on or about government websites:

  • search google for "https access" site:.gov (or rather, find a good way to do that)

OTI Public Comment: OTI Supports the Proposed HTTPS-Only Standard

Comments to the U.S. CIO on Proposed HTTPS-Only Standard for Federal Websites

The CIO of the United States has proposed that all Federal government websites should support mandatory HTTPS encryption. The Open Technology Institute at New America wholeheartedly supports this proposal, which will significantly improve Americans’ privacy and security, and send a clear message that HTTPS protection should be considered a basic standard for all Web-based communications.

The websites of the Federal Government collectively house a vast quantity of important information about disability benefits, taxes, immigration, resources for veterans, Social Security, Medicare, workplace protections, and many other topics that may be highly personal in nature. Americans need and have a right to expect easy access to such information, and in the 21st century that means making these resources available on-line. However, there are many significant risks associated with providing digital access to such essential, sensitive, and frequently-accessed government resources in a manner that does not protect the security and privacy of those requesting them. By requiring Federal web sites to use HTTPS by default, agencies will be acting proactively to protect Americans as they conduct their day-to-day business with the Federal government, while also serving as an example for state and local governments to follow.

In the two decades since it was first released, HTTPS has become the global industry standard for securing private information as it travels across the Internet. Without HTTPS, many of today's most essential online services – ecommerce, online banking, digital medical record systems, etc. – would be unable to guarantee either the secrecy or the fidelity of the information they send to and receive from their users. Such guarantees are basic protections that consumers have every right to expect from all institutions that gather their personal and financial information. The U.S. CIO’s proposal would simply compel all Federal web sites to meet the level of service that Americans already expect and receive from the private sector.

HTTPS-enabled websites provide two critical protections over non-HTTPS sites: encryption and authentication. HTTPS encryption keeps the contents of a particular Web request or transaction secret, so that they cannot be accessed by anyone except the user and website exchanging the information. Even if the communication is intercepted by a third party, it will appear to be nothing but a jumble of random text. HTTPS authentication verifies that a website is actually associated with the person or organization it claims to represent, rather than by an impostor who set up the site to trick users into divulging personal information (known as a phishing attack). By adopting a policy of using HTTPS by default, a website gives its visitors confidence that the information they are getting is coming from the web site they intended to visit, and is exactly what that website intended to send them.

These protections are no longer seen as “optional” or only for “certain kinds of data” (traditionally limited to passwords, credit card numbers and little else). Indeed, encrypting all traffic on the Internet is increasingly seen as the only way for website owners to protect their users from diversion to imposter sites, or injection of malicious code. Recent research demonstrates that it is possible to infect a computer with malware by changing the contents of a legitimate but unencrypted website en-route. Additionally, this past month researchers discovered that non-encrypted traffic to common web sites is in fact already being altered en-route by foreign governments, in ways that have made visitors to these sites become unwitting contributors to distributed attacks on third-party websites.

Without HTTPS, data sent between a website and any of its visitors can be recorded or manipulated by anyone who has access to any part of the network path between the two parties. For the many Americans who often access the Internet via free WiFi hotspots found in coffee shops, airports and city streets, the network path includes anyone who happens to be concurrently using the same WiFi access point. Many Americans also access the Internet from workplace and/or other institutional networks that are subject to comprehensive monitoring, a fact which can make it difficult or dangerous for users of the network to access a wide variety of important government resources. For example, researching OSHA violations from a workplace network could result in interrogation or retribution

Given the growing dangers associated with insecure Internet communications, it is more important than ever for Americans to know that traffic to and from U.S. Federal websites is not being intercepted, tampered with, or used as a vector for malware. The risks to personal privacy and security posed by a lack of universal support for HTTPS are significant, and the Federal government has both the means and the responsibility to lead the way in mitigating those risks.

The tools for implementing HTTPS support are widely available, the costs are minimal, and the best practices are widely documented, including by the government itself. What’s more, the cost of implementation will be particularly trivial for federal agencies since the government has already invested in all of the required infrastructure for creating secure certificates.

The U.S. CIO’s proposal brings the Federal government in line with well-established best practices in the tech sector, and is a privacy and security win for all Americans. Additionally, in adopting the CIO’s recommendations the Federal government will take a leading role in bringing more attention to the need for universal HTTPS adoption, and the importance of continuing to maintain and improve the standard’s underlying technologies. We strongly recommend the adoption of the HTTPS-only policy for Federal websites, and further encourage state and local governments to institute the same policy.

Jordan McCarthy, Staff Technologist ([email protected])
Nat Meysenburg, Staff Technologist ([email protected])

The Open Technology Institute at New America
1899 L Street NW, Suite 400
Washington, DC 20036

Advise secure cookies

Once a site is fully HTTPS, it should be setting the secure flag on all cookies, to avoid leakage of cookies on non-HTTPS requests for that site or for (possibly non-existent) subdomains.

Require 'secure' flag on cookies

Would it be in the scope of this proposal to require all cookies to have the "Secure" flag set, if any cookies are needed? It would further cement the "HTTPS is required" message and I think it would be a great addition.

The Mixed Content page does mention issues with mixed content and cookies, but I think the best place for info about this would be the Migrating APIs to HTTPS page. I can work on a PR if this is a reasonable addition to the proposal.

Strict Transport Security

A page just on Strict Transport Security: its security guarantees, its strictness (no clickthrough of warnings!) and the opportunity to preload one's domain.

Server Name Indication

A page on Server Name Indication -- its benefits, its client support, and how to evaluate the desirability and feasibility of requiring it on one's domain.

Yes, Yes, and Another Yes!

This is great, I'm super excited to see this proposal and to see the federal government taking online privacy/security seriously.

A much-needed bar-raising

Aside from the copious security benefits of doing this, modernizing federal websites through the (mandatory) adoption of HTTPS will represent a sea-change. There are two scenarios in which this will be evident:

  1. The federal government moves forward with this policy, implementation is at least smooth enough, interactions with the federal government become safer, and – perhaps most importantly – other actors that are also lagging in implementing HTTPS have to reflect on the despair-inducing fact that they are behind the federal government in technological terms. For instance, the advertising industry is in desperate need of securing the information it transmits among hundreds of other actors, especially given that they serve as a leaky faucet for every website in which their ads are displayed. (See, e.g., https://openeffect.ca/some-impressions-on-internet-advertiser-security/). And then, maybe, they'll also take this step, for the same reason that the federal government should now.
    -OR-
  2. The federal government becomes one of the last major actors to utilize HTTPS (among governments, or when compared to industry), at which point it will be yet another apathy-inducing, groan-worthy anecdote about how dangerously and expensively slow the federal government is at modernizing.

I personally long for the former – where I can point to the federal government as the leader.

A final note: when it comes to questions of cost, which are certainly valid and should be considered, do we not all expect this to happen at some point? The cost is now or later – with the public's privacy and security (both directly regarding federal sites and in secondary effects as described above) at risk in between.

Respectfully,
Sean Vitka

(Secret message: Can we all note how freaking awesome it is that you're soliciting feedback via GitHub? The number of people who don't think they can engage government on important issues simply for the sheer Luddism of formal process is stunning – kudos to all of you doing this out in the open!)

Excellent proposal - procurement vehicles are key

This is an excellent idea, and the CIO/GSA team is well-placed to execute. I see great notes in other issues about server configuration, which will be important. In my experience, it will be just as important to untangle the maze of procurement vehicles that agencies use in order to buy hosting from companies like Akamai. Today, some of these may make it difficult to achieve the goals of this project simply because the requirements of this project weren't written into the agreements (not because they aren't technically available). If you can identify those agreements and either modify them or provide alternatives (via Blanket Purchase Agreements (BPAs) or otherwise), I imagine that dozens of gov sites could flip to good HTTPS overnight ("good" meaning HSTS, etc.).

Amazon Web Services

How to manage HTTPS termination in Amazon Web Services:

  • An Amazon EC2 instance directly. (Refer to termination via Haproxy, nginx, Apache, IIS, or whatever.)
  • An Amazon ELB. Either: a TCP passthrough (don't terminate on the ELB), or a recommended set of options for ELBs to terminate with the best possible settings. A discussion of what ELBs can and can't do for you when they terminate (e.g. fewer controls, doesn't require SNI).
  • An Amazon CloudFront distribution. Discuss: communicating via HTTPS to the backend, what tradeoffs you make (e.g. lack of SPDY support, SNI cost, 2048-bit max keylength).

There should probably be a discussion of Amazon's CloudHSM and Key Management Service offerings, but I haven't used either of them.

Configuring common servers

Make a page that describes strategies and resources for dealing with common servers and hosting environments:

  • Apache
  • nginx
  • Microsoft IIS
  • Amazon Web Services
  • Akamai
  • Cloudflare

Perfect Forward Secrecy

There are many options and things to choose when using TLS, but one feature that truly limits the damage of data breaches is PFS. Please make sure that PFS is used to protect the integrity of previous communications and that it becomes mandatory for PFS to be used on all federal websites.

Thank you for soliciting feedback on Github! 🤘

Dealing with mixed content and migrating legacy content

In the last day or two, there have been some great threads on the WebAppSec list about making it more straightforward for websites to migrate to HTTPS without having to go and clean up all the legacy URLs (and without disabling mixed content blocking).

The principal issue seems to be: how do you pull this off in such a way that doesn't break your site for older clients that don't support whatever client extension is being proposed to solve it?

No mention of NIST SP 800-52r1

NIST SP 800-52r1 (http://dx.doi.org/10.6028/NIST.SP.800-52r1) is normative for TLS usage, but is not mentioned here. While it specifies that TLS 1.2 be preferentially used (along with quite a few other requirements), it does not make TLS 1.2 mandatory (and should) and as well unfortunately requires the use of several non-PFS ciphers (and should not).

Perhaps some of the guidance from NIST SP-80052r1 could be distilled here.

Getting HTTPS certificates

A page dedicated to what you need to know when getting an HTTPS certificate. This can resolve a few questions:

  • Are there any US government certificate authorities I can use? (Answer: not right now, unless your website is used under controlled circumstances.)
  • DV vs OV vs EV
  • Favoring ease of rotation, and automation where possible
  • Mention that SHA-2 and 2048-bit are the industry baseline
  • Mention that ECDSA is a possibility if Windows XP doesn't need to be supported

Very happy to see this excellent proposal!

This is great news!

I've been working on the Chrome Security team for a few years, and we've been advocating greater HTTPS adoption to make the web safer. It's wonderful to see the idea that HTTPS is the baseline finally taking off. Kudos and thank you!

Technical overview of how HTTPS works

Not tied to any particular implementation. The basic idea of HTTPS, and some high-level details about the handshake.

I'm also perfectly fine deferring most of the hard stuff here to other explanations, rather than writing something that many people have tried to do before.

I wrote a super high-level description in my post about SHA-1's weakness:

When you show up to a website using green lock, the website presents a file — an SSL "certificate" — to your browser. This certificate is used to do two things: encrypt your connection to the website, and verify that you've connected to the real website.

Any certificate can be used to encrypt your connection. But to verify that you're at the real Facebook, your browser has to have a way to decide whether to trust that certificate, and show you a green lock.

Your browser does this by figuring out whether the website's certificate file has been issued by a "Certificate Authority" (CA). CAs generally charge money to give website owners this file. Your browser trusts over 50 Certificate Authorities to create and vouch for certificates, ranging from Verisign to GoDaddy to various governments — and the many hundreds of intermediary CAs to whom those 50+ have delegated trust. As you might guess, this is a very flawed system, but it's the system that we have right now.

And I tried again in 18F's HSTS post:

When you visit a website, your computer connects to the website's computer. This means you send information about yourself sprinting across the internet at the speed of light, passing through the computers of companies and countries from all over the world that sit between you and the website's computer. That's how the internet works: a sprawling, unpredictable network of computers under the control of potentially anyone.

When you connect over ordinary http://, it's like sending a postcard in the mail, where every computer in between you and the website gets to see your information.

http

That includes cookies, the browser you use, and any other data the website asks you to send (in this example, your location).

https

And because it's like a postcard, any computer in between you and the website can freely erase, change, or add information on the postcard (imagine it's written in pencil). In fact, because insecure http:// connections are so common, this happens all the time and it's often invisible to the ordinary user.

When you can connect over https://, it's like sending a locked briefcase that only the website's computer can open. IP addresses and a domain name are all that the internet's computers get to see.

However, none of this touches the actual public-private key cryptography, or how the handshake process works.

EFF public comment: HTTPS-Only is necessary and overdue

COMMENTS OF THE ELECTRONIC FRONTIER FOUNDATION REGARDING THE HTTPS-ONLY STANDARD

The Electronic Frontier Foundation (EFF) is grateful for this opportunity to respond to the request by the Office of Management and Budget (OMB) and for comments regarding The HTTPS-Only Standard. EFF is a nonprofit civil liberties organization with more than 22,000 dues-paying members. It has worked for more than 20 years to protect consumer interests, innovation, and free expression in the digital world.

HTTPS deployment in one of EFF's major topic areas. EFF's work in this area includes the SSL Observatory, a research project that catalogues existing deployment of HTTPS; Encrypt the Web, a longstanding project to encourage deployment of encryption, including a report on which major companies support various encryption technology; HTTPS Everywhere, a browser extension to help individuals discover and use the HTTPS version of websites; and Let's Encrypt, a collaboration with Mozilla to launch a free, automated certificate authority to decrease the barriers to entry in deploying HTTPS.

EFF whole-heartedly supports the federal government's adoption of this essential cybersecurity standard. We also urge all state, local, and national governments worldwide to follow suit, as soon as possible.

HTTPS, the secure version of HTTP, protects web browsing activity by encrypting and authenticating everything sent between an individual and a web server. It is rapidly replacing insecure HTTP on the Internet and security experts are making plans to provide warnings when accessing HTTP pages.

Without HTTPS, a person's browsing activity can be monitored by anyone who controls their network or simply uses the same WiFi network (using a technique called ARP poisoning). For many people, the list of possible snoops could include their employer, school, ISP, national spy agencies, parents, spouse, and/or fellow library patrons. HTTPS is not a silver bullet for all security and privacy problems, but no site can be secure or private without it.

Unfortunately, federal web sites have lagged far behind industry in implementing HTTPS. The most popular commercial web sites, like Google, Facebook, and Twitter, have used HTTPS-only for years. But many federal web sites don't implement HTTPS at all, making it impossible to access them securely. Other sites implement HTTPS, but don't make it the default. And some offer HTTPS but with out-of-date, insecure software and configurations.

Government web sites receive a wide array of confidential information. That information absolutely needs to be protected from eavesdropping. But HTTPS doesn't just protect uploaded information like social security numbers. It also protects the confidentiality of what people read. A few examples of how failure to deploy HTTPS puts citizens at risk:

This is just a sample of the many protected groups who need and deserve real confidential access to government services.

Fortunately, deployment of HTTPS is easier and cheaper than it has ever been. We call on the federal government to implement the HTTPS-Only Standard as quickly as possible. State, local, and national governments worldwide should do the same.

A version of this feedback, altered to introduce the HTTPS-Only standard to our readers, is available on the EFF web site.

More Costs, More Barriers, No Accountability? Oh my!

I am all for https when it is needed, but a blanket mandate would have the following repercussions off the top of my head.

  1. Cost -- Has there been some basic analysis in terms of the cost of implementation? The total amount would be quite shocking to the American taxpayer, I think.

  2. Roadblock to Embracing SaaS -- This would be (yet) another roadblock in having government websites embrace SaaS / web services which often rely on CNAMEs for domain masking (which can make https difficult and / expensive).

  3. Lack of Accountability -- If an application that should be running https is not (and what is this number -- government web sites generally serve static content), then someone should make that one application adhere to https with some major punishment for the potential breach of trust with the public.

Managing certificate expiry

There's no great trivial solution for monitoring certificate expiry right now. We're all trying to get there.

  • Point to a few free/cheap/enterprise cert monitoring services.
  • Does your CA support completely automated certificate renewal? (API? DNS-based validation?)

Point to the ambitions:

  • Short-lived certificates: Google's rotating every 3 months. Try to get there.
  • Very short-lived certificates: What if you rotated your cert every day, and didn't have to worry about revocation, key backup, expiry monitoring, fear of some kinds of key compromise, or even screwing up forward secrecy?

I continue to think there's a need for a service that just gives you an RSS feed of certificate warnings, that someone could plug into a generic feed->email service like IFTTT or Scout. But that's out of scope for this ticket.

+1 from Mozilla

Mozilla has been working to increase the use of HTTPS for a long time, for example, through our support for Let’s Encrypt, and we're very happy to see that US government joining the effort to encrypt the web.

Compliance guide

One page that just goes down, piece by piece, what you should do to meet this guidance's standards. In response to an email I got today, asking me for that.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.