Email test: sikkerpånettet.dk

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.

We check if your mail servers (MX) support secure TLS versions only.

A mail server may support more than one TLS version.

Note: Quite some mail servers only support older TLS versions. If the sending and receiving mail server both do not support the same TLS version, they will usually fall back to unencrypted mail transport. Because of that it could be advisable to keep supporting TLS versions with a 'phase out' status for a while. Make an informed decision based on log data on when to disable these 'phase out' TLS versions.

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

we check if your receiving mail servers (MX) support secure ciphers (algorithm selections) only. To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

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. Ipv6.cool 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]

If your mail servers support 'Good' ciphers only, this test is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The receiving mail servers enforce their own cipher preference while negotiating with sending mail servers, and do not accept any preference of the sending mail servers. (requirement level: Required);

II. Prescribed ordering: Ciphers are offered by the receiving mail 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 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.

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

We check if your receiving mail servers (MX) support secure hash functions to create the digital signature during key exchange.

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail 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)

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

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

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail 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) v2.0' from NCSC-NL, guideline B8-1 and table 13 (in English).

Requirement level: Recommended

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 mail servers do not support TLS 1.3, the test is not applicable. For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLS session is initiated. The amount of early data support indicated by the mail 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 EHLO command before the TLS handshake but after the STARTTLS command (i.e. no round trips (0-RTT) needed before application data to the server). If the TLS handshake is completed and the mail server responds, then the mail 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).

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

Sending mail servers usually ignore whether a mail server certificate is issued by a publicly trusted certificate authority. Without DNSSEC the lookup of the mail server domain is vulnerable to manipulation. Thus a certificate issued by a publicly trusted certificate authority cannot add any authenticity value. Quite a few receiving mail servers are therefore using self-signed certificates, often issued by an internal (private) certificate authority. For authenticity a mail server should use DNSSEC and DANE.

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

Requirement level: Optional

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates 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

We check if the signed fingerprint of each of your mail server certificates 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

Sending mail servers usually ignore the domain in the certificate. Without DNSSEC the lookup of the mail server domain is vulnerable to manipulation. Thus matching the domain on the certificate against the mail server domain does not add any authenticity value. Quite a few receiving mail servers are therefore using self-signed certificates, often issued by an internal (private) certificate authority.

For authenticity a mail server should use DNSSEC and DANE. A certificate with a domain that matches the domain of the mail server is only required when DANE 'trust anchor assertion' (DANE-TA, 2) is used.

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

Requirement level: Optional / Required (only when DANE-TA is used)

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the mail server domain(s).

Furthermore the test will lead to a fail if there is no DNSSEC proof of 'Denial of Existence' for TLSA records. If a signed TLSA record exists but at the same time there is an insecure NXDOMAIN for the same domain (due to faulty signer software), the test will also show a fail. The latter two failure scenario's could lead to non-delivery of emails addressed to you by DANE validating mail senders.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.0' from NCSC-NL, Appendix A, under 'Certificate pinning and DANE' (in English).

DANE allows you to publish information about your mail server certificates in a special DNS record, called TLSA record. Sending mail servers can check the authenticity of your certificates not only through the certificate authority but also through the TLSA records. A sending mail server can also use the TLSA record as a signal to only connect via STARTTLS (and not unencrypted). When the DANE fingerprint of a receiving mail server is checked by the sending mail server, an active attacker who is able to manipulate the mail trafic cannot strip STARTTLS encryption.

We check if there is an active DANE scheme to reliably handle certificate rollovers on your receiving mailservers (MX).

Such a scheme will be proven useful when there is a need to update your mail server certificate(s). It can prevent that DANE becomes invalid during the transition period which could endanger mail deliverability at your domain. A rollover scheme is not expected to be 'active' all the time.

Below you will find two possible DANE rollover procedures (source: slides by Viktor Dukhovni). In each procedure two DANE TLSA records need to be present which is checked by this subtest.

Requirement level: Optional

DANE rollover procedures

1. Current + Next

• Generate next key when deploying current key and cert

• Deploy new chain, and publish new TLSA records:

• _25._tcp.mx.example.com. IN TLSA 3 1 1 curr-pubkey-sha256

• _25._tcp.mx.example.com. IN TLSA 3 1 1 next-pubkey-sha256

• Weeks later, obtain certificate for pre-generated next key

• But first, make sure TLSA record is already in place

• Repeat!

2. Current + Issuer CA

• Publish TLSA RRs for server key & issuer CA key:

• _25._tcp.mx.example.com. IN TLSA 3 1 1 ee-pubkey-sha256

• _25._tcp.mx.example.com. IN TLSA 2 1 1 ta-pubkey-sha256

• Deploy certificates from same CA, if EE key changes:

• Promptly update 3 1 1 hash to match new EE key

• If CA key changes, keep same EE key

• Obtain cert from new CA

• Promptly update 2 1 1 hash to match new CA key