Verdict:

Two or more name servers of your domain have an IPv6 address.

Technical details:

Test explanation:

Verdict:

All name servers that have an IPv6 address are reachable over IPv6.

Test explanation:

Verdict:

At least one of your web servers has an IPv6 address.

Technical details:

Test explanation:

Verdict:

All your web servers with an IPv6 address are reachable over IPv6.

Test explanation:

Verdict:

Your website on IPv6 seems to be the same as your website on IPv4.

Test explanation:

Verdict:

Your domain is DNSSEC signed.

Technical details:

Test explanation:

If a domain redirects to another domain via CNAME, then we also check if the CNAME domain is signed (which is conformant with the DNSSEC standard). If the CNAME domain is not signed, the result of this subtest will be negative.

Note: the validity of the signature is not part of this subtest, but part of the next subtest.

Verdict:

Your domain is secure, because its DNSSEC signature is valid.

Technical details:

Test explanation:

If a domain redirects to another signed domain via CNAME, then we also check if the signature of the CNAME domain is valid (which is conformant with the DNSSEC standard). If the signature of the CNAME domain is not valid, the result of this subtest will be negative.

Verdict:

Your website offers HTTPS.

Technical details:

Test explanation:

If so, we also check in the below subtests whether HTTPS is configured sufficiently secure in conformance with the 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL.

HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user. Note: for performance reasons the HTTPS test section only runs for the first available IPv6 and IPv4 address.

Verdict:

Your web server automatically redirects visitors from HTTP to HTTPS on the same domain.

Technical details:

Test explanation:

We check if your web server automatically redirects vistors from HTTP to HTTPS on the same domain (through a 301/302 redirect), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

• http://example.com ⇒ https://example.com ⇒ https://www.example.com
• http://www.example.com ⇒ https://www.example.com

You must contact the web server administrator for the domain for changes in HTTPS redirection.

Verdict:

Your web server offers an HSTS policy.

Technical details:

Test explanation:

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period (max-age) of at least six months to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS, you will have to wait longer until the validity of the HSTS policy in all browsers that vistited your website, has expired.

Verdict:

Your web server supports secure TLS versions only.

Technical details:

Test explanation:

We check if your web server supports secure TLS versions only.

A web server may support more than one TLS version.

Note: Browser makers have announced that they will stop supporting TLS 1.1 and 1.0 by Q1 2020. This will cause websites that do not support TLS 1.2 and/or 1.3 to be unreachable.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B1-1 and table 1 (in English).

• Good: TLS 1.3 and 1.2
• Phase out: TLS 1.1 and 1.0
• Insufficient: SSL 3.0, 2.0 and 1.0

Verdict:

Your web server supports secure ciphers only.

Technical details:

Test explanation:

We check if your web server supports secure ciphers (algorithm selections) only.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

• Since TLS 1.3, the term 'cipher suite' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term 'cipher suite' ambiguous, NCSC-NL uses the term 'algorithm selection' to comprise all four cipher functions.

• NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find 'Good', 'Sufficient' and 'Phase out' algorithm selections in the by NCSC-NL prescibed order, based on appendix C of the 'IT Security Guidelines for Transport Layer Security (TLS)'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least 'Phase out'.

Good:

• ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
• ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
• ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
• ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
• ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
• ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

• ECDHE-ECDSA-AES256-SHA384 [1.2]
• ECDHE-ECDSA-AES256-SHA [1.0]
• ECDHE-ECDSA-AES128-SHA256 [1.2]
• ECDHE-ECDSA-AES128-SHA [1.0]
• ECDHE-RSA-AES256-SHA384 [1.2]
• ECDHE-RSA-AES256-SHA [1.0]
• ECDHE-RSA-AES128-SHA256 [1.2]
• ECDHE-RSA-AES128-SHA [1.0]
• DHE-RSA-AES256-GCM-SHA384 [1.2]
• DHE-RSA-CHACHA20-POLY1305 [1.2]
• DHE-RSA-AES128-GCM-SHA256 [1.2]
• DHE-RSA-AES256-SHA256 [1.2]
• DHE-RSA-AES256-SHA [1.0]
• DHE-RSA-AES128-SHA256 [1.2]
• DHE-RSA-AES128-SHA [1.0]

Phase out:

• ECDHE-ECDSA-DES-CBC3-SHA [1.0]
• ECDHE-RSA-DES-CBC3-SHA [1.0]
• DHE-RSA-DES-CBC3-SHA [1.0]
• AES256-GCM-SHA384 [1.2]
• AES128-GCM-SHA256 [1.2]
• AES256-SHA256 [1.2]
• AES256-SHA [1.0]
• AES128-SHA256 [1.2]
• AES128-SHA [1.0]
• DES-CBC3-SHA [1.0]

Verdict:

This subtest is not applicable as your web server supports 'Good' ciphers only.

Technical details:

Test explanation:

If your web server supports 'Good' ciphers only, this test is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The web server enforces its own cipher preference while negotiating with a web browser, and does not accept any preference of the web browser. (requirement level: Required);

