konklone

Ah, that is too bad. It's certainly always possible the countries list could expand in future, but it's not something I have insight into and unfortunately can't give you too much to go on.

Wikimedia Foundation | Lead Product Manager, Security | REMOTE (US + 18 countries) | Full-time

I lead the security and safety team for Wikipedia, at the Wikimedia Foundation. I’m hiring a product manager to lead our security roadmap and steer the priorities of our security engineering team.

It’s a high-pace, shipping-heavy time for the whole project right now, as we are dedicating ourselves to surviving all the ways AI is messing with us and the internet, and getting to the other side of it. I joined myself about a year ago, and have found it to be a great time and place to swing big and surprise people.

This is a PM role and PM background is certainly helpful, but it’s not strictly required (everyone has the first PM job at some point). A technical background and security expertise are a must for this role, so we’re also open to people in engineering roles, who have demonstrated PM-relevant skills and are interested in making a pivot.

You can apply at https://job-boards.greenhouse.io/wikimedia/jobs/8140060?gh_s... - we don’t auto-filter based on AI or anything like that, I will personally see your resume.

On isitchristmas.com, this happens for several days surrounding Christmas. The defined use case is informing you of whether it is Christmas.

The document distinguishes between enterprise-facing and public-facing systems. For enterprise-facing (government employees, contractors, etc.), it's talking about discontinuing use of TOTP. For public-facing systems, it doesn't impose any restrictions, since (as you're saying) the general public really needs options.

Login.gov does support identity verification. Not all uses of Login.gov require it, so many accounts are just used for email with MFA.

Author of the post here :)

In those 5 years, HTTPS has gone from being the minority of traffic to being ~90% of the connections observed by most Chrome clients (scroll down a few graphs for the Chrome-observed one): https://transparencyreport.google.com/https/overview

Firefox has reported similar numbers. It's now more common for new web features to require HTTPS when they are introduced, to avoid developing HTTP sites as dependencies: https://blog.mozilla.org/security/2018/01/15/secure-contexts...

That doesn't mean that HTTP is banned, but given the magnitude of the change and the size of the web, I think it's fair to say that it's being deprecated.

More practically, anyone who wanted to build a product (or a government process) on intercepting or modifying people's unencrypted web traffic would find their dataset to be an order of magnitude smaller, and orders of magnitude less useful (since so much of the remaining HTTP traffic is in the long tail of small/older sites).

There's not federalism within states in a legal sense the way there is between states and the feds, but cities value their independence too and prefer to have their own infrastructure. I would expect the city, rather than the state, to be the reason they don't use a subdomain of the state's .gov domain.

CLAs are frowned upon by some, but they don't completely kill contribution from 3rd parties. I've signed plenty, and I've encountered plenty of projects that use them that continue to have a good community of outside unaffiliated contributors.

I wouldn't use the word "illegal" - it's a directive of OMB (the White House's management and budget office), not a law or a regulation or an executive order. The only true enforcers are OMB themselves.

But to answer your other question, as part of the Department of Commerce, a "CFO Act" agency, USPTO would not be exempt.

The policy is still in effect, and its supporting home page is here: https://https.cio.gov

Cloud Foundry doesn't have a problem injecting headers, as HTTP traffic is plaintext inside the system itself. It's once it starts traveling across the public internet that encryption is needed. This does make it harder for network edge caches and for middleboxes, but that's not totally a bad thing either.

Just so it's clear, NSA is technically part of DoD. (Though it's a bit like FBI's relation to DOJ, they operate very independently.)

Also, the DoD CIO has had, since ~2003, this excellent FAQ supporting open source:

http://dodcio.defense.gov/Open-Source-Software-FAQ/

But as people on this thread and elsewhere will tell you, that hasn't resulted in widespread support at DoD for open source.

I'm from 18F, and I'm now a "contributor", but only because they accepted my pull requests. :)

In fact, there are now way more state/local .gov domains (~4,000) than federal .gov domains (~1,300).

Exactly.

What you're trusting the browser for there is the extra protection that preloading provides, but that's not the whole benefit here. The larger benefit is that it makes it infeasible for services to neglect to support HTTPS. So, even if your browser's preload list is busted, the site will be guaranteed to support HTTPS because of this effort, which you'll still benefit from.

Very true. HPKP is not part of this change, and if you look at GSA's guidance on HPKP, it's cognizant of this risk:

https://https.cio.gov/certificates/#http-public-key-pinning

