Third party standards

Overview

When the Foundation works with a third party vendor to outsource a solution which uses our Foundation-controlled domainnames in the DNS (which is often desirable for legitimacy if the service interfaces with end-users), we have certain technical requirements that must be met in order to integrate with our broader operational infrastructure in terms of technical and security policy.

Evolution and Coordination

This document attempts to record current standards that are in practical effect. These standards necessarily evolve over time. The primary purpose of this document is to provide a reference point to avoid having to re-iterate or re-formulate the same information repeatedly. Reading this document is not a substitute for coordinating with Operations well in advance to ensure that a 3rd party service will integrate with our infrastructure. In some cases there could be non-obvious technical barriers that need to be addressed on a per-service basis which are not covered here.

Standards

Namespacing

Given that all services within the Foundation share our DNS host namespaces, we have to impose a broader view on naming conventions and choices. For example, it would be inappropriate to allocate the hostname dev.wikimedia.org to host a development-related site that was specific to one small group within the Foundation and did not cover the development work of other groups. This is a highly-subjective matter, but it is a legitimate concern with some requests, and some care must be taken.

HTTP(S) Requirements

If a service which is routed through our DNS domainnames offers any HTTP service at all:

1. HTTPS must be implemented - An HTTP-only service without a valid HTTPS listener on the same hostnames and IPs will not work with our HTTPS-related security policies. This is a sort of reverse-requirement: if HTTPS does not work, the 3rd-party-hosted site will not function for many users, as modern browsers and devices have hardcoded rules enforcing that connections to our domains are only allowed over the HTTPS protocol. This policy is already in place for almost all of our domains. wikimedia.org is currently an exception due to legacy 3rd party services, but it's a critical exception that we're hoping to address as soon as possible in order to close some of the final loopholes in our policy.

2. Certificates and Keys come from Ops - In order to control security policy on our domains, we do not authorize 3rd parties to acquire SSL certificates on our behalf for any of our domains. The certificates and keys necessary for (1) above must be generated by the Operations team using our standard practices and vendors, and then handed over to the 3rd party vendor via secure mechanisms such as PGP for the 3rd party to deploy in their infrastructure. They will have a maximum validity of 1 year, and thus renewal and re-issue must be coordinated in a timely fashion between Operations and the 3rd party annually as well.

Additionally, we would recommend that sites implement their HTTPS robustly according to modern TLS operational standards. We understand that at this time we're ahead of the curve on this and not all services are operationally capable or prepared for these measures, which is why these items aren't hard requirements:

• Redirect all HTTP traffic to HTTPS
• Send Strict Transport Security headers over HTTPS
• Disable SSL versions 2 and 3 to prevent POODLE and other such attacks
• Disable RC4-based algorithms completely, as recommended by the IETF
• Do not use weak or shared DH parameters
• Support Forward Secret ciphersuite negotiation with capable, modern browsers
• Support AEAD ciphersuite negotiation with capable, modern browsers
• OCSP Stapling

Much of this, as well as other basic errors in HTTPS configuration, can validated and debugged by checking the site against the public Qualys ssllabs analyzer

Email Requirements

If a service sends or receives email with sender or receiver domainnames within our official domainnames, SPF/DKIM security policies must be taken into account.

DKIM/SPF is restricted to subdomains of wikimedia.org - As a general rule, we cannot DKIM or SPF -authorize 3rd parties to send legitimate emails on behalf of @wikimedia.org addresses, as this compromises the security of many other things for which email is a legitimate authorization. Any DKIM or SPF record authorizing 3rd party keys and/or IP addresses would have to be for a specific subdomains, such as authorizations covering addresses like foo@bar.wikimedia.org.