Tighten up your TLS

Transport Layer Security (TLS) is the encryption protocol used by all secure websites today. It's the "S" in "HTTPS", which you'll see on virtually all Platform.sh-hosted projects (thank you, Let's Encrypt!), and has replaced SSL for that task. For most sites simply enabling it by default is sufficient to keep a site secure, and that happens automatically in Platform.sh's case. However, in some cases it's helpful to tweak even further.

That's why we're happy to announce that as of today we're rolling out several new TLS-related features for all sites.

TLS version restriction

Like any protocol, TLS is periodically updated with new versions that address security weaknesses in older versions. Almost all browsers today TLS 1.2, which is the latest, as well as all earlier versions including SSL. That means when a browser connects to your site it will use the most up to date version that both the server and browser both support. In most cases that's perfectly fine.

If you want to really lock down your site, however, at the cost of banning a few really old web browsers, you can now set a minimum TLS version that a browser must use. That's a requirement of some security compliance programs, too. If the browser tries to use an older, insecure version of TLS it will get blocked. Just add the following snippet to a particular route in your routes.yaml file.

tls:
    min_version: TLSv1.2

And now that domain will reject any HTTPS connection that isn't using at least TLS 1.2.

HSTS support

HTTP Strict Transport Security (HSTS) lets you tell browsers that they should use HTTPS for all requests to a site, even if a stray link happens to use HTTP. You can now enable it by simply adding the following block to a route in routes.yaml:

tls:
    strict_transport_security:
        enabled:true

Now, that site will send an HSTS header with all requests, telling browsers to enforce HTTPS usage.

Client-authenticated TLS

Often when a site is being used as an API backend for an IoT device or mobile client application it's necessary to lock the site down to access just from selected users using TLS. This process is called "Client-authenticated TLS", and requires loading custom root TLS certificates on the server that determine whether or not a particular client request is authorized.

Starting today, it's also possible to provide those custom certificates as part of your route. Once again, it's just a few lines in a route definition:

tls:
    client_authentication: "require"
    client_certificate_authorities:
        - !include
            type: string
            path: file1.key
        - !include
            type: string
            path: file2.key

More information on all three options is available in our documentation.

Enjoy your more-secure sites!