How to disable weak cipher suites and enable HSTS
This article outlines steps to increase the security of externally exposed routes from your OpenShift cluster, through the use of more secure cipher suites and HTTP Strict Transport Security (HSTS).
OpenShift developers who have created and deployed services into OpenShift and created and exposed secure routes for those services.
Disable weak cipher suites
Cipher suites perform an important role in determining the security of a TLS connection. Over time, vulnerabilities have been identified in the algorithms used by cipher suites, which has resulted in published methods of decrypting and manipulating encrypted traffic. It's therefore generally recommended to use as modern a cipher suite as possible.
UKCloud for OpenShift v3.x
To provide extended client compatibility, the OpenShift router supports cipher suites from TLS 1.0 - TLS 1.2 by default. Some of these cipher suites (especially older ones) are vulnerable to man-in-the-middle (MITM) attacks.
If exposed secure routes are only being accessed from modern clients (that support TLS 1.2 and above), you can disable the weak cipher suites by adding the following environment variable to any router
oc set env dc/router ROUTER_CIPHERS=modern -n default
This triggers a rollout of the
DeploymentConfig. Going forward, the new router pods will only accept cipher suites from TLS 1.2.
By default, the OpenShift control plane (web console) only supports TLS 1.2 ciphers, although these do not provide forward secrecy.
We can restrict the ciphers to only those that provide forward secrecy. To do this, raise a Service Request with the UKCloud OpenShift Support team via the My Calls section of the UKCloud Portal.
UKCloud for OpenShift v4.x
There are no weak ciphers supported by the OpenShift
IngressController since by default it supports TLS 1.2 cipher suites with forward secrecy. It is possible to further restrict the ciphers by modifying the default
IngressController object, specifically the value of
oc edit ingresscontroller default -n openshift-ingress-operator
As an example, the below would omit cipher suites using the DHE key exchange:
apiVersion: operator.openshift.io/v1 kind: IngressController metadata: name: example namespace: openshift-ingress-operator spec: tlsSecurityProfile: type: Custom custom: ciphers: - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES256-GCM-SHA384 - ECDHE-RSA-AES256-GCM-SHA384 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 minTLSVersion: VersionTLS12
There are no weak ciphers supported by the OpenShift control plane (API) since by default it supports TLS 1.2 and 1.3 cipher suites with forward secrecy.
HSTS (HTTP Strict Transport Security) prevents MITM attacks, such as protocol downgrading by setting a header within HTTPS responses. This header (
Strict-Transport-Security) is cached by a browser and ensures that future requests to the same host always use HTTPS rather than HTTP.
It is currently not possible to enable HSTS for the the OpenShift v3.x web console or OpenShift v4.x API server.
You should enable HSTS only on routes that currently have a valid certificate. If the certificate becomes invalid, the route will be inaccessible, due to how browsers' HSTS mechanisms works. You should exercise particular caution if you're using a non-standard hostname (that is, not ending in
<your-cluster-hostname>.ukcloud.com) for a route. In this case you should ensure a valid certificate is contained within the route spec (for edge and re-encrypt routes) or within the container (if using the pass-through TLS encryption method).
Enable HSTS on secure routes by using the following command:
oc annotate route <routename> haproxy.router.openshift.io/hsts_header=max-age=31536000
By default in UKCloud for OpenShift v4.x clusters, the following apps routes provisioned during deployment have HSTS enabled:
UKCloud for OpenShift v3.x Specific
UKCloud for OpenShift v4.x Specific
If you find a problem with this article, click Improve this Doc to make the change yourself or raise an issue in GitHub. If you have an idea for how we could improve any of our services, send an email to firstname.lastname@example.org.