diff --git a/Changelog.md b/Changelog.md
index 9f15c3431..f73821da8 100644
--- a/Changelog.md
+++ b/Changelog.md
@@ -1,10 +1,9 @@
# Change Log
-## 1.11.0 (in progress)
+## 1.11.0
_Compared to the latest 1.10 release._
-
### TLS updates for NCSC 2025 guidelines
All tests were updated to match the
@@ -34,10 +33,18 @@ Most significant changes:
### Significant internal changes
-- ...
-### Possibly required changes to deployments
+- Upgraded to Django 5, Python 3.13, and Debian Trixie base image.
+- Switched TLS implementation to sslyze/nassl based reimplementation.
+- Switched to pyproject/uv.lock for project dependencies, replacing requirements files.
+- Added post-quantum hybrid ECDHE-MLKEM for TLS 1.3 in our web server.
+- Outgoing traffic now uses the configured public IPv4/IPv6 addresses.
+- Routinator can now be configured with an allowlist for shared instances.
+
+### Bug fixes
-...
+- Fixed [simhash exception when both address families fail](https://github.com/internetstandards/Internet.nl/issues/1893).
+- Fixed JSON serialization of sets in batch results.
+- Fixed [report generation locking](https://github.com/internetstandards/Internet.nl/issues/1749) for results views.
### API changes
diff --git a/docker/webserver.Dockerfile b/docker/webserver.Dockerfile
index 3dfc9cf26..2f12e8100 100644
--- a/docker/webserver.Dockerfile
+++ b/docker/webserver.Dockerfile
@@ -1,6 +1,9 @@
FROM nginx:1.29.1-alpine3.22
-RUN apk add --no-cache \
+RUN apk upgrade --no-cache \
+ # upgrade libexpat to match python3's pyexpat native module
+ libexpat \
+ && apk add --no-cache \
# for random quic host key
openssl \
# for htpasswd
diff --git a/translations/en/main.po b/translations/en/main.po
index 4308ddbae..5686d7e19 100644
--- a/translations/en/main.po
+++ b/translations/en/main.po
@@ -9,7 +9,7 @@ msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-02-16 23:27+0100\n"
-"PO-Revision-Date: 2026-03-10 11:05:33.065200\n"
+"PO-Revision-Date: 2026-04-15 14:31:13.464249\n"
"Last-Translator: \n"
"Language-Team: \n"
"Language: \n"
@@ -68,7 +68,7 @@ msgstr ""
"In 2023, [SIDN Fund](https://www.sidnfonds.nl/) financially supported the project to containerise the Internet.nl application in order to simplify its installation and facilitate further growth of the number of tests.\n"
"\n"
"## Practice what you preach?\n"
-"We periodically test the domain names of members of the Internet Standards Platform. The [test reports](https://dashboard.internet.nl/#/published/103/) are publicly available.\n"
+"We periodically test the domain names of members of the Internet Standards Platform. The [test reports](https://dashboard.internet.nl/published/103/) are publicly available.\n"
"\n"
"\n"
"## What are Internet Standards?\n"
@@ -304,6 +304,11 @@ msgstr ""
"### Donations\n"
"To thank and support the (open source) projects we are building upon, we regularly make donations to them.\n"
"\n"
+"#### 2025\n"
+"- Django Software Foundation: USD 1719,94\n"
+"- Mastodon gGmbH: EUR 1500\n"
+"- Zammad Foundation: EUR 1500\n"
+"\n"
"#### 2024\n"
"- Celery: USD 1500\n"
"- Mastodon.nl (Stichting ActivityClub): EUR 1500\n"
@@ -330,6 +335,8 @@ msgstr ""
"\n"
"- [top.nic.br](https://top.nic.br/) (Brazil)\n"
"- [sikkerpånettet.dk](https://xn--sikkerpnettet-vfb.dk/) (Denmark)\n"
+"- [internet.bzh](https://internet.bzh) (France)\n"
+"- [internet-standards.de](https://internet-standards.de) (Germany)\n"
"\n"
"### Attribution in case of re-use\n"
"If you re-use the Internet.nl source code and/or test results in your own website or service, we kindly ask you for attribution. For example, you can use the following text and display it in a prominent place.\n"
@@ -464,7 +471,7 @@ msgstr ""
"* Currently we are not able to query and evaluate the public key in your DKIM record,\n"
"because we would need the DKIM selector (that should be in the mails you send) to do so.\n"
"* To pass this test we expect your name server to answer `NOERROR` to our query for\n"
-"`_domainkey.example.nl`. When `_domainkey.example.nl` is an 'empty non-\n"
+"`_domainkey.example.org`. When `_domainkey.example.org` is an 'empty non-\n"
"terminal' some name servers that are not conformant with the standard\n"
"[RFC 2308](https://www.rfc-editor.org/rfc/rfc2308) incorrectly answer `NXDOMAIN` instead of `NOERROR`. This makes it\n"
"impossible for us to detect support for DKIM records.\n"
@@ -531,21 +538,21 @@ msgstr ""
" \n"
"*A. Single domain without A or AAAA record*\n"
"\n"
-" example.nl. TXT \"v=spf1 -all\"\n"
-" *.example.nl. TXT \"v=spf1 -all\"\n"
-" _dmarc.example.nl. TXT \"v=DMARC1; p=reject;\"\n"
+" example.org. TXT \"v=spf1 -all\"\n"
+" *.example.org. TXT \"v=spf1 -all\"\n"
+" _dmarc.example.org. TXT \"v=DMARC1; p=reject\"\n"
"\n"
" \n"
"\n"
"*B. Single no-mail domain with A or AAAA record*\n"
"\n"
-" example.nl. AAAA 2a00:d78:0:712:94:198:159:35\n"
-" example.nl. A 94.198.159.35\n"
-" example.nl. MX 0 .\n"
-" example.nl. TXT \"v=spf1 -all\"\n"
-" *.example.nl. TXT \"v=spf1 -all\"\n"
-" www.example.nl. CNAME example.nl\n"
-" _dmarc.example.nl. TXT \"v=DMARC1; p=reject;\""
+" example.org. AAAA 2a00:d78:0:712:94:198:159:35\n"
+" example.org. A 94.198.159.35\n"
+" example.org. MX 0 .\n"
+" example.org. TXT \"v=spf1 -all\"\n"
+" *.example.org. TXT \"v=spf1 -all\"\n"
+" www.example.org. CNAME example.nl\n"
+" _dmarc.example.org. TXT \"v=DMARC1; p=reject\""
msgid "detail mail auth dmarc-policy label"
msgstr "DMARC policy"
@@ -1113,7 +1120,7 @@ msgstr ""
"A certificate authority must not issue a certificate unless the certificate authority determines that the certificate request is consistent with the applicable CAA records.\n"
"\n"
"Note that CAA records are located during validation by walking up the DNS hierarchy until one or more records are found.\n"
-"For example, if no CAA records are found on `sub.example.nl`, `example.nl` will be queried.\n"
+"For example, if no CAA records are found on `sub.example.org`, `example.org` will be queried.\n"
"The domain were the applicable CAA records are found is shown in the table with technical details below.\n"
"\n"
"The verdict is good if one or more CAA records were found that all have correct syntax, and at least one of these CAA records has the `issue` tag.\n"
@@ -1153,7 +1160,7 @@ msgstr ""
"\n"
"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.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B3-1 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 4.4.\n"
"\n"
"*Requirement level: Optional / Required (only when DANE-TA is used)*"
@@ -1175,77 +1182,128 @@ msgstr ""
msgid "detail mail tls cert-pubkey exp"
msgstr ""
-"We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters. \n"
+"We check if the public key of your mail server certificate and every intermediate certificate is based on a secure signing algorithm with secure parameters. \n"
+"\n"
+"The verification of certificates makes use of digital signatures. The public key of a certificate can be used to verify that a signature was created using the corresponding private key.\n"
"\n"
-"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.\n"
-"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.\n"
+"**Signing algorithm:**\n"
+"The signing algorithm is determined when generating the certificate. A certificate can only contain one signing algorithm. It is possible to configure multiple certificates on a server to support more than one algorithm. Only the signing algorithms ECDSA, RSA and EdDSA are considered sufficiently secure. EdDSA is actually rarely, if ever, used. All mentioned algorithms are vulnerable to the quantum threat. They offer sufficient protection for now. Quantum-safe alternatives are not yet part of the TLS standards.\n"
"\n"
-"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. \n"
+"**Parameters:** The security of ECDSA and EdDSA digital signatures depends on the chosen curve. The security of RSA is tied to the key length of the public key. \n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).\n"
+"For details on the relevant certificate field name see paragraph [\"4.1.2.7. Subject Public Key Info\" of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.7).\n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.2\n"
"\n"
"---\n"
-"**Elliptic curves for ECDSA**\n"
"\n"
-"* Good: `secp384r1`, `secp256r1`, `x448`, and `x25519`\n"
-"* Phase out: `secp224r1`\n"
-"* Insufficient: Other curves\n"
+"**Security level of elliptic curves for ECDSA**\n"
"\n"
-"**Length of RSA-keys**\n"
+"* Sufficient:\n"
+" \n"
+" * `secp521r1` (rarely used)\n"
+" * `secp384r1`\n"
+" * `secp256r1`\n"
+" * `x448`\n"
+" * `x25519`\n"
+" * `brainpoolP512r1` (rarely used)\n"
+" * `brainpoolP384r1` (idem)\n"
+" * `brainpoolP256r1` (idem)\n"
+"\n"
+"* Phase out:\n"
+"\n"
+" * `secp224r1`\n"
+"\n"
+"* Insufficient:\n"
+"\n"
+" * Other curves\n"
+"\n"
+"**Security level of length of RSA keys**\n"
+"\n"
+"* Sufficient: At least 3072 bit\n"
+"* Phase out: 2048 – 3071 bit\n"
+"* Insufficient: Less than 2048 bit\n"
+"\n"
+"**Security level of Edwards curves for EdDSA (rarely used)**\n"
+"\n"
+"* Sufficient:\n"
+"\n"
+" * `Ed448`\n"
+" * `Ed25519`\n"
+"\n"
+"* Insufficient:\n"
+"\n"
+" * Other curves\n"
+" \n"
+"---\n"
"\n"
-"* Good: At least 3072 bit\n"
-"* Sufficient: 2048 – 3071 bit\n"
-"* Insufficient: Less than 2048 bit"
+"Note that the above names are based on the [IANA naming conventions](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Sometimes alternative names are used to refer to the same curves, like `prime256v1` (ANSI) and `NIST P-256` for `secp256r1`."
msgid "detail mail tls cert-pubkey label"
msgstr "Public key of certificate"
msgid "detail mail tls cert-pubkey tech table"
-msgstr "Mail server (MX)|Affected signature parameters|Status"
+msgstr "Mail server (MX)|Outdated signature parameter|Security level"
msgid "detail mail tls cert-pubkey verdict bad"
msgstr ""
-"The digital signature of at least one of your mail server certificates uses "
-"*insufficiently* secure parameters."
+"The public key of at least one of your mail server certificates is *not* "
+"based on a secure signing algorithm with secure parameters."
msgid "detail mail tls cert-pubkey verdict good"
msgstr ""
-"The digital signatures of all your mail server certificates use secure "
-"parameters."
+"The public keys of all your mail server certificates are based on a secure "
+"signing algorithm with secure parameters."
msgid "detail mail tls cert-pubkey verdict phase-out"
msgstr ""
-"The digital signature of at least one of your mail server certificates uses "
-"parameters that have a *phase out* status, because they are known to be "
-"fragile and are at risk of of becoming *insufficiently* secure."
+"The public key of at least one of your mail server certificates is based on "
+"a signing algorithm with parameters that should be *phased out* as they are "
+"weaker, although you might still use them if absolutely needed. In a future "
+"update, they will likely become insufficient."
msgid "detail mail tls cert-signature exp"
msgstr ""
-"We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm. \n"
+"We check if each of your mail server certificates is signed (by a certificate authority) with a secure signing algorithm, while making use of a secure hash function.\n"
+"\n"
+"For details on the relevant certificate field name see paragraph [\"4.1.1.2. signatureAlgorithm\" of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.1.2).\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B3-2 and table 3 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.5.\n"
"\n"
"---\n"
+"**Security level of signing algorithms**\n"
"\n"
-"**Hash functions for certificate verification**\n"
+"* Sufficient: ECDSA, RSA, EdDSA\n"
+"* Insufficient: DSS, EXPORT-*, PSK, Anon, NULL, KRB5\n"
"\n"
-"* Good: SHA-512, SHA-384, SHA-256\n"
+"**Security level of hash functions**\n"
+"\n"
+"* Good: SHA-256, SHA-384, SHA-512\n"
+"* Phase out: SHA-224\n"
"* Insufficient: SHA-1, MD5"
msgid "detail mail tls cert-signature label"
-msgstr "Signature of certificate"
+msgstr "Signature on certificate"
msgid "detail mail tls cert-signature tech table"
-msgstr "Mail server (MX)|Affected hash algorithm|Status"
+msgstr "Mail server (MX)|Outdated hash function|Security level"
msgid "detail mail tls cert-signature verdict bad"
msgstr ""
-"At least one of your mail server certificates is signed using a hash "
-"algorithm that is *insufficiently* secure."
+"At least one of your mail server certificates is signed using an "
+"*insufficiently* secure signing algorithm and hash function."
msgid "detail mail tls cert-signature verdict good"
msgstr ""
-"All your mail server certificates are signed using a secure hash algorithm."
+"All your mail server certificates are signed using a secure signing "
+"algorithm and hash function."
+
+msgid "detail mail tls cert-signature verdict phase-out"
+msgstr ""
+"At least one of your mail server certificates is signed using a signing "
+"algorithm and hash function that should be *phased out* as they are weaker, "
+"although you might still use them if absolutely needed. In a future update, "
+"they will likely become insufficient."
msgid "detail mail tls cert-trust exp"
msgstr ""
@@ -1255,7 +1313,7 @@ msgstr ""
"\n"
"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.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B3-4 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 4.4.\n"
"\n"
"*Requirement level: Optional*"
@@ -1277,40 +1335,38 @@ msgstr ""
msgid "detail mail tls cipher-order exp"
msgstr ""
-"**PENDING UPDATE**\n"
-"\n"
-"We check if your receiving mail servers (MX) enforce their own cipher preference ('I'), and offer ciphers in accordance with the prescribed ordering ('II'). \n"
+"We check if your receiving mail servers offer cipher suites in descending order of their security level, without accepting any other preference of a sending mail server. \n"
"\n"
-"When your mail servers support 'Good' ciphers only, this test is not applicable as the ordering has no significant security advantage. \n"
+"This means your mail servers should enforce their own cipher suites preference while negotiating with a sending mail server. Furthermore, cipher suites should be offered by your mail server, with 'Good' and 'Sufficient' being preferred over 'Phase out' cipher suites. \n"
"\n"
-"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 the sending mail servers;\n"
+"When your mail servers support 'Good' and 'Sufficient' cipher suites only, this subtest is not applicable as the ordering has no significant security advantage. \n"
"\n"
-"II. *Prescribed ordering*: Ciphers are offered by the receiving mail servers in accordance with the prescribed order where 'Good' is preferred over 'Sufficient' over 'Phase out' ciphers.\n"
-" \n"
-"In the above table with technical details **only the first found out of prescribed order algorithm selections** are listed.\n"
+"In case of a deviating order, the table above with technical details shows the 'Phase Out' cipher suite chosen by your mail servers, with in the last column showing over which 'Good' or 'Sufficient' cipher suite the server chose it. Only the **first found** ordering issue is shown.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B2-5."
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 2 and 3."
msgid "detail mail tls cipher-order label"
-msgstr "Cipher order"
+msgstr "Cipher suite order"
msgid "detail mail tls cipher-order tech table"
-msgstr "Mail server (MX)|Cipher preferred by server|Expected preferred cipher"
+msgstr ""
+"Mail server (MX)|Cipher suite preferred by server|Expected preferred cipher "
+"suite"
msgid "detail mail tls cipher-order verdict bad"
msgstr ""
-"At least one of your mail servers does *not* enforce its own cipher preference ('I').\n"
-"At least one of your mail servers does *not* prefer 'Good' and 'Sufficient' over 'Phase out' ciphers ('II')."
+"At least one of your mail servers does *not* enforce its own preference for "
+"cipher suites in descending order of their security level."
msgid "detail mail tls cipher-order verdict good"
msgstr ""
-"All your mail servers enforce their own cipher preference ('I'), and offer "
-"ciphers in accordance with the prescribed ordering ('II')."
+"All your mail servers enforce their own preference for cipher suites in "
+"descending order of their security level."
msgid "detail mail tls cipher-order verdict na"
msgstr ""
-"This subtest is not applicable as your mail server supports 'Good' ciphers "
-"only."
+"This subtest is not applicable as your mail servers support 'Good' and "
+"'Sufficient' cipher suites only."
msgid "detail mail tls cipher-order verdict seclevel-bad"
msgstr ""
@@ -1328,83 +1384,102 @@ msgstr ""
msgid "detail mail tls ciphers exp"
msgstr ""
-"**UPDATE OF EXPLANATION PENDING**\n"
+"We check if your receiving mail servers (MX) only support secure (i.e. security level 'Good' and/or 'Sufficient') cipher suites. A mail server usually supports multiple cipher suites. \n"
"\n"
-"We check if your receiving mail servers (MX) only support secure, i.e. 'Good' and/or 'Sufficient', ciphers (also known as algorithm selections).\n"
+"A cipher suite consists of ciphers for four cryptographic functions: 1. key exchange, 2. authentication (i.e. certificate verification), 3. bulk encryption, and 4. hashing. \n"
"\n"
-"To prevent us from running into rate limits of receiving mail servers, the test result only contains the **first found affected algorithm selections**.\n"
+"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.\n"
"\n"
-"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.\n"
+"Both Internet.nl and NCSC-NL use the [IANA naming convention](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) for cipher suites. Another common notation is the [OpenSSL naming convention](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-SUITE-NAMES). Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation. \n"
"\n"
-"* 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.\n"
-"* NCSC-NL uses the [IANA naming convention](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) for algorithm selections. Internet.nl uses the [OpenSSL naming convention](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-SUITE-NAMES). Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.\n"
-"* Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method. \n"
+"Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method. \n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.2 to 3.3.5 and appendix B.\n"
"\n"
"---\n"
-"Below you find 'Good', 'Sufficient' and 'Phase out' algorithm selections in the by NCSC-NL prescribed 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'.\n"
-"\n"
-"\n"
-"Good:\n"
-"\n"
-"* `ECDHE-ECDSA-AES256-GCM-SHA384` (`TLS_AES_256_GCM_SHA384` in 1.3) [1.2]\n"
-"* `ECDHE-ECDSA-CHACHA20-POLY1305` (`TLS_CHACHA20_POLY1305_SHA256` in 1.3) [1.2]\n"
-"* `ECDHE-ECDSA-AES128-GCM-SHA256` (`TLS_AES_128_GCM_SHA256` in 1.3) [1.2]\n"
-"* `ECDHE-RSA-AES256-GCM-SHA384` (`TLS_AES_256_GCM_SHA384` in 1.3) [1.2]\n"
-"* `ECDHE-RSA-CHACHA20-POLY1305` (`TLS_CHACHA20_POLY1305_SHA256` in 1.3) [1.2]\n"
-"* `ECDHE-RSA-AES128-GCM-SHA256` (`TLS_AES_128_GCM_SHA256` in 1.3) [1.2]\n"
-"\n"
-"Sufficient:\n"
-"\n"
-"* `ECDHE-ECDSA-AES256-SHA384` [1.2]\n"
-"* `ECDHE-ECDSA-AES256-SHA` [1.0]\n"
-"* `ECDHE-ECDSA-AES128-SHA256` [1.2]\n"
-"* `ECDHE-ECDSA-AES128-SHA` [1.0]\n"
-"* `ECDHE-RSA-AES256-SHA384` [1.2]\n"
-"* `ECDHE-RSA-AES256-SHA` [1.0]\n"
-"* `ECDHE-RSA-AES128-SHA256` [1.2]\n"
-"* `ECDHE-RSA-AES128-SHA` [1.0]\n"
-"* `DHE-RSA-AES256-GCM-SHA384` [1.2]\n"
-"* `DHE-RSA-CHACHA20-POLY1305` [1.2]\n"
-"* `DHE-RSA-AES128-GCM-SHA256` [1.2]\n"
-"* `DHE-RSA-AES256-SHA256` [1.2]\n"
-"* `DHE-RSA-AES256-SHA` [1.0]\n"
-"* `DHE-RSA-AES128-SHA256` [1.2]\n"
-"* `DHE-RSA-AES128-SHA` [1.0]\n"
-"\n"
-"Phase out:\n"
-"\n"
-"* `ECDHE-ECDSA-DES-CBC3-SHA` [1.0]\n"
-"* `ECDHE-RSA-DES-CBC3-SHA` [1.0]\n"
-"* `DHE-RSA-DES-CBC3-SHA` [1.0]\n"
-"* `AES256-GCM-SHA384` [1.2]\n"
-"* `AES128-GCM-SHA256` [1.2]\n"
-"* `AES256-SHA256` [1.2]\n"
-"* `AES256-SHA` [1.0]\n"
-"* `AES128-SHA256` [1.2]\n"
-"* `AES128-SHA` [1.0]\n"
-"* `DES-CBC3-SHA` [1.0]"
+"\n"
+"**Security level of cipher suites**\n"
+"\n"
+"Below you find cipher suites with status 'Good', 'Sufficient' and 'Phase out', based on appendix B of NCSC-NL's guidelines.\n"
+"\n"
+"Good [TLS 1.3]:\n"
+"\n"
+"* `TLS_AES_256_GCM_SHA384`\n"
+"* `TLS_CHACHA20_POLY1305_SHA256`\n"
+"\n"
+"Sufficient [TLS 1.3]:\n"
+"\n"
+"* `TLS_AES_128_CCM_SHA256`\n"
+"* `TLS_AES_128_GCM_SHA256`\n"
+"\n"
+"Sufficient [TLS 1.2]:\n"
+"\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_128_CCM`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_256_CCM`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256`\n"
+"\n"
+"Phase out [TLS 1.2]:\n"
+"* `TLS_DHE_RSA_WITH_AES_128_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_AES_128_CCM`\n"
+"* `TLS_DHE_RSA_WITH_AES_128_GCM_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_AES_256_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_AES_256_CCM`\n"
+"* `TLS_DHE_RSA_WITH_AES_256_GCM_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384`"
msgid "detail mail tls ciphers label"
-msgstr "Ciphers (Algorithm selections)"
+msgstr "Cipher suites"
msgid "detail mail tls ciphers tech table"
-msgstr "Mail server (MX)|First found affected cipher|Status"
+msgstr "Mail server (MX)|Outdated cipher suite|Security level"
msgid "detail mail tls ciphers verdict bad"
msgstr ""
"At least one of your mail servers supports one or more *insufficiently* "
-"secure ciphers."
+"secure cipher suites."
msgid "detail mail tls ciphers verdict good"
-msgstr "All your mail servers support secure ciphers only."
+msgstr "All your mail servers support secure cipher suites only."
msgid "detail mail tls ciphers verdict phase-out"
msgstr ""
-"At least one of your mail servers supports one or more ciphers that have a "
-"*phase out* status, because they are known to be fragile and are at risk of "
-"becoming *insufficiently* secure."
+"At least one of your mail servers supports one or more cipher suites that "
+"should be *phased out* as they are weaker, although you might still use them"
+" if absolutely needed. In a future update, they will likely become "
+"insufficient."
msgid "detail mail tls compression exp"
msgstr ""
@@ -1412,14 +1487,15 @@ msgstr ""
"\n"
"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. \n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B7-1 and table 11 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.1.\n"
"\n"
"---\n"
-"**Compression option**\n"
"\n"
-"* Good: No compression\n"
-"* Sufficient: Application-level compression\n"
-"* Insufficient: TLS compression"
+"**Security level of TLS compression**\n"
+"\n"
+"* Good: N/A (TLS 1.3)\n"
+"* Good: No TLS compression (TLS 1.2)\n"
+"* Insufficient: TLS compression (TLS 1.2)"
msgid "detail mail tls compression label"
msgstr "TLS compression"
@@ -1445,7 +1521,7 @@ msgstr ""
"\n"
"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.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, Appendix A, under 'Certificate pinning and DANE' (in English)."
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, chapter \"2 Step-by-step plan: How do I arrive at an appropriate TLS configuration?\"."
msgid "detail mail tls dane-exists label"
msgstr "DANE existence"
@@ -1529,70 +1605,98 @@ msgstr ""
"servers."
msgid "detail mail tls extended-master-secret exp"
-msgstr "This test checks for Extended Master Secret."
+msgstr ""
+"We check if your receiving mail servers (MX) support Extended Master Secret.\n"
+"\n"
+"Extended Master Secret (EMS), that is specified in [RFC 7627](https://www.rfc-editor.org/rfc/rfc7627), is an extension for TLS 1.2 that prevents Triple Handshakes machine-in-the-middle attacks. \n"
+"\n"
+"Increasingly, TLS libraries are enforcing EMS by default, also because security regulations such as FIPS require it. If your mail server does not support EMS, sending mail servers that enforce EMS will be unable to establish a TLS 1.2 connection with your mail server.\n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 4.1."
msgid "detail mail tls extended-master-secret label"
msgstr "Extended Master Secret (EMS)"
msgid "detail mail tls extended-master-secret tech table"
-msgstr "Mail server|EMS result"
+msgstr "Mail server (MX)|EMS"
msgid "detail mail tls extended-master-secret verdict bad"
-msgstr "EMS is not supported."
+msgstr "At least one of your mail servers does *not* support EMS."
msgid "detail mail tls extended-master-secret verdict good"
-msgstr "EMS is supported."
+msgstr "All your mail servers support EMS."
msgid "detail mail tls extended-master-secret verdict na-no-tls-1-2"
-msgstr "EMS is only available in TLS 1.2, which is not enabled."
+msgstr ""
+"This subtest is not applicable as EMS is only available in TLS 1.2, which is"
+" not enabled on your mail servers."
msgid "detail mail tls extended-master-secret verdict unknown"
-msgstr "We could not determine the EMS status."
+msgstr ""
+"No result available. At the time the test was run, this subtest was not yet "
+"part of the test."
msgid "detail mail tls fs-params exp"
msgstr ""
"We check if the public parameters used in Diffie-Hellman key exchange by your receiving mail servers (MX) are secure.\n"
"\n"
-"**ECDHE**: 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.\n"
-"\n"
-"**DHE**: 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](https://www.rfc-editor.org/rfc/rfc7919). Self-generated groups are 'Insufficient'.\n"
+"**ECDHE**: The security of key exchange with Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) depends on the elliptic curve used. We test what elliptic curve is used.\n"
"\n"
+"**DHE**: The security of key exchange with Diffie-Hellman Ephemeral (DHE) depends on the finite field group used. We test if one of the standardised finite field groups that are specified in [RFC 7919](https://www.rfc-editor.org/rfc/rfc7919) is used. Self-generated groups have security level 'Insufficient'. \n"
"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.\n"
"\n"
-"**RSA as an alternative**: 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.\n"
+"**Alternatives for ECDHE and DHE**\n"
+"\n"
+"* **Quantum-safe cryptographic algorithms** `X25519MLKEM768`, `SecP256r1MLKEM768` and `SecP384r1MLKEM1024` have security level 'Good'. These are hybrid algorithms that use a combination of ECDHE and ML-KEM. Particularly, `X25519MLKEM768` is increasingly supported by TLS software libraries and is utilised by most web browsers. The parameters are inherently part of these algorithms. There is thus no need to make any additional choices.\n"
+"* **RSA** and non-ephemeral Diffie-Hellman (ECDH and DH) should *not* be used for key exchange as their security level is 'Insufficient'. They do not offer forward secrecy. Note that RSA is still considered as 'Sufficient' for authentication (i.e. certificate verification).\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B5-1 and table 9 for ECDHE, and guideline B6-1 and table 10 for DHE (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.3\n"
"\n"
"---\n"
-"**Elliptic curve for ECDHE**\n"
-"\n"
-"* Good: `secp384r1`, `secp256r1`, `x448`, and `x25519`\n"
-"* Phase out: `secp224r1`\n"
-"* Insufficient: Other curves\n"
"\n"
-"**Finite field group for DHE**\n"
+"**Security level of elliptic curves for ECDHE**\n"
"\n"
"* Sufficient:\n"
+" \n"
+" * `secp521r1` (rarely used)\n"
+" * `secp384r1`\n"
+" * `secp256r1`\n"
+" * `x448`\n"
+" * `x25519`\n"
+" * `brainpoolP512r1` (rarely used)\n"
+" * `brainpoolP384r1` (idem)\n"
+" * `brainpoolP256r1` (idem)\n"
"\n"
-" * [ffdhe4096](https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe4096.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
-" sha256 checksum: `64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3`\n"
-" * [ffdhe3072](https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe3072.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
-" sha256 checksum: `c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab` \n"
-" * Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.\n"
+"* Phase out:\n"
+"\n"
+" * `secp224r1`\n"
+"\n"
+"* Insufficient:\n"
+"\n"
+" * Other curves\n"
+"\n"
+"**Security level of finite field groups for DHE**\n"
"\n"
"* Phase out:\n"
"\n"
-" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe2048.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
-" sha256 checksum: `9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b`\n"
+" * `ffdhe8192` (rarely used because of performance loss)\n"
+" * `ffdhe6144` (idem)\n"
+" * [`ffdhe4096`](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
+" sha256 checksum: `64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3`\n"
+" * [`ffdhe3072`](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe3072.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
+" sha256 checksum: `c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab` \n"
+" \n"
+"* Insufficient:\n"
"\n"
-"* Insufficient: Other groups\n"
+" * `ffdhe2048`\n"
+" * Other groups (i.e. not-standardised, self-generated)\n"
"\n"
"---\n"
"\n"
-"Note: the above names are based on the [IANA naming conventions](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Sometimes alternative names are used to refer to the same curves, like `prime256v1` (ANSI) and `NIST P-256` for `secp256r1`."
+"Note that the above names are based on the [IANA naming conventions](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Sometimes alternative names are used to refer to the same curves, like `prime256v1` (ANSI) and `NIST P-256` for `secp256r1`."
msgid "detail mail tls fs-params label"
-msgstr "Key exchange parameters"
+msgstr "Parameters for key exchange"
msgid "detail mail tls fs-params tech table"
msgstr "Mail server (MX)|Affected parameters|Security level"
@@ -1609,42 +1713,49 @@ msgstr ""
msgid "detail mail tls fs-params verdict na"
msgstr ""
-"This subtest is not applicable as your mail servers do not support Diffie-"
-"Hellman key exchange. Note that RSA is an alternative for key exchange, but "
-"has the *phase out* status."
+"This subtest is not applicable as your mail servers do *not* support Diffie-"
+"Hellman key exchange."
msgid "detail mail tls fs-params verdict phase-out"
msgstr ""
"At least one of your mail servers supports parameters for Diffie-Hellman key"
-" exchange that have a *phase out* status, because they are known to be "
-"fragile and are at risk of of becoming *insufficiently* secure."
+" exchange that should be *phased out* as they are weaker, although you might"
+" still use them if absolutely needed. In a future update, they will likely "
+"become insufficient."
msgid "detail mail tls kex-hash-func exp"
msgstr ""
"We check if your receiving mail servers (MX) support secure hash functions to create the digital signature during key exchange.\n"
"\n"
-"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. \n"
+"The 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.\n"
"\n"
-"*Requirement level: Recommended*\n"
+"Note that this subtest is only relevant for TLS 1.2. The supported hash functions can be configured via a separate TLS setting (e.g. `SignatureAlgorithms` in OpenSSL) and are *not* part of the cipher suite configuration. \n"
+"\n"
+"For more details on the status of SHA-1 and MD5, see [RFC 9155](https://www.rfc-editor.org/rfc/rfc9155.html#name-server-key-exchange). We do not test for MD5 because it is only supported by very outdated software.\n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.5. \n"
"\n"
"---\n"
-"**Outdated signature algorithms**\n"
"\n"
-"* Good: Only SHA-256, SHA-384 or SHA-512 supported\n"
-"* Phase out: SHA1 or SHA224 supported"
+"**Security level of hash functions for key exchange**\n"
+"\n"
+"* Good: SHA-256, SHA-384, SHA-512\n"
+"* Phase out: SHA-224 (rarely used)\n"
+"* Insufficient: SHA-1, MD5"
msgid "detail mail tls kex-hash-func label"
msgstr "Hash function for key exchange"
msgid "detail mail tls kex-hash-func tech table"
-msgstr "Mail server (MX)|Outdated signature algorithm result"
+msgstr "Mail server (MX)|Outdated hash function"
msgid "detail mail tls kex-hash-func verdict bad"
msgstr ""
+"At least one of your mail servers supports one or more *insufficiently* "
+"secure hash functions for key exchange."
msgid "detail mail tls kex-hash-func verdict good"
-msgstr ""
-"All your mail servers support only secure hash functions for key exchange."
+msgstr "All your mail servers support secure hash functions for key exchange."
msgid "detail mail tls kex-hash-func verdict other"
msgstr ""
@@ -1655,9 +1766,10 @@ msgstr ""
msgid "detail mail tls kex-hash-func verdict phase-out"
msgstr ""
-"At least one of your mail servers does *not* support a secure hash function "
-"for key exchange. You should *phase out* this setting deliberately, because "
-"it is at risk of becoming *insufficiently* secure in the future."
+"At least one of your mail servers supports a hash function for key exchange "
+"that should be *phased out* as it is weaker, although you might still use it"
+" if absolutely needed. In a future update, it will likely become "
+"insufficient."
msgid "detail mail tls kex-hash-func verdict {phase-out}"
msgstr ""
@@ -1729,20 +1841,26 @@ msgstr ""
msgid "detail mail tls renegotiation-client exp"
msgstr ""
-"We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX). \n"
+"We check whether a sending mail server can initiate a renegotiation with your receiving mail server (MX) and, if so, whether the number of allowed renegotiations is sufficiently limited.\n"
"\n"
-"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. \n"
+"Allowing clients to initiate renegotiation is generally not necessary. Client-initiated renegotiation opens a web server to DoS attacks inside a TLS connection. Therefore it is important either not to allow renegotiations or to strictly limit their number. We consider more than 10 allowed renegotiations as insufficient.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B8-1 and table 13 (in English).\n"
+"An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections. However, these are easier to detect and defend against using standard mitigations. \n"
"\n"
-"*Requirement level: Optional*\n"
+"Note that client-initiated renegotiation could impact availability, but not confidentiality. \n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.2.\n"
+"\n"
+"*Requirement level: Recommended*\n"
"\n"
"---\n"
"\n"
-"**Client-initiated renegotiation**\n"
+"**Security level of client-initiated renegotiation**\n"
"\n"
-"* Good: Off (or N/A for TLS 1.3)\n"
-"* Sufficient: On"
+"* Good: N/A (TLS 1.3)\n"
+"* Good: No renegotiation (TLS 1.2)\n"
+"* Sufficient: Limited renegotiation (TLS 1.2)\n"
+"* Phase out: Unlimited renegotiation (TLS 1.2)"
msgid "detail mail tls renegotiation-client label"
msgstr "Client-initiated renegotiation"
@@ -1752,10 +1870,14 @@ msgstr "Mail server (MX)|Client-initiated renegotiation"
msgid "detail mail tls renegotiation-client verdict allowed-with-low-limit"
msgstr ""
+"At least one of your mail servers allows client-initiated renegotiation, "
+"while sufficiently limiting the number of allowed renegotiations."
msgid ""
"detail mail tls renegotiation-client verdict allowed-with-too-high-limit"
msgstr ""
+"At least one of your mail servers allows for client-initiated renegotiation,"
+" while *not sufficiently* limiting the number of allowed renegotiations."
msgid "detail mail tls renegotiation-client verdict bad"
msgstr ""
@@ -1767,7 +1889,7 @@ msgstr ""
"All your mail servers do not allow for client-initiated renegotiation."
msgid "detail mail tls renegotiation-client verdict not-allowed"
-msgstr ""
+msgstr "Your mail servers do not allow client-initiated renegotiation."
msgid "detail mail tls renegotiation-secure exp"
msgstr ""
@@ -1775,13 +1897,15 @@ msgstr ""
"\n"
"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.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B8-1 and table 12 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.2.\n"
"\n"
"---\n"
-"**Insecure renegotiation**\n"
"\n"
-"* Good: Off (or N/A for TLS 1.3)\n"
-"* Insufficient: On"
+"**Security level of insecure renegotiation**\n"
+"\n"
+"* Good: N/A (TLS 1.3)\n"
+"* Good: No insecure renegotiation (TLS 1.2)\n"
+"* Insufficient: Insecure renegotiation (TLS 1.2)"
msgid "detail mail tls renegotiation-secure label"
msgstr "Secure renegotiation"
@@ -1881,34 +2005,32 @@ msgstr ""
msgid "detail mail tls version exp"
msgstr ""
-"**PENDING UPDATE**\n"
+"We check if your receiving mail servers (MX) only supports secure TLS versions (i.e. with a security level of 'Good' or 'Sufficient'). \n"
"\n"
-"We check if your mail servers (MX) support secure TLS versions only. \n"
-"\n"
-"A mail server may support more than one TLS version. \n"
+"A web server may support more than one TLS version. \n"
"\n"
-"Note that 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.\n"
+"Please note that modern browsers no longer support TLS 1.0/1.1 and SSL. As a result, websites that do not support TLS 1.2 and/or 1.3 are unreachable for almost everyone.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B1-1 and table 1 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.1. \n"
"\n"
"---\n"
-"**Version**\n"
"\n"
-"* Good: TLS 1.3 \n"
+"**Security level of TLS versions**\n"
+"\n"
+"* Good: TLS 1.3\n"
"* Sufficient: TLS 1.2\n"
-"* Phase out: TLS 1.1 and 1.0\n"
-"* Insufficient: SSL 3.0, 2.0 and 1.0"
+"* Insufficient: TLS 1.0/1.1, SSL 1.0/2.0/3.0"
msgid "detail mail tls version label"
msgstr "TLS version"
msgid "detail mail tls version tech table"
-msgstr "Mail server (MX)|TLS versions|Status"
+msgstr "Mail server (MX)|TLS version|Security level"
msgid "detail mail tls version verdict bad"
msgstr ""
-"At least one of your mail servers supports one or more *insufficiently* "
-"secure TLS versions."
+"At least one of your mail servers supports *insufficiently* secure TLS "
+"versions."
msgid "detail mail tls version verdict good"
msgstr "All your mail servers support secure TLS versions only."
@@ -1938,13 +2060,15 @@ msgstr ""
"If the TLS handshake is completed and the mail server responds,\n"
"then the mail server is considered to support 0-RTT.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B9-1 and table 14 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.4.\n"
"\n"
"---\n"
-"**0-RTT**\n"
"\n"
-"* Good: Off (or N/A prior to TLS 1.3)\n"
-"* Insufficient: On"
+"**Security level of 0-RTT**\n"
+"\n"
+"* Good: No 0-RTT (TLS 1.3)\n"
+"* Good: N/A (TLS 1.2)\n"
+"* Insufficient: Using 0-RTT (TLS 1.3)"
msgid "detail mail tls zero-rtt label"
msgstr "0-RTT"
@@ -1961,7 +2085,8 @@ msgstr "None of your mail servers support 0-RTT."
msgid "detail mail tls zero-rtt verdict na"
msgstr ""
-"This subtest is not applicable as your mail servers do not support TLS 1.3."
+"This subtest is not applicable as 0-RTT is only available in TLS 1.3, which "
+"is not enabled on your mail servers."
msgid "detail tech data bogus"
msgstr "bogus"
@@ -2375,15 +2500,15 @@ msgstr ""
"6. The source values `unsafe-eval`, `unsafe-inline` and `unsafe-hashes` should *not* be used, because these enable XSS attacks. \n"
"7. The `data:` scheme should *not* be used in the `default-src`, `script-src` and `object-src` directives, because this enables XSS attacks.\n"
"8. A domain with the `http://` scheme or a domain without a scheme should *not* be used, because this enables sources to be downloaded over an insecure connection. Use the `https://` scheme instead.\n"
-"9. A wildcard (i.e. `*`) for the full host part of a URL should *not* be used in any directive, because this allows for any external source. Furthermore do *not* use just `https:` as this is equivalent to `https://*`. Always specify the main domain as well (e.g. `https://scripts.example.nl` or `https://*.example.nl`). \n"
+"9. A wildcard (i.e. `*`) for the full host part of a URL should *not* be used in any directive, because this allows for any external source. Furthermore do *not* use just `https:` as this is equivalent to `https://*`. Always specify the main domain as well (e.g. `https://scripts.example.org` or `https://*.example.org`). \n"
"10. `127.0.0.1` should *not* be used in any directive, because it enables content injection attacks in a compromised system.\n"
"\n"
"Additional recommendations:\n"
"\n"
"1. Only use domains in CSP directives as specific as possible, which is tested automatically to some extent in this subtest for CSP.\n"
"\n"
-" * Do *not* allow all domains under a TLD (`*.nl`) or SLD (`*.gov.uk`), although we currently do *not* test for this. \n"
-" * Do *not* allow a different main domain under a SLD in `default-src` (for example `example2.gov.nl` for `example1.gov.nl`), although we currently do *not* test for this either.\n"
+" * Do *not* allow all domains under a TLD (`*.org`) or SLD (`*.example.org`), although we currently do *not* test for this. \n"
+" * Do *not* allow a different main domain under a SLD in `default-src` (for example `example2.example.org` for `example1.example.org.`), although we currently do *not* test for this either.\n"
"\n"
"2. Ideally do *not* use inline scripts or styles. For cases where you cannot avoid using inline scripts or styles, do *not* use `unsafe-inline` (as mentioned above) but preferably use CSP hashes or otherwise CSP nonces.\n"
"3. Use the HTTP header as a mechanism for serving your CSP policy. Do *not* use the HTML `` element to serve your CSP policy. The latter is less secure and does not support all CSP directives (e.g. the required `frame-ancestors`). Therefore we do *not* check for CSP that is offered via the HTML `` element.\n"
@@ -2492,7 +2617,7 @@ msgstr ""
"\n"
"If one or more `Canonical` fields are present, the web URI of the `security.txt` file must be listed in a `Canonical` field. When redirecting to a `security.txt` file at least the last URI of the redirect chain must be listed.\n"
"\n"
-"The file must be published under the `/.well-known/` path. Note that placing it under the top-level path has been deprecated. Every web (sub) domain should have its own `security.txt` file. An example file can be found on [`https://example.nl/.well-known/security.txt`](https://example.nl/.well-known/security.txt).\n"
+"The file must be published under the `/.well-known/` path. Note that placing it under the top-level path has been deprecated. Every web (sub) domain should have its own `security.txt` file. An example file can be found on [`https://securitytxt.org/.well-known/security.txt`](https://securitytxt.org/.well-known/security.txt).\n"
"\n"
"Redirecting to a `security.txt` on another domain name is allowed. Especially in the case of a large domain name portfolio, it is advisable from a maintenance perspective to redirect the domain names to a central `security.txt`.\n"
"\n"
@@ -2859,7 +2984,7 @@ msgstr ""
"A certificate authority must not issue a certificate unless the CA determines that the certificate request is consistent with the applicable CAA records.\n"
"\n"
"Note that CAA records are located during validation by walking up the DNS hierarchy until one or more records are found.\n"
-"For example, if no CAA records are found on `sub.example.nl`, `example.nl` will be queried.\n"
+"For example, if no CAA records are found on `sub.example.org`, `example.org` will be queried.\n"
"The domain were the applicable CAA records are found is shown in the table with technical details below.\n"
"\n"
"The verdict is good if one or more CAA records were found that all have correct syntax, and at least one of these CAA records has the `issue` tag with a valid value.\n"
@@ -2896,7 +3021,7 @@ msgstr ""
"\n"
"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.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B3-1 (in English)."
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 4.4."
msgid "detail web tls cert-hostmatch label"
msgstr "Domain name on certificate"
@@ -2916,83 +3041,136 @@ msgstr ""
msgid "detail web tls cert-pubkey exp"
msgstr ""
-"We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters. \n"
+"We check if the public key of your certificate and every intermediate certificate is based on a secure signing algorithm with secure parameters. \n"
+"\n"
+"The verification of certificates makes use of digital signatures. The public key of a certificate can be used to verify that a signature was created using the corresponding private key.\n"
"\n"
-"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.\n"
-"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.\n"
+"**Signing algorithm:**\n"
+"The signing algorithm is determined when generating the certificate. A certificate can only contain one signing algorithm. It is possible to configure multiple certificates on a server to support more than one algorithm. Only the signing algorithms ECDSA, RSA and EdDSA are considered sufficiently secure. EdDSA is actually rarely, if ever, used. All mentioned algorithms are vulnerable to the quantum threat. They offer sufficient protection for now. Quantum-safe alternatives are not yet part of the TLS standards.\n"
"\n"
-"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. \n"
+"**Parameters:** The security of ECDSA and EdDSA digital signatures depends on the chosen curve. The security of RSA is tied to the key length of the public key. \n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).\n"
+"For details on the relevant certificate field name see paragraph [\"4.1.2.7. Subject Public Key Info\" of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.7).\n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.2\n"
"\n"
"---\n"
-"**Elliptic curves for ECDSA**\n"
"\n"
-"* Good: `secp384r1`, `secp256r1`, `x448`, and `x25519`\n"
-"* Phase out: `secp224r1`\n"
-"* Insufficient: Other curves\n"
+"**Security level of elliptic curves for ECDSA**\n"
+"\n"
+"* Sufficient:\n"
+" \n"
+" * `secp521r1` (rarely used)\n"
+" * `secp384r1`\n"
+" * `secp256r1`\n"
+" * `x448`\n"
+" * `x25519`\n"
+" * `brainpoolP512r1` (rarely used)\n"
+" * `brainpoolP384r1` (idem)\n"
+" * `brainpoolP256r1` (idem)\n"
+"\n"
+"* Phase out:\n"
+"\n"
+" * `secp224r1`\n"
+"\n"
+"* Insufficient:\n"
+"\n"
+" * Other curves\n"
+"\n"
+"**Security level of length of RSA keys**\n"
+"\n"
+"* Sufficient: At least 3072 bit\n"
+"* Phase out: 2048 – 3071 bit\n"
+"* Insufficient: Less than 2048 bit\n"
+"\n"
+"**Security level of Edwards curves for EdDSA (rarely used)**\n"
+"\n"
+"* Sufficient:\n"
+"\n"
+" * `Ed448`\n"
+" * `Ed25519`\n"
+"\n"
+"* Insufficient:\n"
"\n"
-"**Length of RSA-keys**\n"
+" * Other curves\n"
+" \n"
+"---\n"
"\n"
-"* Good: At least 3072 bit\n"
-"* Sufficient: 2048 – 3071 bit\n"
-"* Insufficient: Less than 2048 bit"
+"Note that the above names are based on the [IANA naming conventions](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Sometimes alternative names are used to refer to the same curves, like `prime256v1` (ANSI) and `NIST P-256` for `secp256r1`."
msgid "detail web tls cert-pubkey label"
msgstr "Public key of certificate"
msgid "detail web tls cert-pubkey tech table"
-msgstr "Web server IP address|Affected signature parameters|Status"
+msgstr "Web server IP address|Outdated signature parameter|Security level"
msgid "detail web tls cert-pubkey verdict bad"
msgstr ""
-"The digital signature of your website certificate uses *insufficiently* "
-"secure parameters."
+"The public key of your website certificate is *not* based on a secure "
+"signing algorithm with secure parameters."
msgid "detail web tls cert-pubkey verdict good"
msgstr ""
-"The digital signature of your website certificate uses secure parameters."
+"The public key of your website certificate is based on a secure signing "
+"algorithm with secure parameters."
msgid "detail web tls cert-pubkey verdict phase-out"
msgstr ""
-"The digital signature of your website certificate uses parameters that have "
-"a *phase out* status, because they are known to be fragile and are at risk "
-"of of becoming *insufficiently* secure."
+"The public key of your website certificate is based on a signing algorithm "
+"with parameters that should be *phased out* as they are weaker, although you"
+" might still use them if absolutely needed. In a future update, they will "
+"likely become insufficient."
msgid "detail web tls cert-signature exp"
msgstr ""
-"We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm. \n"
+"We check if your website certificate is signed (by a certificate authority) with a secure signing algorithm, while making use of a secure hash function.\n"
+"\n"
+"For details on the relevant certificate field name see paragraph [\"4.1.1.2. signatureAlgorithm\" of RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.1.2).\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B3-2 and table 3 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.5.\n"
"\n"
"---\n"
+"**Security level of signing algorithms**\n"
"\n"
-"**Hash functions for certificate verification**\n"
+"* Sufficient: ECDSA, RSA, EdDSA\n"
+"* Insufficient: DSS, EXPORT-*, PSK, Anon, NULL, KRB5\n"
"\n"
-"* Good: SHA-512, SHA-384, SHA-256\n"
+"**Security level of hash functions**\n"
+"\n"
+"* Good: SHA-256, SHA-384, SHA-512\n"
+"* Phase out: SHA-224\n"
"* Insufficient: SHA-1, MD5"
msgid "detail web tls cert-signature label"
-msgstr "Signature of certificate"
+msgstr "Signature on certificate"
msgid "detail web tls cert-signature tech table"
-msgstr "Web server IP address|Affected hash algorithm|Status"
+msgstr "Web server IP address|Outdated hash function|Security level"
msgid "detail web tls cert-signature verdict bad"
msgstr ""
-"Your website certificate is signed using a hash algorithm that is "
-"*insufficiently* secure."
+"Your website certificate is signed using an *insufficiently* secure signing "
+"algorithm and hash function."
msgid "detail web tls cert-signature verdict good"
-msgstr "Your website certificate is signed using a secure hash algorithm."
+msgstr ""
+"Your website certificate is signed using a secure signing algorithm and hash"
+" function."
+
+msgid "detail web tls cert-signature verdict phase-out"
+msgstr ""
+"Your website certificate is signed using a signing algorithm and hash "
+"function that should be *phased out* as they are weaker, although you might "
+"still use them if absolutely needed. In a future update, they will likely "
+"become insufficient."
msgid "detail web tls cert-trust exp"
msgstr ""
"We check if we are able to build a valid chain of trust for your website certificate. \n"
"\n"
-"For a valid chain of trust, your certificate must be published by a [publicly trusted certificate authority](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/), and your web server must present all necessary intermediate certificates. \n"
+"For a valid chain of trust, your certificate must be signed by a [publicly trusted certificate authority](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/), and your web server must present all necessary intermediate certificates. The certificates must not have expired.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B3-4 (in English)."
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 4.4."
msgid "detail web tls cert-trust label"
msgstr "Trust chain of certificate"
@@ -3014,13 +3192,13 @@ msgid "detail web tls cipher-order exp"
msgstr ""
"We check if your web server offers cipher suites in descending order of their security level, without accepting any other preference of the web browser. \n"
"\n"
-"So, the web server should enforce its own cipher suites preference while negotiating with a web browser. Furthermore, cipher suites should be offered by the web server, with 'Good' and ‘Sufficient’ being preferred over 'Phase out' cipher suites. \n"
+"This means the web server should enforce its own cipher suites preference while negotiating with a web browser. Furthermore, cipher suites should be offered by the web server, with 'Good' and 'Sufficient' being preferred over 'Phase out' cipher suites. \n"
"\n"
"When your web server supports 'Good' and 'Sufficient' cipher suites only, this subtest is not applicable as the ordering has no significant security advantage. \n"
"\n"
-"In case of a deviating order, the table above with technical details shows the **first found** cipher suite that is preferred by the server, followed by the expected preferred cipher suite.\n"
+"In case of a deviating order, the table above with technical details shows the 'Phase Out' cipher suite chosen by the server, with in the last column showing over which 'Good' or 'Sufficient' cipher suite the server chose it. Only the **first found** ordering issue is shown.\n"
"\n"
-"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL, paragraph 2 and 3."
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 2 and 3."
msgid "detail web tls cipher-order label"
msgstr "Cipher suite order"
@@ -3071,7 +3249,7 @@ msgstr ""
"\n"
"Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method. \n"
"\n"
-"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL, paragraph 3.3.2 to 3.3.5 and appendix B.\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.2 to 3.3.5 and appendix B.\n"
"\n"
"---\n"
"\n"
@@ -3141,7 +3319,7 @@ msgid "detail web tls ciphers label"
msgstr "Cipher suites"
msgid "detail web tls ciphers tech table"
-msgstr "Web server IP address|Affected cipher suites|Status"
+msgstr "Web server IP address|Outdated cipher suite|Security level"
msgid "detail web tls ciphers verdict bad"
msgstr ""
@@ -3152,8 +3330,9 @@ msgstr "Your web server supports secure cipher suites only."
msgid "detail web tls ciphers verdict phase-out"
msgstr ""
-"Your web server supports one or more cipher suites that have a *phase out* "
-"status because they are at risk of becoming *insufficiently* secure."
+"Your web server supports one or more cipher suites that should be *phased "
+"out* as they are weaker, although you might still use them if absolutely "
+"needed. In a future update, they will likely become insufficient."
msgid "detail web tls compression exp"
msgstr ""
@@ -3161,14 +3340,15 @@ msgstr ""
"\n"
"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. \n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B7-1 and table 11 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.1.\n"
"\n"
"---\n"
-"**Compression option**\n"
"\n"
-"* Good: No compression\n"
-"* Sufficient: Application-level compression (in this case HTTP compression)\n"
-"* Insufficient: TLS compression"
+"**Security level of TLS compression**\n"
+"\n"
+"* Good: N/A (TLS 1.3)\n"
+"* Good: No TLS compression (TLS 1.2)\n"
+"* Insufficient: TLS compression (TLS 1.2)"
msgid "detail web tls compression label"
msgstr "TLS compression"
@@ -3188,7 +3368,7 @@ msgstr ""
"\n"
"As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the website domain, or if there are DANE related DNSSEC issues (e.g. no proof of 'Denial of Existence').\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, Appendix A, under 'Certificate pinning and DANE' (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, chapter \"2 Step-by-step plan: How do I arrive at an appropriate TLS configuration?\".\n"
"\n"
"*Requirement level: Optional*"
@@ -3278,25 +3458,36 @@ msgstr ""
"The DANE fingerprint on your domain is valid for your web certificate."
msgid "detail web tls extended-master-secret exp"
-msgstr "This test checks for Extended Master Secret."
+msgstr ""
+"We check if your web server supports Extended Master Secret.\n"
+"\n"
+"Extended Master Secret (EMS), that is specified in [RFC 7627](https://www.rfc-editor.org/rfc/rfc7627), is an extension for TLS 1.2 that prevents Triple Handshakes machine-in-the-middle attacks. \n"
+"\n"
+"Increasingly, TLS libraries are enforcing EMS by default, also because security regulations such as FIPS require it. If your server does not support EMS, clients that enforce EMS will be unable to establish a TLS 1.2 connection with your server.\n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 4.1."
msgid "detail web tls extended-master-secret label"
msgstr "Extended Master Secret (EMS)"
msgid "detail web tls extended-master-secret tech table"
-msgstr "Web server|EMS result"
+msgstr "Web server IP address|EMS"
msgid "detail web tls extended-master-secret verdict bad"
-msgstr "EMS is not supported."
+msgstr "Your web server does *not* support EMS."
msgid "detail web tls extended-master-secret verdict good"
-msgstr "EMS is supported."
+msgstr "Your web server supports EMS."
msgid "detail web tls extended-master-secret verdict na-no-tls-1-2"
-msgstr "EMS is only available in TLS 1.2, which is not enabled."
+msgstr ""
+"This subtest is not applicable as EMS is only available in TLS 1.2, which is"
+" not enabled on your web server."
msgid "detail web tls extended-master-secret verdict unknown"
-msgstr "We could not determine the EMS status."
+msgstr ""
+"No result available. At the time the test was run, this subtest was not yet "
+"part of the test."
msgid "detail web tls fs-params exp"
msgstr ""
@@ -3312,14 +3503,15 @@ msgstr ""
"* **Quantum-safe cryptographic algorithms** `X25519MLKEM768`, `SecP256r1MLKEM768` and `SecP384r1MLKEM1024` have security level 'Good'. These are hybrid algorithms that use a combination of ECDHE and ML-KEM. Particularly, `X25519MLKEM768` is increasingly supported by TLS software libraries and is utilised by most web browsers. The parameters are inherently part of these algorithms. There is thus no need to make any additional choices.\n"
"* **RSA** and non-ephemeral Diffie-Hellman (ECDH and DH) should *not* be used for key exchange as their security level is 'Insufficient'. They do not offer forward secrecy. Note that RSA is still considered as 'Sufficient' for authentication (i.e. certificate verification).\n"
"\n"
-"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL, paragraph 3.3.3\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.3\n"
"\n"
"---\n"
+"\n"
"**Security level of elliptic curves for ECDHE**\n"
"\n"
"* Sufficient:\n"
" \n"
-" * `secp521r1`\n"
+" * `secp521r1` (rarely used)\n"
" * `secp384r1`\n"
" * `secp256r1`\n"
" * `x448`\n"
@@ -3357,10 +3549,10 @@ msgstr ""
"Note that the above names are based on the [IANA naming conventions](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Sometimes alternative names are used to refer to the same curves, like `prime256v1` (ANSI) and `NIST P-256` for `secp256r1`."
msgid "detail web tls fs-params label"
-msgstr "Key exchange parameters"
+msgstr "Parameters for key exchange"
msgid "detail web tls fs-params tech table"
-msgstr "Web server IP address|Affected parameters|Status"
+msgstr "Web server IP address|Outdated parameter|Security level"
msgid "detail web tls fs-params verdict bad"
msgstr ""
@@ -3379,8 +3571,9 @@ msgstr ""
msgid "detail web tls fs-params verdict phase-out"
msgstr ""
"Your web server supports parameters for Diffie-Hellman key exchange that "
-"have a *phase out* status, because they are known to be fragile and are at "
-"risk of of becoming *insufficiently* secure."
+"should be *phased out* as they are weaker, although you might still use them"
+" if absolutely needed. In a future update, they will likely become "
+"insufficient."
msgid "detail web tls http-compression exp"
msgstr ""
@@ -3409,7 +3602,7 @@ msgstr "Your web server does not support HTTP compression."
msgid "detail web tls https-exists exp"
msgstr ""
-"We check if your website is reachable on HTTPS. \n"
+"We check if your website is reachable over HTTPS. \n"
"\n"
"If so, we also check in the below subtests whether HTTPS is configured sufficiently secure in conformance with the ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL.\n"
"\n"
@@ -3424,22 +3617,22 @@ msgid "detail web tls https-exists tech table"
msgstr "Web server IP address|HTTPS existent"
msgid "detail web tls https-exists verdict bad"
-msgstr "Your website is *not* reachable on HTTPS."
+msgstr "Your website is *not* reachable over HTTPS."
msgid "detail web tls https-exists verdict good"
-msgstr "Your website is reachable on HTTPS."
+msgstr "Your website is reachable over HTTPS."
msgid "detail web tls https-exists verdict other"
msgstr "Your web server is unreachable."
msgid "detail web tls https-forced exp"
msgstr ""
-"We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP. \n"
+"We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 30x redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP. \n"
"\n"
"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:\n"
"\n"
-"* `http://example.nl` ⇒ `https://example.nl` ⇒ `https://www.example.nl`\n"
-"* `http://www.example.nl` ⇒ `https://www.example.nl`\n"
+"* `http://example.org` ⇒ `https://example.org` ⇒ `https://www.example.org`\n"
+"* `http://www.example.org` ⇒ `https://www.example.org`\n"
"\n"
"Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.\n"
"\n"
@@ -3473,31 +3666,27 @@ msgid "detail web tls https-hsts exp"
msgstr ""
"We check if your web server supports HSTS. \n"
"\n"
-"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.\n"
+"Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to Machine-in-the-Middle (MitM) attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.\n"
"\n"
-"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 of *at least* 1 year (`max-age=31536000`) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired. \n"
+"HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing MitM attacks. We consider a HSTS cache validity period of *at least* 1 year (`max-age=31536000`) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired. \n"
"\n"
"The test does **not** check whether `preload` is used and whether the domain is included in the [HSTS Preload List](https://hstspreload.org/).\n"
"\n"
"---\n"
+"\n"
"**Deployment recommendation**\n"
"\n"
"HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will *not be reachable* by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy. \n"
"\n"
"Therefore we advise you to follow the implementation steps below:\n"
"\n"
-"1․ Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);\n"
+"1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);\n"
"\n"
-"2․ Increase the HSTS cache validity period in the stages below. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.\n"
-"\n"
-"* Start with 5 minutes (`max-age=300`);\n"
-"* Increase it to 1 week (`max-age=604800`);\n"
-"* Increase it to 1 month (`max-age=2592000`);\n"
-"* Increase it to 1 year (`max-age=31536000`) or more.\n"
+"2. Increase the HSTS cache validity period in stages. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.\n"
" \n"
-"3․ Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use `includeSubDomains` if you are fully sure that **all** the (nested) subdomains of your domain properly support HTTPS now and in the future.\n"
+"3. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use `includeSubDomains` if you are fully sure that **all** the (nested) subdomains of your domain properly support HTTPS now and in the future.\n"
"\n"
-"4․ Use `preload` **only** if you are very sure that you want your domain to be included in the [HSTS Preload List](https://hstspreload.org/). HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.\n"
+"4. Use `preload` **only** if you are very sure that you want your domain to be included in the [HSTS Preload List](https://hstspreload.org/). HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.\n"
"\n"
"---\n"
"\n"
@@ -3524,26 +3713,32 @@ msgid "detail web tls kex-hash-func exp"
msgstr ""
"We check if your web server supports secure hash functions to create the digital signature during key exchange.\n"
"\n"
-"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. \n"
+"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.\n"
+"\n"
+"Note that this subtest is only relevant for TLS 1.2. The supported hash functions can be configured via a separate TLS setting (e.g. `SignatureAlgorithms` in OpenSSL) and are *not* part of the cipher suite configuration. \n"
"\n"
-"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL, parargaph 3.3.5. For more details on the status of SHA-1 and MD5, see [RFC 9155](https://www.rfc-editor.org/rfc/rfc9155.html#name-server-key-exchange). We do not test for MD5 because it is only supported by very outdated software.\n"
+"For more details on the status of SHA-1 and MD5, see [RFC 9155](https://www.rfc-editor.org/rfc/rfc9155.html#name-server-key-exchange). We do not test for MD5 because it is only supported by very outdated software.\n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.5. \n"
"\n"
"---\n"
"\n"
"**Security level of hash functions for key exchange**\n"
"\n"
"* Good: SHA-256, SHA-384, SHA-512\n"
-"* Phase out: SHA-224\n"
+"* Phase out: SHA-224 (rarely used)\n"
"* Insufficient: SHA-1, MD5"
msgid "detail web tls kex-hash-func label"
msgstr "Hash function for key exchange"
msgid "detail web tls kex-hash-func tech table"
-msgstr "Web server IP address|Outdated signature algorithm result"
+msgstr "Web server IP address|Outdated hash function"
msgid "detail web tls kex-hash-func verdict bad"
msgstr ""
+"Your web server supports one or more *insufficiently* secure hash functions "
+"for key exchange."
msgid "detail web tls kex-hash-func verdict good"
msgstr "Your web server only supports secure hash functions for key exchange."
@@ -3557,9 +3752,9 @@ msgstr ""
msgid "detail web tls kex-hash-func verdict phase-out"
msgstr ""
-"Your web server supports a hash function for key exchange that you should "
-"*phase out* deliberately, because it is at risk of becoming *insufficiently*"
-" secure in the future."
+"Your web server supports a hash function for key exchange that should be "
+"*phased out* as it is weaker, although you might still use it if absolutely "
+"needed. In a future update, it will likely become insufficient."
msgid "detail web tls kex-hash-func verdict {phase-out}"
msgstr ""
@@ -3587,23 +3782,26 @@ msgstr ""
msgid "detail web tls ocsp-stapling exp"
msgstr ""
"We check if your web server supports the [TLS Certificate Status extension](https://www.rfc-editor.org/rfc/rfc6961) \n"
-"also known as OCSP stapling. \n"
+"(also known as OCSP stapling), in case the certificate on your webserver has a pointer to an OCSP server. \n"
"\n"
-"The web browser can verify the validity of the certificate presented by the web server by contacting the certificate authority using the OCSP protocol. OCSP provides a certificate authority with information on browsers communicating to the web server: this may be a privacy risk. A web server can also provide OCSP responses to web browsers itself through OCSP stapling. This solves this privacy risk, does not require connectivity between web browser and certificate authority, and is faster. \n"
+"Note that we do not use the OCSP data to evaluate the validity of the certificate. Furthermore, note that OCSP has been deprecated by several certificate authorities. In case your website certificate does not have a pointer to an OCSP server, this subtest will pass.\n"
"\n"
-"When connecting to your web server we use the TLS Certificate Status extension to request OCSP data be included in the server response. If your web server includes OCSP data in the response we then verify that the OCSP data is valid i.e. correctly signed by a known certificate authority. Note: we do not use the OCSP data to evaluate the validity of the certificate.\n"
+"The web browser can verify the validity of the certificate presented by the web server by contacting the certificate authority using the OCSP protocol. OCSP provides a certificate authority with information on browsers communicating to the web server. This may be a privacy risk. A web server can also provide OCSP data to a web browser directly through OCSP stapling. This solves this privacy risk, does not require connectivity between web browser and certificate authority, and is faster. \n"
"\n"
-"See \n"
-"['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, table 15 (in English).\n"
+"When connecting to your web server we use the TLS Certificate Status extension to request OCSP data be included in the server response. If your web server includes OCSP data in the response we then verify that the OCSP data is valid i.e. correctly signed by a known certificate authority. \n"
+"\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL, paragraph 3.4.5.\n"
"\n"
"*Requirement level: Optional*\n"
"\n"
"---\n"
"\n"
-"**OCSP stapling**\n"
+"**Security level of OCSP stapling**\n"
"\n"
-"* Good: On\n"
-"* Sufficient: Off"
+"* Good: Certificate without OCSP pointer\n"
+"* Good: Certificate with OCSP pointer, stapling enabled, and valid OCSP data\n"
+"* Insufficient: Certificate with OCSP pointer, stapling enabled, but no valid OCSP data \n"
+"* Informational: Certificate with OCSP pointer, but no stapling enabled"
msgid "detail web tls ocsp-stapling label"
msgstr "OCSP stapling"
@@ -3623,9 +3821,13 @@ msgstr ""
msgid "detail web tls ocsp-stapling verdict not-in-cert"
msgstr ""
+"Your website certificate does not have an OCSP pointer, so OCSP stapling "
+"does not apply."
msgid "detail web tls ocsp-stapling verdict ok"
-msgstr "Your web server does *not* support OCSP stapling."
+msgstr ""
+"Your web server does *not* support OCSP stapling, although your website "
+"certificate has an OCSP pointer."
msgid "detail web tls renegotiation-client exp"
msgstr ""
@@ -3637,7 +3839,7 @@ msgstr ""
"\n"
"Note that client-initiated renegotiation could impact availability, but not confidentiality. \n"
"\n"
-"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL, parargaph 3.4.2.\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.2.\n"
"\n"
"*Requirement level: Recommended*\n"
"\n"
@@ -3645,10 +3847,10 @@ msgstr ""
"\n"
"**Security level of client-initiated renegotiation**\n"
"\n"
-"* Good: No, N/A (TLS 1.3)\n"
-"* Good: No, not allowed (TLS 1.2)\n"
-"* Sufficient: Limited (TLS 1.2)\n"
-"* Phase out: Unlimited (TLS 1.2)"
+"* Good: N/A (TLS 1.3)\n"
+"* Good: No renegotiation (TLS 1.2)\n"
+"* Sufficient: Limited renegotiation (TLS 1.2)\n"
+"* Phase out: Unlimited renegotiation (TLS 1.2)"
msgid "detail web tls renegotiation-client label"
msgstr "Client-initiated renegotiation"
@@ -3684,13 +3886,15 @@ msgstr ""
"\n"
"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.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B8-1 and table 12 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.2.\n"
"\n"
"---\n"
-"**Insecure renegotiation**\n"
"\n"
-"* Good: Off (or N/A for TLS 1.3)\n"
-"* Insufficient: On"
+"**Security level of insecure renegotiation**\n"
+"\n"
+"* Good: N/A (TLS 1.3)\n"
+"* Good: No insecure renegotiation (TLS 1.2)\n"
+"* Insufficient: Insecure renegotiation (TLS 1.2)"
msgid "detail web tls renegotiation-secure label"
msgstr "Secure renegotiation"
@@ -3714,9 +3918,10 @@ msgstr ""
"\n"
"Please note that modern browsers no longer support TLS 1.0/1.1 and SSL. As a result, websites that do not support TLS 1.2 and/or 1.3 are unreachable for almost everyone.\n"
"\n"
-"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) from NCSC-NL, parargaph 3.3.1. \n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.3.1. \n"
"\n"
"---\n"
+"\n"
"**Security level of TLS versions**\n"
"\n"
"* Good: TLS 1.3\n"
@@ -3764,13 +3969,15 @@ msgstr ""
"non-[HTTP 425 Too Early](https://www.rfc-editor.org/rfc/rfc8470#section-5.2)\n"
"response, then the web server is considered to support 0-RTT.\n"
"\n"
-"See ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL, guideline B9-1 and table 14 (in English).\n"
+"See ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) from NCSC-NL, paragraph 3.4.4.\n"
"\n"
"---\n"
-"**0-RTT**\n"
"\n"
-"* Good: Off (or N/A prior to TLS 1.3)\n"
-"* Insufficient: On"
+"**Security level of 0-RTT**\n"
+"\n"
+"* Good: No 0-RTT (TLS 1.3)\n"
+"* Good: N/A (TLS 1.2)\n"
+"* Insufficient: Using 0-RTT (TLS 1.3)"
msgid "detail web tls zero-rtt label"
msgstr "0-RTT"
@@ -3786,13 +3993,14 @@ msgstr "Your web server does not support 0-RTT."
msgid "detail web tls zero-rtt verdict na"
msgstr ""
-"This subtest is not applicable as your web server does not support TLS 1.3."
+"This subtest is not applicable as 0-RTT is only available in TLS 1.3, which "
+"is not enabled on your web server."
msgid "detail web-mail ipv6 ns-AAAA exp"
msgstr ""
"We check if your domain name has at least two name servers with an IPv6 address. \n"
"\n"
-"This is consistent with the [\"Technical requirements for the registration and use of .nl domain names\"](https://www.sidn.nl/downloads/KwpW_ORWRWetYuoBp5GeYA/7e91faddb53ad85b8c6a2fce15d764cb/Technical_requirements_for_the_registration_and_use_of_nl_domain_names.pdf) d.d. 13 November 2017 by SIDN (.nl TLD registry) that require each .nl domain to have at least two name servers.\n"
+"This is consistent with the [\"Technical requirements for the registration and use of .nl domain names\"](https://www.sidn.nl/en/nl-domain-name/technical-requirements-for-the-registration-and-use-of-nl-domain-names) d.d. 1 January 2023 by SIDN (.nl TLD registry) that require each .nl domain to have at least two name servers.\n"
"\n"
"'IPv4-mapped IPv6 addresses' ([RFC 4291](https://www.rfc-editor.org/rfc/rfc4291), beginning with ::ffff:) will fail in this test, as they do *not* provide IPv6 connectivity."
@@ -4089,11 +4297,10 @@ msgstr "Batch API and web-based dashboard"
#, md-format
msgid "faqs content"
msgstr ""
-"## Tests\n"
-"* [About the website test](/test-site/)\n"
-"* [About the email test](/test-mail/)\n"
-"* [About the connection test](/test-connection/)\n"
-"\n"
+"## Background\n"
+"* About [website test](/test-site/), [email test](/test-mail/), and [connection test](/test-connection/)\n"
+"* [Video recordings of presentations](/faqs/video/)\n"
+" \n"
"## Standards\n"
"* [Modern address (IPv6)](/faqs/ipv6/)\n"
"* [Domain signature (DNSSEC)](/faqs/dnssec/)\n"
@@ -4169,7 +4376,7 @@ msgstr ""
"* **Order**: The names of the hosters in the Hall of Fame are shown in random order.\n"
"\n"
"## Automated compliance checks\n"
-"The [Internet.nl dashboard](https://dashboard.internet.nl) is used to regularly check if the hosters listed in the Hall of Fame for Hosters are still on a double 100% score (mail and web) for the own domain. This is an automated check and will be performed twice per month. The [test reports for the listed hosters](https://dashboard.internet.nl/#/published/103/) are publicly available.\n"
+"The [Internet.nl dashboard](https://dashboard.internet.nl) is used to regularly check if the hosters listed in the Hall of Fame for Hosters are still on a double 100% score (mail and web) for the own domain. This is an automated check and will be performed twice per month. The [test reports for the listed hosters](https://dashboard.internet.nl/published/103/) are publicly available.\n"
"\n"
"## Delisting \n"
"Non-compliant hosters will be manually delisted based on the following criteria and rules:\n"
@@ -4191,7 +4398,7 @@ msgstr ""
"## Why\n"
"* [Does my site need HTTPS?](https://doesmysiteneedhttps.com/)\n"
"* [\"Why HTTPS for Everything?\"](https://https.cio.gov/everything/) by CIO.gov\n"
-"* [\"Still think you don't need HTTPS?\"](https://scotthelme.co.uk/still-think-you-dont-need-https/)by Scott Helme\n"
+"* [\"Still think you don't need HTTPS?\"](https://scotthelme.co.uk/still-think-you-dont-need-https/) by Scott Helme\n"
"\n"
"## Usage statistics\n"
"* [.nl statistics on HTTPS](https://stats.sidnlabs.nl/nl/) by SIDN Labs\n"
@@ -4200,18 +4407,18 @@ msgstr ""
"* [Pulse - TLS1.3 metric](https://pulse.internetsociety.org/en/technologies/#metric-tls13) by Internet Society\n"
"\n"
"## Background information\n"
-"* [\"IT Security Guidelines for Transport Layer Security (TLS), v2.1\"](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) by NCSC-NL\n"
-"* [\"ICT security guidelines for web applications\"](https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties) by NCSC-NL (in Dutch)\n"
+"* ['Transport Layer Security (TLS), Security guidelines version 2025-05'](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05) by NCSC-NL\n"
+"* ['ICT security guidelines for web applications'](https://www.ncsc.nl/webapplicaties/ict-beveiligingsrichtlijnen-webapplicaties) by NCSC-NL (in Dutch)\n"
"* [Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/)\n"
"* [Bettercrypto.org](https://bettercrypto.org)\n"
"* [How HTTPS works](https://howhttps.works/)\n"
"\n"
"## Specifications\n"
"### HTTPS\n"
-"* [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110)\n"
+"* [RFC 9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc9325.html)\n"
+"* [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://www.rfc-editor.org/rfc/rfc8996.html)\n"
"* [RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446)\n"
"* [RFC 5246: The Transport Layer Security (TLS) Protocol, Version 1.2](https://www.rfc-editor.org/rfc/rfc5246)\n"
-"* [RFC 9325:Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc9325.html)\n"
"* [RFC 6797: HTTP Strict Transport Security (HSTS)](https://www.rfc-editor.org/rfc/rfc6797)\n"
"\n"
"### CAA\n"
@@ -4232,7 +4439,6 @@ msgid "faqs ipv6 content"
msgstr ""
"## Why\n"
"* [\"Three reasons why IPv6 is worth the effort\"](https://blog.apnic.net/2018/12/13/three-reasons-why-ipv6-is-worth-the-effort/) by Nick Buraglio\n"
-"* [\"Making a Strong Case for IPv6\"](https://www.baselinemag.com/networking/making-a-strong-case-for-ipv6/) by John Curran (ARIN)\n"
"* [\"IPv6: It's time to get on board\"](https://engineering.fb.com/networking-traffic/ipv6-it-s-time-to-get-on-board/) by Paul Saab (Facebook)\n"
"* [\"Reasons for IPv6\"](https://ipv6now.com.au/primers/IPv6Reasons.php) by IPv6NOW\n"
"\n"
@@ -4293,7 +4499,7 @@ msgstr ""
"The [batch API and web-based dashboard](/faqs/batch-and-dashboard/) are used by hundreds of users. Some organisations re-use the test results in their own public websites or reports. Below are some examples.\n"
"\n"
"- [Basisbeveiliging](https://basisbeveiliging.nl/)\n"
-"- [CBS: Application of Internet Standards for Business Web Sites](https://www.cbs.nl/nl-nl/longread/aanvullende-statistische-diensten/2024/toepassing-van-internetstandaarden-voor-websites-van-bedrijven-2023) [in Dutch]\n"
+"- [CBS: Application of Internet Standards for Business Web Sites](https://www.cbs.nl/nl-nl/longread/aanvullende-statistische-diensten/2025/toepassing-van-internetstandaarden-voor-websites-van-bedrijven-2024) [in Dutch]\n"
"- [Digital Insights Platform](https://www.digitalinsightsplatform.nl/)\n"
"- [European Commission: EU Internet Standards Deployment Monitoring Website](https://ec.europa.eu/internet-standards/)\n"
"- [Netherlands Standardisation Forum: Measurement of Information Security Standards](https://www.forumstandaardisatie.nl/metingen/informatieveiligheidstandaarden) [in Dutch]\n"
@@ -4416,6 +4622,7 @@ msgstr ""
"* [Route Origin Authorisation (ROA) statistics](https://roa-stats.manrs.org/) by MANRS\n"
"* [.nl statistics for Route Origin Authorisation (ROA)](https://stats.sidnlabs.nl/en/web.html#secure%20routing%20(rpki)) by SIDN Labs\n"
"* [Route Origin Validation (ROV) statistics](https://stats.labs.apnic.net/rpki) by APNIC\n"
+"* [RIPEstat - RPKI by country](https://stat.ripe.net/resource/nl#tab=routing) by RIPE NCC\n"
"\n"
"## Background information\n"
"* [RPKI Documentation](https://rpki.readthedocs.io) by the RPKI team at NLnet Labs and the RPKI community\n"
@@ -4463,6 +4670,17 @@ msgstr "Secure email transport (STARTTLS and DANE)"
msgid "faqs title"
msgstr "Knowledge base"
+msgid "faqs video content"
+msgstr ""
+"* [Benjamin @ FOSDEM2026](https://fosdem.org/2026/schedule/event/H9GEBT-fos-check-tooling-for-mail-config/) (2026-01-31)\n"
+"* [Sasha @ NLNOG Day 2025](https://nlnog.net/events/past-events/nlnog-day-2025/) (2025-09-30)\n"
+"* [Gerben and Bart @ IX Fórum Setor Público 2025](https://setorpublico.forum.ix.br/anteriores/2025/) (2025-09-17)\n"
+"* [Benjamin @ WHY2025](https://media.ccc.de/v/why2025-258-how-not-to-configure-your-domainname-internet-nl) (2025-08-11)\n"
+"* [Benjamin @ RIPE86](https://ripe86.ripe.net/archives/video/1028/) (2023-05-24)"
+
+msgid "faqs video title"
+msgstr "## Video recordings of presentations"
+
#, md-format
msgid "halloffame champions menu"
msgstr "Champions!"
@@ -4615,7 +4833,7 @@ msgid "privacy content"
msgstr ""
"# Privacy statement\n"
"\n"
-"*Revised 28th of January 2025*\n"
+"*Revised 25th of March 2025*\n"
"\n"
"The Dutch Internet Standards Platform respects your privacy and strives to minimize the collection and processing of your personal data. With this privacy statement, we would like to inform you about what personal data we collect when you use our website and other services on Internet.nl and how we process this data. Your rights are covered by the applicable laws, mainly the [European General Data Protection Regulation (GDPR)](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679) and the [Dutch Telecommunications Act](https://wetten.overheid.nl/BWBR0009950/).\n"
"\n"
@@ -4634,7 +4852,7 @@ msgstr ""
"- Domain names that you provided to perform email or website tests:\n"
"\n"
" \t- Domain names are stored in the application database. They will be shown in the test reports available for the user via a permalink and could be shown in the Hall of Fame.\n"
-"\t- Only the domain name is stored, but *not* the 'local-part' (i.e. the part before @example.nl) of a provided email address.\n"
+"\t- Only the domain name is stored, but *not* the 'local-part' (i.e. the part before @example.org) of a provided email address.\n"
"\n"
"#### Server logs\n"
" For debugging connection issues and for solving (security) incidents we keep the below data in our web server logs.\n"
@@ -4692,9 +4910,6 @@ msgstr ""
"### Sentry\n"
"We use [Sentry](https://sentry.io/) to log crashes and similar bugs in tests and pages. For this, we may send Sentry the domain being tested, any information collected in the test, and the HTTP headers of the request. We do not include the IP address of your client in the information we send to Sentry. Information is only submitted on test or page crashes. No information is shared about performed tests or requested pages that do not result in crashes.\n"
"\n"
-"### Public DNS resolvers\n"
-"The [Internet.nl dashboard](https://dashboard.internet.nl) checks whether a given domain name returns valid DNS responses and is testable using the following public DNS resolvers: [CZ.NIC](https://www.nic.cz/page/4219/kopie-otevrene-dnssec-validujici-resolvery/), [Quad9](https://www.quad9.net/) and [dns0.eu](https://www.dns0.eu/).\n"
-"\n"
"## What measures are in place to secure the collected data?\n"
"\n"
"### Access and third parties\n"
@@ -4803,10 +5018,14 @@ msgid "results further-testing connection content"
msgstr ""
"- ### IPv6:\n"
" - [IPv6 test](https://ipv6-test.com/)\n"
+"\n"
"- ### DNSSEC validation:\n"
-" - [DNSSEC resolver algorithm test](https://rootcanary.org/test.html) \n"
+" - [DNSSEC resolver algorithm test](https://rootcanary.org/test.html)\n"
+" - [Check My DNS](https://cmdns.dev.dns-oarc.net/)\n"
+"\n"
"- ### HTTPS:\n"
" - [SSL Client Test](https://www.ssllabs.com/ssltest/viewMyClient.html)\n"
+"\n"
"- ### RPKI validation\n"
" - [RPKI Webtest](https://rpkitest.nlnetlabs.net/)\n"
" - [Is BGP safe yet?](https://isbgpsafeyet.com/)"
diff --git a/translations/en/manual_hof.po b/translations/en/manual_hof.po
index 43b1eff00..81979b5b6 100644
--- a/translations/en/manual_hof.po
+++ b/translations/en/manual_hof.po
@@ -17,7 +17,7 @@ msgstr ""
"\n"
"These hosters are allowed to use the 'Internet.nl compliant badge' that is shown on this page in their own communications.\n"
"\n"
-"The scores of the listed hosters' own domains are automatically [checked and published](https://dashboard.internet.nl/#/published/103/). \n"
+"The scores of the listed hosters' own domains are automatically [checked and published](https://dashboard.internet.nl/published/103/). \n"
"\n"
"---"
diff --git a/translations/en/news.po b/translations/en/news.po
index d848b56ce..f17d3328e 100644
--- a/translations/en/news.po
+++ b/translations/en/news.po
@@ -4,6 +4,7 @@ msgstr ""
msgid "article .index"
msgstr ""
+"release-1.11\n"
"punktum-dk-contribution\n"
"release-1.10\n"
"release-1.9\n"
@@ -30,7 +31,7 @@ msgstr ""
msgid "article UA-day-2023 body"
msgstr ""
-"UA regards new TLDs (for example, those with more than 2 or 3 characters such as .amsterdam), as well as domain names and email addresses with non-latin characters (such as `straße.de`, `example.ελ` or `überhaupt@example.nl`).\n"
+"UA regards new TLDs (for example, those with more than 2 or 3 characters such as .amsterdam), as well as domain names and email addresses with non-latin characters (such as `straße.de`, `example.ελ` or `überhaupt@example.org`).\n"
"\n"
"On March 28 the Dutch Internet Standards Platform is organising an open dialogue meeting on UA with participants from ICANN, SIDN, and the Dutch National Office for Identity Data (RvIG), among others. The goal is to gain a better understanding of the issues, as well as possible solutions and actions.\n"
"\n"
@@ -306,7 +307,7 @@ msgstr ""
"* The detection of the internet provider is more precise and timeouts occur less frequent.\n"
"\n"
"## Website test\n"
-"* The test checks whether a HSTS-policy is available. Through HSTS a web browser will 'know' after the first visit that a website can only be accessed through a secure connection (HTTPS, not HTTP). This can prevent so-called man-in-the-middle attacks, e.g. when using public Wi-Fi. In case of deviations, the message is no longer 'orange' but 'red'.\n"
+"* The test checks whether a HSTS-policy is available. Through HSTS a web browser will 'know' after the first visit that a website can only be accessed through a secure connection (HTTPS, not HTTP). This can prevent so-called Machine-in-the-Middle (MitM) attacks, e.g. when using public Wi-Fi. In case of deviations, the message is no longer 'orange' but 'red'.\n"
"* The test now checks whether the website enforces HTTPS by using a server redirect (301 or 302) or by applying only HTTPS (and no HTTP). In case of deviations, the message is no longer 'orange' but 'red'.\n"
"* In the case of some websites, the TLS results incorrectly showed that 'client-initiated renegotiation' was allowed. This has been solved.\n"
"* In the test results of websites with a redirect from IPv6/IPv4 to IPv4-only, the HSTS-policy over IPv6 remained incorrectly undetected. This has been solved.\n"
@@ -451,7 +452,7 @@ msgstr ""
"* Non-receiving domain: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use [Null MX](https://www.rfc-editor.org/rfc/rfc7505). In case your domain does *not* have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even *not* an Null MX record). \n"
"\n"
"## Minimum max-age for HSTS extended\n"
-"HTTP Strict Transport Security ([HSTS](https://www.rfc-editor.org/rfc/rfc6797)) forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We have decided to extend the mimimum HSTS cache validity period from 6 months to 1 year (`max-age=31536000`). This is in conformance with the common good practice. \n"
+"HTTP Strict Transport Security ([HSTS](https://www.rfc-editor.org/rfc/rfc6797)) forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing Machine-in-the-Middle (MitM) attacks. We have decided to extend the mimimum HSTS cache validity period from 6 months to 1 year (`max-age=31536000`). This is in conformance with the common good practice. \n"
"\n"
"Further details on the above improvements can be found in the test explanations of the relevant subtests of the [website test](/test-site/) and the [email test](/test-mail/). \n"
"\n"
@@ -526,10 +527,10 @@ msgstr ""
"Below we describe the major changes.\n"
"\n"
"* The previous version of Internet.nl did test the **security of the HTTPS configuration over either IPv6 or IPv4**. Through manual testing we regularly see websites that have unintended different HTTPS configurations over IPv6 and IPv4. Therefore in the new release the HTTPS configuration is tested over both IPv6 and IPv4. **From now on** the result of this test item is part of the overall score in the website test.\n"
-"* The website tests checks whether a **HSTS policy** is published. Through HSTS a web browser gets informed after the first usage that a website only may be visited over HTTPS. This can prevent so-called man-in-the-middle attacks (for example when a public Wi-Fi hotspot is used). The result of this test item is displayed as an orange warning in case the HSTS policy is absent. As of **July 2016** the result will be part of the score in the website test.\n"
+"* The website tests checks whether a **HSTS policy** is published. Through HSTS a web browser gets informed after the first usage that a website only may be visited over HTTPS. This can prevent so-called Machine-in-the-Middle (MitM) attacks (for example when a public Wi-Fi hotspot is used). The result of this test item is displayed as an orange warning in case the HSTS policy is absent. As of **July 2016** the result will be part of the score in the website test.\n"
"* The website test does test whether **HTTPS is enforced** for a website. There are two ways to enforce HTTPS that are described below.The result of this test item is displayed as an orange warning in case the HSTS policy is absent. As of **July 2016** the result will be part of the score in the website test.\n"
-" 1. By redirecting HTTP to HTTPS. This can be done by redirecting `http://example.nl` to `https://example.nl`. It is important that both domain names are identical because a web browser does only accept a HSTS policy for a certain domain when a HTTPS connection is used. If `http://example.nl` redirects to `https://www.example.nl` then a HSTS policy normally will not be used by the browser, unless a user explicitly enters `https://example.nl` or clicks on a hyperlink with this URL.\n"
-" 2. By only supporting HTTPS and no HTTP. Because a browser normally uses a HTTP-connection after a user enters a domain name, users should enter `https://example.nl` to reach the website or click on a hyperlink with this URL.\n"
+" 1. By redirecting HTTP to HTTPS. This can be done by redirecting `http://example.org` to `https://example.org`. It is important that both domain names are identical because a web browser does only accept a HSTS policy for a certain domain when a HTTPS connection is used. If `http://example.org` redirects to `https://www.example.org` then a HSTS policy normally will not be used by the browser, unless a user explicitly enters `https://example.org` or clicks on a hyperlink with this URL.\n"
+" 2. By only supporting HTTPS and no HTTP. Because a browser normally uses a HTTP-connection after a user enters a domain name, users should enter `https://example.org` to reach the website or click on a hyperlink with this URL.\n"
"* The website test does check whether **HTTP compression** is used. Enabling HTTP compression does make many websites vulnerable for BREACH when no other mitigating measures are in place. Switching off HTTP compression could negatively impact performance. In case HTTP compression is detected an **orange warning** is displayed.\n"
"* The website test of the previous version of Internet.nl already checked whether the **content of a website was similar over IPv6 and IPv4**. The test took into account legitimate differences for example caused by different add banners. The result of this test item **from now on** is part of the overall score in the website test. \n"
"* If a user does enter a **non-existing domain name** a red error message is displayed.\n"
@@ -803,6 +804,100 @@ msgstr ""
msgid "article release-1.10 title"
msgstr "Internet.nl adds CAA test and announces TLS test changes"
+msgid "article release-1.11 body"
+msgstr ""
+"## What is TLS?\n"
+"\n"
+"## Why is securely configured TLS important?\n"
+"\n"
+"## NCSC's latest TLS guidelines\n"
+"\n"
+"## Other improvements in this release\n"
+"\n"
+"## Roadmap next release\n"
+"\n"
+"## About Internet.nl\n"
+"The test tool [Internet.nl](https://internet.nl) is an initiative of the Dutch Internet Standards Platform which is a collaboration of partners from the Internet community and the Dutch government. The aim of the platform is to jointly increase the use of modern Internet standards to make the Internet more accessible, safer and more reliable for everyone. The software code of Internet.nl is available under an open source license. \n"
+"\n"
+"---\n"
+"\n"
+"## Release notes 1.11\n"
+"\n"
+"### TLS updates for NCSC 2025 guidelines\n"
+"\n"
+"All tests were updated to match the\n"
+"[2025-05 version of the NCSC TLS guidelines](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05).\n"
+"Most significant changes:\n"
+"\n"
+"- The list of good/sufficient/phase out/insufficient TLS versions, TLS authentication, curves, hashes, \n"
+" key exchange algorithms, FFDHE groups, RSA key lengths, and bulk encryption algorithms were updated\n"
+" to match the new guidelines.\n"
+"- A test for Extended Master Secret (RFC7627) was added.\n"
+"- Client-initiated renegotiation is now acceptable, if limited to less than 10 renegotiations.\n"
+"- All checks on certificates apply to all certificates sent by the server,\n"
+" except root certificates (according to our trust store). In previous versions,\n"
+" the certificate selection was different per test.\n"
+"\n"
+"### Other TLS updates\n"
+"\n"
+"- Certificates that do not have OCSP enabled, which means stapling is not possible,\n"
+" [are now detected as such](https://github.com/internetstandards/Internet.nl/issues/1641).\n"
+" Several issues with OCSP stapling reliability were also resolved.\n"
+"- Issues were fixed where the cipher order failed to detect some bad scenarios,\n"
+" including some where servers preferred RSA over ECDHE, or CBC over POLY1305.\n"
+"- CCM_8 ciphers are now detected when enabled on a server.\n"
+"- OLD ciphers are no longer detected.\n"
+"- The cipher order test no longer separates between \"the server cipher order preference is wrong\" \n"
+" and \"the server has no preference\".\n"
+"\n"
+"### Significant internal changes\n"
+"\n"
+"- Upgraded to Django 5, Python 3.13, and Debian Trixie base image.\n"
+"- Switched TLS implementation to sslyze/nassl based reimplementation.\n"
+"- Switched to pyproject/uv.lock for project dependencies, replacing requirements files.\n"
+"- Added post-quantum hybrid ECDHE-MLKEM for TLS 1.3 in our web server.\n"
+"- Outgoing traffic now uses the configured public IPv4/IPv6 addresses.\n"
+"- Routinator can now be configured with an allowlist for shared instances.\n"
+"\n"
+"### Bug fixes\n"
+"\n"
+"- Fixed [simhash exception when both address families fail](https://github.com/internetstandards/Internet.nl/issues/1893).\n"
+"- Fixed JSON serialization of sets in batch results.\n"
+"- Fixed [report generation locking](https://github.com/internetstandards/Internet.nl/issues/1749) for results views.\n"
+"\n"
+"### API changes\n"
+"\n"
+"This release has API version 2.7.0.\n"
+"\n"
+"The changes noted above are reflected in the API as well, e.g. which ciphers\n"
+"are considered bad, as listed in the API output, along with score impacts.\n"
+"\n"
+"Additionally, the API structure changes are:\n"
+"- OCSP stapling has a new status `not_in_cert` (not_tested), for when a certificate does not have\n"
+" OCSP enabled, therefore stapling is neither required nor possible.\n"
+"- The cipher order status no longer returns `not_prescribed` or `not_seclevel` for new tests.\n"
+" The insufficient status is now `bad` (failed) for preferring phase out over good and/or sufficient,\n"
+" regardless of the reason (server not enforcing any preference or server enforcing wrong preference).\n"
+"- `cert_signature_phase_out` was added to the TLS details, listing certificate signature algorithms\n"
+" that are at phase-out level (warning). Analogous to the existing `cert_signature_bad`.\n"
+"- `extended_master_secret` was added to the TLS details, with values: `supported` (good),\n"
+" `not_supported` (failed), `na_no_tls_1_2` (good), `unknown` (not_tested).\n"
+"- `client_reneg` in the TLS details was changed from a boolean to a string enum with values:\n"
+" `not_allowed` (good), `allowed_with_low_limit` (info), `allowed_with_too_high_limit` (failed)."
+
+msgid "article release-1.11 date"
+msgstr "April 21, 2026"
+
+msgid "article release-1.11 lead"
+msgstr ""
+"As of today, you can use Internet.nl to check whether the secure connection "
+"for your website or email is compliant with the latest TLS guidelines from "
+"NCSC-NL. This means that websites and email servers that previously passed "
+"the test may now still have areas for improvement."
+
+msgid "article release-1.11 title"
+msgstr "Fully updated TLS test in new version of Internet.nl"
+
msgid "article release-1.7 body"
msgstr ""
"## Improved CSP test\n"
diff --git a/translations/nl/main.po b/translations/nl/main.po
index 96f49682a..03dcb506e 100644
--- a/translations/nl/main.po
+++ b/translations/nl/main.po
@@ -9,7 +9,7 @@ msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2015-02-16 23:27+0100\n"
-"PO-Revision-Date: 2026-03-10 11:05:33.137682\n"
+"PO-Revision-Date: 2026-04-15 14:31:13.372274\n"
"Last-Translator: \n"
"Language-Team: \n"
"Language: \n"
@@ -67,7 +67,7 @@ msgstr ""
"In 2023 heeft [SIDN fonds](https://www.sidnfonds.nl/) het project om de Internet.nl-applicatie te containeriseren financieel ondersteund met als doel om de installatie ervan te vereenvoudigen en verdere groei van het aantal tests mogelijk te maken.\n"
"\n"
"## Practice what you preach?\n"
-"We testen periodiek de domeinnamen van de leden van het Platform Internetstandaarden. De [test-rapporten](https://dashboard.internet.nl/#/published/103/) zijn openbaar.\n"
+"We testen periodiek de domeinnamen van de leden van het Platform Internetstandaarden. De [test-rapporten](https://dashboard.internet.nl/published/103/) zijn openbaar.\n"
"\n"
"## Wat zijn Internetstandaarden?\n"
"Om wereldwijd gegevens tussen verschillende computers te kunnen uitwisselen, zijn internationale afspraken nodig over de manier waarop de computers met elkaar praten. Zeg maar de digitale \"stekkers en stopcontacten\" die alles met elkaar verbinden. Deze afspraken noemen we Internetstandaarden of -protocollen. Een voorbeeld is SMTP, een bekend protocol voor het versturen van e-mail. Deze technische kern van internet is voor de meeste gebruikers onzichtbaar en onbekend, maar cruciaal voor de werking van internet vandaag en in de toekomst.\n"
@@ -303,6 +303,11 @@ msgstr ""
"### Donaties\n"
"Om de (open source) projecten waar we op voortbouwen te bedanken en te ondersteunen, geven we hen regelmatig donaties.\n"
"\n"
+"#### 2025\n"
+"- Django Software Foundation: USD 1719,94\n"
+"- Mastodon gGmbH: EUR 1500\n"
+"- Zammad Foundation: EUR 1500\n"
+"\n"
"#### 2024\n"
"- Celery: USD 1500\n"
"- Mastodon.nl (Stichting ActivityClub): EUR 1500\n"
@@ -330,6 +335,8 @@ msgstr ""
"\n"
"- [top.nic.br](https://top.nic.br/) (Brazilië)\n"
"- [sikkerpånettet.dk](https://xn--sikkerpnettet-vfb.dk/) (Denemarken)\n"
+"- [internet.bzh](https://internet.bzh) (Frankrijk)\n"
+"- [internet-standards.de](https://internet-standards.de) (Duitsland)\n"
"\n"
"### Naamsvermelding bij hergebruik\n"
"Als je de broncode en/of testresultaten van Internet.nl hergebruikt in je eigen website of dienst, dan vragen wij je vriendelijk om naamsvermelding. Je kan daarvoor bijvoorbeeld de volgende tekst gebruiken en op een duidelijke plaats weergeven.\n"
@@ -539,7 +546,7 @@ msgstr ""
"\n"
" example.nl. TXT \"v=spf1 -all\"\n"
" *.example.nl. TXT \"v=spf1 -all\"\n"
-" _dmarc.example.nl. TXT \"v=DMARC1; p=reject;\"\n"
+" _dmarc.example.nl. TXT \"v=DMARC1; p=reject\"\n"
"\n"
" \n"
"\n"
@@ -551,7 +558,7 @@ msgstr ""
" example.nl. TXT \"v=spf1 -all\"\n"
" *.example.nl. TXT \"v=spf1 -all\"\n"
" www.example.nl. CNAME example.nl\n"
-" _dmarc.example.nl. TXT \"v=DMARC1; p=reject;\""
+" _dmarc.example.nl. TXT \"v=DMARC1; p=reject\""
msgid "detail mail auth dmarc-policy label"
msgstr "DMARC policy"
@@ -1132,7 +1139,7 @@ msgstr ""
"Een certificaatautoriteit mag geen certificaat uitgeven, tenzij de certificaatautoriteit vaststelt dat de certificaataanvraag consistent is met de toepasselijke CAA-records.\n"
"\n"
"Merk op dat CAA-records tijdens de validatie worden gevonden door omhoog te lopen in de DNS-hiërarchie totdat een of meer records worden gevonden.\n"
-"Als er bijvoorbeeld geen CAA-records worden gevonden op `sub.example.nl`, wordt `example.nl` bevraagd.\n"
+"Als er bijvoorbeeld geen CAA-records worden gevonden op `sub.example.org`, wordt `example.org` bevraagd.\n"
"Het domein waar de betreffende CAA-records zijn gevonden, staat in de tabel met technische details hieronder.\n"
"\n"
"Het oordeel is goed als er één of meer CAA-records zijn gevonden die allemaal een correcte syntaxis hebben en ten minste één van deze CAA-records de tag `issue` met geldige waarde heeft. Anders resulteert de test in een onvoldoende. Er wordt niet gecontroleerd of de certificaatautoriteit van het huidige certificaat overeenkomt met een of meer van de `issue` en `issuewild` waarden, oftewel of het huidige certificaat op dit moment opnieuw uitgegeven zou kunnen worden.\n"
@@ -1148,7 +1155,7 @@ msgid "detail mail tls caa label"
msgstr "CAA voor mailserver"
msgid "detail mail tls caa tech table"
-msgstr "Mail server|Findings"
+msgstr "Mailserver|Bevindingen"
msgid "detail mail tls caa verdict bad"
msgstr "Je mailserver heeft *geen* CAA."
@@ -1171,7 +1178,7 @@ msgstr ""
"\n"
"Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE. Een certificaat met domeinnaam die overeenkomt met de domeinnaam van je mailserver is alleen vereist als je gebruik maakt van DANE 'trust anchor assertion' (DANE-TA, 2).\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B3-1.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 4.4.\n"
"\n"
"*Niveau van vereistheid: Optioneel / Vereist (alleen als DANE-TA wordt gebruikt)*"
@@ -1193,81 +1200,132 @@ msgstr ""
msgid "detail mail tls cert-pubkey exp"
msgstr ""
-"We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.\n"
+"We testen of de publieke sleutel van je mailserver-certificaat en van ieder tussenliggend certificaat is gebaseerd op een veilig ondertekeningsalgoritme met veilige parameters. \n"
+"\n"
+"Bij de verificatie van certificaten wordt gebruikgemaakt van digitale handtekeningen. De publieke sleutel van een certificaat kan worden gebruikt om te verifiëren dat een handtekening is aangemaakt met behulp van de bijbehorende privésleutel.\n"
"\n"
-"Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbinding\n"
-"te garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.\n"
+"**Ondertekeningsalgoritme:**\n"
+"Het ondertekeningsalgoritme wordt bepaald bij het genereren van het certificaat. Een certificaat kan slechts één ondertekeningsalgoritme bevatten. Het is mogelijk om meer dan één algoritme te ondersteunen door meerdere certificaten op één server te configureren. Alleen de ondertekeningsalgoritmen ECDSA, RSA en EdDSA worden als voldoende veilig beschouwd. EdDSA wordt in de praktijk zelden of nooit gebruikt. Alle algoritmes zijn kwetsbaar voor de quantumdreiging. Zij bieden vooralsnog voldoende bescherming. Quantumveilige alternatieven zijn nog geen onderdeel van de TLS-standaarden.\n"
"\n"
-"Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.\n"
+"**Parameters:** De veiligheid van digitale handtekeningen met ECDSA en EdDSA is afhankelijk van de geselecteerde kromme. De veiligheid van RSA houdt verband met de sleutellengte van de publieke sleutel.\n"
"\n"
-"De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.\n"
+"Voor meer informatie over de relevante veldnaam in het certificaat, zie paragraaf [\"4.1.2.7. Subject Public Key Info\" van RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.7).\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.2. \n"
"\n"
"---\n"
-"**Elliptische krommen voor ECDSA**\n"
"\n"
-"* Goed: `secp384r1`, `secp256r1`, `x448`, and `x25519`\n"
-"* Uit te faseren: `secp224r1`\n"
-"* Onvoldoende: Andere krommen\n"
+"**Beveiligingsniveau van elliptische krommen voor ECDSA**\n"
+"\n"
+"* Voldoende:\n"
+" \n"
+" * `secp521r1` (zelden gebruikt)\n"
+" * `secp384r1`\n"
+" * `secp256r1`\n"
+" * `x448`\n"
+" * `x25519`\n"
+" * `brainpoolP512r1` (zelden gebruikt)\n"
+" * `brainpoolP384r1` (idem)\n"
+" * `brainpoolP256r1` (idem)\n"
+"\n"
+"* Uit te faseren:\n"
+"\n"
+" * `secp224r1`\n"
+"\n"
+"* Onvoldoende:\n"
+"\n"
+" * Andere krommen\n"
+"\n"
+"**Beveiligingsniveau van de lengte van RSA-sleutels**\n"
+"\n"
+"* Voldoende: Tenminste 3072 bit\n"
+"* Uit te faseren: 2048 – 3071 bit\n"
+"* Onvoldoende: Minder dan 2048 bit\n"
+"\n"
+"**Beveiligingsniveau van Edwards-krommen voor EdDSA (zelden gebruikt)**\n"
"\n"
-"**Lengte van RSA-sleutels**\n"
+"* Voldoende:\n"
+"\n"
+" * `Ed448`\n"
+" * `Ed25519`\n"
+"\n"
+"* Onvoldoende:\n"
+"\n"
+" * Andere krommen\n"
+" \n"
+"---\n"
"\n"
-"* Goed: Minimaal 3072 bit\n"
-"* Voldoende: 2048 – 3071 bit\n"
-"* Onvoldoende: Minder dan 2048 bit"
+"Let op: de bovenstaande namen zijn gebaseerd op de [IANA naamgevingsconventies](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals `prime256v1` (ANSI) en `NIST P-256` voor `secp256r1`."
msgid "detail mail tls cert-pubkey label"
msgstr "Publieke sleutel van certificaat"
msgid "detail mail tls cert-pubkey tech table"
-msgstr "Mailserver (MX)|Getroffen handtekening-parameters|Status"
+msgstr "Mailserver (MX)|Verouderde handtekening-parameter|Beveiligingsniveau"
msgid "detail mail tls cert-pubkey verdict bad"
msgstr ""
-"De digitale handtekening van tenminste één van je mailserver-certificaten "
-"gebruikt *onvoldoende* veilige parameters."
+"De publieke sleutel van tenminste één van je mailserver-certificaten is "
+"*niet* gebaseerd op een veilig ondertekeningsalgoritme met veilige "
+"parameters."
msgid "detail mail tls cert-pubkey verdict good"
msgstr ""
-"De digitale handtekeningen van al je mailserver-certificaten gebruiken "
-"veilige parameters."
+"De publieke sleutels van al je mailserver-certificaten zijn gebaseerd op een"
+" veilig ondertekeningsalgoritme met veilige parameters."
msgid "detail mail tls cert-pubkey verdict phase-out"
msgstr ""
-"De digitale handtekening van tenminste één van je mailserver-certificaten "
-"gebruikt parameters die de status *uit te faseren* hebben, omdat bekend is "
-"dat deze fragiel zijn en het risico lopen in de toekomst *onvoldoende* "
-"veilig te worden."
+"De publieke sleutel van tenminste één van je mailserver-certificaten is "
+"gebaseerd op een ondertekeningsalgoritme met parameters die zouden moeten "
+"worden *uitgefaseerd* omdat ze zwakker zijn, hoewel je ze nog steeds kunt "
+"gebruiken als het echt nodig is. In een toekomstige update zullen ze "
+"waarschijnlijk onvoldoende zijn."
msgid "detail mail tls cert-signature exp"
msgstr ""
-"We testen of de ondertekende fingerprint van ieder van je mailserver-certificaten is gemaakt met een veilig algoritme voor hashing. \n"
+"We testen of ieder van je mailserver-certificaten is ondertekend (door een certificaatautoriteit) met een veilig ondertekeningsalgoritme, waarbij gebruik is gemaakt van een veilige hashfunctie.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B3-2 en tabel 3.\n"
+"Voor meer informatie over de relevante veldnaam in het certificaat, zie paragraaf [\"4.1.1.2. signatureAlgorithm\" van RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.1.2).\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.5.\n"
"\n"
"---\n"
"\n"
-"**Hashfuncties voor certificaatverificatie**\n"
+"**Beveiligingsniveau ondertekeningsalgoritmes**\n"
+"\n"
+"* Voldoende: ECDSA, RSA, EdDSA\n"
+"* Onvoldoende: DSS, EXPORT-*, PSK, Anon, NULL, KRB5\n"
"\n"
-"* Goed: SHA-512, SHA-384, SHA-256\n"
+"**Beveiligingsniveau van hashfuncties**\n"
+"\n"
+"* Goed: SHA-256, SHA-384, SHA-512 \n"
+"* Uitfaseren: SHA-224\n"
"* Onvoldoende: SHA-1, MD5"
msgid "detail mail tls cert-signature label"
-msgstr "Handtekening van certificaat"
+msgstr "Handtekening op certificaat"
msgid "detail mail tls cert-signature tech table"
-msgstr "Mailserver (MX)|Getroffen hashing-algoritme|Status"
+msgstr "Mailserver (MX)|Verouderde hashfunctie|Beveiligingsniveau"
msgid "detail mail tls cert-signature verdict bad"
msgstr ""
-"Tenminste één van je mailserver-certificaten is ondertekend met een "
-"algoritme voor hashing dat *onvoldoende* veilig is."
+"Tenminste één van je mailserver-certificaten is ondertekend met behulp van "
+"een ondertekeningsalgoritme en hashfunctie die *onvoldoende* veilig zijn."
msgid "detail mail tls cert-signature verdict good"
msgstr ""
-"Al je mailserver-certificaten zijn ondertekend met een veilig algoritme voor"
-" hashing."
+"Al je mailserver-certificaten zijn ondertekend met behulp van een "
+"ondertekeningsalgoritme en hashfunctie die veilig zijn."
+
+msgid "detail mail tls cert-signature verdict phase-out"
+msgstr ""
+"Tenminste één van je mailserver-certificaten is ondertekend met behulp van "
+"een ondertekeningsalgoritme en hashfunctie die zouden moeten worden "
+"*uitgefaseerd* omdat ze zwakker zijn, hoewel je ze nog steeds kunt gebruiken"
+" als het echt nodig is. In een toekomstige update zullen ze waarschijnlijk "
+"onvoldoende zijn."
msgid "detail mail tls cert-trust exp"
msgstr ""
@@ -1279,7 +1337,7 @@ msgstr ""
"\n"
"Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B3-4.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 4.4.\n"
"\n"
"*Niveau van vereistheid: Optioneel*"
@@ -1302,38 +1360,38 @@ msgstr ""
msgid "detail mail tls cipher-order exp"
msgstr ""
-"We testen of je ontvangende mailservers (MX) hun eigen cipher-voorkeur afdwingen ('I'), en ciphers aanbieden conform de voorgeschreven volgorde ('II').\n"
-"\n"
-"Als je mailserver alleen 'Goede' ciphers ondersteunt, dan is deze test niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.\n"
+"We testen of je ontvangende mailservers (MX) cipher suites aanbieden in aflopende volgorde van hun beveiligingsniveau, zonder een andere voorkeur van een verzendende mailserver te accepteren. \n"
"\n"
-"I. *Server afgedwongen cipher-voorkeur*: Ontvangende mailservers dwingen hun cipher-voorkeur af tijdens de onderhandeling met verzendende mailservers, en accepteren geen voorkeur van de verzendende mailservers;\n"
+"Je mailservers moeten dus hun eigen voorkeur voor cipher suites afdwingen tijdens de onderhandelingen met een verzendende mailserver. Bovendien moeten cipher suites worden aangeboden door je mailservers, waarbij 'Goed' en 'Voldoende' de voorkeur krijgen boven 'Uit te faseren' cipher suites. \n"
"\n"
-"II. *Voorgeschreven volgorde*: Ciphers worden aangeboden door de ontvangende mailservers in overeenstemming met de voorgeschreven volgorde waarbij *Goede* boven *Voldoende* boven *Uit te faseren* ciphers worden geprefereerd. \n"
+"Wanneer je mailservers alleen 'Goed' en 'Voldoende' cipher suites ondersteunen, dan is deze subtest niet van toepassing, aangezien de volgorde geen significant beveiligingsvoordeel oplevert. \n"
"\n"
-"In de bovenstaande tabel met technische details staan **alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde**.\n"
+"In geval van afwijkende volgorde, wordt in de bovenstaande tabel met technische details weergegeven welke 'Uit te faseren' cipher suite door je mailservers is gekozen, met in de laatste kolom de 'Goed' of 'Voldoende' cipher suite die eerst gekozen had moeten worden. Alleen de **eerst gevonden** afwijking wordt weergegeven.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B2-5."
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 2 en 3."
msgid "detail mail tls cipher-order label"
-msgstr "Cipher-volgorde"
+msgstr "Volgorde van cipher suites"
msgid "detail mail tls cipher-order tech table"
-msgstr "Mail server (MX)|Cipher preferred by server|Expected preferred cipher"
+msgstr ""
+"Mailserver (MX)|Cipher suite geprefereerd door server|Verwachte "
+"geprefereerde cipher suite"
msgid "detail mail tls cipher-order verdict bad"
msgstr ""
-"Tenminste één van je mailservers dwingt *niet* zijn eigen cipher-voorkeur af ('I').\n"
-"Tenminste één van je mailservers prefereert *niet* 'Goede' en 'Voldoende' boven 'Uit te faseren' ciphers ('II')."
+"Tenminste één van je mailservers dwingt *niet* zijn eigen voorkeur af voor "
+"cipher suites in aflopende volgorde van hun beveiligingsniveau."
msgid "detail mail tls cipher-order verdict good"
msgstr ""
-"Al je mailservers dwingen hun eigen cipher-voorkeur af ('I'), en bieden "
-"ciphers aan conform de voorgeschreven volgorde ('II')."
+"Al je mailservers dwingen hun eigen voorkeur af voor cipher suites in "
+"aflopende volgorde van hun beveiligingsniveau."
msgid "detail mail tls cipher-order verdict na"
msgstr ""
-"Deze subtest is niet van toepassing aangezien je mailserver alleen 'Goede' "
-"ciphers ondersteunt."
+"Deze subtest is niet van toepassing aangezien je mailservers alleen 'Goede' "
+"en 'Voldoende' cipher suites ondersteunen."
msgid "detail mail tls cipher-order verdict seclevel-bad"
msgstr ""
@@ -1351,81 +1409,103 @@ msgstr ""
msgid "detail mail tls ciphers exp"
msgstr ""
-"**UPDATE OF EXPLANATION PENDING**\n"
+"We testen of je ontvangende mailservers alleen veilige (d.w.z. beveiligingsniveau 'Goed' en/of 'Voldoende') cipher suites ondersteunen. Een mailserver ondersteunt meestal meerdere cipher suites.\n"
"\n"
-"We testen of je ontvangende mailservers (MX) alleen veilige, d.w.z. 'Goede' en/of 'Voldoende', ciphers (ook algoritmeselecties genoemd) ondersteunen. Om te voorkomen dat we tegen 'rate limits' van ontvangende mailservers aanlopen, bevat het testresultaat **alleen de eerstgevonden getroffen algoritmeselectie**.\n"
+"Een cipher suite bestaat uit ciphers voor vier cryptografische functies: 1. sleuteluitwisseling, 2. authenticatie (d.w.z. certificaatverificatie), 3. bulkversleuteling, en 4. hashing.\n"
"\n"
-"Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing.\n"
+"Vanaf TLS 1.3 omvat de term 'cipher suite' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite.\n"
"\n"
-"* Vanaf TLS 1.3 omvat de term 'cipher suite' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term 'cipher suite' ambigu maakt, gebruikt NCSC de term 'algoritmeselectie' om alle vier de functies te omvatten.\n"
-"* NCSC gebruikt de [IANA-naamgeving](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) voor algoritmeselectie. Internet.nl hanteert de [OpenSSL-naamgeving](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-SUITE-NAMES). Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.\n"
-"* Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.\n"
+"Zowel Internet.nl als NCSC-NL gebruikt de [IANA-naamgevingsconventie](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) voor cipher suites. Een andere veelgebruikte notatie is de [OpenSSL-naamgevingsconventie](https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-SUITE-NAMES). Sinds TLS 1.3 volgt OpenSSL de IANA-naamgevingsconventie. Een vertaling tussen beide is te vinden in de OpenSSL-documentatie. \n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.\n"
+"Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met de manier van testen. \n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) van NCSC, paragraaf 3.3.2 tot en met 3.3.5 en bijlage B.\n"
"\n"
"---\n"
-"Hieronder staan 'Goede', 'Voldoende' en 'Uit te faseren' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0'. Achter iedere algoritmeselectie staat de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste 'Uit te faseren' is.\n"
-"\n"
-"\n"
-"Goed:\n"
-"\n"
-"* `ECDHE-ECDSA-AES256-GCM-SHA384` (`TLS_AES_256_GCM_SHA384` in 1.3) [1.2]\n"
-"* `ECDHE-ECDSA-CHACHA20-POLY1305` (`TLS_CHACHA20_POLY1305_SHA256` in 1.3) [1.2]\n"
-"* `ECDHE-ECDSA-AES128-GCM-SHA256` (`TLS_AES_128_GCM_SHA256` in 1.3) [1.2]\n"
-"* `ECDHE-RSA-AES256-GCM-SHA384` (`TLS_AES_256_GCM_SHA384` in 1.3) [1.2]\n"
-"* `ECDHE-RSA-CHACHA20-POLY1305` (`TLS_CHACHA20_POLY1305_SHA256` in 1.3) [1.2]\n"
-"* `ECDHE-RSA-AES128-GCM-SHA256` (`TLS_AES_128_GCM_SHA256` in 1.3) [1.2]\n"
-"\n"
-"Voldoende:\n"
-"\n"
-"* `ECDHE-ECDSA-AES256-SHA384` [1.2]\n"
-"* `ECDHE-ECDSA-AES256-SHA` [1.0]\n"
-"* `ECDHE-ECDSA-AES128-SHA256` [1.2]\n"
-"* `ECDHE-ECDSA-AES128-SHA` [1.0]\n"
-"* `ECDHE-RSA-AES256-SHA384` [1.2]\n"
-"* `ECDHE-RSA-AES256-SHA` [1.0]\n"
-"* `ECDHE-RSA-AES128-SHA256` [1.2]\n"
-"* `ECDHE-RSA-AES128-SHA` [1.0]\n"
-"* `DHE-RSA-AES256-GCM-SHA384` [1.2]\n"
-"* `DHE-RSA-CHACHA20-POLY1305` [1.2]\n"
-"* `DHE-RSA-AES128-GCM-SHA256` [1.2]\n"
-"* `DHE-RSA-AES256-SHA256` [1.2]\n"
-"* `DHE-RSA-AES256-SHA` [1.0]\n"
-"* `DHE-RSA-AES128-SHA256` [1.2]\n"
-"* `DHE-RSA-AES128-SHA` [1.0]\n"
-"\n"
-"Uit te faseren:\n"
-"\n"
-"* `ECDHE-ECDSA-DES-CBC3-SHA` [1.0]\n"
-"* `ECDHE-RSA-DES-CBC3-SHA` [1.0]\n"
-"* `DHE-RSA-DES-CBC3-SHA` [1.0]\n"
-"* `AES256-GCM-SHA384` [1.2]\n"
-"* `AES128-GCM-SHA256` [1.2]\n"
-"* `AES256-SHA256` [1.2]\n"
-"* `AES256-SHA` [1.0]\n"
-"* `AES128-SHA256` [1.2]\n"
-"* `AES128-SHA` [1.0]\n"
-"* `DES-CBC3-SHA` [1.0]"
+"\n"
+"**Beveiligingsniveau van cipher suites**\n"
+"\n"
+"Hieronder vind je de cipher suites met de status 'Goed', 'Voldoende' en 'Uit te faseren', gebaseerd op bijlage B van de richtlijnen van NCSC.\n"
+"\n"
+"Goed [TLS 1.3]:\n"
+"\n"
+"* `TLS_AES_256_GCM_SHA384`\n"
+"* `TLS_CHACHA20_POLY1305_SHA256`\n"
+"\n"
+"Voldoende [TLS 1.3]:\n"
+"\n"
+"* `TLS_AES_128_CCM_SHA256`\n"
+"* `TLS_AES_128_GCM_SHA256`\n"
+" \n"
+"Voldoende [TLS 1.2]:\n"
+"\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_128_CCM`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_256_CCM`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256`\n"
+"\n"
+"\n"
+"Uit te faseren [TLS 1.2]:\n"
+"* `TLS_DHE_RSA_WITH_AES_128_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_AES_128_CCM`\n"
+"* `TLS_DHE_RSA_WITH_AES_128_GCM_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_AES_256_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_AES_256_CCM`\n"
+"* `TLS_DHE_RSA_WITH_AES_256_GCM_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256`\n"
+"* `TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384`\n"
+"* `TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384`\n"
+"* `TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384`"
msgid "detail mail tls ciphers label"
-msgstr "Ciphers (Algoritmeselecties)"
+msgstr "Cipher suites"
msgid "detail mail tls ciphers tech table"
-msgstr "Mailserver (MX)|Eerst gevonden onveilige cipher|Status"
+msgstr "Mailserver (MX)|Verouderde cipher suite|Beveiligingsniveau"
msgid "detail mail tls ciphers verdict bad"
msgstr ""
"Tenminste één van je mailservers ondersteunt een of meer *onvoldoende* "
-"veilige ciphers."
+"veilige cipher suites."
msgid "detail mail tls ciphers verdict good"
-msgstr "Al je mailservers ondersteunen alleen veilige ciphers."
+msgstr "Al je mailservers ondersteunen alleen veilige cipher suites."
msgid "detail mail tls ciphers verdict phase-out"
msgstr ""
-"Tenminste één van je mailservers ondersteunt een of meer ciphers die de "
-"status *uit te faseren* hebben, omdat bekend is dat deze fragiel zijn en het"
-" risico lopen in de toekomst *onvoldoende* veilig te worden."
+"Tenminste één van je mailservers ondersteunt één of meer cipher suites die "
+"zouden moeten worden *uitgefaseerd* omdat ze zwakker zijn, hoewel je ze nog "
+"steeds kunt gebruiken als het echt nodig is. In een toekomstige update "
+"zullen ze waarschijnlijk onvoldoende zijn."
msgid "detail mail tls compression exp"
msgstr ""
@@ -1434,14 +1514,15 @@ msgstr ""
"Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaad\n"
"kan om deze optie uit te schakelen.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B7-1 en tabel 11.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.4.1.\n"
"\n"
"---\n"
-"**Compressie-optie**\n"
"\n"
-"* Goed: Geen compressie\n"
-"* Voldoende: Compressie op applicatieniveau \n"
-"* Onvoldoende: TLS-compressie"
+"**Beveiligingsniveau van TLS-compressie**\n"
+"\n"
+"* Goed: N.v.t. (TLS 1.3)\n"
+"* Goed: Geen TLS-compressie (TLS 1.2)\n"
+"* Onvoldoende: TLS-compressie (TLS 1.2)"
msgid "detail mail tls compression label"
msgstr "TLS-compressie"
@@ -1467,7 +1548,7 @@ msgstr ""
"\n"
"De test slaagt daarnaast niet als er geen DNSSEC-bewijs van 'Denial of Existence' voor TLSA-records is. Als een ondertekend TLSA-record bestaat maar tegelijkertijd is er een 'insecure' `NXDOMAIN` voor hetzelfde domein (door verkeerd werkende DNSSEC-ondertekeningssoftware), dan zal de test ook niet slagen. De laatste twee foutscenario's kunnen leiden tot afleveringsproblemen van aan jou gerichte e-mails door DANE-validerende mailverzenders.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, Appendix A, onder 'Certificate pinning en DANE'."
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, hoofdstuk \"2 Stappenplan: Hoe kom ik tot een passende TLS configuratie?\"."
msgid "detail mail tls dane-exists label"
msgstr "DANE aanwezigheid"
@@ -1551,70 +1632,98 @@ msgstr ""
"mailserver(s) opzetten."
msgid "detail mail tls extended-master-secret exp"
-msgstr "This test checks for Extended Master Secret."
+msgstr ""
+"We testen of je ontvangende mailservers (MX) Extended Master Secret ondersteunen.\n"
+"\n"
+"Extended Master Secret (EMS), zoals beschreven in [RFC 7627](https://www.rfc-editor.org/rfc/rfc7627), is een uitbreiding voor TLS 1.2 die Triple Handshakes machine-in-the-middle aanvallen voorkomt.\n"
+"\n"
+"Steeds vaker dwingen TLS-bibliotheken standaard EMS af, mede omdat beveiligingsvoorschriften zoals FIPS dit vereisen. Als je mailserver geen ondersteuning biedt voor EMS, kunnen verzendende mailservers die EMS afdwingen geen verbinding via TLS 1.2 met je mailserver tot stand brengen.\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 4.1. "
msgid "detail mail tls extended-master-secret label"
msgstr "Extended Master Secret (EMS)"
msgid "detail mail tls extended-master-secret tech table"
-msgstr "Mail server|EMS result"
+msgstr "Mailserver (MX)|EMS"
msgid "detail mail tls extended-master-secret verdict bad"
-msgstr "EMS is not supported."
+msgstr "Tenminste één van je mailservers ondersteunt EMS *niet*."
msgid "detail mail tls extended-master-secret verdict good"
-msgstr "EMS is supported."
+msgstr "Al je mailservers ondersteunen EMS."
msgid "detail mail tls extended-master-secret verdict na-no-tls-1-2"
-msgstr "EMS is only available in TLS 1.2, which is not enabled."
+msgstr ""
+"Deze subtest is niet van toepassing, aangezien EMS alleen beschikbaar is in "
+"TLS 1.2, dat niet is ingeschakeld op je mailservers."
msgid "detail mail tls extended-master-secret verdict unknown"
-msgstr "We could not determine the EMS status."
+msgstr ""
+"Geen resultaat beschikbaar. Op het moment dat de test werd uitgevoerd, "
+"maakte deze subtest nog geen deel uit van de test."
msgid "detail mail tls fs-params exp"
msgstr ""
-"We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je mailservers (MX), veilig zijn. \n"
+"We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je ontvangende mailservers (MX), veilig zijn. \n"
"\n"
-"**ECDHE**: De veiligheid van de ECDHE-sleuteluitwisseling is afhankelijk van de geselecteerde elliptische kromme. We testen of de bitlengte van de gebruikte kromme tenminste 224 bits is. Op dit moment kunnen we niet de naam van de elliptische kromme testen.\n"
+"**ECDHE**: De veiligheid van de ECDHE-sleuteluitwisseling is afhankelijk van de gebruikte elliptische kromme. We testen welke elliptische kromme wordt gebruikt.\n"
"\n"
-"**DHE**: De veiligheid van de Diffie-Hellman Ephemeral (DHE) sleuteluitwisseling is afhankelijk van de lengte van de publieke en geheime sleutels die in de geselecteerde finite field-groep wordt gebruikt. We testen of je publieke DHE-sleutelmateriaal gebruikmaakt van een van de gepredefinieerde finite field-groepen die zijn gespecificeerd in [RFC 7919](https://www.rfc-editor.org/rfc/rfc7919). Zelf-gegenereerde groepen zijn 'Onvoldoende'.\n"
+"**DHE**: De veiligheid van de Diffie-Hellman Ephemeral (DHE) sleuteluitwisseling is afhankelijk van de gebruikte finite field-groep. We testen of een van de gestandaardiseerde finite field-groepen die zijn gespecificeerd in [RFC 7919](https://www.rfc-editor.org/rfc/rfc7919) wordt gebruikt. Zelf-gegenereerde groepen hebben het beveiligingsniveau 'Onvoldoende'. De grotere sleutellengtes die noodzakelijk zijn voor het gebruik van DHE gaan ten koste van de prestaties. Maak een zorgvuldige afweging en gebruik waar mogelijk ECDHE in plaats van DHE.\n"
"\n"
-"De grotere sleutellengtes die noodzakelijk zijn voor het gebruik van DHE gaan ten koste van de prestaties. Maak een zorgvuldige afweging en gebruik waar mogelijk ECDHE in plaats van DHE.\n"
+"**Alternatieven voor ECDHE en DHE**\n"
"\n"
-"**RSA als alternatief**: Naast ECDHE en DHE, kan RSA gebruikt worden voor sleuteluitwisseling. RSA loopt het risico om onvoldoende veilig te worden (huidige status 'Uit te faseren'). De publieke RSA-parameters worden getest in de subtest 'Handtekening-parameters van certificaat'. Overigens heeft RSA voor certificaatverificatie wel de status 'Goed'.\n"
+"* **Quantumveilige cryptografische algoritmen** `X25519MLKEM768`, `SecP256r1MLKEM768` en `SecP384r1MLKEM1024` hebben beveiligingsniveau 'Goed'. Dit zijn hybride algoritmen die een combinatie van ECDHE en ML-KEM gebruiken. Met name `X25519MLKEM768` wordt steeds vaker ondersteund door TLS-softwarebibliotheken en wordt door de meeste webbrowsers gebruikt. De parameters maken inherent deel uit van deze algoritmen. Er hoeven dus geen aanvullende keuzes te worden gemaakt.\n"
+"* **RSA en non-ephemeral Diffie-Hellman (ECDH en DH)** moeten *niet* worden gebruikt voor sleuteluitwisseling, aangezien hun beveiligingsniveau 'Onvoldoende' is. Ze bieden geen forward secrecy. Merk op dat RSA nog steeds als 'Voldoende' wordt beschouwd voor authenticatie (d.w.z. certificaatverificatie).\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.3.\n"
"\n"
-"---\n"
-"**Elliptische krommen voor ECDHE**\n"
"\n"
-"* Goed: `secp384r1`, `secp256r1`, `x448`, en `x25519`\n"
-"* Uit te faseren: `secp224r1`\n"
-"* Onvoldoende: Andere krommen\n"
+"---\n"
"\n"
-"**Finite field-groepen voor DHE**\n"
+"**Beveiligingsniveau van elliptische krommen voor ECDHE**\n"
"\n"
"* Voldoende:\n"
+" \n"
+" * `secp521r1` (zelden gebruikt)\n"
+" * `secp384r1`\n"
+" * `secp256r1`\n"
+" * `x448`\n"
+" * `x25519`\n"
+" * `brainpoolP512r1` (zelden gebruikt)\n"
+" * `brainpoolP384r1` (idem)\n"
+" * `brainpoolP256r1` (idem)\n"
"\n"
-" * [ffdhe4096](https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe4096.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
-" sha256 checksum: `64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3`\n"
-" * [ffdhe3072](https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe3072.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
-" sha256 checksum: `c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab`\n"
-" * Merk op dat we ook testen op ffdhe8192 and ffdhe6144 die beide voldoende zijn. Echter, hun beperkte beveiligingswinst weegt zelden op tegen het prestatie-verlies.\n"
+"* Uit te faseren:\n"
+"\n"
+" * `secp224r1`\n"
+"\n"
+"* Onvoldoende:\n"
+"\n"
+" * Andere krommen\n"
+"\n"
+"**Beveiligingsniveau van finite field-groepen voor DHE**\n"
"\n"
"* Uit te faseren:\n"
"\n"
-" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe2048.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
-" sha256 checksum: `9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b`\n"
+" * `ffdhe8192` (zelden gebruikt vanwege prestatie-verlies)\n"
+" * `ffdhe6144` (idem)\n"
+" * [`ffdhe4096`](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
+" sha256 checksum: `64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3`\n"
+" * [`ffdhe3072`](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe3072.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n"
+" sha256 checksum: `c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab`\n"
+"\n"
+"* Onvoldoende:\n"
"\n"
-"* Onvoldoende: Andere groepen\n"
+" * `ffdhe2048`\n"
+" * Andere groepen (d.w.z. niet-gestandaardiseerd, zelf-gegenereerd)\n"
"\n"
"---\n"
"\n"
"Let op: de bovenstaande namen zijn gebaseerd op de [IANA naamgevingsconventies](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals `prime256v1` (ANSI) en `NIST P-256` voor `secp256r1`."
msgid "detail mail tls fs-params label"
-msgstr "Sleuteluitwisselingsparameters"
+msgstr "Parameters voor sleuteluitwisseling"
msgid "detail mail tls fs-params tech table"
msgstr "Mailserver (MX)|Getroffen parameters|Veiligheidsniveau"
@@ -1631,38 +1740,46 @@ msgstr ""
msgid "detail mail tls fs-params verdict na"
msgstr ""
-"Deze subtest is niet van toepassing, omdat je mailservers *niet* Diffie-Hellman-sleuteluitwisseling ondersteunen. Let \n"
-"op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status *uit te faseren*."
+"Deze subtest is niet van toepassing, omdat je mailservers *niet* Diffie-"
+"Hellman-sleuteluitwisseling ondersteunen."
msgid "detail mail tls fs-params verdict phase-out"
msgstr ""
"Tenminste één van je mailservers ondersteunt parameters voor Diffie-Hellman-"
-"sleuteluitwisseling die de status *uit te faseren* hebben, omdat bekend is "
-"dat deze fragiel zijn en het risico lopen in de toekomst *onvoldoende* "
-"veilig te worden."
+"sleuteluitwisseling die zouden moeten worden *uitgefaseerd* omdat ze zwakker"
+" zijn, hoewel je ze nog steeds kunt gebruiken als het echt nodig is. In een "
+"toekomstige update zullen ze waarschijnlijk onvoldoende zijn."
msgid "detail mail tls kex-hash-func exp"
msgstr ""
"We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.\n"
"\n"
-"Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.\n"
+"De ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.\n"
"\n"
-"*Niveau van vereistheid: Aanbevolen*\n"
+"Houd er rekening mee dat deze subtest alleen van toepassing is op TLS 1.2 en niet op TLS 1.3. De ondersteunde hashfuncties kunnen worden geconfigureerd via een aparte TLS-instelling (bijvoorbeeld `SignatureAlgorithms` in OpenSSL) en maken *geen* deel uit van de configuratie van de cipher suites. \n"
+"\n"
+"Voor meer details over de status van SHA-1 en MD5 zie [RFC 9155](https://www.rfc-editor.org/rfc/rfc9155.html#name-server-key-exchange). We testen niet op MD5 omdat dit alleen nog maar door zeer verouderde software wordt ondersteund.\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.5. \n"
"\n"
"---\n"
-"**Ondersteuning voor verouderde handtekeningen**\n"
"\n"
-"* Good: Only SHA-256, SHA-384 or SHA-512 supported\n"
-"* Phase out: SHA1 or SHA224 supported"
+"**Beveiligingsniveau van hashfuncties voor sleuteluitwisseling**\n"
+"\n"
+"* Goed: SHA-256, SHA-384, SHA-512 \n"
+"* Uitfaseren: SHA-224 (zelden gebruikt)\n"
+"* Onvoldoende: SHA-1, MD5"
msgid "detail mail tls kex-hash-func label"
msgstr "Hashfunctie voor sleuteluitwisseling"
msgid "detail mail tls kex-hash-func tech table"
-msgstr "Mail server (MX)|Outdated signature algorithm result"
+msgstr "Mailserver (MX)|Verouderde hashfunctie"
msgid "detail mail tls kex-hash-func verdict bad"
msgstr ""
+"Tenminste één van je mailservers ondersteunt één of meer *onvoldoende* "
+"veilige hashfuncties voor sleuteluitwisseling."
msgid "detail mail tls kex-hash-func verdict good"
msgstr ""
@@ -1678,10 +1795,10 @@ msgstr ""
msgid "detail mail tls kex-hash-func verdict phase-out"
msgstr ""
-"Ten minste één van je mailservers ondersteunt *geen* veilige hashfunctie "
-"voor sleuteluitwisseling. Deze instelling dien je weloverwogen *uit te "
-"faseren*, omdat deze het risico loopt in de toekomst *onvoldoende* veilig te"
-" worden. "
+"Ten minste één van je mailservers ondersteunt een hashfunctie voor "
+"sleuteluitwisseling die zouden moeten worden *uitgefaseerd* omdat deze "
+"zwakker is, hoewel je deze nog steeds kunt gebruiken als het echt nodig is. "
+"In een toekomstige update zal deze waarschijnlijk onvoldoende zijn."
msgid "detail mail tls kex-hash-func verdict {phase-out}"
msgstr ""
@@ -1741,20 +1858,27 @@ msgstr ""
msgid "detail mail tls renegotiation-client exp"
msgstr ""
-"We testen of een verzendende mailserver een renegotiation kan initiëren met jouw ontvangende mailservers (MX). \n"
+"We controleren of een verzendende mailserver een renegotiation met je ontvangende mailserver (MX) kan starten en, zo ja, of het aantal toegestane renegotiations voldoende gelimiteerd is.\n"
"\n"
-"In het algemeen is het niet nodig om clients de mogelijkheid te bieden om een renegotiation te initiëren (client-initiated renegotiation). Bovendien komt een ontvangende mailserver hierdoor binnen een TLS-verbinding bloot te staan aan DoS-aanvallen. Een aanvaller kan ook zonder renegotiation op initiatief van een client soortgelijke DoS-aanvallen uitvoeren door veel parallelle TLS-verbindingen te openen. Dergelijke aanvallen zijn echter eenvoudiger te traceren en met de standaardmaatregelen te mitigeren. Merk op dat client-initiated renegotiation impact heeft op de beschikbaarheid en niet op de vertrouwelijkheid.\n"
+"Het is over het algemeen niet nodig om clients toe te staan renegotiations te initiëren. Client-initiated renegotiation maakt een mailserver kwetsbaar voor DoS-aanvallen binnen een TLS-verbinding. Daarom is het belangrijk om renegotiations niet toe te staan of het aantal ervan strikt te limiteren. Wij beschouwen meer dan 10 toegestane renegotiations als onvoldoende.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn 8-1 en tabel 13.\n"
+"Een aanvaller kan ook zonder client-initiated renegotiation soortgelijke DoS-aanvallen uitvoeren door veel parallelle TLS-verbindingen te openen. Dergelijke aanvallen zijn echter eenvoudiger te detecteren en met de standaardmaatregelen te mitigeren. \n"
"\n"
-"*Niveau van vereistheid: Optioneel*\n"
+"Merk op dat client-initiated renegotiation impact kan hebben op de beschikbaarheid, maar niet op de vertrouwelijkheid.\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS\n"
+") van NCSC, paragraaf 3.4.2.\n"
+"\n"
+"*Niveau van vereistheid: Aanbevolen*\n"
"\n"
"---\n"
"\n"
-"**Client-initiated renegotiation**\n"
+"**Beveiligingsniveau van client-initiated renegotiation**\n"
"\n"
-"* Goed: Uit (of n.v.t. voor TLS 1.3)\n"
-"* Voldoende: Aan"
+"* Goed: N.v.t. (TLS 1.3)\n"
+"* Goed: Geen renegotiation (TLS 1.2)\n"
+"* Voldoende: Gelimiteerde renegotiation (TLS 1.2)\n"
+"* Uit te faseren: Ongelimiteerd renegotiation (TLS 1.2)"
msgid "detail mail tls renegotiation-client label"
msgstr "Client-initiated renegotiation"
@@ -1764,10 +1888,15 @@ msgstr "Mailserver (MX)|Client-initiated renegotiation"
msgid "detail mail tls renegotiation-client verdict allowed-with-low-limit"
msgstr ""
+"Tenminste één van je mailservers staat client-initiated renegotiation toe, "
+"terwijl het aantal toegestane renegotiations voldoende wordt gelimiteerd."
msgid ""
"detail mail tls renegotiation-client verdict allowed-with-too-high-limit"
msgstr ""
+"Tenminste één van je mailservers staat client-initiated renegotiation toe, "
+"terwijl het aantal toegestane renegotiations *onvoldoende* wordt "
+"gelimiteerd."
msgid "detail mail tls renegotiation-client verdict bad"
msgstr ""
@@ -1779,7 +1908,7 @@ msgid "detail mail tls renegotiation-client verdict good"
msgstr "Al je mailservers staan geen client-initiated renegotiation toe."
msgid "detail mail tls renegotiation-client verdict not-allowed"
-msgstr ""
+msgstr "Je mailservers staan geen client-initiated renegotiation toe."
msgid "detail mail tls renegotiation-secure exp"
msgstr ""
@@ -1787,13 +1916,15 @@ msgstr ""
"\n"
"In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten 'opnieuw onderhandelen' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B8-1 en tabel 12.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.4.2.\n"
"\n"
"---\n"
+"\n"
"**Insecure renegotiation**\n"
"\n"
-"* Goed: Uit (of n.v.t. voor TLS 1.3)\n"
-"* Onvoldoende: Aan "
+"* Goed: N.v.t. (TLS 1.3)\n"
+"* Goed: Geen insecure renegotiation (TLS 1.2)\n"
+"* Onvoldoende: Insecure renegotiation (TLS 1.2)"
msgid "detail mail tls renegotiation-secure label"
msgstr "Secure renegotiation"
@@ -1896,32 +2027,32 @@ msgstr ""
msgid "detail mail tls version exp"
msgstr ""
-"We testen of je ontvangende mailservers (MX) alleen veilige TLS-versies ondersteunen. \n"
+"We testen of je ontvangende mailservers (MX) alleen veilige TLS-versies ondersteunt (d.w.z. met een beveiligingsniveau van 'Goed' of 'Voldoende'). \n"
"\n"
-"Een mailserver kan meer dan één TLS-versie ondersteunen.\n"
+"Een webserver kan meer dan één TLS-versie ondersteunen.\n"
"\n"
-"Merk op dat behoorlijk wat mailservers alleen oudere TLS-versies ondersteunen. Als de verzendende en ontvangende mailserver niet allebei dezelfde TLS-versie ondersteunen, dan zullen ze doorgaans terugvallen op onversleuteld transport. Om die reden kan het raadzaam zijn om de TLS-versies met status 'uit te faseren' voorlopig te blijven ondersteunen. Maak op basis van loggegevens een weloverwogen keuze voor het uitzetten van deze 'uit te faseren' TLS-versies.\n"
+"Houd er rekening mee dat moderne browsers TLS 1.0/1.1 en SSL niet langer ondersteunen. Als gevolg hiervan zijn websites die TLS 1.2 en/of 1.3 niet ondersteunen voor vrijwel niemand bereikbaar.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B1-1 en tabel 1\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.1.\n"
"\n"
"---\n"
-"**Versie**\n"
+"\n"
+"**Beveiligingsniveau van TLS-versies**\n"
"\n"
"* Goed: TLS 1.3\n"
"* Voldoende: TLS 1.2\n"
-"* Uit te faseren: TLS 1.1 en 1.0\n"
-"* Onvoldoende: SSL 3.0, 2.0 en 1.0"
+"* Onvoldoende: TLS 1.0/1.1, SSL 1.0/2.0/3.0"
msgid "detail mail tls version label"
msgstr "TLS-versie"
msgid "detail mail tls version tech table"
-msgstr "Mailserver (MX)|TLS-versies|Status"
+msgstr "Mailserver (MX)|TLS-versie|Beveiligingsniveau"
msgid "detail mail tls version verdict bad"
msgstr ""
-"Tenminste één van je mailservers ondersteunt een of meer *onvoldoende* "
-"veilige TLS-versies."
+"Tenminste één van je mailservers ondersteunt *onvoldoende* veilige TLS-"
+"versies."
msgid "detail mail tls version verdict good"
msgstr "Al je mailservers ondersteunen alleen veilige TLS-versies."
@@ -1934,19 +2065,21 @@ msgstr ""
msgid "detail mail tls zero-rtt exp"
msgstr ""
-"We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.\n"
+"We testen of je ontvangende mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.\n"
"\n"
"0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.\n"
"\n"
-"Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie geïnitieerd. De omvang van de ondersteuning voor [early data](https://www.openssl.org/docs/manmaster/man3/SSL_get_max_early_data.html) zoals [aangegeven](https://www.rfc-editor.org/rfc/rfc8446#section-4.2.10) door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando vóór de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.\n"
+"Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. VVoor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie geïnitieerd. De omvang van de ondersteuning voor [early data](https://www.openssl.org/docs/manmaster/man3/SSL_get_max_early_data.html) zoals [aangegeven](https://www.rfc-editor.org/rfc/rfc8446#section-4.2.10) door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar waarbij het EHLO-commando vóór de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B9-1 en tabel 14.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.4.4.\n"
"\n"
"---\n"
-"**0-RTT**\n"
"\n"
-"* Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)\n"
-"* Onvoldoende: Aan"
+"**Beveiligingsniveau van 0-RTT**\n"
+"\n"
+"* Goed: Geen 0-RTT (TLS 1.3)\n"
+"* Goed: N.v.t. (TLS 1.2)\n"
+"* Onvoldoende: Wel 0-RTT (TLS 1.3)"
msgid "detail mail tls zero-rtt label"
msgstr "0-RTT"
@@ -1963,8 +2096,8 @@ msgstr "Geen van je mailservers ondersteunen 0-RTT."
msgid "detail mail tls zero-rtt verdict na"
msgstr ""
-"Deze subtest is niet van toepassing aangezien je mailservers TLS 1.3 niet "
-"ondersteunen."
+"Deze subtest is niet van toepassing, aangezien 0-RTT alleen beschikbaar is "
+"in TLS 1.3, dat niet is ingeschakeld op je mailservers."
msgid "detail tech data bogus"
msgstr "bogus"
@@ -2394,8 +2527,8 @@ msgstr ""
"\n"
"1. Sta alleen zo specifiek mogelijke domeinen toe in CSP-richtlijnen. Dit wordt in deze subtest voor CSP tot op zekere hoogte automatisch getest.\n"
"\n"
-" * Sta *niet* alle domeinen onder een TLD (`*.nl`) of SLD (`*.gov.uk`) toe, hoewel we hier momenteel *niet* op testen. \n"
-" * Sta *niet* een ander domein onder een SLD toe in `default-src` (bijvoorbeeld `voorbeeld2.gov.nl` voor `voorbeeld1.gov.nl`), hoewel we hier momenteel *niet* op testen.\n"
+" * Sta *niet* alle domeinen onder een TLD (`*.nl`) of SLD (`*.example.nl`) toe, hoewel we hier momenteel *niet* op testen. \n"
+" * Sta *niet* een ander domein onder een SLD toe in `default-src` (bijvoorbeeld `voorbeeld2.example.nl` voor `voorbeeld1.example.nl`), hoewel we hier momenteel *niet* op testen.\n"
"\n"
"2. Gebruik *niet* inline scripts of styles. In gevallen waarin je het gebruik van inline scripts of styles niet kunt vermijden, gebruik dan *niet* `unsafe-inline` (zoals hierboven vermeld) maar gebruik bij voorkeur CSP-hashes of anders CSP-nonces.\n"
"3. Gebruik de HTTP-header als mechanisme voor het serveren van je CSP-beleid. Gebruik *niet* het HTML `` element om je CSP-beleid te serveren. Het laatste is minder veilig en ondersteunt niet alle CSP-richtlijnen (bijvoorbeeld niet het vereiste `frame-ancestors`). Daarom controleren we *niet* op CSP die wordt aangeboden via het HTML ``-element.\n"
@@ -2417,7 +2550,7 @@ msgstr "Webserver-IP-adres|Bevindingen"
msgid "detail web appsecpriv http-csp verdict bad"
msgstr ""
"Je webserver biedt *geen* Content-Security-Policy (CSP) aan, of biedt CSP "
-"aan met bepaalde *onveilige* instellingen ."
+"aan met bepaalde *onveilige* instellingen."
msgid "detail web appsecpriv http-csp verdict good"
msgstr ""
@@ -2909,7 +3042,7 @@ msgstr ""
"\n"
"Het kan handig zijn om meerdere domeinnamen (bijvoorbeeld de domeinnaam met en zonder www) als Subject Alternative Name (SAN) in het certificaat op te nemen. \n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B3-1."
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 4.4."
msgid "detail web tls cert-hostmatch label"
msgstr "Domeinnaam op certificaat"
@@ -2929,90 +3062,143 @@ msgstr ""
msgid "detail web tls cert-pubkey exp"
msgstr ""
-"We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.\n"
+"We testen of de publieke sleutel van je certificaat en van ieder tussenliggend certificaat is gebaseerd op een veilig ondertekeningsalgoritme met veilige parameters. \n"
"\n"
-"Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbinding\n"
-"te garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.\n"
+"Bij de verificatie van certificaten wordt gebruikgemaakt van digitale handtekeningen. De publieke sleutel van een certificaat kan worden gebruikt om te verifiëren dat een handtekening is aangemaakt met behulp van de bijbehorende privésleutel.\n"
"\n"
-"Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.\n"
+"**Ondertekeningsalgoritme:**\n"
+"Het ondertekeningsalgoritme wordt bepaald bij het genereren van het certificaat. Een certificaat kan slechts één ondertekeningsalgoritme bevatten. Het is mogelijk om meer dan één algoritme te ondersteunen door meerdere certificaten op één server te configureren. Alleen de ondertekeningsalgoritmen ECDSA, RSA en EdDSA worden als voldoende veilig beschouwd. EdDSA wordt in de praktijk zelden of nooit gebruikt. Alle algoritmes zijn kwetsbaar voor de quantumdreiging. Zij bieden vooralsnog voldoende bescherming. Quantumveilige alternatieven zijn nog geen onderdeel van de TLS-standaarden.\n"
"\n"
-"De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.\n"
+"**Parameters:** De veiligheid van digitale handtekeningen met ECDSA en EdDSA is afhankelijk van de geselecteerde kromme. De veiligheid van RSA houdt verband met de sleutellengte van de publieke sleutel.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA. \n"
+"Voor meer informatie over de relevante veldnaam in het certificaat, zie paragraaf [\"4.1.2.7. Subject Public Key Info\" van RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.7).\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.2. \n"
"\n"
"---\n"
-"**Elliptische krommen voor ECDSA**\n"
"\n"
-"* Goed: `secp384r1`, `secp256r1`, `x448`, and `x25519`\n"
-"* Uit te faseren: `secp224r1`\n"
-"* Onvoldoende: Andere krommen\n"
+"**Beveiligingsniveau van elliptische krommen voor ECDSA**\n"
"\n"
-"**Lengte van RSA-sleutels**\n"
+"* Voldoende:\n"
+" \n"
+" * `secp521r1` (zelden gebruikt)\n"
+" * `secp384r1`\n"
+" * `secp256r1`\n"
+" * `x448`\n"
+" * `x25519`\n"
+" * `brainpoolP512r1` (zelden gebruikt)\n"
+" * `brainpoolP384r1` (idem)\n"
+" * `brainpoolP256r1` (idem)\n"
"\n"
-"* Goed: Minimaal 3072 bit\n"
-"* Voldoende: 2048 – 3071 bit\n"
-"* Onvoldoende: Minder dan 2048 bit"
+"* Uit te faseren:\n"
+"\n"
+" * `secp224r1`\n"
+"\n"
+"* Onvoldoende:\n"
+"\n"
+" * Andere krommen\n"
+"\n"
+"**Beveiligingsniveau van de lengte van RSA-sleutels**\n"
+"\n"
+"* Voldoende: Tenminste 3072 bit\n"
+"* Uit te faseren: 2048 – 3071 bit\n"
+"* Onvoldoende: Minder dan 2048 bit\n"
+"\n"
+"**Beveiligingsniveau van Edwards-krommen voor EdDSA (zelden gebruikt)**\n"
+"\n"
+"* Voldoende:\n"
+"\n"
+" * `Ed448`\n"
+" * `Ed25519`\n"
+"\n"
+"* Onvoldoende:\n"
+"\n"
+" * Andere krommen\n"
+" \n"
+"---\n"
+"\n"
+"Let op: de bovenstaande namen zijn gebaseerd op de [IANA naamgevingsconventies](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals `prime256v1` (ANSI) en `NIST P-256` voor `secp256r1`."
msgid "detail web tls cert-pubkey label"
msgstr "Publieke sleutel van certificaat"
msgid "detail web tls cert-pubkey tech table"
-msgstr "Webserver-IP-adres|Getroffen handtekening-parameters|Status"
+msgstr ""
+"Webserver-IP-adres|Verouderde handtekening-parameter|Beveiligingsniveau"
msgid "detail web tls cert-pubkey verdict bad"
msgstr ""
-"De digitale handtekening van je websitecertificaat gebruikt *onvoldoende* "
-"veilige parameters."
+"De publieke sleutel van tenminste één van je mailserver-certificaten is "
+"*niet* gebaseerd op een veilig ondertekeningsalgoritme met veilige "
+"parameters."
msgid "detail web tls cert-pubkey verdict good"
msgstr ""
-"De digitale handtekening van je websitecertificaat gebruikt veilige "
-"parameters."
+"De publieke sleutel van je websitecertificaat is gebaseerd op een veilig "
+"ondertekeningsalgoritme met veilige parameters."
msgid "detail web tls cert-pubkey verdict phase-out"
msgstr ""
-"De digitale handtekening van je websitecertificaat gebruikt parameters die "
-"de status *uit te faseren* hebben, omdat bekend is dat deze fragiel zijn en "
-"het risico lopen in de toekomst *onvoldoende* veilig te worden."
+"De publieke sleutel van je websitecertificaat is gebaseerd op een "
+"ondertekeningsalgoritme met parameters die zouden moeten worden "
+"*uitgefaseerd* omdat ze zwakker zijn, hoewel je ze nog steeds kunt gebruiken"
+" als het echt nodig is. In een toekomstige update zullen ze waarschijnlijk "
+"onvoldoende zijn."
msgid "detail web tls cert-signature exp"
msgstr ""
-"We testen of de ondertekende fingerprint van het websitecertificaat is gemaakt met een veilig algoritme voor hashing. \n"
+"We testen of je websitecertificaat is ondertekend (door een certificaatautoriteit) met een veilig ondertekeningsalgoritme, waarbij gebruik is gemaakt van een veilige hashfunctie.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B3-2 en tabel 3.\n"
+"Voor meer informatie over de relevante veldnaam in het certificaat, zie paragraaf [\"4.1.1.2. signatureAlgorithm\" van RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#section-4.1.1.2).\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.5.\n"
"\n"
"---\n"
"\n"
-"**Hashfuncties voor certificaatverificatie**\n"
+"**Beveiligingsniveau ondertekeningsalgoritmes**\n"
+"\n"
+"* Voldoende: ECDSA, RSA, EdDSA\n"
+"* Onvoldoende: DSS, EXPORT-*, PSK, Anon, NULL, KRB5\n"
"\n"
-"* Goed: SHA-512, SHA-384, SHA-256\n"
+"**Beveiligingsniveau van hashfuncties**\n"
+"\n"
+"* Goed: SHA-256, SHA-384, SHA-512 \n"
+"* Uitfaseren: SHA-224\n"
"* Onvoldoende: SHA-1, MD5"
msgid "detail web tls cert-signature label"
-msgstr "Handtekening van certificaat"
+msgstr "Handtekening op certificaat"
msgid "detail web tls cert-signature tech table"
-msgstr "Webserver-IP-adres|Getroffen hashing-algoritme|Status"
+msgstr "Webserver-IP-adres|Verouderde hashfunctie|Beveiligingsniveau"
msgid "detail web tls cert-signature verdict bad"
msgstr ""
-"Je websitecertificaat is ondertekend met een algoritme voor hashing dat "
-"*onvoldoende* veilig is."
+"Je websitecertificaat is ondertekend met behulp van een "
+"ondertekeningsalgoritme en hashfunctie die *onvoldoende* veilig zijn."
msgid "detail web tls cert-signature verdict good"
msgstr ""
-"Je websitecertificaat is ondertekend met een voldoende algoritme voor "
-"hashing."
+"Je websitecertificaat is ondertekend met behulp van een "
+"ondertekeningsalgoritme en hashfunctie die veilig zijn."
+
+msgid "detail web tls cert-signature verdict phase-out"
+msgstr ""
+"Je websitecertificaat is ondertekend met behulp van een "
+"ondertekeningsalgoritme en hashfunctie die zouden moeten worden "
+"*uitgefaseerd* omdat ze zwakker zijn, hoewel je ze nog steeds kunt gebruiken"
+" als het echt nodig is. In een toekomstige update zullen ze waarschijnlijk "
+"onvoldoende zijn."
msgid "detail web tls cert-trust exp"
msgstr ""
"We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen. \n"
"\n"
-"Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een [publiekelijk vertrouwde \n"
+"Er is sprake van een geldige vertrouwensketen, als je certificaat is ondertekend door een [publiekelijk vertrouwde \n"
"certificaatautoriteit](https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/) én je webserver alle \n"
-"noodzakelijke tussenliggende certificaten presenteert. \n"
+"noodzakelijke tussenliggende certificaten presenteert. De certificaten mogen niet verlopen zijn.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B3-4."
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 4.4."
msgid "detail web tls cert-trust label"
msgstr "Vertrouwensketen van certificaat"
@@ -3032,22 +3218,22 @@ msgstr ""
msgid "detail web tls cipher-order exp"
msgstr ""
-"We controleren of je webserver cipher suites aanbiedt in aflopende volgorde van hun beveiligingsniveau, zonder een andere voorkeur van de webbrowser te accepteren. \n"
+"We testen of je webserver cipher suites aanbiedt in aflopende volgorde van hun beveiligingsniveau, zonder een andere voorkeur van de webbrowser te accepteren. \n"
"\n"
-"De webserver moet dus zijn eigen voorkeur voor cipher suites afdwingen tijdens de onderhandelingen met een webbrowser. Bovendien moeten cipher suites worden aangeboden door de webserver, waarbij 'Goed' en 'Voldoende' de voorkeur krijgen boven 'Uit te faseren' cipher suites. \n"
+"Je webserver moet dus zijn eigen voorkeur voor cipher suites afdwingen tijdens de onderhandelingen met een webbrowser. Bovendien moeten cipher suites worden aangeboden door je webserver, waarbij 'Goed' en 'Voldoende' de voorkeur krijgen boven 'Uit te faseren' cipher suites. \n"
"\n"
"Wanneer je webserver alleen 'Goed' en 'Voldoende' cipher suites ondersteunt, dan is deze subtest niet van toepassing, aangezien de volgorde geen significant beveiligingsvoordeel oplevert. \n"
"\n"
-"In geval van afwijkende volgorde, wordt in de bovenstaande tabel met technische details de **eerst gevonden** cipher suite weergegeven die door de server wordt geprefereerd en de daarnaast de verwacht geprefereerde cipher suite.\n"
+"In geval van afwijkende volgorde, wordt in de bovenstaande tabel met technische details weergegeven welke 'Uit te faseren' cipher suite door je webserver is gekozen, met in de laatste kolom de 'Goed' of 'Voldoende' cipher suite die eerst gekozen had moeten worden. Alleen de **eerst gevonden** afwijking wordt weergegeven.\n"
"\n"
-"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) van NCSC, paragraaf 2 en 3."
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 2 en 3."
msgid "detail web tls cipher-order label"
-msgstr "Cipher suite volgorde"
+msgstr "Volgorde van cipher suites"
msgid "detail web tls cipher-order tech table"
msgstr ""
-"Web server IP|Cipher suite geprefereerd door server|Verwacht geprefereerd "
+"Web server IP|Cipher suite geprefereerd door server|Verwachte geprefereerde "
"cipher suite"
msgid "detail web tls cipher-order verdict bad"
@@ -3081,7 +3267,7 @@ msgstr ""
msgid "detail web tls ciphers exp"
msgstr ""
-"We checken of je webserver alleen veilige (d.w.z. beveiligingsniveau 'Goed' en/of 'Voldoende') cipher suites ondersteunt. Een webserver ondersteunt meestal meerdere cipher suites.\n"
+"We testen of je webserver alleen veilige (d.w.z. beveiligingsniveau 'Goed' en/of 'Voldoende') cipher suites ondersteunt. Een webserver ondersteunt meestal meerdere cipher suites.\n"
"\n"
"Een cipher suite bestaat uit ciphers voor vier cryptografische functies: 1. sleuteluitwisseling, 2. authenticatie (d.w.z. certificaatverificatie), 3. bulkversleuteling, en 4. hashing.\n"
"\n"
@@ -3091,7 +3277,7 @@ msgstr ""
"\n"
"Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met de manier van testen. \n"
"\n"
-"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) van NCSC, paragraaf 3.3.2 tot en met 3.3.5 en bijlage B.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.2 tot en met 3.3.5 en bijlage B.\n"
"\n"
"---\n"
"\n"
@@ -3162,7 +3348,7 @@ msgid "detail web tls ciphers label"
msgstr "Cipher suites"
msgid "detail web tls ciphers tech table"
-msgstr "Webserver-IP-adres|Getroffen cipher suites|Status"
+msgstr "Webserver-IP-adres|Verouderde cipher suite|Beveiligingsniveau"
msgid "detail web tls ciphers verdict bad"
msgstr ""
@@ -3173,8 +3359,10 @@ msgstr "Je webserver ondersteunt alleen veilige cipher suites."
msgid "detail web tls ciphers verdict phase-out"
msgstr ""
-"Je webserver ondersteunt een of meer cipher suites die de status *uit te "
-"faseren* hebben omdat deze het risico lopen *onvoldoende* veilig te worden."
+"Je webserver ondersteunt één of meer cipher suites die zouden moeten worden "
+"*uitgefaseerd* omdat ze zwakker zijn, hoewel je ze nog steeds kunt gebruiken"
+" als het echt nodig is. In een toekomstige update zullen ze waarschijnlijk "
+"onvoldoende zijn."
msgid "detail web tls compression exp"
msgstr ""
@@ -3183,14 +3371,15 @@ msgstr ""
"Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaad\n"
"kan om deze optie uit te schakelen.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B7-1 en tabel 11.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.4.1.\n"
"\n"
"---\n"
-"**Compressie-optie**\n"
"\n"
-"* Goed: Geen compressie\n"
-"* Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)\n"
-"* Onvoldoende: TLS-compressie"
+"**Beveiligingsniveau van TLS-compressie**\n"
+"\n"
+"* Goed: N.v.t. (TLS 1.3)\n"
+"* Goed: Geen TLS-compressie (TLS 1.2)\n"
+"* Onvoldoende: TLS-compressie (TLS 1.2)"
msgid "detail web tls compression label"
msgstr "TLS-compressie"
@@ -3210,7 +3399,7 @@ msgstr ""
"\n"
"Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het websitedomein, of als er DANE-gerelateerde DNSSEC-issues zijn (bijv. geen bewijs voor 'Denial of Existence').\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, Appendix A, onder 'Certificate pinning en DANE'.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, hoofdstuk \"2 Stappenplan: Hoe kom ik tot een passende TLS configuratie?\".\n"
"\n"
"*Niveau van vereistheid: Optioneel*"
@@ -3303,25 +3492,36 @@ msgstr ""
"De DANE-fingerprint op je domeinnaam is geldig voor je websitecertificaat."
msgid "detail web tls extended-master-secret exp"
-msgstr "This test checks for Extended Master Secret."
+msgstr ""
+"We testen of je webserver Extended Master Secret ondersteunt.\n"
+"\n"
+"Extended Master Secret (EMS), zoals beschreven in [RFC 7627](https://www.rfc-editor.org/rfc/rfc7627), is een uitbreiding voor TLS 1.2 die Triple Handshakes machine-in-the-middle aanvallen voorkomt.\n"
+"\n"
+"Steeds vaker dwingen TLS-bibliotheken standaard EMS af, mede omdat beveiligingsvoorschriften zoals FIPS dit vereisen. Als je server geen ondersteuning biedt voor EMS, kunnen clients die EMS afdwingen geen verbinding via TLS 1.2 met je server tot stand brengen.\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 4.1. "
msgid "detail web tls extended-master-secret label"
msgstr "Extended Master Secret (EMS)"
msgid "detail web tls extended-master-secret tech table"
-msgstr "Web server|EMS result"
+msgstr "Webserver-IP-adres|EMS"
msgid "detail web tls extended-master-secret verdict bad"
-msgstr "EMS is not supported."
+msgstr "Je webserver ondersteunt EMS *niet*."
msgid "detail web tls extended-master-secret verdict good"
-msgstr "EMS is supported."
+msgstr "Je webserver ondersteunt EMS."
msgid "detail web tls extended-master-secret verdict na-no-tls-1-2"
-msgstr "EMS is only available in TLS 1.2, which is not enabled."
+msgstr ""
+"Deze subtest is niet van toepassing, aangezien EMS alleen beschikbaar is in "
+"TLS 1.2, dat niet is ingeschakeld op je webserver."
msgid "detail web tls extended-master-secret verdict unknown"
-msgstr "We could not determine the EMS status."
+msgstr ""
+"Geen resultaat beschikbaar. Op het moment dat de test werd uitgevoerd, "
+"maakte deze subtest nog geen deel uit van de test. "
msgid "detail web tls fs-params exp"
msgstr ""
@@ -3329,27 +3529,28 @@ msgstr ""
"\n"
"**ECDHE**: De veiligheid van de ECDHE-sleuteluitwisseling is afhankelijk van de gebruikte elliptische kromme. We testen welke elliptische kromme wordt gebruikt.\n"
"\n"
-"**DHE**: De veiligheid van de Diffie-Hellman Ephemeral (DHE) sleuteluitwisseling is afhankelijk van de gebruikte finite field-groep. We testen of een van de gestandaardiseerde finite field-groepen die zijn gespecificeerd in [RFC 7919](https://www.rfc-editor.org/rfc/rfc7919) wordt gebruikt. Zelf-gegenereerde groepen hebben het beveiligiungsniveau 'Onvoldoende'. De grotere sleutellengtes die noodzakelijk zijn voor het gebruik van DHE gaan ten koste van de prestaties. Maak een zorgvuldige afweging en gebruik waar mogelijk ECDHE in plaats van DHE.\n"
+"**DHE**: De veiligheid van de Diffie-Hellman Ephemeral (DHE) sleuteluitwisseling is afhankelijk van de gebruikte finite field-groep. We testen of een van de gestandaardiseerde finite field-groepen die zijn gespecificeerd in [RFC 7919](https://www.rfc-editor.org/rfc/rfc7919) wordt gebruikt. Zelf-gegenereerde groepen hebben het beveiligingsniveau 'Onvoldoende'. De grotere sleutellengtes die noodzakelijk zijn voor het gebruik van DHE gaan ten koste van de prestaties. Maak een zorgvuldige afweging en gebruik waar mogelijk ECDHE in plaats van DHE.\n"
"\n"
"**Alternatieven voor ECDHE en DHE**\n"
"\n"
-"* **Kwantumveilige cryptografische algoritmen** `X25519MLKEM768`, `SecP256r1MLKEM768` en `SecP384r1MLKEM1024` hebben beveiligingsniveau 'Goed'. Dit zijn hybride algoritmen die een combinatie van ECDHE en ML-KEM gebruiken. Met name `X25519MLKEM768` wordt steeds vaker ondersteund door TLS-softwarebibliotheken en wordt door de meeste webbrowsers gebruikt. De parameters maken inherent deel uit van deze algoritmen. Er hoeven dus geen aanvullende keuzes te worden gemaakt.\n"
+"* **Quantumveilige cryptografische algoritmen** `X25519MLKEM768`, `SecP256r1MLKEM768` en `SecP384r1MLKEM1024` hebben beveiligingsniveau 'Goed'. Dit zijn hybride algoritmen die een combinatie van ECDHE en ML-KEM gebruiken. Met name `X25519MLKEM768` wordt steeds vaker ondersteund door TLS-softwarebibliotheken en wordt door de meeste webbrowsers gebruikt. De parameters maken inherent deel uit van deze algoritmen. Er hoeven dus geen aanvullende keuzes te worden gemaakt.\n"
"* **RSA en non-ephemeral Diffie-Hellman (ECDH en DH)** moeten *niet* worden gebruikt voor sleuteluitwisseling, aangezien hun beveiligingsniveau 'Onvoldoende' is. Ze bieden geen forward secrecy. Merk op dat RSA nog steeds als 'Voldoende' wordt beschouwd voor authenticatie (d.w.z. certificaatverificatie).\n"
"\n"
-"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) van NCSC, paragraaf 3.3.3.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.3.\n"
"\n"
"\n"
"---\n"
+"\n"
"**Beveiligingsniveau van elliptische krommen voor ECDHE**\n"
"\n"
"* Voldoende:\n"
" \n"
-" * `secp521r1`\n"
+" * `secp521r1` (zelden gebruikt)\n"
" * `secp384r1`\n"
" * `secp256r1`\n"
" * `x448`\n"
" * `x25519`\n"
-" * `brainpoolP512r1` (rarely used)\n"
+" * `brainpoolP512r1` (zelden gebruikt)\n"
" * `brainpoolP384r1` (idem)\n"
" * `brainpoolP256r1` (idem)\n"
"\n"
@@ -3382,10 +3583,10 @@ msgstr ""
"Let op: de bovenstaande namen zijn gebaseerd op de [IANA naamgevingsconventies](https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml). Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals `prime256v1` (ANSI) en `NIST P-256` voor `secp256r1`."
msgid "detail web tls fs-params label"
-msgstr "Sleuteluitwisselingsparameters"
+msgstr "Parameters voor sleuteluitwisseling"
msgid "detail web tls fs-params tech table"
-msgstr "Webserver-IP-adres|Getroffen parameters|Status"
+msgstr "Webserver-IP-adres|Verouderde parameter|Beveiligingsniveau"
msgid "detail web tls fs-params verdict bad"
msgstr ""
@@ -3405,8 +3606,9 @@ msgstr ""
msgid "detail web tls fs-params verdict phase-out"
msgstr ""
"Je webserver ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling "
-"die de status *uit te faseren* hebben, omdat bekend is dat deze fragiel zijn"
-" en het risico lopen in de toekomst *onvoldoende* veilig te worden."
+"die zouden moeten worden *uitgefaseerd* omdat ze zwakker zijn, hoewel je ze "
+"nog steeds kunt gebruiken als het echt nodig is. In een toekomstige update "
+"zullen ze waarschijnlijk onvoldoende zijn."
msgid "detail web tls http-compression exp"
msgstr ""
@@ -3442,7 +3644,7 @@ msgstr ""
"\n"
"HTTPS garandeert de vertrouwelijkheid en integriteit van uitgewisselde informatie. Omdat het van de situatie afhangt hoe (privacy-)gevoelig en waardevol informatie is, is een veilige HTTPS-configuratie voor iedere website van belang. Ook triviale, publieke informatie kan door omstandigheden voor de gebruiker zeer gevoelig en waardevol zijn. \n"
"\n"
-"Merk op dat vanwege performance-redenen alle testen in de categorie 'Beveiligde verbinding (HTTPS)' alleen worden uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres."
+"Houd er rekening mee dat vanwege performance-redenen alle testen in de categorie 'Beveiligde verbinding (HTTPS)' alleen worden uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres."
msgid "detail web tls https-exists label"
msgstr "HTTPS beschikbaar"
@@ -3461,7 +3663,7 @@ msgstr "Je webserver is niet bereikbaar."
msgid "detail web tls https-forced exp"
msgstr ""
-"We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP. \n"
+"We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 30x redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP. \n"
"\n"
"In geval van doorverwijzing moet de domeinnaam eerst zelf 'upgraden' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:\n"
"\n"
@@ -3500,31 +3702,27 @@ msgid "detail web tls https-hsts exp"
msgstr ""
"We testen of je webserver HSTS ondersteunt. \n"
"\n"
-"Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.\n"
+"Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor Machine-in-the-Middle-aanvallen (MitM). Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.\n"
"\n"
-"HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt man-in-the-middle-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van *tenminste* 1 jaar (`max-age=31536000`) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen. \n"
+"HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt MitM-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van *tenminste* 1 jaar (`max-age=31536000`) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen. \n"
"\n"
"De test controleert **niet** of `preload` wordt gebruikt en of het domein is opgenomen in de [HSTS Preload Lijst](https://hstspreload.org/).\n"
"\n"
"---\n"
+"\n"
"**Aanbevelingen voor implementatie**\n"
"\n"
"HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze *niet bereikbaar* zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen. \n"
"\n"
"Daarom adviseren we u om de onderstaande implementatiestappen te volgen:\n"
"\n"
-"1․ Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);\n"
-"\n"
-"2․ Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina's. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.\n"
+"1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);\n"
"\n"
-"* Begin met 5 minuten (`max-age=300`);\n"
-"* Verhoog dit naar 1 week (`max-age=604800`);\n"
-"* Verhoog dit naar 1 maand (`max-age=2592000`);\n"
-"* Verhoog het naar 1 jaar (`max-age=31536000`) of meer.\n"
+"2. Verhoog de geldigheidsduur van de HSTS-cache in fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina's. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af, voordat je naar de volgende fase gaat.\n"
"\n"
-"3․ Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik `includeSubDomains` alleen als je er volledig zeker van bent dat **alle** (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.\n"
+"3. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik `includeSubDomains` alleen als je er volledig zeker van bent dat **alle** (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.\n"
"\n"
-"4․ Gebruik `preload` **alleen** als je heel zeker weet dat je je domein wil laten opnemen in de [HSTS Preload Lijst](https://hstspreload.org/). HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien. \n"
+"4. Gebruik `preload` **alleen** als je heel zeker weet dat je je domein wil laten opnemen in de [HSTS Preload Lijst](https://hstspreload.org/). HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien. \n"
"\n"
"---\n"
"\n"
@@ -3553,24 +3751,30 @@ msgstr ""
"\n"
"De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.\n"
"\n"
-"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) van NCSC, paragraaf 3.3.5. Voor meer details over de status van SHA-1 en MD5 zie [RFC 9155](https://www.rfc-editor.org/rfc/rfc9155.html#name-server-key-exchange). We testen niet op MD5 omdat dit alleen nog maar door zeer verouderde software wordt ondersteund.\n"
+"Houd er rekening mee dat deze subtest alleen van toepassing is op TLS 1.2 en niet op TLS 1.3. De ondersteunde hashfuncties kunnen worden geconfigureerd via een aparte TLS-instelling (bijvoorbeeld `SignatureAlgorithms` in OpenSSL) en maken *geen* deel uit van de configuratie van de cipher suites. \n"
+"\n"
+"Voor meer details over de status van SHA-1 en MD5 zie [RFC 9155](https://www.rfc-editor.org/rfc/rfc9155.html#name-server-key-exchange). We testen niet op MD5 omdat dit alleen nog maar door zeer verouderde software wordt ondersteund.\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.5. \n"
"\n"
"---\n"
"\n"
"**Beveiligingsniveau van hashfuncties voor sleuteluitwisseling**\n"
"\n"
"* Goed: SHA-256, SHA-384, SHA-512 \n"
-"* Uitfaseren: SHA-224\n"
+"* Uitfaseren: SHA-224 (zelden gebruikt)\n"
"* Onvoldoende: SHA-1, MD5"
msgid "detail web tls kex-hash-func label"
msgstr "Hashfunctie voor sleuteluitwisseling"
msgid "detail web tls kex-hash-func tech table"
-msgstr "Web server IP address|Outdated signature algorithm result"
+msgstr "Webserver-IP-adres|Verouderde hashfunctie"
msgid "detail web tls kex-hash-func verdict bad"
msgstr ""
+"Je webserver ondersteunt een of meer *onvoldoende* veilige hashfuncties voor"
+" sleuteluitwisseling."
msgid "detail web tls kex-hash-func verdict good"
msgstr ""
@@ -3586,9 +3790,10 @@ msgstr ""
msgid "detail web tls kex-hash-func verdict phase-out"
msgstr ""
-"Je webserver ondersteunt een hashfunctie voor sleuteluitwisseling die je "
-"weloverwogen dient *uit te faseren*, omdat deze het risico loopt in de "
-"toekomst *onvoldoende* veilig te worden. "
+"Je webserver ondersteunt een hashfunctie voor sleuteluitwisseling die zouden"
+" moeten worden *uitgefaseerd* omdat deze zwakker is, hoewel je deze nog "
+"steeds kunt gebruiken als het echt nodig is. In een toekomstige update zal "
+"deze waarschijnlijk onvoldoende zijn."
msgid "detail web tls kex-hash-func verdict {phase-out}"
msgstr ""
@@ -3615,22 +3820,28 @@ msgstr ""
msgid "detail web tls ocsp-stapling exp"
msgstr ""
-"We testen of je webserver de [TLS Certificate Status extension](https://www.rfc-editor.org/rfc/rfc6961) of te wel OCSP stapling ondersteunt. \n"
+"We testen of je webserver de [TLS Certificate Status extension](https://www.rfc-editor.org/rfc/rfc6961) (oftewel OCSP stapling) ondersteunt, indien je websitecertificaat een verwijzing naar een OCSP-server bevat.\n"
+"\n"
+"Let op dat we de OCSP-data niet gebruiken om de geldigheid van het certificaat te controleren. Houd er bovendien rekening mee dat OCSP door verschillende certificaatleveranciers niet meer wordt gebruikt. Als je websitecertificaat geen verwijzing naar een OCSP-server bevat, dan zal deze subtest slagen.\n"
"\n"
-"De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.\n"
+"De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een webserver kan de OCSP-data ook zelf direct verstrekken aan de webbrowser via OCSP stapling. Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.\n"
"\n"
-"Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifiëren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.\n"
+"Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifiëren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. \n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, tabel 15.\n"
+"\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS\n"
+") van NCSC, paragraaf 3.4.5.\n"
"\n"
"*Niveau van vereistheid: Optioneel*\n"
"\n"
"---\n"
"\n"
-"**OCSP stapling**\n"
+"**Beveiligingsniveau van OCSP-stapling**\n"
"\n"
-"* Goed: Aan\n"
-"* Voldoende: Uit"
+"* Goed: Certificaat zonder OCSP-verwijzing\n"
+"* Goed: Certificaat met OCSP-verwijzing, stapling ingeschakeld en valide OCSP-data\n"
+"* Onvoldoende: Certificaat met OCSP-verwijzing, stapling ingeschakeld, maar geen valide OCSP-data\n"
+"* Ter informatie: Certificaat met OCSP-verwijzing, maar stapling niet ingeschakeld"
msgid "detail web tls ocsp-stapling label"
msgstr "OCSP stapling"
@@ -3647,9 +3858,13 @@ msgstr "Je webserver ondersteunt OCSP en de data in het antwoord is valide."
msgid "detail web tls ocsp-stapling verdict not-in-cert"
msgstr ""
+"Je websitecertificaat bevat geen OCSP-verwijzing, waardoor OCSP-stapling "
+"niet van toepassing is."
msgid "detail web tls ocsp-stapling verdict ok"
-msgstr "Je webserver ondersteunt OCSP *niet*."
+msgstr ""
+"Je webserver ondersteunt OCSP *niet*, hoewel je websitecertificaat een OCSP-"
+"verwijzing bevat."
msgid "detail web tls renegotiation-client exp"
msgstr ""
@@ -3661,18 +3876,19 @@ msgstr ""
"\n"
"Merk op dat client-initiated renegotiation impact kan hebben op de beschikbaarheid, maar niet op de vertrouwelijkheid.\n"
"\n"
-"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) van NCSC, paragraaf 3.4.2.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS\n"
+") van NCSC, paragraaf 3.4.2.\n"
"\n"
"*Niveau van vereistheid: Aanbevolen*\n"
"\n"
"---\n"
"\n"
-"**Beveiligingsniveaus van client-initiated renegotiation**\n"
+"**Beveiligingsniveau van client-initiated renegotiation**\n"
"\n"
-"* Goed: Nee, n.v.t. (TLS 1.3)\n"
-"* Goed: Nee, uit (TLS 1.2)\n"
-"* Voldoende: Gelimiteerd (TLS 1.2)\n"
-"* Uitfaseren: Ongelimiteerd (TLS 1.2)"
+"* Goed: N.v.t. (TLS 1.3)\n"
+"* Goed: Geen renegotiation (TLS 1.2)\n"
+"* Voldoende: Gelimiteerde renegotiation (TLS 1.2)\n"
+"* Uit te faseren: Ongelimiteerd renegotiation (TLS 1.2)"
msgid "detail web tls renegotiation-client label"
msgstr "Client-initiated renegotiation"
@@ -3708,13 +3924,15 @@ msgstr ""
"\n"
"In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten 'opnieuw onderhandelen' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B8-1 en tabel 12.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.4.2.\n"
"\n"
"---\n"
+"\n"
"**Insecure renegotiation**\n"
"\n"
-"* Goed: Uit (of n.v.t. voor TLS 1.3)\n"
-"* Onvoldoende: Aan "
+"* Goed: N.v.t. (TLS 1.3)\n"
+"* Goed: Geen insecure renegotiation (TLS 1.2)\n"
+"* Onvoldoende: Insecure renegotiation (TLS 1.2)"
msgid "detail web tls renegotiation-secure label"
msgstr "Secure renegotiation"
@@ -3738,9 +3956,10 @@ msgstr ""
"\n"
"Houd er rekening mee dat moderne browsers TLS 1.0/1.1 en SSL niet langer ondersteunen. Als gevolg hiervan zijn websites die TLS 1.2 en/of 1.3 niet ondersteunen voor vrijwel niemand bereikbaar.\n"
"\n"
-"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) van NCSC, paragraaf 3.3.1.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.3.1.\n"
"\n"
"---\n"
+"\n"
"**Beveiligingsniveau van TLS-versies**\n"
"\n"
"* Goed: TLS 1.3\n"
@@ -3773,13 +3992,15 @@ msgstr ""
"\n"
"Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina `/` opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor [early data](https://www.openssl.org/docs/manmaster/man3/SSL_get_max_early_data.html) zoals [aangegeven](https://www.rfc-editor.org/rfc/rfc8446#section-4.2.10) door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging _vóór_ de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-[HTTP 425 Too Early](https://www.rfc-editor.org/rfc/rfc8470#section-5.2), dan wordt aangenomen dat de webserver 0-RTT ondersteunt.\n"
"\n"
-"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn B9-1 en tabel 14.\n"
+"Zie ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security/ICT-beveiligingsrichtlijnen-voor-TLS) van NCSC, paragraaf 3.4.4.\n"
"\n"
"---\n"
-"**0-RTT**\n"
"\n"
-"* Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)\n"
-"* Onvoldoende: Aan"
+"**Beveiligingsniveau van 0-RTT**\n"
+"\n"
+"* Goed: Geen 0-RTT (TLS 1.3)\n"
+"* Goed: N.v.t. (TLS 1.2)\n"
+"* Onvoldoende: Wel 0-RTT (TLS 1.3)"
msgid "detail web tls zero-rtt label"
msgstr "0-RTT"
@@ -3795,15 +4016,15 @@ msgstr "Je webserver ondersteunt geen 0-RTT."
msgid "detail web tls zero-rtt verdict na"
msgstr ""
-"Deze subtest is niet van toepassing aangezien je webserver TLS 1.3 niet "
-"ondersteunt. "
+"Deze subtest is niet van toepassing, aangezien 0-RTT alleen beschikbaar is "
+"in TLS 1.3, dat niet is ingeschakeld op je webserver."
msgid "detail web-mail ipv6 ns-AAAA exp"
msgstr ""
"We testen of je domeinnaam tenminste twee nameservers met een IPv6-adres \n"
"heeft. \n"
"\n"
-"Dit sluit aan bij de [\"Technische eisen voor registratie en gebruik van .nl-domeinnamen\"](https://www.sidn.nl/downloads/7li2X9A-Q1-_qkgnZn1TAg/02066e69fc93d5b64b4aa16c469c38f6/Technische_eisen_voor_registratie_en_gebruik_van_nl_domeinamen.pdf) d.d. 13 november 2017 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.\n"
+"Dit sluit aan bij de [\"Technische eisen voor registratie en gebruik van .nl-domeinnamen\"](https://www.sidn.nl/nl-domeinnaam/technische-eisen-voor-registratie-en-gebruik-van-nl-domeinnamen) d.d. 1 januari 2023 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.\n"
"\n"
"'IPv4-mapped IPv6 addresses' ([RFC 4291](https://www.rfc-editor.org/rfc/rfc4291), beginnend met ::ffff:) zullen falen in deze test, aangezien zij *geen* IPv6-connectiviteit bieden."
@@ -4106,10 +4327,9 @@ msgstr "Batch API en webgebaseerd dashboard"
#, md-format
msgid "faqs content"
msgstr ""
-"## Testen\n"
-"* [Over de websitetest](/test-site/)\n"
-"* [Over de e-mailtest](/test-mail/)\n"
-"* [Over de verbindingstest](/test-connection/)\n"
+"## Achtergrond\n"
+"* Over [websitetest](/test-site/), [e-mailtest](/test-mail/), en [verbindingstest](/test-connection/)\n"
+"* [Video-opnames van presentaties](/faqs/video/)\n"
"\n"
"## Standaarden\n"
"* [Modern adres (IPv6)](/faqs/ipv6/)\n"
@@ -4186,7 +4406,7 @@ msgstr ""
"* **Volgorde:** De namen van de hosters in de Hall of Fame worden telkens getoond in willekeurige volgorde.\n"
"\n"
"## Geautomatiseerde controles op compliance\n"
-"Het [Internet.nl dashboard](https://dashboard.internet.nl) wordt gebruikt om regelmatig te controleren of de hosters die in de Hall of Fame voor Hosters staan nog steeds een dubbele 100%-score (mail en web) scoren voor hun eigen domein. Dit is een geautomatiseerde controle en wordt twee keer per maand uitgevoerd. De [testrapporten voor de opgenomen hosters](https://dashboard.internet.nl/#/published/103/) zijn openbaar beschikbaar.\n"
+"Het [Internet.nl dashboard](https://dashboard.internet.nl) wordt gebruikt om regelmatig te controleren of de hosters die in de Hall of Fame voor Hosters staan nog steeds een dubbele 100%-score (mail en web) scoren voor hun eigen domein. Dit is een geautomatiseerde controle en wordt twee keer per maand uitgevoerd. De [testrapporten voor de opgenomen hosters](https://dashboard.internet.nl/published/103/) zijn openbaar beschikbaar.\n"
"\n"
"## Verwijdering \n"
"Niet-conforme hosters worden handmatig verwijderd op basis van de volgende criteria en regels:\n"
@@ -4217,18 +4437,18 @@ msgstr ""
"* [Pulse - TLS1.3 metric](https://pulse.internetsociety.org/en/technologies/#metric-tls13) door Internet Society\n"
"\n"
"## Achtergrondinformatie\n"
-"* [\"ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), versie 2.1\"](https://www.ncsc.nl/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) door NCSC-NL\n"
-"* [\"ICT-beveiligingsrichtlijnen voor webapplicaties\"](https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties) door NCSC-NL\n"
+"* ['Transport Layer Security (TLS), Beveiligingsrichtlijnen versie 2025-05'](https://www.ncsc.nl/transport-layer-security-tls/richtlijnen2025-05) door NCSC\n"
+"* ['ICT-beveiligingsrichtlijnen voor webapplicaties'](https://www.ncsc.nl/webapplicaties/ict-beveiligingsrichtlijnen-webapplicaties) door NCSC\n"
"* [Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/)\n"
"* [Bettercrypto.org](https://bettercrypto.org)\n"
"* [How HTTPS works](https://howhttps.works/)\n"
"\n"
"## Specificaties\n"
"### HTTPS\n"
-"* [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110)\n"
+"* [RFC 9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc9325.html)\n"
+"* [RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://www.rfc-editor.org/rfc/rfc8996.html)\n"
"* [RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446)\n"
"* [RFC 5246: The Transport Layer Security (TLS) Protocol, Version 1.2](https://www.rfc-editor.org/rfc/rfc5246)\n"
-"* [RFC 9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)](https://www.rfc-editor.org/rfc/rfc9325.html)\n"
"* [RFC 6797: HTTP Strict Transport Security (HSTS)](https://www.rfc-editor.org/rfc/rfc6797)\n"
"\n"
"### CAA\n"
@@ -4249,7 +4469,6 @@ msgid "faqs ipv6 content"
msgstr ""
"## Waarom\n"
"* [\"Three reasons why IPv6 is worth the effort\"](https://blog.apnic.net/2018/12/13/three-reasons-why-ipv6-is-worth-the-effort/) by Nick Buraglio\n"
-"* [\"Making a Strong Case for IPv6\"](https://www.baselinemag.com/networking/making-a-strong-case-for-ipv6/) door John Curran (ARIN)\n"
"* [\"IPv6: It's time to get on board\"](https://engineering.fb.com/networking-traffic/ipv6-it-s-time-to-get-on-board/) door Paul Saab (Facebook)\n"
"* [\"Reasons for IPv6\"](https://ipv6now.com.au/primers/IPv6Reasons.php) door IPv6NOW\n"
"\n"
@@ -4310,7 +4529,7 @@ msgstr ""
"De [batch API en webgebaseerd dashboard](/faqs/batch-and-dashboard/) worden door honderden gebruikers gebruikt. Sommige organisaties hergebruiken de testresultaten in hun eigen openbare websites of rapporten. Hieronder staan enkele voorbeelden.\n"
"\n"
"- [Basisbeveiliging](https://basisbeveiliging.nl/)\n"
-"- [CBS: Toepassing van Internetstandaarden voor websites van bedrijven](https://www.cbs.nl/nl-nl/longread/aanvullende-statistische-diensten/2024/toepassing-van-internetstandaarden-voor-websites-van-bedrijven-2023)\n"
+"- [CBS: Toepassing van Internetstandaarden voor websites van bedrijven](https://www.cbs.nl/nl-nl/longread/aanvullende-statistische-diensten/2025/toepassing-van-internetstandaarden-voor-websites-van-bedrijven-2024)\n"
"- [Digital Insights Platform](https://www.digitalinsightsplatform.nl/)\n"
"- [European Commissie: EU Internet Standards Deployment Monitoring Website](https://ec.europa.eu/internet-standards/)\n"
"- [Forum Standaardisatie: Meting Informatieveiligheidstandaarden](https://www.forumstandaardisatie.nl/metingen/informatieveiligheidstandaarden)\n"
@@ -4435,6 +4654,7 @@ msgstr ""
"* [Route Origin Authorisation (ROA) statistieken](https://roa-stats.manrs.org/) door MANRS\n"
"* [.nl-statistieken voor Route Origin Authorisation (ROA)](https://stats.sidnlabs.nl/nl/web.html#secure%20routing%20(rpki)) door SIDN Labs\n"
"* [Route Origin Validation (ROV) statistieken](https://stats.labs.apnic.net/rpki) door APNIC\n"
+"* [RIPEstat - RPKI by country](https://stat.ripe.net/resource/nl#tab=routing) door RIPE NCC\n"
"\n"
"## Achtergrondinformatie\n"
"* [RPKI Documentation](https://rpki.readthedocs.io) door het RPKI-team bij NLnet Labs en de RPKI-community\n"
@@ -4482,6 +4702,17 @@ msgstr "Beveiligd e-mailtransport (STARTTLS en DANE)"
msgid "faqs title"
msgstr "Kennisbank"
+msgid "faqs video content"
+msgstr ""
+"* [Benjamin @ FOSDEM2026](https://fosdem.org/2026/schedule/event/H9GEBT-fos-check-tooling-for-mail-config/) (2026-01-31)\n"
+"* [Sasha @ NLNOG Day 2025](https://nlnog.net/events/past-events/nlnog-day-2025/) (2025-09-30)\n"
+"* [Gerben and Bart @ IX Fórum Setor Público 2025](https://setorpublico.forum.ix.br/anteriores/2025/) (2025-09-17)\n"
+"* [Benjamin @ WHY2025](https://media.ccc.de/v/why2025-258-how-not-to-configure-your-domainname-internet-nl) (2025-08-11)\n"
+"* [Benjamin @ RIPE86](https://ripe86.ripe.net/archives/video/1028/) (2023-05-24)"
+
+msgid "faqs video title"
+msgstr "Video-opnames van presentaties"
+
msgid "halloffame champions menu"
msgstr "Kampioenen!"
@@ -4624,7 +4855,7 @@ msgid "privacy content"
msgstr ""
"# Privacyverklaring\n"
"\n"
-"*Herzien op 28 januari 2025*\n"
+"*Herzien op 25 maart 2025*\n"
"\n"
"Platform Internetstandaarden respecteert jouw privacy en streeft ernaar het verzamelen en het verwerken van jouw persoonsgegevens tot een minimum te beperken. Met deze privacyverklaring, willen we je graag informeren over welke persoonsgegevens we verzamelen als je onze website en andere diensten op Internet.nl gebruikt en hoe we deze gegevens verwerken. Je rechten zijn vastgelegd in de van toepassing zijnde wetten, met name de [Europese Algemene verordening gegevensbescherming (AVG)](https://eur-lex.europa.eu/legal-content/NL/TXT/HTML/?uri=CELEX:32016R0679) en de [Nederlandse Telecommunicatiewet](https://wetten.overheid.nl/BWBR0009950/).\n"
"\n"
@@ -4699,9 +4930,6 @@ msgstr ""
"### Sentry\n"
"We gebruiken [Sentry](https://sentry.io/) om crashes en soortgelijke bugs in tests of pagina's te loggen. Hiervoor sturen we Sentry het domein dat wordt getest, alle informatie die in de test wordt verzameld, en de HTTP-headers van het verzoek. We nemen het IP-adres van je client niet op in de informatie die we naar Sentry sturen. Informatie wordt alleen verzonden in het geval van crashende tests of pagina's. Over uitgevoerde tests of opgevraagde pagina's die niet leiden tot crashes wordt geen informatie gedeeld.\n"
"\n"
-"### Publieke DNS-resolvers\n"
-"Het [Internet.nl-dashboard](https://dashboard.internet.nl) controleert met behulp van de volgende publieke DNS-resolvers of een gegeven domeinnaam geldige DNS-antwoorden teruggeeft en testbaar is: [CZ.NIC](https://www.nic.cz/page/4219/kopie-otevrene-dnssec-validujici-resolvery/), [Quad9](https://www.quad9.net/) en [dns0.eu](https://www.dns0.eu/).\n"
-"\n"
"## Welke maatregelen zijn genomen om de verzamelde data te beveiligen?\n"
"\n"
"### Toegang en derde partijen\n"
@@ -4812,10 +5040,14 @@ msgid "results further-testing connection content"
msgstr ""
"- ### IPv6:\n"
" - [IPv6 test](https://ipv6-test.com/)\n"
+"\n"
"- ### DNSSEC-validatie:\n"
-" - [DNSSEC resolver algorithm test](https://rootcanary.org/test.html) \n"
+" - [DNSSEC resolver algorithm test](https://rootcanary.org/test.html)\n"
+" - [Check My DNS](https://cmdns.dev.dns-oarc.net/)\n"
+" \n"
"- ### HTTPS:\n"
" - [SSL Client Test](https://www.ssllabs.com/ssltest/viewMyClient.html)\n"
+" \n"
"- ### RPKI-validatie\n"
" - [RPKI Webtest](https://rpkitest.nlnetlabs.net/)\n"
" - [Is BGP safe yet?](https://isbgpsafeyet.com/)"
diff --git a/translations/nl/manual_hof.po b/translations/nl/manual_hof.po
index 04a75764a..8a0056928 100644
--- a/translations/nl/manual_hof.po
+++ b/translations/nl/manual_hof.po
@@ -17,7 +17,7 @@ msgstr ""
"\n"
"Deze hosters mogen de 'Internet.nl compliant badge' die op deze pagina wordt getoond gebruiken in hun eigen communicatie.\n"
"\n"
-"De scores van de eigen domeinen van de opgenomen hosters worden automatisch [gecontroleerd en gepubliceerd](https://dashboard.internet.nl/#/published/103/).\n"
+"De scores van de eigen domeinen van de opgenomen hosters worden automatisch [gecontroleerd en gepubliceerd](https://dashboard.internet.nl/published/103/).\n"
"\n"
"---"
diff --git a/translations/nl/news.po b/translations/nl/news.po
index 3059c686f..338033575 100644
--- a/translations/nl/news.po
+++ b/translations/nl/news.po
@@ -4,6 +4,8 @@ msgstr ""
msgid "article .index"
msgstr ""
+"release-1.11\n"
+"plis-meeting-dec-2025\n"
"punktum-dk-contribution\n"
"plis-meeting-sept-2025\n"
"release-1.10\n"
@@ -561,7 +563,7 @@ msgstr ""
"* De detectie van een internetprovider is nauwkeuriger en heeft minder vaak time-outs.\n"
"\n"
"## Websitetest\n"
-"* De test checkt of er een HSTS-policy aanwezig is. Door HSTS 'weet' een webbrowser na het eerste bezoek dat een website alleen via een beveiligde verbinding (HTTPS en niet HTTP) bezocht mag worden. Dit kan zogeheten man-in-the-middle-aanvallen voorkomen, zoals bij het gebruik van publieke WiFi. Bij afwijkingen is de melding niet langer 'oranje' maar 'rood'.\n"
+"* De test checkt of er een HSTS-policy aanwezig is. Door HSTS 'weet' een webbrowser na het eerste bezoek dat een website alleen via een beveiligde verbinding (HTTPS en niet HTTP) bezocht mag worden. Dit kan zogeheten Machine-in-the-Middle-aanvallen (MitM) voorkomen, zoals bij het gebruik van publieke WiFi. Bij afwijkingen is de melding niet langer 'oranje' maar 'rood'.\n"
"* In de test telt nu mee of de website HTTPS afdwingt door een server redirect (301 of 302) of door alleen HTTPS (en geen HTTP) toe te passen. Bij afwijkingen is de melding niet langer 'oranje' maar 'rood'.\n"
"* De TLS-resultaten gaven bij een aantal sites onterecht de melding dat 'client-initiated renegotiation' was toegestaan. Dit is opgelost.\n"
"* Bij websites met een redirect van IPv6/IPv4 naar IPv4-only werd de HSTS-policy over IPv6 onterecht niet gedetecteerd. Dit is opgelost.\n"
@@ -882,7 +884,7 @@ msgstr ""
"\n"
"\n"
"## Minimale max-age voor HSTS uitgebreid\n"
-"HTTP Strict Transport Security ([HSTS](https://www.rfc-editor.org/rfc/rfc6797)) dwingt een webbrowser om direct via HTTPS te verbinden bij het opnieuw bezoeken van je website. Dit helpt bij het voorkomen van man-in-the-middle aanvallen. We hebben besloten om de minimum HSTS cache geldigheidsduur te verlengen van 6 maanden naar 1 jaar (`max-age=31536000`). Dit is in overeenstemming met de gangbare good practices. \n"
+"HTTP Strict Transport Security ([HSTS](https://www.rfc-editor.org/rfc/rfc6797)) dwingt een webbrowser om direct via HTTPS te verbinden bij het opnieuw bezoeken van je website. Dit helpt bij het voorkomen van Machine-in-the-Middle-aanvallen (MitM). We hebben besloten om de minimum HSTS cache geldigheidsduur te verlengen van 6 maanden naar 1 jaar (`max-age=31536000`). Dit is in overeenstemming met de gangbare good practices. \n"
"\n"
"Meer details over de bovenstaande verbeteringen zijn te vinden in de testuitleg van de betreffende subtests van de [websitetest](/test-site/) en de [e-mailtest](/test-mail/). \n"
"\n"
@@ -957,7 +959,7 @@ msgstr ""
"De meest in het oog springende verbeteringen staan hieronder.\n"
"\n"
"1. De vorige versie van Internet.nl testte de veiligheid van de HTTPS-configuratie over IPv6 óf over IPv4. Omdat we via handmatig testen regelmatig websites tegen zijn gekomen die onbedoeld verschillende HTTPS-configuraties over IPv6 en IPv4 hanteren, wordt vanaf nu de **HTTPS-configuratie zowel over IPV6 als over IPv4** getest. Het resultaat van dit uitgebreide testonderdeel weegt **vanaf nu** mee in de score van de websitetest.\n"
-"2. Voor websites wordt nu ook getest of er een **HSTS-policy** aanwezig is. HSTS zorgt ervoor dat een webbrowser na het eerste bezoek weet dat een website alleen over HTTPS bezocht mag worden. Hiermee kunnen zogeheten man-in-the-middle-aanvallen (bijvoorbeeld als gebruik wordt gemaakt van een publieke wifi-hotspot) worden voorkomen. Het resultaat van dit nieuwe testonderdeel komt nu bij afwijking terug als oranje waarschuwing en telt nog niet mee in de score van de websitetest. **Vanaf juli 2016** weegt het resultaat wel mee in de score.\n"
+"2. Voor websites wordt nu ook getest of er een **HSTS-policy** aanwezig is. HSTS zorgt ervoor dat een webbrowser na het eerste bezoek weet dat een website alleen over HTTPS bezocht mag worden. Hiermee kunnen zogeheten Machine-in-the-Middle-aanvallen (MitM; bijvoorbeeld als gebruik wordt gemaakt van een publieke wifi-hotspot) worden voorkomen. Het resultaat van dit nieuwe testonderdeel komt nu bij afwijking terug als oranje waarschuwing en telt nog niet mee in de score van de websitetest. **Vanaf juli 2016** weegt het resultaat wel mee in de score.\n"
"3. De website-test controleert nu ook of door websites **HTTPS afgedwongen** wordt. Het afdwingen kan op de twee onderstaande manieren. Het resultaat van dit nieuwe testonderdeel komt bij afwijking terug als oranje waarschuwing en telt nog niet mee in de score van de websitetest. **Vanaf juli 2016** weegt het resultaat wel mee in de score.\n"
" 1. Door HTTP naar HTTPS te 'redirecten'. Dat kan door `http://example.nl` naar `https://example.nl` te laten verwijzen. Het is belangrijk dat het identieke domeinen zijn omdat een webbrowser alleen een HSTS-policy voor een bepaalde domeinnaam accepteert over een HTTPS-verbinding. Als `http://example.nl` doorverwijst naar `https://www.example.nl` dan zal de HSTS-policy bij normaal gebruik niet voor `example.nl` in de browser worden opgeslagen, tenzij een gebruiker bewust `https://example.nl` intoetst of hierop als link klikt.\n"
" 2. Door alleen HTTPS en geen HTTP te ondersteunen. Doordat een browser normaal gesproken bij het intoetsen van een domeinnaam een HTTP-verbinding opzet moeten gebruikers bewust `https://example.nl` intoetsen om de website te bereiken of daarop als link klikken.\n"
@@ -1148,6 +1150,135 @@ msgstr ""
msgid "article paneldiscussie-the-power-of-internet-standards title"
msgstr "Paneldiscussie: The Power of Internet Standards"
+msgid "article plis-meeting-dec-2025 body"
+msgstr ""
+"## Introductie RDI\n"
+"Brenda Langedijk, specialistisch inspecteur bij de RDI, gaf een introductie van de RDI, die sinds 2023 lid is van het Platform Internetstandaarden.\n"
+"\n"
+"De RDI staat voor de beschikbaarheid en betrouwbaarheid van IT- en communicatienetwerken, zodat Nederland veilig verbonden is. Hiertoe houdt de RDI onder meer toezicht op de [Cyberbeveiligingswet (Cbw)](https://www.rdi.nl/onderwerpen/cyberveiligheid/cyberbeveiligingswet), de Nederlandse implementatie van de Europese NIS2-richtlijn (Network and Information Systems Directive). Naar verwachting treedt de Cbw in het tweede kwartaal van 2026 in werking.\n"
+"\n"
+"De Cbw gaat gelden voor essentiële en belangrijke organisaties in verschillende sectoren, zoals energie, ruimtevaart, onderzoek, digitale infrastructuur en overheid. Ook grotere bedrijven in andere sectoren kunnen onder de wet vallen.\n"
+"\n"
+"Organisaties die onder de Cbw vallen, krijgen onder andere te maken met de registratieplicht, zorgplicht en meldplicht. De overheid adviseert organisaties om zich hier nu alvast op voor te bereiden, door bijvoorbeeld een [risicoafweging](https://www.rdi.nl/onderwerpen/cyberveiligheid/cyberbeveiligingswet/risicomanagement) te maken. Onder andere [cloudserviceproviders](https://www.rdi.nl/onderwerpen/cyberveiligheid/cloud/toezicht-rdi) kunnen hier op de website van RDI meer over lezen. Het is nu al mogelijk vrijwillig te registreren op [mijn.ncsc.nl](https://mijn.ncsc.nl/).\n"
+"\n"
+"Vaak wordt gesteld dat er geen mogelijkheden zijn als het om uitbesteden naar Cloudoplossingen en hyperscalers gaat, maar een voorbeeld om zelf een risicoafweging te kunnen doen is gebruik te maken van de [Cloud Control Matrix](https://cloudsecurityalliance.org/research/cloud-controls-matrix) van de Cloud Security Alliance (CSA).\n"
+"\n"
+"De RDI houdt op verschillende manieren toezicht op de Cbw: van verschillende vormen van voorlichting tot inspecties op locatie. Zij werkt hierbij samen met andere toezichthouders op wetten rondom digitale weerbaarheid.\n"
+"In verband met strategische autonomie, is ook de Wet veiligheidstoets investeringen, fusies en overnames (Wet vifo) relevant. Op de naleving van deze wet wordt toezicht gehouden door het [Bureau Toetsing Investeringen (BTI)](https://www.bureautoetsinginvesteringen.nl/), dat onder de Minister van Economische Zaken valt. \n"
+"\n"
+"## Terugblik en vooruitblik evenementen\n"
+"De vorige bijeenkomst van het Platform Internetstandaarden vond plaats op 18 september 2025 bij [ECP | Platform voor de InformatieSamenleving](https://ecp.nl/) in Den Haag. Sindsdien waren platformleden actief bij diverse externe evenementen, als organisator, spreker of bezoeker.\n"
+"\n"
+"Sasha Romijn (Internet.nl) nam deel aan NLNOG Day 2025 op 30 september in Amsterdam. Zij presenteerde er ‘[The How and Why of Internet.nl](https://www.youtube.com/watch?v=ZEtglnvTSyc)’ en deelde hierin onder meer feedback van de NLNOG-gemeenschap op Internet.nl.\n"
+"\n"
+"Gerben Klein Baltink (Platform Internetstandaarden) en Wouter Kobes (Forum Standaardisatie) namen op 30 oktober deel aan de Logius Roadshow. Tijdens de sessie ‘Veilige en beheersbare domeinnamen binnen de overheid’ gaven zij aandacht aan het [webgebaseerde dashboard](https://nl.internet.nl/faqs/batch-and-dashboard/) van Internet.nl.\n"
+"\n"
+"Vooruitkijkend staan er ook weer belangrijke evenementen op de agenda, zoals [39C3](https://events.ccc.de/congress/2025/infos/startpage.html) (27 tot 30 december 2025), [FOSDEM 2026](https://fosdem.org/2026/) (31 januari tot 1 februari 2026), [Domain pulse 2026](https://domainpulse.ch/#E586F2) (4 tot 5 februari 2026), [M3AAWG](https://www.m3aawg.org/upcoming-meetings) (16 tot 19 februari 2026), [ICANN85](https://meetings.icann.org/en/meetings/icann85/) (7 tot 12 maart 2026), [IETF 125](https://www.ietf.org/meeting/125/) (13 tot 20 maart 2026) en [Cloudfest 2026](https://www.cloudfest.com/) (23 tot 26 maart 2026).\n"
+"\n"
+"IETF 125 wordt gehouden in Shenzhen, China. Om de risico’s op spionage tijdens reizen naar China te beperken, heeft de AIVD een [advies](https://www.aivd.nl/onderwerpen/cyberdreiging/mogelijke-spionage-bij-reizen-naar-china) opgesteld.\n"
+"\n"
+"## De rol van open source software in de wereldwijde DNS-infrastructuur\n"
+"Maarten Aertsen (NLnet Labs) neemt op persoonlijke titel deel aan de Security and Stability Advisory Committee (SSAC) van ICANN. Vanuit die hoedanigheid presenteerde hij het rapport ‘[The Domain Name System Runs on Free and Open Source Software (FOSS)](https://www.icann.org/en/ssac/publications/documents/sac132-executive-summary-for-the-domain-name-system-runs-on-free-and-open-source-software-foss-25-09-2025-en)’ van de SSAC. Dit rapport onderzoekt de rol van vrije en open source software (FOSS) binnen het Domain Name System (DNS) en is opgesteld met beleidsmakers in gedachten.\n"
+"\n"
+"Het onderzoek laat zien dat de wereldwijde en gedistribueerde DNS-infrastructuur sterk afhankelijk is van FOSS:\n"
+"- Van de 12 organisaties die de rootservers beheren, gebruiken er ten minste negen uitsluitend FOSS DNS-implementaties om query’s te beantwoorden.\n"
+"- Negen van de tien grootste partijen die autoritatieve DNS-diensten verlenen voor TLD-registries gebruiken hiervoor FOSS.\n"
+"- Op het gebied van domeinnaamregistratie zijn veel grote systemen weliswaar propriëtair, maar ze zijn overwegend gebouwd op FOSS-componenten.\n"
+"- FOSS is sterk vertegenwoordigd in het diverse ecosysteem van DNS-resolvers.\n"
+"\n"
+"FOSS verschilt van propriëtaire software. Kenmerkend is dat gebruikers de vrijheid hebben om de software te gebruiken, te bestuderen, te delen en te wijzigen. Iedereen kan bijdragen aan de software en dit gebeurt vaak zonder dat hieraan contractuele afspraken ten grondslag liggen of dat hiervoor betalingen worden gedaan. Bij propriëtaire software is dit niet of minder het geval.\n"
+"\n"
+"FOSS is niet per definitie veiliger of minder veilig dan propriëtaire software. De veiligheid van software hangt af van de kwaliteit van onderhoud, niet van de licentie. In tegenstelling tot FOSS in het algemeen, kent de DNS-wereld een handvol langdurig actieve onderhoudsorganisaties.\n"
+"\n"
+"Beleid moet op deze realiteit worden afgestemd. Zou het bijvoorbeeld klakkeloos uitgaan van een conventionele klant-leverancierrelatie en de individuen en organisaties die FOSS onderhouden aanmerken als leverancier, dan loop je onder de Europese [Verordening cyberweerbaarheid](https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX:02024R2847-20241120) en [NIS 2-richtlijn](https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX:02022L2555-20221227) het risico dat deze partijen zodanig worden belast, dat ze het project verlaten en de software minder veilig en minder beschikbaar wordt.\n"
+"\n"
+"Voor beleid dat bijdraagt aan een veilige en stabiele werking van het internet, zijn de volgende strategieën van belang:\n"
+"- Wijs verantwoordelijkheden op de juiste manier toe: Leg verplichtingen op aan commerciële integrators en operators, in plaats van aan maintainers.\n"
+"- Stimuleer duurzaam onderhoud: Richt onafhankelijke organisaties voor onderhoud (‘opensourcesoftwarestewards’ onder de Verordening cyberweerbaarheid) in, of ondersteun deze, om ondersteuning en onderhoud door de gemeenschap voor kritieke projecten te financieren.\n"
+"- Pas supply chain-concepten aan: Erken dat het ontbreken van contracten betekent dat er geen directe relaties met leveranciers zijn en pas de regelgevingsstrategie daarop aan.\n"
+"- Voorkom conflicterende regionale regelgeving: Voorkom overlappende regelgeving voor wereldwijd kritieke infrastructuur, zoals rootservers.\n"
+"\n"
+"Er is onder beleidsmakers veel interesse in het rapport.\n"
+"\n"
+"## De adoptie van security.txt: een best practice voor open internetstandaarden\n"
+"Daniël Federer gaf een presentatie over de resultaten van het stimuleringsproject van de Vereniging van Registrars (VvR) voor de adoptie van security.txt, waarvan hij de projectleider was.\n"
+"Security.txt, vastgelegd in [RFC 9116](https://datatracker.ietf.org/doc/rfc9116/), is een bestandsformaat dat organisaties helpt om kenbaar te maken hoe beveiligingsonderzoekers kwetsbaarheden kunnen melden. Het is een relatief nieuwe standaard en het gebruik ervan is nog geen gemeengoed. De stimulering hiervan heeft de VvR op verzoek van en met steun van SIDN fonds opgepakt.\n"
+"\n"
+"Om het voor registrars makkelijk te maken, is de VvR in gesprek gegaan met leveranciers van controlpanels om ondersteuning voor security.txt toe te voegen. Hierop zijn [DirectAdmin](https://docs.directadmin.com/changelog/version-1.663.html#automatic-security-txt-rfc-9116-support) en [Plesk](https://docs.plesk.com/en-US/obsidian/administrator-guide/plesk-administration/securing-plesk/securitytxt-standard-compliance.80027/) voorzien van ‘native’ security.txt-functionaliteit.\n"
+"\n"
+"Verder heeft de VvR samen met SIDN een [incentiveprogramma](https://www.sidn.nl/nieuws-en-blogs/sidn-introduceert-incentive-om-gebruik-van-security-txt-te-stimuleren) opgezet. SIDN heeft hiervoor haar Registrar Scorecard (RSC) uitgebreid. Registrars ontvangen van SIDN een vergoeding voor iedere domeinnaam waarvan de website een geldig en bruikbaar security.txt-bestand aanbiedt.\n"
+"\n"
+"Tot slot heeft de VvR een [WordPress-plugin](https://wordpress.org/plugins/generate-security-txt/) laten ontwikkelen waarmee het toevoegen van een security.txt-bestand met enkele klikken mogelijk is. De plugin bevat een koppeling met Internet.nl om te controleren of alles correct is ingesteld, ook voor andere standaarden. De plugin is vrij van advertenties en kent geen premium.\n"
+"\n"
+"Mede dankzij het project is de adoptie van security.txt gegroeid naar bijna 13%. In het aantal meldingen van kwetsbaarheden wordt ook een toename ervaren. De kwaliteit van meldingen laat weleens te wensen over, maar dit wordt niet veroorzaakt door security.txt.\n"
+"\n"
+"Het mooie van security.txt is dat deze open standaard eenvoudig is toe te passen en dat kwetsbaarheden daardoor snel op de juiste plek kunnen worden gemeld. Dit draagt bij aan een veiliger internet. Nu is het belangrijk om de druk erop te houden en security.txt verder onder de aandacht te brengen, bijvoorbeeld door er een Engelstalig artikel over te schrijven.\n"
+"\n"
+"## ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) versie 2025-05\n"
+"Koen Sandbrink, adviseur Cybersecurity bij het NCSC, was aangesloten voor een tweetal presentaties, de eerste over de geüpdatete beveiligingsrichtlijnen voor Transport Layer Security (TLS).\n"
+"\n"
+"Het TLS-protocol zorgt voor versleuteling bij de uitwisseling van gegevens tussen clients en servers. De meest actuele versie is versie 1.3, vastgelegd in [RFC 8446](https://datatracker.ietf.org/doc/rfc8446/).\n"
+"\n"
+"NCSC heeft in 2014 voor het eerst beveiligingsrichtlijnen voor TLS gepubliceerd en onderhoudt deze sindsdien. De vorige versie van de richtlijnen dateert uit 2021. De geüpdatete versie is [versie 2025-05](https://www.ncsc.nl/api/media/sites/default/files/2025-11/TLS-Richtlijnen-2025-05.pdf).\n"
+"\n"
+"In versie 2025-05 zijn theorie en richtlijnen uit elkaar gehaald, waardoor de structuur is veranderd. Ook zijn de beveiligingsniveaus geactualiseerd. Het beveiligingsniveau van TLS 1.1 en TLS 1.0 is nu bijvoorbeeld ‘Onvoldoende’. In de vorige versie was dit ‘Uit te faseren’.\n"
+"\n"
+"De richtlijnen bevatten ook advies in verband met de quantumdreiging. Niet-quantumveilige instellingen zijn hooguit ‘Voldoende’. Voor authenticatie zijn nog geen algoritmes met beveiligingsniveau ‘Goed’.\n"
+"\n"
+"Volgens het Besluit beveiligde verbinding met overheidswebsites en -webapplicaties zijn bestuursorganen verplicht om hun publiek toegankelijke websites en webapplicaties te beveiligen volgens de TLS-richtlijnen. Dit besluit wordt gewijzigd. Waar het huidige besluit versie 2.1.1 voorschrijft, wordt in het herziene besluit verwezen naar versie 2025-05.\n"
+"\n"
+"Over het aangepaste besluit loopt een consultatie: [https://www.internetconsultatie.nl/verzamelbesluitdigitaleoverheid](https://www.internetconsultatie.nl/verzamelbesluitdigitaleoverheid). Reageren kan tot 6 januari 2026.\n"
+"\n"
+"De nieuwe richtlijnen worden ook in Internet.nl geïmplementeerd.\n"
+"\n"
+"## Gebruik van het Automatic Certificate Management Environment (ACME)-protocol voor certificaatbeheer\n"
+"Koen vervolgde met een presentatie over ACME, een internetstandaard ([RFC 8555](https://datatracker.ietf.org/doc/html/rfc8555)) waarmee je de periodieke vervanging van certificaten kunt automatiseren.\n"
+"\n"
+"Het [Certification Authority/Browser Forum (CA/Browser Forum)](https://cabforum.org/), een overlegorgaan van certificaatautoriteiten en leveranciers van browsersoftware en andere applicaties die certificaten gebruiken, heeft bepaald dat de levensduur van TLS-certificaten stapsgewijs wordt verkort naar uiteindelijk 47 dagen vanaf 2029.\n"
+"\n"
+"De certificaatautoriteit Let’s Encrypt loopt op de muziek vooruit door nu al certificaten met een kortere levensduur aan te bieden. Let’s Encrypt heeft ook een belangrijke rol gespeeld in de ontwikkeling en promotie van ACME.\n"
+"\n"
+"ACME is verplicht voor de overheid (‘[Pas toe of leg uit](https://www.forumstandaardisatie.nl/open-standaarden/acme)’) voor publiek vertrouwde TLS-certificaten en aanbevolen voor niet-publiek vertrouwde certificaten.\n"
+"\n"
+"Bij de implementatie en het gebruik van ACME moet met een aantal punten rekening worden gehouden. Met ACME regel je het beheer van certificaten bijvoorbeeld niet meer centraal, maar op de systemen die ze gebruiken. Om certificaten aan te vragen, gebruiken deze systemen inloggegevens en die moet je veilig opslaan. ACME vereist verder dat poort 80 open blijft, wat niet iedereen wil. [DNS-PERSIST-01](https://datatracker.ietf.org/doc/html/draft-ietf-acme-dns-persist-00) gaat hierbij helpen.\n"
+"\n"
+"ACME wordt mogelijk ook in Internet.nl geïmplementeerd.\n"
+"\n"
+"## Ontwikkelingen op het gebied van Internet.nl, API en dashboard\n"
+"Sasha Romijn, ontwikkelaar van de Internet.nl-website en API, en Elger Jonker, ontwikkelaar van het Internet.nl-dashboard, gaven een update over actuele ontwikkelingen rond Internet.nl.\n"
+"\n"
+"In 2025 zijn tot dusver via de website 830K testen uitgevoerd en via de API 11M testen. Ten opzichte van 2024 is in het aantal website-testen een kleine daling zichtbaar, mede door een verschuiving naar de API. Het aantal API-testen is gestegen.\n"
+"\n"
+"De grootste ontwikkeling voor de website is de implementatie van de nieuwe TLS-richtlijnen van het NCSC. De wijzigingen in de TLS-test beïnvloeden de Internet.nl-testscore, zowel in de websitetest als in de e-mailtest. Om verrassingen te voorkomen, zal een preproductieomgeving breder beschikbaar worden gemaakt om alvast te kunnen testen.\n"
+"\n"
+"Verder komt PQC-ondersteuning binnenkort beschikbaar in nassl en later ook in Internet.nl.\n"
+"\n"
+"Voor het dashboard zijn de nieuwe subtest voor Certification Authority Authorization (CAA) en de eigen API belangrijke ontwikkelingen. Ook wordt gewerkt aan de stabiliteit van het dashboard. Voor de roadmap, zie [https://github.com/internetstandards/Internet.nl-dashboard/issues/633](https://github.com/internetstandards/Internet.nl-dashboard/issues/633). Hier kunnen ook nieuwe wensen worden doorgegeven.\n"
+"\n"
+"## En verder…\n"
+"Verder is teruggeblikt op de vorige bijeenkomst en zijn de plannen voor de volgende bijeenkomst besproken. Er werd afgesloten met een borrel.\n"
+"\n"
+"## Geïnteresseerd in de onderwerpen waarover het Platform Internetstandaarden spreekt?\n"
+"Voor meer informatie over moderne internetstandaarden of activiteiten van het Platform Internetstandaarden, volg ons op [Mastodon](https://mastodon.nl/@internet_nl) of [LinkedIn](https://www.linkedin.com/company/internet-nl/)."
+
+msgid "article plis-meeting-dec-2025 date"
+msgstr "7 april 2026"
+
+msgid "article plis-meeting-dec-2025 lead"
+msgstr ""
+"Op donderdag 4 december kwam het Platform Internetstandaarden samen voor de "
+"vierde en laatste bijeenkomst van het jaar. De bijeenkomst vond plaats bij "
+"de Rijksinspectie Digitale Infrastructuur (RDI) in Amersfoort, waar het "
+"platform gastvrij werd ontvangen. Op de agenda stonden onder andere een "
+"introductie van de RDI, een terugblik en vooruitblik op evenementen, "
+"ontwikkelingen rond Internet.nl en presentaties over open source software en"
+" DNS-infrastructuur, security.txt, geüpdatete TLS-richtlijnen en ACME. "
+"Gerben Klein Baltink zat de bijeenkomst voor, waaraan in totaal 19 "
+"deelnemers meededen."
+
+msgid "article plis-meeting-dec-2025 title"
+msgstr "Terugblik bijeenkomst Platform Internetstandaarden 4 december 2025"
+
msgid "article plis-meeting-sept-2025 body"
msgstr ""
"## Introductie van ECP\n"
@@ -1346,6 +1477,100 @@ msgstr ""
msgid "article release-1.10 title"
msgstr "Internet.nl voegt CAA-test toe en kondigt wijzigingen TLS-test aan"
+msgid "article release-1.11 body"
+msgstr ""
+"## Wat is TLS?\n"
+"\n"
+"## Waarom is veilig ingestelde TLS belangrijk?\n"
+"\n"
+"## Nieuwste TLS-richtlijnen van NCSC\n"
+"\n"
+"## Andere verbeteringen in deze release\n"
+"\n"
+"## Roadmap volgende release\n"
+"\n"
+"## Over Internet.nl\n"
+"De testtool [Internet.nl](https://internet.nl) is een initiatief van het Platform Internetstandaarden, een samenwerkingsverband van partijen uit de Internetgemeenschap en de Nederlandse overheid. Het doel van het platform is om gezamenlijk het gebruik van moderne internetstandaarden verder te vergroten om daarmee het internet voor iedereen toegankelijker, veiliger en betrouwbaarder te maken. De softwarecode van Internet.nl is online beschikbaar onder een open source licentie.\n"
+"\n"
+"---\n"
+"\n"
+"## Release notes 1.11\n"
+"\n"
+"### TLS updates for NCSC 2025 guidelines\n"
+"\n"
+"All tests were updated to match the\n"
+"[2025-05 version of the NCSC TLS guidelines](https://www.ncsc.nl/en/transport-layer-security-tls/security-guidelines-for-transport-layer-security-2025-05).\n"
+"Most significant changes:\n"
+"\n"
+"- The list of good/sufficient/phase out/insufficient TLS versions, TLS authentication, curves, hashes, \n"
+" key exchange algorithms, FFDHE groups, RSA key lengths, and bulk encryption algorithms were updated\n"
+" to match the new guidelines.\n"
+"- A test for Extended Master Secret (RFC7627) was added.\n"
+"- Client-initiated renegotiation is now acceptable, if limited to less than 10 renegotiations.\n"
+"- All checks on certificates apply to all certificates sent by the server,\n"
+" except root certificates (according to our trust store). In previous versions,\n"
+" the certificate selection was different per test.\n"
+"\n"
+"### Other TLS updates\n"
+"\n"
+"- Certificates that do not have OCSP enabled, which means stapling is not possible,\n"
+" [are now detected as such](https://github.com/internetstandards/Internet.nl/issues/1641).\n"
+" Several issues with OCSP stapling reliability were also resolved.\n"
+"- Issues were fixed where the cipher order failed to detect some bad scenarios,\n"
+" including some where servers preferred RSA over ECDHE, or CBC over POLY1305.\n"
+"- CCM_8 ciphers are now detected when enabled on a server.\n"
+"- OLD ciphers are no longer detected.\n"
+"- The cipher order test no longer separates between \"the server cipher order preference is wrong\" \n"
+" and \"the server has no preference\".\n"
+"\n"
+"### Significant internal changes\n"
+"\n"
+"- Upgraded to Django 5, Python 3.13, and Debian Trixie base image.\n"
+"- Switched TLS implementation to sslyze/nassl based reimplementation.\n"
+"- Switched to pyproject/uv.lock for project dependencies, replacing requirements files.\n"
+"- Added post-quantum hybrid ECDHE-MLKEM for TLS 1.3 in our web server.\n"
+"- Outgoing traffic now uses the configured public IPv4/IPv6 addresses.\n"
+"- Routinator can now be configured with an allowlist for shared instances.\n"
+"\n"
+"### Bug fixes\n"
+"\n"
+"- Fixed [simhash exception when both address families fail](https://github.com/internetstandards/Internet.nl/issues/1893).\n"
+"- Fixed JSON serialization of sets in batch results.\n"
+"- Fixed [report generation locking](https://github.com/internetstandards/Internet.nl/issues/1749) for results views.\n"
+"\n"
+"### API changes\n"
+"\n"
+"This release has API version 2.7.0.\n"
+"\n"
+"The changes noted above are reflected in the API as well, e.g. which ciphers\n"
+"are considered bad, as listed in the API output, along with score impacts.\n"
+"\n"
+"Additionally, the API structure changes are:\n"
+"- OCSP stapling has a new status `not_in_cert` (not_tested), for when a certificate does not have\n"
+" OCSP enabled, therefore stapling is neither required nor possible.\n"
+"- The cipher order status no longer returns `not_prescribed` or `not_seclevel` for new tests.\n"
+" The insufficient status is now `bad` (failed) for preferring phase out over good and/or sufficient,\n"
+" regardless of the reason (server not enforcing any preference or server enforcing wrong preference).\n"
+"- `cert_signature_phase_out` was added to the TLS details, listing certificate signature algorithms\n"
+" that are at phase-out level (warning). Analogous to the existing `cert_signature_bad`.\n"
+"- `extended_master_secret` was added to the TLS details, with values: `supported` (good),\n"
+" `not_supported` (failed), `na_no_tls_1_2` (good), `unknown` (not_tested).\n"
+"- `client_reneg` in the TLS details was changed from a boolean to a string enum with values:\n"
+" `not_allowed` (good), `allowed_with_low_limit` (info), `allowed_with_too_high_limit` (failed)."
+
+msgid "article release-1.11 date"
+msgstr "21 april 2026"
+
+msgid "article release-1.11 lead"
+msgstr ""
+"Vanaf vandaag kan je op Internet.nl testen of de beveiligde verbinding van "
+"je website of e-mail voldoet aan de nieuwste TLS-richtlijnen van NCSC-NL. "
+"Dit betekent ook dat websites en e-mailservers die eerder slaagden voor de "
+"test nu toch verbeterpunten kunnen hebben."
+
+msgid "article release-1.11 title"
+msgstr "Volledig geactualiseerde TLS-test in nieuwe versie van Internet.nl"
+
msgid "article release-1.7 body"
msgstr ""
"## Verbeterde CSP-test\n"