Passed
:
IPv6

Verdict:

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

Test explanation:

We check if your domain name has at least two name servers with an IPv6
address. This is consistent with the technical requirement of
SIDN
(.nl TLD registry) that each .nl domain must have at least two name
servers.

Technical details:

Verdict:

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

Test explanation:

We check if we can connect to your web server(s) over IPv6 on any available
ports (80 and/our 443). We test all IPv6 addresses that we receive from your
name servers. A partial score will be given if not all IPv6 addresses are
reachable. If an IPv6 address is (syntactically) invalid, we consider it
unreachable.

Verdict:

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

Test explanation:

We compare the web content that we receive from your web server over both
IPv6 and IPv4 on any available ports (80 and/or 443). In case there are
multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4
address. If the content difference is not higher than 10%, we expect the
main web content to be the same. Therefore websites with small differences
(for example due to changing ads) will pass this subtest as well.

Passed
:
DNSSEC

Well done! Your domain is signed with a valid signature. Therefore visitors
with enabled domain signature validation, are protected against manipulated
translation from your domain into rogue internet addresses.

Verdict:

Your website offers HTTPS.

Test explanation:

We check if your website is reachable on HTTPS. If so, we also check in the
below subtests whether HTTPS is configured sufficiently secure. 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.

Technical details:

Verdict:

Your web server enforces HTTPS by redirecting HTTP to HTTPS on the same
domain.

Test explanation:

We check if your web server enfroces HTTPS by a 301/302 redirect from HTTP to HTTPS on the same domain, or by supporting only HTTPS. In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This makes also sure that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

Technical details:

Verdict:

Your web server offers an HSTS policy.

Test explanation:

We check if your web server supports HSTS. HSTS forces a web browser to
connect directly via HTTPS when revisiting your website. This helps
preventing man-in-the-middle attacks. A common retention time duration for
the HSTS policy is six months to one year. 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. See
’Web application guidelines from NCSC-
NL’, guideline U/WA.05 (in Dutch).

Verdict:

Your web server does not support HTTP compression.

Test explanation:

We test if your web server supports HTTP compression. HTTP compression makes
the secure connection with your webserver vulnerable for the BREACH attack.
Turning it off could negatively impact the performance of the web server.
If you use it, check if it is possible to take countermeasures on the
application level against the attack vector. Note: this subtest checks if
the web server on root directory level supports HTTP compression. However it
does not check additional website sources like images and scripts. See
’TLS guidelines from NCSC-NL’, guideline
B6-1 (in Dutch).

Technical details:

Verdict:

Your web server supports sufficiently secure TLS versions only.

Test explanation:

We check if your web server supports secure TLS versions only. The oldest
TLS versions (i.e. SSL 1.0, 2.0 and 3.0) contain severe vulnerabilities.
Therefore they should not be used. TLS 1.0 and 1.1 are sufficiently secure.
The most recent version, TLS 1.2, offers the best protection. A web server
may support more than one TLS version. See ’TLS guidelines from NCSC-
NL’, guideline B1-1 (in Dutch).

Technical details:

Verdict:

Your web server supports sufficiently secure cipher suites only.

Test explanation:

We check if your web server supports sufficiently secure cipher suites only.
A cipher suite is a combination of algorithms used for authentication and
encryption that is conformant to the TLS standard. A web server may support
more than one cipher suite. See ’TLS guidelines from NCSC-
NL, guideline B2-1 to B2-4 (in Dutch).

Verdict:

Test explanation:

We check if the bit-length of the public parameters used in Diffie-Hellman
key exchange by your web server is sufficiently secure. It is also important
that the bit-length of the secret Diffie-Hellman key is sufficiently
secure. However, due to its secret nature we are not able to check this.
Besides Diffie-Hellman, RSA (that can be used for certificate verification
as well) is secure to use for key exchange. The RSA public parameters are
tested in the subtest “Public key of certificate”. See ’TLS guidelines
from NCSC-NL’, guidelines
B4-1 to B4-3 (in Dutch).

Technical details:

Verdict:

Your web server does not support TLS compression.

Test explanation:

We check if your web server supports TLS compression. The use of compression
can give an attacker insights in secret parts of encrypted communication.
TLS compression is rarely used, so switching it off does not do any harm.
See ’ICT security guidelines for TLS’ from NCSC-
NL, guideline B6-1 (in Dutch).

Technical details:

Verdict:

Your web server supports secure renegotiation.

Test explanation:

We check if your web server supports secure renegotiaton. The TLS standard
allows to step out of the application phase and force a new handshake. This
is called renegotiation. Originally this was designed very insecurely, but
the standard was updated and now allows for secure renegotiation. The old
version, i.e. insecure renegotiation, should not be supported. See ’TLS
guidelines from NCSC-NL’, guideline
B6-2 (in Dutch).

Technical details:

Verdict:

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

Test explanation:

We check if a client (usually a web browser) can initiate a renegotiation
with your web server. There seems to be no need to support client-initiated
renegotiation. Although the option does not bear a risk for confidentiality,
it does make a web server vulnerable to DDoS attacks. Therefore you should
not support it. See ’TLS guidelines from NCSC-
NL’, guideline B6-2 (in Dutch).

Technical details:

Verdict:

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

Test explanation:

We check if we are able to build a valid chain of trust for your website
certificate. For a valid chain of trust, your certificate must be published
by a trusted certificate authority, and your web server
must present all necessary intermediate certificates. See ’TLS guidelines
from NCSC-NL’, guideline
B3-6 (in Dutch).

Technical details:

Verdict:

Your website certificate contains a public key with a secure length.

Test explanation:

We check if the bit-length of the public key of your website certificate is
sufficiently secure. Note: it is also important that the bit-length of the
secret key is sufficiently secure. However, due to its secret nature we are
not able to check this. See ’TLS guidelines from NCSC-
NL’, guideline B3-3 to B3-5 (in Dutch).

Technical details:

Verdict:

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

Test explanation:

We check if the domain name of your website matches the domain name on the
certificate. 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 ’TLS guidelines from NCSC-NL’,
guideline B3-1 (in Dutch).

Technical details:

Verdict:

The DANE fingerprint on your domain is valid for your web certificate.

Test explanation:

We check if the DANE fingerprint presented by your domain is valid for your
web certificate. DANE allows you to publish information about your website
certificate in a special DNS record, called TLSA record. Clients, like web
browsers, can check the authenticity of your certificate not only through
the certificate authority but also through the TLSA record. A client can
also use the TLSA record as a signal to only use HTTPS (and not HTTP).
DNSSEC is preconditional for DANE. Note: cases where we detect a valid TLSA
record but no DNSSEC support or where we get an error while retrieving the
TLSA record, are also considered failures for this test.