Website test: andatche.com

The domain andatche.com has a test score of 100%.
Congratulations, your domain will be added to the Hall of Fame soon!

Passed : IPv6

Well done! Your website is reachable for visitors using a modern internet addresses, making it fully part of the modern Internet.

Name servers

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:

Name server IPv6 address IPv4 address
ns1.zugz.wang. 2600:1800:5::1 208.94.148.13
ns3.zugz.wang. 2600:1802:7::1 208.80.126.13
ns0.zugz.wang. 2a02:1348:ffff:ffff::6d6b:2554 109.107.37.84
ns2.zugz.wang. 2600:1801:6::1 208.80.124.13

Verdict:

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

Test explanation:

We check if all name servers, that have an AAAA record with IPv6 adress, are reachable over IPv6.

Web server

Verdict:

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

Test explanation:

We check if there is at least one AAAA record with IPv6 address for your web server.

Technical details:

Web server IPv6 address IPv4 address
andatche.com 2a02:1348:ffff:ffff::6d6b:246d 109.107.36.109

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 domain is DNSSEC signed.

Test explanation:

We check if your domain is DNSSEC signed. Note: the validity of the signature is not part of this subtest, but part of the next subtest.

Technical details:

Domain Registrar
andatche.com Gandi SAS

Verdict:

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

Test explanation:

We check if your domain is signed with a valid signature making it ‘secure’.

Technical details:

Domain Status
andatche.com secure

Passed : HTTPS

Well done! The connection with your website is sufficiently secured. Therefore information in transit between your website and its visitors is protected against eavesdropping and tampering.

HTTP

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:

Web server IP address HTTPS existent
2a02:1348:ffff:ffff::6d6b:246d yes
109.107.36.109 yes

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:

  • http://example.nlhttps://example.nlhttps://www.example.nl
  • http://www.example.nlhttps://www.example.nl

See ’Web application guidelines from NCSC-NL’, guideline U/WA.05 (in Dutch).

Technical details:

Web server IP address HTTPS enforced
2a02:1348:ffff:ffff::6d6b:246d yes
109.107.36.109 yes

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).

Technical details:

Web server IP address HSTS policy
2a02:1348:ffff:ffff::6d6b:246d max-age=31536000;
109.107.36.109 max-age=31536000;

Verdict:

Your web server supports HTTP compression, which could be a security risk.

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:

Web server IP address HTTP compression
2a02:1348:ffff:ffff::6d6b:246d yes
109.107.36.109 yes
TLS

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:

Web server IP address Insecure TLS versions
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -

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).

Technical details:

Web server IP address Insecure cipher suites
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -

Verdict:

Your web server supports sufficiently secure Diffie-Hellman parameters for key exchange.

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:

Web server IP address Insecure parameters
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -

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:

Web server IP address TLS compression
2a02:1348:ffff:ffff::6d6b:246d no
109.107.36.109 no

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:

Web server IP address Secure renegotiation
2a02:1348:ffff:ffff::6d6b:246d yes
109.107.36.109 yes

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:

Web server IP address Client-initiated renegotiation
2a02:1348:ffff:ffff::6d6b:246d no
109.107.36.109 no
Certificate

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:

Web server IP address Untrusted certificate chain
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -

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:

Web server IP address Public key with insufficient length
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -

Verdict:

Your website certificate is signed using a sufficiently secure hash algorithm.

Test explanation:

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm. See ’TLS guidelines from NCSC- NL’, guideline B3-2 (in Dutch).

Technical details:

Web server IP address Insecure hash algorithm
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -

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:

Web server IP address Unmatched domains on certificate
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -
DANE

Verdict:

Your website domain does not contain a TLSA record for DANE.

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.

Technical details:

Web server IP address DANE valid
2a02:1348:ffff:ffff::6d6b:246d -
109.107.36.109 -