15. Secure Features¶
In addition to our core HTTPS services, the CTL CDN also provides a number of HTTPS-related features such as OCSP stapling, different security levels, HSTS, etc.
15.1. OCSP Stapling¶
Online Certificate Status Protocol (OCSP) Stapling is a feature that boosts performance whereby the server ‘staples’ a certificate status to the certificate chain it delivers to the client as part of the TLS session establishment. This alleviates the need for the client to perform the extra query to the certificate authorities’ OCSP server to determine the validity of the server’s certificate (revocation status). The CTL CDN periodically updates the certificate status and caches the result such that subsequent client session establishment requests do not require another lookup.
For more details on OCSP, see: https://en.wikipedia.org/wiki/OCSP_stapling
OCSP is provisioned as part of the Alias Definition, under the httpsConfig object using the ocsp attribute:
"httpsConfig": {
"serviceType": "SNI",
"ocsp": true,
"encryptionLevel": "Default",
"certInfo": {
"id": 1,
"name": "sni.example.com"
},
"http2": false
},
Note: the platform will occasionally fail to return an OCSP response after a configuration reload. Specifically, the first request after startup/reload that demands a “stapled” OCSP response will not receive an OCSP block in the SSL negotiation because nginx won’t have cached it yet and doesn’t block the client request to receive it. This behavior is expected (and RFC compliant) in the current version of caching software (19.3 at the time of writing).
15.2. HTTP Strict Transport Security (HSTS)¶
HTTP Strict Transport Security (HSTS) allows the CTL CDN to direct web browsers (or other complying user agents) to interact with it using only secure HTTPS connections for the host in question. HSTS is an IETF standards track protocol and is specified in RFC 6797.
The HSTS policy is communicated to the user by the server agent using an HTTPS response header field named “Strict-Transport-Security”. The CenturyLink CDN supports the mandatory max-age and optional includeSubDomains directives.
For further details, see: https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
It is expected that future SSLLabs grading criteria will require the presence of the HSTS header to maintain an A grade. When such grading changes are made, the inclusion of the HSTS header will become the default behavior.
15.3. Encryption Levels¶
The CTL CDN provides three different security levels for customers to choose from: Risky, Default and Advanced. The profiles are based off the Mozilla server-side TLS recommendations: https://wiki.mozilla.org/Security/Server_Side_TLS. The default and advanced profiles are designed to obtain an A grade from SSL Labs. Note that changes to the cipher definitions will be made from time to time. These changes are pushed out to the network without notice.
Note that the SNI service does not allow for changes to the security protocols offered (e.g., SSL1.1, TLS1.0, etc.) due to how the security stack interacts with the application. Thus, changing the cipher level when using SNI will not affect the protocol selection, only the cipher selections offered. If older protocols are needed, the Premium HTTPS service may be required.
Note that the Shared/Basic HTTPS service uses the Default cipher policy and cannot be changed.
The desired Encryption Level is provisioned as part of the Alias Definition, under the encryptionLevel object with possible options of Default, Advanced or Risky:
"httpsConfig": {
"serviceType": "SNI",
"ocsp": false,
"encryptionLevel": "Default",
"certInfo": {
"id": 1,
"name": "sni.example.com"
},
"http2": false
},
15.4. Redirect to HTTPS¶
For HTTPS-only configurations, it is possible to configure the CTL CDN to redirect HTTP requests to an HTTPS location instead of returning an error. It is expected that future SSL Labs grading criteria will require such behavior to maintain an A grade.
15.5. Secure Origin Fill¶
The CenturyLink CDN offers a number of different secure fill options. Customers can fill via HTTP (default), HTTPS Only (regardless of what protocol the client used) or Dyanmic (using whichever protocol the client used).
15.6. Secure Intra-CDN Fill¶
The Secure Intra-CDN feature allows customers to configure full, end-to-end secure fill of their content. By default, all intra-CDN communication is insecure (over HTTP), regardless of the client protocol and origin fill policy.
Secure intra-CDN is configured on a per-match rule basis at this time using the secureFill object as shown below:
"matchRules": [
{
"expression": "/",
"id": 1414420,
"features": {
"secureFill": {
"value": "True"
}
}
}
]