Our security measures

We built out website with a privacy-and-security-by-default approach. In this page we describe the measures we adopt in order to provide a secure and private browsing experience to our users, and to protect ourselves from external attackers.

This website is HTTPS-only. Every plain HTTP request we receive generates a response containing a 301 redirect to the same resource in HTTPS.

We do not serve or host mixed-content. All of our resources are served on HTTPS. We enforce this by including a Strict-Transport-Security (STS) header in all our responses. Consequently, HSTS (HTTP STS) is enabled by default. The same applies to all the subdomains. The STS header max-age parameters is set to 2 years, so that clients are instructed never to use plain HTTP with our website for the duration of 2 years from the last time they received the STS header. Also, HSTS instructs browsers to treat every non-fatal TLS-related error as a fatal error. Consequently, the scenario of a user clicking through error messages they do not understand or care about is completely avoided.

Additionally, our domain dicelab-rhul.org appears in the preload list of all major browsers. As such, Firefox, Chrome, Safari, and Edge will never attempt to connect to dicelab-rhul.org in plain HTTP, and will automatically rewrite every plain HTTP request to an HTTPS request. Please refer to this external page for further details.

HTTPS essentially means HTTP over TLS. We only support TLS1.3 for security and performance reasons. All major modern browsers support it.

We support the following cipher suites in preferred order:

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256

We support the following key exchange algorithms in preferred order:

• ECDHE with secp521r1
• ECDHE with secp384r1
• ECDHE with x25519

As ECHDE is the only key exchange algorithm we support, TLS sessions with our web server are always forward secure (except with TLS1.3 early data). By supporting well known EC named groups, we enhance the probability of TLS1.3 clients including a key_share entry for at least one of them in their ClientHello. If that is the case, TLS1.3 connections are 1-RTT, (i.e., no HelloRetryRequest).

We plan to support the Encrypted Server Name Indication (ESNI) extension in the near future for added privacy.

As our certificate contains a secp384r1 ECDSA public key, the algorithm we use for our signature in the CertificateVerify message is sha256withECDSA.

We do not support the now broken TLS compression, nor our server private key has appeared on any server supporting SSL2.0. We support TLS_FALLBACK_SCSV as a downgrade prevention method, even though, at the moment, we do not support multiple versions of TLS.

Our certificate, as described above, contains a secp384r1 ECDSA public key. Currently, our certificate is signed by “Let’s Encrypt authority x3” using sha256withRSA. Once Let’s encrypt enables ECDSA signatures, we plan to obtain a certificate signed with sha256withECDSA. Our certificate supports both Certificate Transparency (CT) and OCSP-must-staple. The latter means that our certificate must not be considered valid by a client unless it is served together with a valid “stapled” OCSP response.

Additionally, we specify a DNS CAA record for our domain, in order to whitelist the CAs that can issue certificates for our dicelab-rhul.org.

We support both HTTP/2 (negotiated via the Upgrade: h2 HTTP response header) and HTTP1.1. Additionally, clients can successfully negotiate HTTP/2 via ALPN.

We support Content-Security-Policy level 3 (CSP) and Feature-Policy (FP) HTTP security headers.

Regarding Feature-Policy, we explicitly include the following directives:

• geolocation ‘none’
• midi ‘none’
• sync-xhr ‘none’
• microphone ‘none’
• camera ‘none’
• magnetometer ‘none’
• gyroscope ‘none’
• speaker ‘none’
• fullscreen ‘none’
• payment ‘none’

Essentially, we do not need any of the “features”. Therefore, we explicitly instruct browsers not to ask for any of them.

Regarding Content-Security-Policy, we support CSP level 3. We make use of ‘strict-dynamic’, and include a different (for every response) unpredictable nonce for script-src, style-src, and style-src-elem. The directives we include are the following (the nonce values are not representative of their real values):

Our nonces consist of the Base64 representation of 32 random bytes. Recall that ‘unsafe-inline’ is ignored by CSP2-aware browsers if a valid nonce or hash (or both) are present for the same directive. Likewise, CSP3-aware browsers ignore ‘unsafe-inline’ and any whitelist if ‘strict-dynamic’ is present for the same directive. The directive style-src is present and duplicates part of style-src-elm to ensure back compatibility with older browsers that do not support style-src-elem.

Additionally, we support the following HTTP security headers with the corresponding values:

For Content-Security-Policy and Expect-CT we include a report-uri directive to log the respective violations. Finally, we customize our Server header to a non-disclosing value.

Please refer to this page for our cookie policy, configuration, and security.