Yes, I do know that hostnames are typically outside the HTTPS envelope. However, user-agent is not, and would be exposed (and could then possibly be correlated to other HTTPS traffic from the same IP address). Also, potentially cookies from a previous session -- even a previous HTTPS session -- could be exposed, depending on how careless the server operator is. (You can set flags to make sure cookies only go over HTTPS, but that doesn't always happen.)

From an integrity perspective, connecting to alerts.fema.gov over HTTP does potentially subject the user to code injection attacks. Those do happen:

* https://arxiv.org/abs/1602.07128

* https://citizenlab.org/2015/04/chinas-great-cannon/

* http://www.forbes.com/sites/kashmirhill/2014/10/28/find-out-...

Now, are any of these likely to happen on an arbitrary request to alerts.fema.gov? Maybe not. (Especially since Verizon has since been fined by the FCC.) But I'm trying to point out that it's not just the service owner whose safety has to be weighed in policies like this.

FWIW, the GSA plan announced in this post is intentionally crafted to be gradual and to avoid breaking things. It only affects future domains, not present ones, and so we'll have plenty of time to see whether being a total hardass about HSTS causes negative effects. Agencies can still do specialized services on their existing domains.

There's also going to have to be some carveout somewhere for specialized services like OCSP/CRL, which are already exempted from the policy mandate that came out in June 2015:

https://https.cio.gov/guide/#are-federally-operated-certific...

But in any case, the push should be, clearly and loudly, towards changing the defaults that browsers and users accept, and I think GSA's change weighs the tradeoffs appropriately in making such a push.

@prodtorok - This is one of the nice things about HSTS. The includeSubDomains directive can create automatic client enforcement for all subdomains. If some component of an agency ignores this and doesn't configure HTTPS, they'll find that users of modern browsers won't be able to access the site.

The one downside of includeSubDomains is that, with dynamic HSTS (without preloading), you have to get the user to visit https://agency.gov to "see" the HSTS header once to get that coverage. Visiting https://www.agency.gov or http://agency.gov won't do it.

So another benefit of preloading is that you remove that problem from the table -- browsers will enforce HTTPS for all subdomains, even if the user has never visited the root site. It's a powerful tool, and there is no analogue for other protocols (like IPv6 or DNSSEC) to set policies for an entire zone that you can expect most clients to enforce.

To quote my comment from above - bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh against availability: it's the user's confidentiality and integrity.

That's a larger moral responsibility, in my opinion. And consider that the fallback to prioritize availability in case of a non-attack cert error (e.g. revocation or expiration) is to ask the user to look at a certificate warning and make a personal trust decision about it. There are precious few users who can safely make that kind of a decision. And even if they "get it right" that time and click through and aren't attacked, you're training users to click through warnings, and helping them subject themselves to attacks in the future.

I would argue that that kind of "availability" is a very weak sort of availability. The government has enough problems with training people to click through certificate warnings (see: https://www.iad.gov) -- intentionally leaving that hole open seems unwise.

I wouldn't say this is reinventing the CA system. You don't need to trust any particular browser here. The effect is that web services must offer a secure HTTPS connection, using the existing CA system (or an enterprise CA, if their user base is truly all-enterprise), no matter what browser is being used.

Bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh: it's the user's confidentiality and integrity. That's a larger moral responsibility, in my opinion.

These issues were already worked through for the executive branch as part of the White House HTTPS policy published in June 2015:

https://https.cio.gov/

Some rationale for "Why everything?" can be found here:

https://https.cio.gov/everything/

Personally, I'd say that plain HTTP is insecure enough, and today's internet is hostile enough, that plain HTTP provides a very weak form of "availability". It's on site operators to ensure that when their services and information is available, that it's available in a manner that doesn't subject the user to risk.

Not quite either one -- it's technical enforcement by the TLD, but still done on a per-domain basis (this doesn't affect state/local .gov domains, or legislative/judicial .gov domains). The dotgov.gov program will forcibly preload new domains, but it's not feasible to just submit ".gov" to the preload list right now.

Let's Encrypt isn't specifically mentioned in the post, though the post hits the underlying point:

> GSA provides extensive guidance to agencies on HTTPS deployment at https.cio.gov, and encourages .gov domain owners to obtain low cost or free certificates, trusted by the general public. As a general matter, more expensive certificates do not offer more security value to service owners, and automatic deployment of free certificates can significantly improve service owners’ security posture.

This is also repeated here:

https://https.cio.gov/certificates/#what-kind-of-certificate...

Two GSA programs automate Let's Encrypt to deploy certificates on demand:

* https://www.digitalgov.gov/2016/09/07/lets-encrypt-those-cna...

* https://cloud.gov/docs/apps/custom-domains/#managed-service-...

There's also a USG amendment to the Let's Encrypt Terms of Service that GSA negotiated with them to make it easier for agencies to use it:

https://letsencrypt.org/documents/LE-US-State-Local-SA-Amend...

Subdomains generally get automatically included when a second-level domain is preloaded. So, for .gov domains that fall under scope here, their subdomains will all have HTTPS enforced by modern web browsers.

Web browsers enforce preloading by considering each domain as having HTTP Strict Transport Security (HSTS) set, and so it gets the strict treatment: only https:// connections, and no clicking through certificate warnings.

Some more detail on all this here: https://https.cio.gov/hsts/

Second level domains. There are waayyyyy more subdomains, as you note. You can see some information and estimates on this here:

https://18f.gsa.gov/2017/01/04/tracking-the-us-governments-p...

We (18F, me) personally measured at least 26,000 (though some of these are used as redirects or are just error pages, etc.).

If there's an issue with certificate validation, the attack surface is already open.

DoD does have some .gov domains, so it would affect them in that way. But .mil is not affected.

IPv6 is a federal mandate for agencies: https://www.whitehouse.gov/sites/default/files/omb/assets/eg...

And NIST has a dashboard of adoption: https://usgv6-deploymon.antd.nist.gov/cgi-bin/generate-gov

I think that's an open question. Right now, it's not the millions, that'd be too much to bundle with browsers. But browsers may well change their delivery mechanism for preload information to allow this to scale higher.

In any case, .gov won't add much to the load -- right now there are all of 5,500 .gov domains, and the rate of adding/removal is on the order of dozens every month at most.