II. Prescribed ordering: Ciphers are offered by the web server in accordance with the below prescribed order in which safe and fast ciphers are preferred.

A. Prefer 'Good' over 'Sufficient' over 'Phase out' ciphers (requirement level: Required);

B. Within a particular security level, proceed as follows:

1. Ciphers that perform key exchange based on elliptic curves are preferred over those that use finite fields. Both are preferred over ciphers that use a static key exchange (requirement level: Recommended);
2. Ciphers that do bulk encryption based on AEAD algorithms are preferred over alternatives (requirement level: Recommended);
3. Ciphers that do certificate verification based on ECDSA are preferred over RSA (requirement level: Recommended);
4. Ciphers are preferred in descending order of their key length and then hash size (requirement level: Recommended);
5. AES-256 is preferred over ChaCha20 (requirement level: Optional).

In the above table with technical details only the first found out of prescribed order algorithm selections are listed, with the violated prescribed ordering rule shown next to it.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B2-5.

Verdict:

This subtest is not applicable as your webserver does not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.

Technical details:

Test explanation:

The security of elliptic curve Diffie-Hellman (ECDHE) ephemeral key exchange depends on the used elliptic curve. We check if the bit-length of the used elliptic curves is a least 224 bits. Currently we are not able to check the elliptic curve name.

The security of Diffie-Hellman Ephemeral (DHE) key exchange depends on the lengths of the public and secret keys used within the chosen finite field group. We test if your DHE public key material uses one of the predefined finite field groups that are specified in RFC 7919. Self-generated groups are 'Insufficient'.

The larger key sizes required for the use of DHE come with a performance penalty. Carefully evaluate and use ECDHE instead of DHE if you can.

Besides ECDHE and DHE, RSA can be used for key exchange. However, it is at risk of becoming insufficiently secure (current status 'phase out'). The RSA public parameters are tested in the subtest 'Public key of certificate'. Note that RSA is considered as 'good' for certificate verification.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B5-1 and table 9 for ECDHE, and guideline B6-1 and table 10 for DHE (in English).

Elliptic curve for ECDHE

• Good: secp384r1, secp256r1, x448, and x25519
• Phase out: secp224r1
• Insufficient: Other curves

Finite field group for DHE

Sufficient:

• ffdhe4096 (RFC 7919)
  sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3

• ffdhe3072 (RFC 7919)
  sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab

Phase out:

• ffdhe2048 (RFC 7919)
  sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

Insufficient: Other groups

Verdict:

Your web server supports a secure hash function for key exchange.

Technical details:

Test explanation:

We check if your web server supports secure hash functions to create the digital signature during key exchange.

The web server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The web server creates this digital signature by signing the output of a hash function.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, table 5.

Requirement level: Recommended

SHA2 support for signatures

• Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
• Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)

Verdict:

Your web server does not support TLS compression.

Technical details:

Test explanation:

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B7-1 and table 11 (in English).

Verdict:

Your web server supports secure renegotiation.

Technical details:

Test explanation:

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B8-1 and table 12 (in English).

Verdict:

Your web server does not allow for client-initiated renegotiation.

Technical details:

Test explanation:

Allowing clients to initiate renegotiation is generally not necessary and opens a web server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B8-1 and table 13 (in English).

Verdict:

Your web server does not support 0-RTT.

Technical details:

Test explanation:

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT for non-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable. For web servers that support TLS 1.3, the index / page of the website is fetched using TLS 1.3 and the amount of early data support indicated by the server is checked. When more than zero, a second connection is made re-using the TLS session details of the first connection but sending the HTTP request before the TLS handshake (i.e. no round trips (0-RTT) needed before application data to the server). If the TLS handshake is completed and the web server responds with any non-HTTP 425 Too Early response, then the web server is considered to support 0-RTT.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B9-1 and table 14 (in English).

Verdict:

The trust chain of your website certificate is complete and signed by a trusted root certificate authority.

Technical details:

Test explanation:

For a valid chain of trust, your certificate must be published by a publicly trusted certificate authority, and your web server must present all necessary intermediate certificates.

See 'IT Security Guidelines for Transport Layer Security (TLS)' from NCSC-NL, guideline B3-4 (in English).

Verdict:

The digital signature of your website certificate uses secure parameters.

Technical details:

Test explanation:

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier. The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

• Good: secp384r1, secp256r1, x448, and x25519
• Phase out: secp224r1
• Insufficient: Other curves

Length of RSA-keys

• Good: At least 3072 bit
• Sufficient: 2048 – 3071 bit
• Insufficient: Less than 2048 bit

Verdict:

Your website certificate is signed using a secure hash algorithm.

Technical details:

Test explanation:

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B3-2 and table 3 (in English).

Hash functions for certificate verification

• Good: SHA-512, SHA-384, SHA-256
• Insufficient: SHA-1, MD5

Verdict:

The domain name of your website matches the domain name on your website certificate.

Technical details:

Test explanation:

It could be useful to include more than one domain (e.g. the domain with and without www) as Subject Alternative Name on the certificate.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, guideline B3-1 (in English).