From 41427d1e81661d11641cf00219dd33f2d5a928b4 Mon Sep 17 00:00:00 2001 From: stitch1 Date: Tue, 18 Feb 2025 14:45:16 +0100 Subject: [PATCH] update translations, add faq section on how to update translations --- README.md | 27 + .../locale/en/LC_MESSAGES/django.po | 604 +++++++++++------- .../locale/nl/LC_MESSAGES/django.po | 589 ++++++++++------- .../static/js/translations/internet_nl.en.js | 139 ++-- .../static/js/translations/internet_nl.js | 248 +++---- .../static/js/translations/internet_nl.nl.js | 109 ++-- 6 files changed, 1045 insertions(+), 671 deletions(-) diff --git a/README.md b/README.md index c7211384..d7a11425 100644 --- a/README.md +++ b/README.md @@ -244,6 +244,33 @@ The dependency on Web Security Map is version pinned by a Git SHA in the Websecm ## FAQ / Troubleshooting + +### Updating translations +Works best on a clean commit. + +```python +dashboard update_translations_from_internet_nl +``` + +This will update two PO files and Three JS files, the following: +```sh +git status +``` + +```text +Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git restore ..." to discard changes in working directory) + modified: dashboard/internet_nl_dashboard/locale/en/LC_MESSAGES/django.po + modified: dashboard/internet_nl_dashboard/locale/nl/LC_MESSAGES/django.po + modified: dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.js + modified: dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js + modified: dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.js +``` + +The .js files can be used for inspiration in the internet.nl dashboard. + + ### Missing xcode (mac users) During installation mac users might get the following error, due to not having xcode installed or updated. diff --git a/dashboard/internet_nl_dashboard/locale/en/LC_MESSAGES/django.po b/dashboard/internet_nl_dashboard/locale/en/LC_MESSAGES/django.po index 8a13ecce..64c41e5a 100644 --- a/dashboard/internet_nl_dashboard/locale/en/LC_MESSAGES/django.po +++ b/dashboard/internet_nl_dashboard/locale/en/LC_MESSAGES/django.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: 2024-05-14 12:27:07.898718\n" +"PO-Revision-Date: 2025-01-28 12:01:21.412632\n" "Last-Translator: \n" "Language-Team: \n" "Language: \n" @@ -50,12 +50,12 @@ msgstr "" "\n" "- [Dutch Cloud Community](https://dutchcloudcommunity.nl)\n" "- [Dutch Authority for Digital Infrastructure](https://rdi.nl/)\n" -"- [Dutch Standardisation Forum](https://forumstandaardisatie.nl/)\n" "- [ECP](https://ecp.nl/)\n" -"- [Internet Society international](https://internetsociety.org/)\n" -"- [Internet Society Nederlands chapter](https://isoc.nl/)\n" -"- [Ministry of Economic Affairs and Climate Policy](https://www.government.nl/ministries/ministry-of-economic-affairs-and-climate-policy)\n" +"- [Internet Society international](https://www.internetsociety.org/)\n" +"- [Internet Society Netherlands chapter](https://isoc.nl/)\n" +"- [Ministry of Economic Affairs](https://www.government.nl/ministries/ministry-of-economic-affairs)\n" "- [NCSC-NL](https://ncsc.nl/)\n" +"- [Netherlands Standardisation Forum](https://forumstandaardisatie.nl/)\n" "- [NLnet](https://nlnet.nl/)\n" "- [NLnet Labs](https://nlnetlabs.nl/)\n" "- [RIPE NCC](https://ripe.net/)\n" @@ -63,7 +63,13 @@ msgstr "" "- [SURF](https://surf.nl/)\n" "- [VvR](https://www.verenigingvanregistrars.nl/)\n" "\n" -"ECP provides for the administrative home of the platform. The domain name Internet.nl is provided to the platform by the Netherlands chapter of the Internet Society. [Open Netlabs](https://opennetlabs.nl/) / NLnet Labs laid the foundation for Internet.nl and the underlying tooling. From 1 April 2021 onwards, maintenance and further development will be carried out by the project team of the Internet Standards Platform.\n" +"ECP provides for the administrative home of the platform. The domain name Internet.nl is provided to the platform by the Netherlands chapter of the Internet Society. NLnet Labs laid the foundation for Internet.nl and the underlying tooling. From 1 April 2021 onwards, maintenance and further development is carried out by the project team of the Internet Standards Platform.\n" +"\n" +"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" +"\n" "\n" "## What are Internet Standards?\n" "In order to exchange data between computers around the world, we need international agreements on how computers talk to one another. The digital \"plugs and sockets\" that link everything together, so to speak. These agreements are called Internet Standards or internet protocols. An example is SMTP, a well-known protocol for sending email. This technical core of the internet is invisible and unknown to most users. However it is crucial for a working internet today and in the future.\n" @@ -75,7 +81,7 @@ msgstr "" "Unfortunately, that is not the case. Even in a modern country like the Netherlands (that became the first internet connected European country in 1988) we use too many outdated standards that fall short of reliability. Not using these modern standards is a risk for the individual internet user, but also for the Dutch economy and for the world at large. Therefore, please help improving the internet and make sure that you use modern Internet Standards.\n" "\n" "## Who should act on modern Internet Standards?\n" -"Our access, hosting and email providers should take care of implementing modern internet standards and setting them correctly. Do the test results show any shortcomings? Then please send a message about this to your provider(s). If you use your own connection, webserver or mailserver, you have to take care of the correct settings yourself.\n" +"Our access, hosting and email providers should take care of implementing modern internet standards and setting them correctly. Do the test results show any shortcomings? Then please send a message about this to your provider(s). If you use your own connection, web server or mail server, you have to take care of the correct settings yourself.\n" "\n" "## Why don’t you address the access, hosting and email providers directly?\n" "We do. Still it is important that internet users are aware themselves and send out signals to their provider(s) as well. This may come as a surprise, but in a modern country like the Netherlands we still use many standards that are outdated and lack reliability. Therefore please help us to improve the internet together, and demand modern Internet Standards." @@ -275,10 +281,12 @@ msgstr "" "## Content\n" "Except where otherwise noted, content on this website is licensed under a [Creative Commons Attribution 4.0 International license](https://creativecommons.org/licenses/by/4.0/).\n" "\n" -"## Source code\n" +"## Software\n" +"\n" +"### Source code\n" "The software source code of Internet.nl is published under the [Apache License, version 2.0](https://opensource.org/licenses/Apache-2.0) on [Github](https://github.com/internetstandards/Internet.nl).\n" "\n" -"## Building blocks\n" +"### Building blocks\n" "Internet.nl was made possible by using and combining other open source software. The main open source building blocks of Internet.nl are:\n" "\n" "- [Python 3](https://www.python.org/) (main programming language)\n" @@ -293,16 +301,46 @@ msgstr "" "- [SecTXT](https://github.com/DigitalTrustCenter/sectxt) (for security.txt test)\n" "- [Postfix](https://www.postfix.org/) (mail server for interactive email test, _beta_)\n" "\n" +"### Donations\n" +"To thank and support the (open source) projects we are building upon, we regularly make donations to them.\n" +"\n" +"#### 2024\n" +"- Celery: USD 1500\n" +"- Mastodon.nl (Stichting ActivityClub): EUR 1500\n" +"- nassl & sslyze (Alban Diquet): EUR 1500\n" +"\n" +"#### 2023\n" +"- Celery: USD 1408.98\n" +"- Django Software Foundation: USD 1409\n" +"- Mastodon gGmbH: EUR 1500\n" +"\n" +"#### 2019\n" +"- Celery: EUR 1500\n" +"- Django Software Foundation: EUR 1500\n" +"- Python Software Foundation: EUR 1500\n" +"\n" "## Names and logos\n" "* Both the name Internet.nl and the Internet.nl logo are explicitly excluded from the above licensing. Thus we do not grant permission to use these when our content or software code is reused, unless we make an explicit exception and the related criteria are met (e.g. in case of the [100% badges](/faqs/badges/)).\n" "* The names and logos in the icons that refer to our social media places are explicitly excluded from the above licensing. \n" "\n" -"## Other test websites based on Internet.nl\n" -"As far as we know, the following test websites have reused the Internet.nl source code. Please let us know if your website is based on our source code.\n" +"## Re-use\n" +"\n" +"### Re-users of source code\n" +"As far as we know, the following external websites are re-using the Internet.nl source code. Please let us know if your website is also based on our source code.\n" "\n" -"- [aucheck.com.au](https://aucheck.com.au/) (Australia)\n" "- [top.nic.br](https://top.nic.br/) (Brazil)\n" -"- [sikkerpånettet.dk](https://sikkerpånettet.dk/) (Denmark)" +"- [sikkerpånettet.dk](https://xn--sikkerpnettet-vfb.dk/) (Denmark)\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" +"\n" +"#### Source code\n" +"> This website re-uses source code from the [Internet.nl](https://internet.nl) project.\n" +"\n" +"Note that if you not only re-use but also re-distribute the source code, the previously mentioned Apache license also imposes attribution requirements.\n" +"\n" +"#### Test results\n" +"> This website re-uses test results provided by the [Internet.nl](https://internet.nl) test tool." msgid "detail conn dnssec validation exp" msgstr "" @@ -331,7 +369,7 @@ msgstr "You are protected by DNSSEC signature validation." msgid "detail conn ipv6 connection exp" msgstr "" "We check if your device through its current internet connection is able to \n" -"connect *directly* (i.e. without DNS translation) with our webserver using \n" +"connect *directly* (i.e. without DNS translation) with our web server using \n" "our corresponding IPv6 address.\n" "\n" "Some browser add-ons and routers offer functionality for domain filtering in order to enhance privacy or restrict internet use. To prevent circumvention this kind of functionality often blocks connecting to IP addresses directly, making your internet connection fail for this subtest." @@ -351,7 +389,7 @@ msgstr "You are able to reach computers directly on their IPv6 address." msgid "detail conn ipv6 dns-conn exp" msgstr "" "We check if your device through its current internet connection is able to \n" -"connect to our webserver via IPv6. For this test we provide a domain name \n" +"connect to our web server via IPv6. For this test we provide a domain name \n" "and we expect your resolver to resolve the domain name to the appropriate \n" "IPv6 address." @@ -367,7 +405,7 @@ msgstr "You are able to reach computers via DNS on their IPv6 address." msgid "detail conn ipv6 ipv4-conn exp" msgstr "" "We check if your device through its current internet connection is able to \n" -"connect to our webserver via IPv4. For this test we provide a domain name \n" +"connect to our web server via IPv4. For this test we provide a domain name \n" "and we expect your resolver to resolve the domain name to the appropriate \n" "IPv4 address.\n" "\n" @@ -425,15 +463,17 @@ msgstr "" " \n" "* 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\n" -" this test we expect your name server to answer `NOERROR` to our query for\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" "terminal' some name servers that are not conformant with the standard\n" -"RFC 2308 incorrectly answer `NXDOMAIN` instead of `NOERROR`. This makes it\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" "* For this test we assume 'strict alignment' which is conformant with DMARC. The given domain is considered to be the sender domain in the mail body domain (`From:`) and this must be identical to the DKIM domain (`d=`) and the SPF domain (envelope sender, i.e. return-path that shows up in `MAIL FROM`).\n" "\n" -"For a \"good practice on domains without mail\" see the [explanation of the \"DMARC policy\" subtest](#control-panel-9)." +"Additional notes: \n" +"\n" +"* Some mail systems modify email in transit, potentially invalidating a DKIM signature. In many cases these modifications are harmless. Examples are whitespace replacement and header field line rewrapping. If you are a DKIM signing sender then you can choose whether or not to tolerate these types of changes, both for the header and the body of emails. The `simple` setting tolerates almost no modifications, and `relaxed` tolerates common modifications. If no setting is specified it defaults to `simple` for both header and body. In particular, header modifications are a common cause of a DKIM signature unintentionally becoming invalid, thus hindering deliverability. Using `relaxed` for the header while keeping `simple` for the body (`c=relaxed/simple`), can mitigate these kind of issues.\n" +"* For a \"good practice on domains without mail\" see the [explanation of the \"DMARC policy\" subtest](#control-panel-9)." msgid "detail mail auth dkim label" msgstr "DKIM existence" @@ -480,7 +520,7 @@ msgstr "" "\n" "We also check whether the mail addresses under `rua=` and `ruf=` are valid. In case they contain an external mail address we check whether the external domain is authorised to receive DMARC reports. Make sure that the DMARC authorisation record on the external domain contains at least `\"v=DMARC1;\"`.\n" "\n" -"The test permits the use of the experimental `np` tag (RFC 9091).\n" +"The test permits the use of the experimental `np` tag ([RFC 9091](https://www.rfc-editor.org/rfc/rfc9091)).\n" "\n" "*Good practice for domains without mail*:\n" "\n" @@ -591,7 +631,7 @@ msgstr "" msgid "detail mail dnssec exists exp" msgstr "" -"We check if your domain, more specifically its SOA record, is DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply that contains your mail server domains (MX). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to the attacker's mailserver domain.\n" +"We check if your domain, more specifically its SOA record, is DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply that contains your mail server domains (MX). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to the attacker's mail server domain.\n" "\n" "If a domain redirects to another domain via `CNAME`, then we also check if the CNAME domain is signed (which is conformant with the DNSSEC standard). If the CNAME domain is not signed, the result of this subtest will be negative.\n" "\n" @@ -624,7 +664,7 @@ msgstr "" msgid "detail mail dnssec mx-exists exp" msgstr "" -"We check if the domains of your mail servers (MX), more specifically their SOA records, are DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply containing the IP addresses and DANE records of your mailserver(s). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to an IP address controlled by the attacker or to eavesdrop on the secured mail server connection.\n" +"We check if the domains of your mail servers (MX), more specifically their SOA records, are DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply containing the IP addresses and DANE records of your mail server(s). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to an IP address controlled by the attacker or to eavesdrop on the secured mail server connection.\n" "\n" "If a domain redirects to another domain via `CNAME`, then we also check if the CNAME domain is signed (which is conformant with the DNSSEC standard). If the CNAME domain is not signed, the result of this subtest will be negative.\n" "\n" @@ -655,8 +695,16 @@ msgstr "" msgid "detail mail dnssec mx-exists verdict no-mailservers" msgstr "" -"No receiving mail servers (MX) are set on your domain that does not have " -"A/AAAA records. This is fine if you do not want to receive email." +"The SPF record on your domain indicates that your domain may be used for " +"sending mail. However, your domain does not have a receiving mail server " +"(MX), which could hinder deliverability of your sent mails because not " +"having an MX may be seen by receivers as an indicator for spam. Therefore if" +" you really want to send mail from this domain, configure an MX. However, if" +" you do not want to send mail from this domain, configure an SPF record with" +" the `-all` term only and besides a \"Null MX\" record if your domain has " +"A/AAAA records. Because of your configuration, the subtests in the STARTTLS " +"and DANE category and the mail server specific subtests in the IPv6 and " +"DNSSEC categories are not applicable." msgid "detail mail dnssec mx-exists verdict no-null-mx" msgstr "" @@ -801,10 +849,11 @@ msgstr "" msgid "detail mail ipv6 mx-AAAA verdict no-null-mx" msgstr "" "No receiving mail servers (MX) are set on your domain that has A/AAAA " -"records. We recommend you to explicitly indicate that your domain does not " -"accept email by configuring a \"Null MX\" record. Do not use a \"Null MX\" " -"record and set an MX if you do want to send email from this domain name, as " -"receiving servers may reject email that has an invalid return address." +"records and has an SPF record with only the term -all. We recommend you to " +"set a \"Null MX\" record to explicitly indicate that your domain does not " +"accept email. Because of your configuration, the subtests in the STARTTLS " +"and DANE category and the mail server specific subtests in the IPv6 and " +"DNSSEC categories are not applicable." msgid "detail mail ipv6 mx-AAAA verdict null-mx" msgstr "" @@ -828,8 +877,16 @@ msgstr "" msgid "detail mail ipv6 mx-AAAA verdict other" msgstr "" -"No receiving mail servers (MX) are set on your domain that does not have " -"A/AAAA records. This is fine if you do not want to receive email." +"The SPF record on your domain indicates that your domain may be used for " +"sending mail. However, your domain does not have a receiving mail server " +"(MX), which could hinder deliverability of your sent mails because not " +"having an MX may be seen by receivers as an indicator for spam. Therefore if" +" you really want to send mail from this domain, configure an MX. However, if" +" you do not want to send mail from this domain, configure an SPF record with" +" the `-all` term only and besides a \"Null MX\" record if your domain has " +"A/AAAA records. Because of your configuration, the subtests in the STARTTLS " +"and DANE category and the mail server specific subtests in the IPv6 and " +"DNSSEC categories are not applicable." msgid "detail mail ipv6 mx-reach exp" msgstr "" @@ -863,9 +920,7 @@ msgstr "" "\n" "However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.\n" "\n" -"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.\n" -"\n" -"*Requirement level: Recommended*" +"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks." msgid "detail mail rpki exists label" msgstr "Route Origin Authorisation existence" @@ -896,9 +951,7 @@ msgstr "" "\n" "However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.\n" "\n" -"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.\n" -"\n" -"*Requirement level: Recommended*" +"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks." msgid "detail mail rpki mx-ns-exists label" msgstr "Route Origin Authorisation existence" @@ -935,20 +988,18 @@ msgstr "" "\n" "Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.\n" "\n" -"- `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" +"1․ `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" "\n" -"- `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes: \n" +"2․ `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes:\n" "\n" -" 1. the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" -" 2. the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" -"\n" -"- `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" +"* the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" +"* the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" +" \n" +"3․ `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" "\n" "**What to do if the test result shows the status Invalid?**\n" "\n" -"The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server's IP addresses to fix the route configuration error. \n" -"\n" -"*Requirement level: Recommended*" +"The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server's IP addresses to fix the route configuration error. " msgid "detail mail rpki mx-ns-valid label" msgstr "Route announcement validity" @@ -975,14 +1026,14 @@ msgid "detail mail rpki mx-ns-valid verdict invalid" msgstr "" "At least one IP address of the name servers of your receiving mail servers " "has an `Invalid` validation state. The route announcement of the affected IP" -" adresses is *not* matched by the published RPKI Route Origin Authorisation " -"(ROA). This indicates an unintentional or malicious route configuration " +" addresses is *not* matched by the published RPKI Route Origin Authorisation" +" (ROA). This indicates an unintentional or malicious route configuration " "error, that can be caused by your mail hoster (internal error) or by a third" -" party (external error). In either case, it can lead to the unreachability " -"of your server or the interception of Internet traffic to your server. " -"Contact your mail hoster as soon as possible. In the case of an internal " -"error, your mail hoster should ask its network provider that owns your " -"server's IP addresses to fix the route configuration error." +" party (external error). In either case, it increases the risk for " +"unreachability of your server or for interception of Internet traffic to " +"your server. Contact your mail hoster as soon as possible. In the case of an" +" internal error, your mail hoster should ask its network provider that owns " +"your server's IP addresses to fix the route configuration error." msgid "detail mail rpki mx-ns-valid verdict not-routed" msgstr "" @@ -1003,20 +1054,18 @@ msgstr "" "\n" "Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.\n" "\n" -"- `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" +"1․ `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" "\n" -"- `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes: \n" +"2․ `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes:\n" "\n" -" 1. the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" -" 2. the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" +"* the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" +"* the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" " \n" -"- `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" +"3․ `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" "\n" "**What to do if the test result shows the status Invalid?**\n" "\n" -"The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server's IP addresses to fix the route configuration error. \n" -"\n" -"*Requirement level: Recommended*" +"The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server's IP addresses to fix the route configuration error." msgid "detail mail rpki valid label" msgstr "Route announcement validity" @@ -1041,15 +1090,15 @@ msgstr "" msgid "detail mail rpki valid verdict invalid" msgstr "" "At least one IP address of your receiving mail servers has an `Invalid` " -"validation state. The route announcement of the affected IP adresses is " +"validation state. The route announcement of the affected IP addresses is " "*not* matched by the published RPKI Route Origin Authorisation (ROA). This " "indicates an unintentional or malicious route configuration error, that can " "be caused by your mail hoster (internal error) or by a third party (external" -" error). In either case, it can lead to the unreachability of your server or" -" the interception of Internet traffic to your server. Contact your mail " -"hoster as soon as possible. In the case of an internal error, your mail " -"hoster should ask its network provider that owns your server's IP addresses " -"to fix the route configuration error." +" error). In either case, it increases the risk for unreachability of your " +"server or for interception of Internet traffic to your server. Contact your " +"mail hoster as soon as possible. In the case of an internal error, your mail" +" hoster should ask its network provider that owns your server's IP addresses" +" to fix the route configuration error." msgid "detail mail rpki valid verdict not-routed" msgstr "" @@ -1209,7 +1258,7 @@ msgstr "" msgid "detail mail tls cipher-order verdict bad" msgstr "" -"At least one of your mailservers does *not* enforce its own cipher " +"At least one of your mail servers does *not* enforce its own cipher " "preference ('I')." msgid "detail mail tls cipher-order verdict good" @@ -1386,6 +1435,8 @@ msgstr "" "\n" "The test also accepts other combinations of DANE TLSA records i.e. \"3 x x\" + \"3 x x\" or \"3 x x\" + \"2 x x\". However other types than the above will generally be more error prone and less interoperable. \n" "\n" +"Note that if a mail server simultaneously offers two certificates (one based on RSA and one based on ECDSA), a separate DANE TLSA rollover scheme is recommended for each certificate. The subtest does not check for this scenario. If only one DANE TLSA record is configured for each certificate, this subtest gives a false-positive result.\n" +"\n" "*Requirement level: Optional*" msgid "detail mail tls dane-rollover label" @@ -1418,7 +1469,7 @@ msgstr "Mail server (MX)|DANE TLSA record valid" msgid "detail mail tls dane-valid verdict bad" msgstr "" -"At least one of your mailservers does *not* have any valid DANE " +"At least one of your mail servers does *not* have any valid DANE " "fingerprints. Either someone manipulated the response of your mail server, " "or your mail server has a serious DANE configuration error. The latter makes" " your domain unreachable for any sending mail server that checks DANE " @@ -1426,7 +1477,7 @@ msgstr "" msgid "detail mail tls dane-valid verdict good" msgstr "" -"Each of your mailservers has at least one valid DANE fingerprint. This " +"Each of your mail servers has at least one valid DANE fingerprint. This " "allows sending mail servers that support DANE verification to set up an " "authenticated encrypted transport connection with your receiving mail " "servers." @@ -1456,15 +1507,15 @@ msgstr "" "\n" "* Sufficient:\n" "\n" -" * [ffdhe4096](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem) (RFC 7919) \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/master/ffdhe3072.pem) (RFC 7919) \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" "\n" "* Phase out:\n" "\n" -" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe2048.pem) (RFC 7919) \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" "\n" "* Insufficient: Other groups\n" @@ -1530,7 +1581,7 @@ msgid "detail mail tls kex-hash-func verdict other" msgstr "" "We were unable to determine the hash function used by at least one of your " "mail servers. This could be because the cipher combination used has no " -"signature for certificate verification (e.g it uses RSA key exchange or is " +"signature for certificate verification (e.g. it uses RSA key exchange or is " "anonymous i.e. `anon`)." msgid "detail mail tls kex-hash-func verdict phase-out" @@ -1681,10 +1732,11 @@ msgstr "" msgid "detail mail tls starttls-exists verdict no-null-mx" msgstr "" "No receiving mail servers (MX) are set on your domain that has A/AAAA " -"records. We recommend you to explicitly indicate that your domain does not " -"accept email by configuring a \"Null MX\" record. Do not use a \"Null MX\" " -"record and set an MX if you do want to send email from this domain name, as " -"receiving servers may reject email that has an invalid return address." +"records and has an SPF record with only the term -all. We recommend you to " +"set a \"Null MX\" record to explicitly indicate that your domain does not " +"accept email. Because of your configuration, the subtests in the STARTTLS " +"and DANE category and the mail server specific subtests in the IPv6 and " +"DNSSEC categories are not applicable." msgid "detail mail tls starttls-exists verdict null-mx" msgstr "" @@ -1711,8 +1763,16 @@ msgstr "At least one of your mail servers is unreachable." msgid "detail mail tls starttls-exists verdict other-2" msgstr "" -"No receiving mail servers (MX) are set on your domain that does not have " -"A/AAAA records. This is fine if you do not want to receive email. " +"The SPF record on your domain indicates that your domain may be used for " +"sending mail. However, your domain does not have a receiving mail server " +"(MX), which could hinder deliverability of your sent mails because not " +"having an MX may be seen by receivers as an indicator for spam. Therefore if" +" you really want to send mail from this domain, configure an MX. However, if" +" you do not want to send mail from this domain, configure an SPF record with" +" the `-all` term only and besides a \"Null MX\" record if your domain has " +"A/AAAA records. Because of your configuration, the subtests in the STARTTLS " +"and DANE category and the mail server specific subtests in the IPv6 and " +"DNSSEC categories are not applicable." msgid "detail mail tls version exp" msgstr "" @@ -1892,6 +1952,12 @@ msgstr "Recommendation: 'strict-origin-when-cross-origin' should not be used." msgid "detail tech data http-referrer-policy values" msgstr "Found policy: {values}" +msgid "detail tech data http-securitytxt bom_in_file" +msgstr "" +"Error: The Byte Order Mark (\"BOM\") signature must not appear at the " +"beginning of the content that must be encoded using UTF-8 in Net-Unicode " +"form." + msgid "detail tech data http-securitytxt data_after_sig" msgstr "" "Error: Signed security.txt must not contain data after the signature (line " @@ -1908,6 +1974,12 @@ msgstr "" "Error: Date and time in 'Expires' field must not be in the past (line " "{line_no})." +msgid "detail tech data http-securitytxt invalid_cert" +msgstr "" +"Error: security.txt must be served with a valid TLS certificate.\n" +"\n" +"[Note: this content label is currently not used. See #1046.]" + msgid "detail tech data http-securitytxt invalid_charset" msgstr "" "Error: Charset parameter in Content-Type header must be 'utf-8' if present." @@ -1920,7 +1992,8 @@ msgstr "" msgid "detail tech data http-securitytxt invalid_lang" msgstr "" "Error: Value in 'Preferred-Languages' field must match one or more language " -"tags as defined in RFC 5646, separated by commas (line {line_no})." +"tags as defined in [RFC 5646](https://www.rfc-editor.org/rfc/rfc5646), " +"separated by commas (line {line_no})." msgid "detail tech data http-securitytxt invalid_line" msgstr "" @@ -1930,6 +2003,12 @@ msgstr "" msgid "detail tech data http-securitytxt invalid_media" msgstr "Error: Media type in Content-Type header must be 'text/plain'." +msgid "detail tech data http-securitytxt invalid_uri_scheme" +msgstr "" +"Error: The security.txt file access must use the HTTPS scheme.\n" +"\n" +"[Note: this content label is currently not used. See #1046.]" + msgid "detail tech data http-securitytxt location" msgstr "" "Error: security.txt was located on the top-level path (legacy place), but " @@ -2036,7 +2115,7 @@ msgstr "" "standardised field name (line {line_no})." msgid "detail tech data http-securitytxt utf8" -msgstr "Error: Content must be utf-8 encoded." +msgstr "Error: Content must encoded using UTF-8 in Net-Unicode form." msgid "detail tech data insecure" msgstr "insecure" @@ -2108,9 +2187,11 @@ msgstr "" " * 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" "\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`). Therfore we do *not* check for CSP that is offered via the HTML `` element.\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" "5. Use the HTTP header for `Content-Security-Policy-Report-Only` to experiment with your CSP configuration by monitoring its effect without enforcing it.\n" -"6. Note that an empty source list (i.e. a CSP directive without a value) is equivalent to a source list containing `none`. Besides, note that if other sources are listed in a source list next to `none`, then the attribute `none` is ignored. \n" +"6. Note that an empty source list (i.e. a CSP directive without a value) is equivalent to a source list containing `none`. Besides, note that if other sources are listed in a source list next to `none`, then the attribute `none` is ignored.\n" +"\n" +"Note on IPv6/IPv4: for performance reasons all tests in the category 'Security options' only run for the first available IPv6 and IPv4 address.\n" "\n" "Also see \n" "['Web application guidelines from NCSC-NL'](https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties), guideline U/PW.03 (in Dutch).\n" @@ -2135,7 +2216,7 @@ msgstr "" msgid "detail web appsecpriv http-referrer-policy exp" msgstr "" -"We check if your web server provides an HTTP header for `Referrer-Policy` with a sufficiently secure and privacy-protecting policy value. With this policy your webserver instructs browsers if, what and when referrer data should be sent to the website the user is navigating to from your website. This referrer data is sent in the `Referer` header by the browser to the website the user is navigating to. This navigation does not necessarily have to be cross-domain.\n" +"We check if your web server provides an HTTP header for `Referrer-Policy` with a sufficiently secure and privacy-protecting policy value. With this policy your web server instructs browsers if, what and when referrer data should be sent to the website the user is navigating to from your website. This referrer data is sent in the `Referer` header by the browser to the website the user is navigating to. This navigation does not necessarily have to be cross-domain.\n" "\n" "The data in the `Referer` header is usually used for analytics and logging. However there can be privacy and security risks. The data could be used e.g. for user tracking and the data could leak to third parties who eavesdrop the connection. The HTTP header for `Referrer-Policy` allows you to mitigate these risks by controlling and even minimizing the sending of referrer data.\n" "\n" @@ -2169,7 +2250,9 @@ msgstr "" "1. To prevent leaking of sensitive data through URLs, please make sure URLs of your website do not contain personal or otherwise sensitive data (like personal names or passwords).\n" "2. `strict-origin-when-cross-origin` is the default policy value when no `Referrer-Policy` is published as prescribed in the current \"Editor's Draft\" of the `Referrer-Policy` standard and this default is used by all latest major browsers. Note that some users may still have a different default value configured in their browser.\n" "3. Use the HTTP `Referrer-Policy` header as a mechanism for serving your referrer policy. We do *not* recommend to use the HTML `` element or the HTML `referrerpolicy` content attribute to publish your referrer policy, especially because the sections that describe these methods in the standard are marked as \"not normative\". Therefore we do not check for a referrer policy that is offered via the latter two methods.\n" -"4. Note that a web server may send multiple `Referrer-Policy` headers, and a `Referrer-Policy` header may contain multiple values. Unknown values will be ignored by the browser and only the last known value will be used. This makes it possible to use future standardised policy values that are not supported by all browsers yet. However, currently all latest major browsers support the above mentioned policy values under \"Good\" and \"Warning\". \n" +"4. Note that a web server may send multiple `Referrer-Policy` headers, and a `Referrer-Policy` header may contain multiple values. Unknown values will be ignored by the browser and only the last known value will be used. This makes it possible to use future standardised policy values that are not supported by all browsers yet. However, currently all latest major browsers support the above mentioned policy values under \"Good\" and \"Warning\".\n" +"\n" +"Note on IPv6/IPv4: for performance reasons all tests in the category 'Security options' only run for the first available IPv6 and IPv4 address.\n" "\n" "*Requirement level: Recommended*" @@ -2204,7 +2287,7 @@ msgstr "" "\n" "The syntax of the file is intended to be machine- and human-readable. The contact information can be an email address, a phone number, and/or a web page (e.g. a web form). Note that published contact information is public and can also be abused, for example, to send spam to a published e-mail address.\n" "\n" -"Besides contact infomation, the `security.txt` file must also contain an expiry date. To avoid staleness it is recommended that the date be less than a year into the future. It is optional to also include other relevant information for security researchers, like a link to your policy on dealing with security vulnerabilities reports (usually called a Coordinated Vulnerability Disclosure policy).\n" +"Besides contact information, the `security.txt` file must also contain an expiry date. To avoid staleness it is recommended that the date be less than a year into the future. It is optional to also include other relevant information for security researchers, like a link to your policy on dealing with security vulnerabilities reports (usually called a Coordinated Vulnerability Disclosure policy).\n" "\n" "It is recommended to PGP sign the `security.txt` file while including the web URI on which the file is located in a `Canonical` field. We check if the `security.txt` file is signed. However, we do *not* validate the signature because, unfortunately, there is no standardised place to retrieve a public PGP key (which is required for signature validation).\n" "\n" @@ -2216,6 +2299,8 @@ msgstr "" "\n" "Note that `security.txt` files are normally just a few kilobytes in size. We therefore read and evaluate at maximum the first 100 kB of a found `security.txt` file. \n" "\n" +"Note on IPv6/IPv4: for performance reasons all tests in the category 'Security options' only run for the first available IPv6 and IPv4 address.\n" +"\n" "*Requirement level: Recommended*" msgid "detail web appsecpriv http-securitytxt label" @@ -2246,6 +2331,8 @@ msgstr "" " \n" "'MIME type sniffing' is a technique where the browser scans the content of a file to detect the format of a file regardless of the declared `Content-Type` by the web server. This technique is vulnerable to the so-called 'MIME confusion attack' in which the attacker manipulates the content of a file in a way that it is treated by the browser as a different `Content-Type`, like an executable.\n" "\n" +"Note on IPv6/IPv4: for performance reasons all tests in the category 'Security options' only run for the first available IPv6 and IPv4 address.\n" +"\n" "*Requirement level: Recommended* " msgid "detail web appsecpriv http-x-content-type label" @@ -2273,6 +2360,8 @@ msgstr "" "\n" "Also see ['Web application guidelines from NCSC-NL'](https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties), guideline U/PW.03 (in Dutch).\n" "\n" +"Note on IPv6/IPv4: for performance reasons all tests in the category 'Security options' only run for the first available IPv6 and IPv4 address.\n" +"\n" "*Requirement level: Optional* " msgid "detail web appsecpriv http-x-frame label" @@ -2411,37 +2500,39 @@ msgstr "At least one of your web servers has an IPv6 address." msgid "detail web ipv6 web-ipv46 exp" msgstr "" -"We compare the response and content received from your web server over IPv6 with that received over IPv4. \n" +"We compare the available ports and offered headers and content of your web server via IPv6 with those via IPv4. \n" +"\n" +"We check if:\n" "\n" -"We check:\n" +"1. the same ports, i.e. HTTP (port 80) and/or HTTPS (port 443), are available via both IPv6 and IPv4; \n" +"2. the same HTTP headers are offered via both IPv6 and IPv4. This includes HTTP response codes, like successful responses (200 – 299) and redirection messages (300 – 399). In cases of a client error response (400 - 499) or a server error response (500 - 599) a warning without score impact is given, because such a HTTP response code may indicate a configuration issue;\n" +"3. the same HTML content is offered via both IPv6 and IPv4. We do this by comparing the content received after stripping any nonces. The content difference must not be higher than 10% to pass this subtest. This threshold ensures that small non-problematic differences (for example due to changing advertisements) do not immediately result in a failing result for this subtest. An observed difference may still be intended or due to measurement error. Therefore, in case of failure, this part of the subtest results only in a warning with no score impact.\n" "\n" -"1. if HTTP (port 80) and/or HTTPS (port 443) over IPv4 are also available over IPv6;\n" -"2. if HTTP headers (such as a redirect header) over IPv4 are also received over IPv6;\n" -"3. if HTML content over IPv4 is the same over IPv6. After stripping eventual nonces we do a comparison of the received content. The content difference must not be higher than 10% to pass this subtest. The treshold makes sure that small differences (for example due to changing ads) do not lead to a fail of this subtest as well. An observed difference may be intended or due to a measurement error. Therefore, in this case, a warning is given and it is not weighed into the score. \n" +"Additional notes:\n" "\n" -"Note that in case there are multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4 address to perform the subtest. \n" -"If only an IPv6 address and no IPv4 address is available, the subtest is not applicable because no comparison can be made." +"- In case there are multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4 address to perform the subtest. \n" +"- If only an IPv6 address and no IPv4 address (or vice versa) is available, the subtest is not applicable because no comparison can be made.\n" +"- This subtest follows redirects and also checks all underlying URLs." msgid "detail web ipv6 web-ipv46 label" msgstr "Same website on IPv6 and IPv4" msgid "detail web ipv6 web-ipv46 verdict bad" msgstr "" -"Available ports or offered headers of your website over IPv4 are *not* the " -"same over IPv6." +"Available ports or offered headers of your website via IPv4 are *not* the " +"same via IPv6." msgid "detail web ipv6 web-ipv46 verdict good" -msgstr "Your website on IPv6 seems to be the same as your website on IPv4." +msgstr "Your website via IPv6 looks identical via IPv4." msgid "detail web ipv6 web-ipv46 verdict notice" msgstr "" -"The HTML content of your website over IPv4 is *not* the same over IPv6. " +"The HTML content of your website via IPv4 is *not* the same via IPv6. " msgid "detail web ipv6 web-ipv46 verdict notice-status-code" msgstr "" -"Your website on IPv6 seems to be the same as your website on IPv4, but the " -"HTTP response code is in the 4xx or 5xx range. This may indicate a " -"configuration issue." +"Your website via IPv6 looks identical via IPv4, but the HTTP response code " +"is in the 4xx or 5xx range. This may indicate a configuration issue." msgid "detail web ipv6 web-reach exp" msgstr "" @@ -2473,15 +2564,13 @@ msgstr "" "\n" "However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.\n" "\n" -"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.\n" -"\n" -"*Requirement level: Recommended*" +"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks." msgid "detail web rpki exists label" msgstr "Route Origin Authorisation existence" msgid "detail web rpki exists tech table" -msgstr "Webserver|IP address|RPKI Route Origin Authorization" +msgstr "Web server|IP address|RPKI Route Origin Authorization" msgid "detail web rpki exists verdict bad" msgstr "" @@ -2512,20 +2601,18 @@ msgstr "" "\n" "Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.\n" "\n" -"- `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" +"1․ `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" "\n" -"- `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes:\n" +"2․ `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes:\n" "\n" -" 1. the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" -" 2. the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" +"* the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" +"* the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" " \n" -"- `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" +"3․ `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" "\n" "**What to do if the test result shows the status Invalid?**\n" "\n" -"The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server's IP addresses to fix the route configuration error. \n" -"\n" -"*Requirement level: Recommended*" +"The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server's IP addresses to fix the route configuration error. " msgid "detail web rpki valid label" msgstr "Route announcement validity" @@ -2550,11 +2637,11 @@ msgstr "" msgid "detail web rpki valid verdict invalid" msgstr "" "At least one IP address of your web server has an `Invalid` validation " -"state. The route announcement of the affected IP adresses is *not* matched " +"state. The route announcement of the affected IP addresses is *not* matched " "by the published RPKI Route Origin Authorisation (ROA). This indicates an " "unintentional or malicious route configuration error, that can be caused by " "your web hoster (internal error) or by a third party (external error). In " -"either case, it can lead to the unreachability of your server or the " +"either case, it increases the risk for unreachability of your server or for " "interception of Internet traffic to your server. Contact your web hoster as " "soon as possible. In the case of an internal error, your web hoster should " "ask its network provider that owns your server's IP addresses to fix the " @@ -2952,15 +3039,15 @@ msgstr "" "\n" "* Sufficient:\n" "\n" -" * [ffdhe4096](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem) (RFC 7919) \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) \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" " * Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.\n" "\n" "* Phase out:\n" "\n" -" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe2048.pem) (RFC 7919) \n" +" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe2048.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n" " sha256 checksum: `9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b`\n" "\n" "* Insufficient: Other groups\n" @@ -2986,7 +3073,7 @@ msgstr "" msgid "detail web tls fs-params verdict na" msgstr "" -"This subtest is not applicable as your webserver does *not* support Diffie-" +"This subtest is not applicable as your web server does *not* support Diffie-" "Hellman key exchange. Note that RSA is an alternative for key exchange, but " "has the *phase out* status." @@ -3000,7 +3087,7 @@ msgid "detail web tls http-compression exp" msgstr "" "We test if your web server supports HTTP compression. \n" "\n" -"HTTP compression makes the secure connection with your webserver vulnerable for the BREACH attack. However HTTP compression is commonly used to make more efficient use of available bandwidth. Consider the trade-offs involved with HTTP compression. If you choose to use HTTP compression, verify if it is possible to mitigate related attacks at the application level. An example of such a measure is limiting the extent to which an attacker can influence the response of a server. \n" +"HTTP compression makes the secure connection with your web server vulnerable for the BREACH attack. However HTTP compression is commonly used to make more efficient use of available bandwidth. Consider the trade-offs involved with HTTP compression. If you choose to use HTTP compression, verify if it is possible to mitigate related attacks at the application level. An example of such a measure is limiting the extent to which an attacker can influence the response of a server. \n" "\n" "This subtest checks if the web server on root directory level supports HTTP compression. However it does not check additional website sources like images and scripts. \n" "\n" @@ -3035,7 +3122,9 @@ msgstr "" "\n" "If so, we also check in the below subtests whether HTTPS is configured sufficiently secure in conformance with the ['IT Security Guidelines for Transport Layer Security (TLS) v2.1'](https://english.ncsc.nl/publications/publications/2021/january/19/it-security-guidelines-for-transport-layer-security-2.1) from NCSC-NL.\n" "\n" -"HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user. Note: for performance reasons the tests in the HTTPS test section only run for the first available IPv6 and IPv4 address." +"HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user. \n" +"\n" +"Note on IPv6/IPv4: for performance reasons all tests in the category 'Secure connection (HTTPS)' only run for the first available IPv6 and IPv4 address." msgid "detail web tls https-exists label" msgstr "HTTPS available" @@ -3167,10 +3256,10 @@ msgstr "Your web server supports a secure hash function for key exchange." msgid "detail web tls kex-hash-func verdict other" msgstr "" -"We were unable to determine the hash function used by your webserver. This " +"We were unable to determine the hash function used by your web server. This " "could be because the cipher combination used has no signature for " -"certificate verification (e.g it uses RSA key exchange or is anonymous i.e. " -"`anon`)." +"certificate verification (e.g. it uses RSA key exchange or is anonymous i.e." +" `anon`)." msgid "detail web tls kex-hash-func verdict phase-out" msgstr "" @@ -3358,7 +3447,7 @@ 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 webserver does not support TLS 1.3." +"This subtest is not applicable as your web server does not support TLS 1.3." msgid "detail web-mail ipv6 ns-AAAA exp" msgstr "" @@ -3409,9 +3498,7 @@ msgstr "" "\n" "However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.\n" "\n" -"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.\n" -"\n" -"*Requirement level: Recommended*" +"Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out `Invalid` routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks." msgid "detail web-mail rpki ns-exists label" msgstr "Route Origin Authorisation existence" @@ -3448,18 +3535,18 @@ msgstr "" "\n" "Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.\n" "\n" -"- `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" -"\n" -"- `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes: \n" +"1․ `Valid`: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the `maxLength` attribute). \n" "\n" -" 1. the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" -" 2. the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" +"2․ `Invalid`: The route announcement of the considered IP address is covered by a route authorisation, but it does *not* match. There are two possible causes:\n" "\n" -" Note: The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server's IP addresses to fix the route configuration error. \n" +"* the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is *not* authorised in the route authorisation (result in the table below: \"invalid (as)\");\n" +"* the IP address block (Route Prefix) that is announced is *smaller than is allowed* in the route authorisation, i.e. exceeding `maxLength` value (result in table below: \"invalid (length)\").\n" " \n" -"- `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" +"3․ `NotFound`: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server's IP addresses to publish route authorisations.\n" "\n" -"*Requirement level: Recommended*" +"**What to do if the test result shows the status Invalid?**\n" +"\n" +"The status `Invalid` indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server's IP addresses to fix the route configuration error. " msgid "detail web-mail rpki ns-valid label" msgstr "Route announcement validity" @@ -3484,15 +3571,15 @@ msgstr "" msgid "detail web-mail rpki ns-valid verdict invalid" msgstr "" "At least one IP address of your name servers has an `Invalid` validation " -"state. The route announcement of the affected IP adresses is *not* matched " +"state. The route announcement of the affected IP addresses is *not* matched " "by the published RPKI Route Origin Authorisation (ROA). This indicates an " "unintentional or malicious route configuration error, that can be caused by " "your name server hoster (internal error) or by a third party (external " -"error). In either case, it can lead to the unreachability of your server or " -"the interception of Internet traffic to your server. Contact your name " -"server hoster as soon as possible. In the case of an internal error, your " -"name server hoster should ask its network provider that owns your server's " -"IP addresses to fix the route configuration error." +"error). In either case, it increases the risk for unreachability of your " +"server or for interception of Internet traffic to your server. Contact your " +"name server hoster as soon as possible. In the case of an internal error, " +"your name server hoster should ask its network provider that owns your " +"server's IP addresses to fix the route configuration error." msgid "detail web-mail rpki ns-valid verdict not-routed" msgstr "" @@ -3593,11 +3680,11 @@ msgstr "" "### X-Frame-Options\n" "- [\"7.6 The X-Frame-Options header\" in HTML Living Standard](https://html.spec.whatwg.org/multipage/document-lifecycle.html#x-frame-options)\n" "- [RFC 7034: HTTP Header Field X-Frame-Options](https://www.rfc-editor.org/rfc/rfc7034)\n" -"- [X-Frame-Options, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)\n" +"- [X-Frame-Options, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)\n" "\n" "### X-Content-Type-Options \n" -"- [Blog 'IE8 Security Part VI: Beta 2 Update'](https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/)\n" -"- [X-Content-Type-Options, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)\n" +"- [X-Content-Type-Options, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)\n" +"- [Blog 'IE8 Security Part VI: Beta 2 Update'](https://learn.microsoft.com/nl-nl/archive/blogs/ie/ie8-security-part-vi-beta-2-update)\n" "\n" "### X-XSS-Protection (deprecated)\n" "- [X-XSS-Protection test removed from Internet.nl](/article/x-xss-protection-removed-and-improvement-for-no-mx-domains/)\n" @@ -3605,13 +3692,13 @@ msgstr "" "### Content-Security-Policy (CSP)\n" "- [Content Security Policy Level 3, W3C Working Draft](https://www.w3.org/TR/CSP3/) (In conformance with CSP3 we consider `frame-src` *not* as deprecated.)\n" "- [Content Security Policy Level 2, W3C Recommendation](https://www.w3.org/TR/CSP2/)\n" -"- [Content-Security-Policy, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n" +"- [Content-Security-Policy, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n" "- [Mozilla's Laboratory (Content Security Policy / CSP Toolkit)](https://addons.mozilla.org/nl/firefox/addon/laboratory-by-mozilla/)\n" "\n" "### Referrer-Policy\n" "- [Referrer Policy, W3C Candidate Recommendation, 26 January 2017](https://www.w3.org/TR/referrer-policy/)\n" "- [Referrer Policy, Editor’s Draft](https://w3c.github.io/webappsec-referrer-policy/)\n" -"- [Referrer-Policy, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)\n" +"- [Referrer-Policy, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)\n" "\n" "## Other security options\n" "\n" @@ -3644,6 +3731,22 @@ msgstr "" msgid "faqs badges title" msgstr "Using the 100% badges" +msgid "faqs batch-and-dashboard content" +msgstr "" +"Besides the website for testing individual domain names, Internet.nl also provides the following tooling that can be used for testing multiple domain names:\n" +"\n" +"- [Batch API](https://github.com/internetstandards/Internet.nl-API-docs)\n" +"- [Web-based dashboard](https://dashboard.internet.nl)\n" +"\n" +"## Examples of use\n" +"For some examples of organisations using Internet.nl's API and web-based dashboard see [\"Measurements using Internet.nl\"](/faqs/measurements/).\n" +"\n" +"## Attribution\n" +"If you re-use the Internet.nl test results in your own website or service, we kindly ask you for attribution. For more information see [\"terms of use\"](https://github.com/internetstandards/Internet.nl-API-docs/blob/main/terms-of-use.md) and [\"copyright\"](/copyright/)." + +msgid "faqs batch-and-dashboard title" +msgstr "Batch API and web-based dashboard" + #, md-format msgid "faqs content" msgstr "" @@ -3664,7 +3767,11 @@ msgstr "" "## Test report, badges, and hall of fame\n" "* [Explanation of test report](/faqs/report/)\n" "* [Using the 100% badges](/faqs/badges/)\n" -"* [Criteria for 'Hall of Fame for Hosters'](/faqs/halloffame/)" +"* [Criteria for 'Hall of Fame for Hosters'](/faqs/halloffame/)\n" +"\n" +"## Testing multiple domains\n" +"* [Batch API and web-based dashboard](/faqs/batch-and-dashboard/)\n" +"* [Measurements using Internet.nl](/faqs/measurements/)" #, md-format msgid "faqs dnssec content" @@ -3675,7 +3782,7 @@ msgstr "" "* [\"Cache-poisoning attack snares top Brazilian bank\"](https://www.theregister.co.uk/2009/04/22/bandesco_cache_poisoning_attack/)\n" "* [\"Eircom reveals ‘cache poisoning’ attack by hacker led to outages\"](https://www.siliconrepublic.com/enterprise/eircom-reveals-cache-poisoning-attack-by-hacker-led-to-outages)\n" "* [\"DNS cache poisonings foist malware attacks on Brazilians\"](https://www.theregister.co.uk/2011/11/07/brazilian_dns_cache_poisoing_attacks/)\n" -"* [\"Probable Cache Poisoning of Mail Handling Domains\"](https://www.cert.org/blogs/certcc/post.cfm?EntryID=206)\n" +"* [\"Cache Poisoning of Mail Handling Domains Revisited\"](https://insights.sei.cmu.edu/blog/cache-poisoning-of-mail-handling-domains-revisited/)\n" "* [\"Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery Security\"](https://dl.acm.org/citation.cfm?id=2815695)\n" "\n" "Below follows a quotation from the last mentioned research publication:\n" @@ -3683,6 +3790,7 @@ msgstr "" "> Mail security, like that of many other protocols, is intrinsically tangled with the security of DNS resolution. Rather than target the SMTP protocol, an active network attacker can spoof the DNS records of a destination mail server to redirect SMTP connections to a server under the attacker’s control. [...] We find evidence that 178,439 out of 8,860,639(2.01%) publicly accessible DNS servers provided invalid IPs or MX records for one or more of these domains.\n" "\n" "## Usage statistics\n" +"* [Pulse - DNSSEC metric](https://pulse.internetsociety.org/en/technologies/#metric-dnssec) by Internet Society\n" "* [.nl statistics on DNSSEC](https://stats.sidnlabs.nl/en/) by SIDN Labs\n" "* [DNSSEC Validation Measurement](https://stats.labs.apnic.net/dnssec) by APNIC\n" "* [DNSSEC Deployment Report](https://dnssec-deployment.icann.org/dctld/)\n" @@ -3750,6 +3858,7 @@ msgstr "" "* [.nl statistics on HTTPS](https://stats.sidnlabs.nl/nl/) by SIDN Labs\n" "* [\"Percentage of Web Pages Loaded by Firefox Using HTTPS\"](https://letsencrypt.org/de/stats/#percent-pageloads)\n" "* [\"HTTPS Usage\" by Google](https://www.google.com/transparencyreport/https/metrics/?hl=en)\n" +"* [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" @@ -3774,15 +3883,15 @@ 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.html) by John Curran (ARIN)\n" -"* [\"IPv6: It's time to get on board\"](https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/) by Paul Saab (Facebook)\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" "## Usage statistics\n" +"* [Pulse - IPv6 metric](https://pulse.internetsociety.org/en/technologies/#metric-ipv6) by Internet Society\n" "* [.nl statistics on IPv6](https://stats.sidnlabs.nl/en/) by SIDN Labs\n" "* [APNIC IPv6 Measurements](https://stats.labs.apnic.net/ipv6/)\n" "* [World IPv6 Launch](https://www.worldipv6launch.org/measurements/)\n" -"* [Akamai IPv6 adoption](https://www.akamai.com/us/en/about/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp)\n" "* [Google IPv6 statistics](https://www.google.com/intl/en/ipv6/statistics.html)\n" "* [Cisco IPv6 statistics](https://6lab.cisco.com/stats/)\n" "* [IPv6 RIPEness information](https://ipv6ripeness.ripe.net/)\n" @@ -3790,7 +3899,7 @@ msgstr "" "## Background information\n" "* [FAQ on IPv6](https://www.sidn.nl/en/modern-internet-standards/ipv6) by SIDN\n" "* [ISOC's Deploy360 on IPv6](https://www.internetsociety.org/deploy360/ipv6/)\n" -"* [IPv6 Info Centre at RIPE](https://www.ripe.net/publications/ipv6-info-centre/)\n" +"* [IPv6 Info Centre at RIPE NCC](https://www.ripe.net/publications/ipv6-info-centre/)\n" "* [Wikipedia on IPv6](https://en.wikipedia.org/wiki/IPv6)\n" "* [\"Policy Issues for Receiving Email in a World with IPv6 Hosts\" from M³AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf)\n" "\n" @@ -3815,6 +3924,7 @@ msgstr "" "## Background information\n" "* [How-to on DMARC, DKIM and SPF](https://toolbox.internet.nl) by Dutch Internet Standards Platform\n" "* [FAQ on e-mail security standards](https://www.sidn.nl/en/modern-internet-standards/e-mail-security-standards) by SIDN\n" +"* [Factsheet 'Protect domains against phishing'](https://english.ncsc.nl/publications/publications/2024/february/20/factsheet-protect-domains-against-phishing) by NCSC-NL\n" "* [DMARC.org](https://dmarc.org/), [OpenSPF.org (archive)](http://web.archive.org/web/20190125100326/http://www.openspf.org/), and [DKIM Core](https://dkimcore.org/)\n" "* [DKIM Key Rotation Best Common Practices](https://www.m3aawg.org/DKIMKeyRotation) by M3AAWG\n" "* [Protecting Parked Domains Best Common Practices](https://www.m3aawg.org/M3AAWG-Protecting-Parked-Domains-BCP-update-2022-06) by M3AAWG\n" @@ -3829,11 +3939,29 @@ msgstr "" msgid "faqs mailauth title" msgstr "Protection against email phishing (DMARC, DKIM and SPF)" +msgid "faqs measurements content" +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" +"- [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" +"- [Internet Society Portugal: Observatório de Tecnologias da Internet Portuguesa](https://observatory.isoc.pt/) [in Portugese]\n" +"- [Netherlands registry for government domain names](https://organisaties.overheid.nl/domeinen) [in Dutch]" + +msgid "faqs measurements title" +msgstr "Measurements using Internet.nl" + #, md-format msgid "faqs report score content" msgstr "" "### What norm is Internet.nl using?\n" -"Internet.nl checks the (correct) implementation of modern Internet Standards that improve the reliability of online services. A score of 100% means that a website, e-mail service or internet connection complies with our test norm. This norm is based on the Internet Standards on the 'comply-or-explain' list of the Dutch Standardisation Forum, on the security advices of the Dutch NCSC and on the relevant RFCs of IETF.\n" +"Internet.nl checks the (correct) implementation of modern Internet Standards that improve the reliability of online services. A score of 100% means that a website, e-mail service or internet connection complies with our test norm. This norm is based on the list of open standards mandatory for governments maintained by the Netherlands Standardisation Forum, on the security advices of NCSC-NL and on the relevant RFCs of IETF.\n" +"\n" +"### Does a 100% score mean compliance with all mandatory Internet standards?\n" +"Please note that a 100% score does not necessarily mean compliance with all mandatory Internet standards for Dutch government organisations. This is because not all mandatory Internet standards are (fully) tested, also because this is sometimes impossible or very difficult. Furthermore, certain mandatory Internet standards may be tested but are not yet included in the score.\n" "\n" "### Will the norm be adjusted?\n" "The test norm of Internet.nl will be adjusted over time as the state of the art changes. Adjustments will be announced through news items on our website. New subtests will (usually) not impact the score after their initial release and have the 'RECOMMENDED' or 'OPTIONAL' status. In the future these new items could get the 'REQUIRED' status and weigh in the overall score.\n" @@ -3855,9 +3983,11 @@ msgstr "" "\n" "### How is the percentage score calculated?\n" "- Each main test is resulting in an overall percentage score.\n" -"- Every test category of a main test weighs more or less evenly in the overall percentage score. So if a main test consists of four test categories, the maximum score for every test category is 25%.\n" +"- Every test category of a main test weighs evenly in the overall percentage score. So if a main test consists of five test categories, the maximum score for every test category is 20%.\n" "- Only the subtests with the status 'REQUIRED' weigh in the score of a test category and in the overall percentage score.\n" -"- Websites with a perfect score of 100% will be added to the [Hall of Fame](/halloffame/)." +"- Websites with a perfect score of 100% will be added to the [Hall of Fame](/halloffame/).\n" +"\n" +"See Internet.nl's [documentation on scoring](https://github.com/internetstandards/Internet.nl/blob/main/documentation/scoring.md) for more details." msgid "faqs report score title" msgstr "Norm and score" @@ -3933,9 +4063,9 @@ msgstr "" "* [RFC 7908: Problem Definition and Classification of BGP Route Leaks](https://www.rfc-editor.org/rfc/rfc7908)\n" "\n" "## Usage statistics\n" +"* Pulse [RPKI ROV metric](https://pulse.internetsociety.org/en/technologies/#metric-route-validation) and [RPKI ROA metric](https://pulse.internetsociety.org/en/technologies/#metric-roa-coverage) by Internet Society\n" "* [Route Origin Authorisation (ROA) statistics](https://roa-stats.manrs.org/) by MANRS\n" -"* [Route Origin Authorisation (ROA) statistics](https://rpki-maps.nlnetlabs.nl) by NLnet Labs\n" -"* [.nl statistics for Route Origin Authorisation (ROA)](https://stats.sidnlabs.nl/en/security.html#domain%20names%20protected%20with%20rpki) by SIDN Labs\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" "\n" "## Background information\n" @@ -3945,8 +4075,7 @@ msgstr "" "## Specifications\n" "* [RFC 3779: X.509 Extensions for IP Addresses and AS Identifiers](https://www.rfc-editor.org/rfc/rfc3779)\n" "* [RFC 6482: A Profile for Route Origin Authorizations (ROAs)](https://www.rfc-editor.org/rfc/rfc6482)\n" -"* [RFC 6811: BGP Prefix Origin Validation](https://www.rfc-editor.org/rfc/rfc6811)\n" -"* [RPKI RFCs Graph](https://rpki-rfc.routingsecurity.net/)" +"* [RFC 6811: BGP Prefix Origin Validation](https://www.rfc-editor.org/rfc/rfc6811)" msgid "faqs rpki title" msgstr "Authorisation for routing (RPKI)" @@ -3957,7 +4086,7 @@ msgstr "" "## Why\n" "* [\"Opportunistic Security: Some Protection Most of the Time\"](https://www.rfc-editor.org/rfc/rfc7435) by V. Dukhovni\n" "* [\"New e-mail security protocols mandatory within government\"](https://www.sidnlabs.nl/a/weblog/new-e-mail-security-protocols-mandatory-within-government?language_id=2) by Marco Davids (SIDN)\n" -"* [\"The sad state of SMTP encryption\"](https://blog.filippo.io/the-sad-state-of-smtp-encryption/) by Filippo Valsorda\n" +"* [\"The sad state of SMTP encryption\"](https://words.filippo.io/the-sad-state-of-smtp-encryption/) by Filippo Valsorda\n" "\n" "## Usage statistics\n" "* [DANE trend graphs](https://stats.dnssec-tools.org/#/graphs?top=dane)\n" @@ -4117,7 +4246,7 @@ msgstr "" "modern standards, security, internet security, mail, email security, " "website, website security, internet connection, secure connection, email " "authentication, encryption, ciphers, cipher suites, PKI, SSL certificate, " -"TLS certificate, website certificaat, Internet Standards Platform" +"TLS certificate, website certificate, Internet Standards Platform" msgid "page sitedescription" msgstr "Is your Internet up-to-date?" @@ -4137,7 +4266,7 @@ msgid "privacy content" msgstr "" "# Privacy statement\n" "\n" -"*Revised 24th of October 2023*\n" +"*Revised 28th of January 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" @@ -4169,7 +4298,7 @@ msgstr "" "- Error message with regard to processing the request.\n" "\n" "#### User analytics\n" -"We put analytical cookies on your device to analyze the use of our website. We run Matomo (formerly Piwik) on our own web server. Matomo is one of the most privacy-friendly analytical tools currently available. The statistics generated with these cookies are used only to improve our website.\n" +"We put analytical cookies on your device to analyse the use of our website. We run Matomo (formerly Piwik) on our own web server. Matomo is one of the most privacy-friendly analytical tools currently available. The statistics generated with these cookies are used only to improve our website.\n" "\n" "We collect the following data:\n" "\n" @@ -4180,7 +4309,7 @@ msgstr "" "- URL of the page being viewed;\n" "- URL of the page that was viewed prior to the current page;\n" "- Screen resolution;\n" -"- Time in local timezone;\n" +"- Time in local time zone;\n" "- Files that were clicked and downloaded;\n" "- Link clicks to an outside domain;\n" "- Pages generation time;\n" @@ -4195,14 +4324,16 @@ msgstr "" "- Email address used and other mail header data (like time);\n" "- Any other personal data that the sender put in the mail.\n" "\n" +"We use a locally hosted instance of [Zammad](https://zammad.org/) as a help desk system.\n" +"\n" "## What third-party services are used?\n" "\n" "### WHOIS\n" "In the website and email test, the registrar of the tested domain is queried via WHOIS. For this purpose, a query of the [IANA WHOIS Service](https://www.iana.org/whois) and of the WHOIS Service of the respective TLD registry (e.g. the [WHOIS Service of SIDN](https://www.sidn.nl/whois)) is done using the WHOIS protocol (plain text on TCP port 43).\n" "\n" "### Team Cymru\n" -"* In the RPKI test component of the website and email test, for each IP address found, the corresponding BGP Origin ASN is queried using Team Cymru's [\"IP to ASN Mapping Service\"](https://team-cymru.com/community-services/ip-asn-mapping/).\n" -"* In the connection test, for the IP addresses of your client and of your DNS provider, the ASN Description (for the purpose of naming the ISP and DNS provider) is queried using Team Cymru's [\"IP to ASN Mapping Service\"](https://team-cymru.com/community-services/ip-asn-mapping/).\n" +"* In the RPKI test component of the website and email test, for each IP address found, the corresponding BGP Origin ASN is queried using Team Cymru's [\"IP to ASN Mapping Service\"](https://www.team-cymru.com/ip-asn-mapping).\n" +"* In the connection test, for the IP addresses of your client and of your DNS provider, the ASN Description (for the purpose of naming the ISP and DNS provider) is queried using Team Cymru's [\"IP to ASN Mapping Service\"](https://www.team-cymru.com/ip-asn-mapping).\n" "\n" "IP addresses are anonymized as much as possible prior to the query (for IPv4 on a /24, for IPv6 on a /48). The query takes place via DNS on UDP port 53. \n" "\n" @@ -4218,7 +4349,7 @@ msgstr "" "## What measures are in place to secure the collected data?\n" "\n" "### Access and third parties\n" -"Our services are running on servers that are hosted by Prolocation ([single test website](https://internet.nl) and [batch test API](https://batch.internet.nl)) and by TransIP ([dashboard](https://dashboard.internet.nl)). ECP is in charge of operating the mailbox. Collected data and received information may be shared with other [members of the Internet Standards Platform](/about/) only to answer questions, to solve issues or to improve our services.\n" +"Our services are running on servers that are hosted by Prolocation ([single test website](https://internet.nl), [batch test API](https://batch.internet.nl), our email and our help desk system) and by TransIP ([dashboard](https://dashboard.internet.nl)). ECP is in charge of operating the mailbox. Collected data and received information may be shared with other [members of the Internet Standards Platform](/about/) only to answer questions, to solve issues or to improve our services.\n" "\n" "Except for the services listed under \"What third-party services are used?\", no third party services are used (like external analytics tooling or web fonts). We do not in any way pass on personal data collected by us to third parties (i.e. outside the Internet Standards Platform), unless we are legally obliged to do so (for example, if the authorities with a legal basis request data from us).\n" "\n" @@ -4232,7 +4363,7 @@ msgstr "" "In case you find a vulnerability, despite of our efforts, please act in accordance with our [responsible disclosure](/disclosure/) policy.\n" "\n" "### Anonymization\n" -"- Application: The anonymization of the IP address of your client means that at least the last 16 bits of each IPv4 address and the last 96 bits of each IPv6 address are discarded and replaced with zero's before storing in the application database (e.g. visible is only 198.51.0.0 or 2001:db8::). Besides we anonymize the found reverse name by masking the first one or more labels. By anonymizing the IP address and reverse name we make sure that it is usually nearly impossible to relate these directly to a person anymore, even not with the other associated data collected. \n" +"- Application: The anonymization of the IP address of your client means that at least the last 16 bits of each IPv4 address and the last 96 bits of each IPv6 address are discarded and replaced with zero's before storing in the application database (e.g. visible is only 198.51.0.0 or 2001:db8::). Besides we anonymize the found reverse name by masking the first one or more labels. By anonymizing the IP address and reverse name we make sure that it is usually nearly impossible to relate these directly to a person any more, even not with the other associated data collected.\n" "IP addresses belonging to web servers, mail servers or name servers will not be anonymized, because we consider this data to be public data which is published in DNS. The same goes for domain names; we also consider this to be public data. \n" "- User analytics: At least 16 bits for IPv4 and 80 bits for IPv6 are discarded and replaced with zero's before storing an IP address in our analytics tooling (e.g. visible is only 198.51.0.0 or 2001:db81:85a3::).\n" "\n" @@ -4240,13 +4371,13 @@ msgstr "" "- Application: Because the anonymized visiting IP address and associated collected data can not be directly related to a person, we do not maintain a specific retention period for the data stored in our application database.\n" "- Server logs: Data collected in our server logs will be deleted after three calendar months.\n" "- User analytics: Individual visitor data (including the anonymized IP address) in our analytics tooling will be deleted after 90 days.\n" -"- Email: Processing emails is a core activity of The Dutch Internet Standards Platform. Based on the [requirements](https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/ondernemen/administratie/administratie_opzetten/wat_hoort_er_allemaal_bij_uw_administratie) set by the Dutch Tax and Customs Administration, email correspondence will be deleted after seven years. \n" +"- Email: In accordance with the [requirements](https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/ondernemen/administratie/#hoelang-gegevens-bewaren) set by the Dutch Tax and Customs Administration, email correspondence is retained for at least seven years.\n" "\n" "## Inspection, correction and deletion of data\n" "Pursuant to the European General Data Protection Regulation (GDPR), you have the right of access to your personal data upon request and, if necessary, to amend it or have it deleted. Please [contact us](/about/) in case you wish to do so. Because we keep your full IP address only temporarily in our server logs, you might need to supply us with additional information, such as about your device and browser as well as the date and time of your visit, for us to be able to honour your request.\n" "\n" "## Update privacy statement\n" -"We may change our privacy statement. We will announce this change on our website. Older versions of our privacy statement will be stored in our archive. Send us an email if you want to consult it." +"We may change our privacy statement. We will publish new versions on our website. Older versions of our privacy statement will be stored in our archive. Send us an email if you want to consult it." msgid "probes auto-redirect" msgstr "" @@ -4340,7 +4471,7 @@ msgstr "" " - [IP6.nl](https://ip6.nl/)\n" " - [IP address visibility](https://stat.ripe.net/widget/visibility)\n" "- ### DNSSEC:\n" -" - [DNSViz](http://dnsviz.net/)\n" +" - [DNSViz](https://dnsviz.net/)\n" " - [Zonemaster](https://zonemaster.net)\n" "- ### DMARC, DKIM and SPF :\n" " - [MECSA - EU Commission](https://mecsa.jrc.ec.europa.eu/) (also STARTTLS+DANE)\n" @@ -4371,7 +4502,7 @@ msgstr "" " - [SSL Labs](https://www.ssllabs.com/ssltest/)\n" "- ### Security options:\n" " - [CSP Evaluator](https://csp-evaluator.withgoogle.com/)\n" -" - [Analyze your CSP](https://report-uri.com/home/analyse/)\n" +" - [Analyse your CSP](https://report-uri.com/home/analyse/)\n" "- ### RPKI:\n" " - [Routinator](https://routinator.nlnetlabs.nl/) \n" " - [IRR explorer](https://irrexplorer.nlnog.net/)\n" @@ -4717,6 +4848,14 @@ msgid "test mailipv6 warning summary" msgstr "" "*Not* reachable via modern internet address, or improvement possible (IPv6)" +msgid "test mailrpki error description" +msgstr "" +"Test not ready to run yet. Please try again later. Sorry for the " +"inconvenience." + +msgid "test mailrpki error summary" +msgstr "Test not ready to run (RPKI)" + msgid "test mailrpki failed description" msgstr "" "Too bad! At least one of the IP addresses of your receiving mail server(s) " @@ -4724,8 +4863,8 @@ msgstr "" "by the published route authorisation ([RPKI](/faqs/rpki/)). This indicates " "an unintentional or malicious route configuration error, that can be caused " "by your mail hoster or your name server hoster (internal error) or by a " -"third party (external error). In either case, it can lead to the " -"unreachability of your server or the interception of Internet traffic to " +"third party (external error). In either case, it increases the risk for " +"unreachability of your server or for interception of Internet traffic to " "your server. Contact your mail hoster or name server hoster as soon as " "possible. In the case of an internal error, they should ask their network " "provider that owns your server's IP addresses to fix the route configuration" @@ -4764,7 +4903,7 @@ msgstr "Route authorisation?" msgid "test mailrpki warning description" msgstr "" -"Warning! At least one of the IP addresses of your receiving mail server(s) " +"Too bad! At least one of the IP addresses of your receiving mail server(s) " "and associated name servers has a route announcement for which *no* route " "authorisation is published ([RPKI](/faqs/rpki/)). As a result, email " "transport between sending mail servers with enabled route validation and " @@ -4813,12 +4952,16 @@ msgstr "Secure mail server connection (STARTTLS and DANE)" msgid "test mailtls no-mx description" msgstr "" -"Informational: No receiving mail servers (MX) are set on your domain that " -"does not have A/AAAA records. This is fine if you do not want to receive " -"email. Note that you do *not* need a 'Null MX' record in this case. Your " -"configuration makes the subtests in the STARTTLS and DANE category not " -"applicable. This also goes for the mail server specific subtests in the " -"categories for IPv6 and DNSSEC. " +"Informational: The SPF record on your domain indicates that your domain may " +"be used for sending mail. However, your domain does not have a receiving " +"mail server (MX), which could hinder deliverability of your sent mails " +"because not having an MX may be seen by receivers as an indicator for spam. " +"Therefore if you really want to send mail from this domain, configure an MX." +" However, if you do not want to send mail from this domain, configure an SPF" +" record with the `-all` term only and besides a \"Null MX\" record if your " +"domain has A/AAAA records. Because of your configuration, the subtests in " +"the STARTTLS and DANE category and the mail server specific subtests in the " +"IPv6 and DNSSEC categories are not applicable." msgid "test mailtls no-mx summary" msgstr "Properly configured non-receiving mail domain (STARTTLS and DANE)" @@ -4826,11 +4969,11 @@ msgstr "Properly configured non-receiving mail domain (STARTTLS and DANE)" msgid "test mailtls no-null-mx description" msgstr "" "Informational: No receiving mail servers (MX) are set on your domain that " -"has A/AAAA records. We recommend you to explicitly indicate that your domain" -" does not accept email by configuring a \"Null MX\" record. Your current " -"configuration makes the subtests in the STARTTLS and DANE category not " -"applicable. This also goes for the mail server specific subtests in the " -"categories for IPv6 and DNSSEC. " +"has A/AAAA records and has an SPF record with only the term `-all`. We " +"recommend you to set a \"Null MX\" record to explicitly indicate that your " +"domain does not accept email. Because of your configuration, the subtests in" +" the STARTTLS and DANE category and the mail server specific subtests in the" +" IPv6 and DNSSEC categories are not applicable." msgid "test mailtls no-null-mx summary" msgstr "" @@ -4883,8 +5026,8 @@ msgid "test mailtls unreachable description" msgstr "" "Test error: at least one of your receiving mail servers was not reachable " "for us, making it impossible to (fully) test for STARTTLS and DANE. This " -"could be caused by network connectivity problems or by the mailserver(s) not" -" accepting connections." +"could be caused by network connectivity problems or by the mail server(s) " +"not accepting connections." msgid "test mailtls unreachable summary" msgstr "Unreachable receiving mail server (STARTTLS and DANE)" @@ -4893,7 +5036,7 @@ msgid "test mailtls untestable description" msgstr "" "Test error: at least one of your receiving mail servers was not testable for" " us, making it impossible to (fully) test for STARTTLS and DANE. This could" -" be caused by, among other things, SMTP errors and ratelimiting measures " +" be caused by, among other things, SMTP errors and rate limiting measures " "engaging and dropping connections." msgid "test mailtls untestable summary" @@ -4914,12 +5057,13 @@ msgstr "" "security.txt, are set for your website ([Security " "options](/faqs/appsecpriv/)). With security headers you can activate browser" " mechanisms to protect visitors against attacks involving, for example, " -"cross-site scripting (XSS) or framing. Through a security.txt file you can " +"cross-site scripting (XSS) or framing. Security headers are also relevant " +"for domains with response codes such as '301 Redirect' and '404 Not Found', " +"because they create their own browsing context (MIME type 'text/html') that " +"may be vulnerable to certain attacks. Through a security.txt file you can " "provide researchers who have found a vulnerability on your systems, with " -"your contact infomation and your Coordinated Vulnerability Disclosure " -"policy. Note that HTTPS is a prerequisite for all tested security options. " -"Security headers (except for Referrer-Policy) are *not* relevant for domains" -" that redirect (through a 301/302 HTTP Status Code). " +"your contact information and your Coordinated Vulnerability Disclosure " +"policy. Note that HTTPS is a prerequisite for all tested security options." msgid "test siteappsecpriv failed summary" msgstr "One or more required security options *not* set (Security options)" @@ -4930,12 +5074,14 @@ msgstr "" "and security.txt, are set for your website ([Security " "options](/faqs/appsecpriv/)). With security headers you can activate browser" " mechanisms to protect visitors against attacks involving, for example, " -"cross-site scripting (XSS) or framing. Through a security.txt file you can " -"provide researchers who have found a vulnerability on your systems, with " -"your contact infomation and your Coordinated Vulnerability Disclosure " -"policy. Note that HTTPS is a prerequisite for all tested security options. " -"Security headers (except for Referrer-Policy) are not relevant for domains " -"that redirect (through a 301/302 HTTP Status Code)." +"cross-site scripting (XSS) or framing. Security headers are also relevant " +"for domains with HTTP response codes such as '301 Redirect' and '404 Not " +"Found', because they create their own browsing context (MIME type " +"'text/html') that may be vulnerable to certain attacks. Through a " +"security.txt file you can provide researchers who have found a vulnerability" +" on your systems, with your contact information and your Coordinated " +"Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all " +"tested security options." msgid "test siteappsecpriv info summary" msgstr "One or more optional security options *not* set (Security options)" @@ -4949,12 +5095,13 @@ msgstr "" " set for your website ([Security options](/faqs/appsecpriv/)). With security" " headers you can activate browser mechanisms to protect visitors against " "attacks involving, for example, cross-site scripting (XSS) or framing. " -"Through a security.txt file you can provide researchers who have found a " -"vulnerability on your systems, with your contact infomation and your " -"Coordinated Vulnerability Disclosure policy. Note that HTTPS is a " -"prerequisite for all tested security options. Security headers (except for " -"Referrer-Policy) are *not* relevant for domains that redirect (through a " -"301/302 HTTP Status Code). " +"Security headers are also relevant for domains with HTTP response codes such" +" as '301 Redirect' and '404 Not Found', because they create their own " +"browsing context (MIME type 'text/html') that may be vulnerable to certain " +"attacks. Through a security.txt file you can provide researchers who have " +"found a vulnerability on your systems, with your contact information and " +"your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a " +"prerequisite for all tested security options." msgid "test siteappsecpriv passed summary" msgstr "All security options set (Security options) " @@ -4968,12 +5115,14 @@ msgstr "" " security.txt, are set for your website ([Security " "options](/faqs/appsecpriv/)). With security headers you can activate browser" " mechanisms to protect visitors against attacks involving, for example, " -"cross-site scripting (XSS) or framing. Through a security.txt file you can " -"provide researchers who have found a vulnerability on your systems, with " -"your contact infomation and your Coordinated Vulnerability Disclosure " -"policy. Note that HTTPS is a prerequisite for all tested security options. " -"Security headers (except for Referrer-Policy) are *not* relevant for domains" -" that redirect (through a 301/302 HTTP Status Code). " +"cross-site scripting (XSS) or framing. Security headers are also relevant " +"for domains with HTTP response codes such as '301 Redirect' and '404 Not " +"Found', because they create their own browsing context (MIME type " +"'text/html') that may be vulnerable to certain attacks. Through a " +"security.txt file you can provide researchers who have found a vulnerability" +" on your systems, with your contact information and your Coordinated " +"Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all " +"tested security options. " msgid "test siteappsecpriv warning summary" msgstr "One or more recommended security options *not* set (Security options)" @@ -5073,6 +5222,14 @@ msgid "test siteipv6 warning summary" msgstr "" "*Not* reachable via modern internet address, or improvement possible (IPv6)" +msgid "test siterpki error description" +msgstr "" +"Test not ready to run yet. Please try again later. Sorry for the " +"inconvenience." + +msgid "test siterpki error summary" +msgstr "Test not ready to run (RPKI)" + msgid "test siterpki failed description" msgstr "" "Too bad! At least one of the IP addresses of your web server and associated " @@ -5080,11 +5237,12 @@ msgstr "" "published route authorisation ([RPKI](/faqs/rpki/)). This indicates an " "unintentional or malicious route configuration error, that can be caused by " "your web hoster or your name server hoster (internal error) or by a third " -"party (external error). In either case, it can lead to the unreachability of" -" your server or the interception of Internet traffic to your server. Contact" -" your web hoster or name server hoster as soon as possible. In the case of " -"an internal error, they should ask their network provider that owns your " -"server's IP addresses to fix the route configuration error." +"party (external error). In either case, it increases the risk for " +"unreachability of your server or for interception of Internet traffic to " +"your server. Contact your web hoster or name server hoster as soon as " +"possible. In the case of an internal error, they should ask their network " +"provider that owns your server's IP addresses to fix the route configuration" +" error." msgid "test siterpki failed summary" msgstr "*Unauthorised* route announcement (RPKI)" @@ -5118,7 +5276,7 @@ msgstr "Route authorisation?" msgid "test siterpki warning description" msgstr "" -"Warning! At least one of the IP addresses of your web server and associated " +"Too bad! At least one of the IP addresses of your web server and associated " "name servers has a route announcement for which *no* route authorisation is " "published ([RPKI](/faqs/rpki/)). As a result, visitors with enabled route " "validation are *not* (fully) protected against various unintentional or " @@ -5168,12 +5326,12 @@ msgstr "Secure connection?" msgid "test sitetls unreachable description" msgstr "" -"Your webserver was not reachable for us, making it impossible to (fully) " +"Your web server was not reachable for us, making it impossible to (fully) " "test for HTTPS. This could be caused by network connectivity problems or by " -"the webserver not accepting connections." +"the web server not accepting connections." msgid "test sitetls unreachable summary" -msgstr "Unreachable webserver (HTTPS)" +msgstr "Unreachable web server (HTTPS)" msgid "test sitetls warning description" msgstr "" @@ -5190,7 +5348,7 @@ msgstr "" "## Notes\n" "\n" "* Logo: We recommend you to save and use our [logo](/static/logo_en.svg) on your own web server. In that way there will not be any contact with our web server when your website is visited.\n" -"* Content-Security-Policy (CSP): In case you are using a CSP policy for your website you would also need to add `internet.nl` to the rules for `form-action` and possibly also for `img-src` in case you link to the logo on our webserver." +"* Content-Security-Policy (CSP): In case you are using a CSP policy for your website you would also need to add `internet.nl` to the rules for `form-action` and possibly also for `img-src` in case you link to the logo on our web server." msgid "widget mail html-block" msgstr "**Test your email**" diff --git a/dashboard/internet_nl_dashboard/locale/nl/LC_MESSAGES/django.po b/dashboard/internet_nl_dashboard/locale/nl/LC_MESSAGES/django.po index bf855e54..1e5fd7c4 100644 --- a/dashboard/internet_nl_dashboard/locale/nl/LC_MESSAGES/django.po +++ b/dashboard/internet_nl_dashboard/locale/nl/LC_MESSAGES/django.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: 2024-05-14 12:27:07.966760\n" +"PO-Revision-Date: 2025-01-28 12:01:21.310918\n" "Last-Translator: \n" "Language-Team: \n" "Language: \n" @@ -50,9 +50,9 @@ msgstr "" "- [Dutch Cloud Community](https://dutchcloudcommunity.nl/)\n" "- [ECP](https://ecp.nl/)\n" "- [Forum Standaardisatie](https://forumstandaardisatie.nl/)\n" -"- [Internet Society internationaal](https://internetsociety.org/)\n" +"- [Internet Society internationaal](https://www.internetsociety.org/)\n" "- [Internet Society Nederland](https://isoc.nl/)\n" -"- [Ministerie van Economische Zaken en Klimaat](https://www.rijksoverheid.nl/ministeries/ministerie-van-economische-zaken-en-klimaat)\n" +"- [Ministerie van Economische Zaken](https://www.rijksoverheid.nl/ministeries/ministerie-van-economische-zaken)\n" "- [NCSC](https://ncsc.nl/)\n" "- [NLnet](https://nlnet.nl/)\n" "- [NLnet Labs](https://nlnetlabs.nl/)\n" @@ -62,7 +62,12 @@ msgstr "" "- [SURF](https://surf.nl/)\n" "- [Vereniging van Registrars](https://www.verenigingvanregistrars.nl/)\n" " \n" -"ECP biedt de administratieve basis voor het platform. De domeinnaam Internet.nl is beschikbaar gesteld aan het platform door Internet Society Nederland. [Open Netlabs](https://opennetlabs.nl/) / NLnet Labs heeft de basis gelegd voor Internet.nl en de onderliggende tooling. Vanaf 1 april 2021 vinden onderhoud en doorontwikkeling plaats door het projectteam van het Platform Internetstandaarden.\n" +"ECP biedt de administratieve basis voor het platform. De domeinnaam Internet.nl is beschikbaar gesteld aan het platform door Internet Society Nederland. NLnet Labs heeft de basis gelegd voor Internet.nl en de onderliggende tooling. Vanaf 1 april 2021 vinden onderhoud en doorontwikkeling plaats door het projectteam van het Platform Internetstandaarden.\n" +"\n" +"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" "\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" @@ -275,10 +280,12 @@ msgstr "" "## Content\n" "Tenzij anders vermeld, is de inhoud van de website Internet.nl beschikbaar onder de [\"Creative Commons Naamsvermelding 4.0 Internationaal\" licentie](https://creativecommons.org/licenses/by/4.0/deed.nl).\n" "\n" -"## Broncode\n" +"## Software\n" +"\n" +"### Broncode\n" "De software-broncode van Internet.nl is gepubliceerd onder de [Apache Licentie, versie 2.0](https://opensource.org/licenses/Apache-2.0) op [Github](https://github.com/internetstandards/Internet.nl).\n" "\n" -"## Bouwstenen\n" +"### Bouwstenen\n" "Internet.nl is mede mogelijk gemaakt door andere open source software te gebruiken en te combineren. De belangrijkste open source bouwstenen van Internet.nl zijn:\n" "\n" "- [Python 3](https://www.python.org/) (belangrijkste programmeertaal)\n" @@ -293,17 +300,49 @@ msgstr "" "- [SecTXT](https://github.com/DigitalTrustCenter/sectxt) (voor security.txt-test)\n" "- [Postfix](https://www.postfix.org/) (mailserver voor interactieve e-mailtest, _beta_)\n" "\n" +"### Donaties\n" +"Om de (open source) projecten waar we op voortbouwen te bedanken en te ondersteunen, geven we hen regelmatig donaties.\n" +"\n" +"#### 2024\n" +"- Celery: USD 1500\n" +"- Mastodon.nl (Stichting ActivityClub): EUR 1500\n" +"- nassl & sslyze (Alban Diquet): EUR 1500\n" +"\n" +"#### 2023\n" +"- Celery: USD 1408,98\n" +"- Django Software Foundation: USD 1409\n" +"- Mastodon gGmbH: EUR 1500\n" +"\n" +"#### 2019\n" +"- Celery: EUR 1500\n" +"- Django Software Foundation: EUR 1500\n" +"- Python Software Foundation: EUR 1500\n" +"\n" "## Namen en logo's\n" "- De naam Internet.nl en het Internet.nl-logo zijn expliciet uitgesloten van bovengenoemde licentiëring. We geven geen toestemming voor het gebruik van beide als onze content of softwarecode wordt hergebruikt, tenzij er door ons een expliciete uitzondering wordt gemaakt en aan de bijbehorende criteria is voldaan (bijv. bij de [100%-badges](/faqs/badges/)).\n" "- De namen en logo's in de iconen die verwijzen naar onze plekken op social media zijn expliciet uitgesloten van bovengenoemde licentiëring.\n" "\n" -"## Andere testwebsites gebaseerd op Internet.nl\n" +"## Hergebruik\n" "\n" -"Voor zover bekend hebben de volgende test-websites de Internet.nl broncode hergebruikt. Laat het ons weten als jouw website gebaseerd is op onze broncode.\n" +"### Hergebruikers van broncode\n" +"\n" +"Voor zover bekend maken de volgende test-websites hergebuik van de Internet.nl broncode. Laat het ons weten als jouw website gebaseerd is op onze broncode.\n" "\n" -"- [aucheck.com.au](https://aucheck.com.au/) (Australië)\n" "- [top.nic.br](https://top.nic.br/) (Brazilië)\n" -"- [sikkerpånettet.dk](https://sikkerpånettet.dk/) (Denemarken)" +"- [sikkerpånettet.dk](https://xn--sikkerpnettet-vfb.dk/) (Denemarken)\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" +"\n" +"#### Broncode\n" +"\n" +"> Deze website maakt hergebruik van broncode van het [Internet.nl](https://internet.nl)-project.\n" +"\n" +"Merk op dat als je de broncode niet alleen hergebruikt, maar ook verder verspreidt, de eerder genoemde Apache-licentie ook eisen stelt aan naamsvermelding.\n" +"\n" +"#### Testresultaten\n" +"\n" +"> Deze website maakt hergebruik van testresultaten van de [Internet.nl](https://internet.nl)-testtool." msgid "detail conn dnssec validation exp" msgstr "" @@ -432,13 +471,16 @@ msgstr "" "* Om te slagen voor deze test verwachten we dat je nameserver `NOERROR` antwoordt op onze bevraging\n" "voor `_domainkey.example.nl`. Als `_domainkey.example.nl` een 'empty non-\n" "terminal' is, dan zullen sommige nameservers die zich niet houden aan de\n" -"standaard RFC 2308, foutief antwoorden met `NXDOMAIN` in plaats van\n" +"standaard [RFC 2308](https://www.rfc-editor.org/rfc/rfc2308), foutief antwoorden met `NXDOMAIN` in plaats van\n" "`NOERROR`. Dit maakt het detecteren van het DKIM-record voor ons onmogelijk.\n" "* Op dit moment zijn we niet in staat om de publieke sleutel in je DKIM-record op te vragen en te beoordelen, omdat we daarvoor \n" "een e-mail van jouw domein zouden moeten ontvangen.\n" "* Bij deze test gaan we uit van 'strict alignment' hetgeen conform DMARC is. Het geteste domein wordt beschouwd als het verzenddomein in het mailbericht (`From:`) en moet gelijk zijn aan zowel het DKIM-domein (`d=`) als het SPF-domein (envelope sender, d.w.z. return-path dat terugkomt in `MAIL FROM`).\n" "\n" -"Voor een \"good practice voor domeinnamen zonder mail\" zie de [uitleg van de \"DMARC-policy\" subtest](#control-panel-9)." +"Aanvullende opmerkingen:\n" +"\n" +"* Sommige e-mailsystemen wijzigen e-mail tijdens het transport, waardoor een DKIM-handtekening mogelijk ongeldig wordt. In veel gevallen zijn deze wijzigingen onschuldig. Voorbeelden zijn het vervangen van witruimte en het herordenen van headervelden. Als u een DKIM-ondertekenende verzender bent, dan kunt u kiezen of u dit soort wijzigingen wel of niet tolereert, zowel voor de header als voor de body van e-mails. De `simple` instelling tolereert bijna geen wijzigingen en `relaxed` tolereert veel voorkomende wijzigingen. Als er geen instelling is opgegeven, wordt standaard `simple` gebruikt voor zowel de header als de body. Met name headerwijzigingen zijn een veelvoorkomende oorzaak dat een DKIM-handtekening onbedoeld ongeldig wordt, waardoor de bezorgbaarheid wordt belemmerd. Het gebruik van `relaxed` voor de header en `simple` voor de body (`c=relaxed/simple`) kan dit soort problemen verminderen.\n" +"* Voor een \"good practice voor domeinnamen zonder mail\" zie de [uitleg van de \"DMARC-policy\" subtest](#control-panel-9)." msgid "detail mail auth dkim label" msgstr "DKIM aanwezigheid" @@ -484,7 +526,7 @@ msgstr "" "\n" "We controleren ook of de mailadressen onder `rua=` en `ruf=` geldig zijn. Als deze een extern e-mailadres bevatten dan controleren we of het externe domein geautoriseerd is om DMARC-rapportages te ontvangen. Zorg ervoor dat het DMARC-autorisatierecord op het externe domein ten minste `\"v=DMARC1;\"` bevat.\n" "\n" -"De test staat het gebruik van de experimentele `np` tag toe (RFC 9091).\n" +"De test staat het gebruik van de experimentele `np` tag toe ([RFC 9091](https://www.rfc-editor.org/rfc/rfc9091)).\n" "\n" "*Good practice voor domeinnaam zonder mail:*\n" "\n" @@ -662,8 +704,17 @@ msgstr "" msgid "detail mail dnssec mx-exists verdict no-mailservers" msgstr "" -"Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die " -"geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. " +"Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden " +"gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen " +"ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail " +"kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden " +"gezien als een indicator voor spam. Als je daarom echt mail vanaf deze " +"domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail " +"wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met " +"alleen de term `-all` en daarnaast een \"Null MX\" record als je domeinnaam " +"A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de " +"categorie STARTTLS en DANE en de mailserver-specifieke subtests in de " +"categorieën IPv6 en DNSSEC niet van toepassing." msgid "detail mail dnssec mx-exists verdict no-null-mx" msgstr "" @@ -812,12 +863,12 @@ msgstr "" msgid "detail mail ipv6 mx-AAAA verdict no-null-mx" msgstr "" -"Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel" -" A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je " -"domeinnaam geen e-mail accepteert door een \"Null MX\" record te publiceren." -" Gebruik geen \"Null MX\"-record en stel een MX in als je wel e-mail wil " -"verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met " -"een ongeldig retouradres kunnen weigeren." +"Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-" +"records heeft en dat een SPF-record heeft met alleen de term `-all`. We " +"raden je aan een \"Null MX\" record in te stellen om expliciet aan te geven " +"dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de " +"subtests in de categorie STARTTLS en DANE en de mailserver-specifieke " +"subtests in de categorieën IPv6 en DNSSEC niet van toepassing." msgid "detail mail ipv6 mx-AAAA verdict null-mx" msgstr "" @@ -842,8 +893,17 @@ msgstr "" msgid "detail mail ipv6 mx-AAAA verdict other" msgstr "" -"Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die " -"geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. " +"Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden " +"gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen " +"ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail " +"kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden " +"gezien als een indicator voor spam. Als je daarom echt mail vanaf deze " +"domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail " +"wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met " +"alleen de term `-all` en daarnaast een \"Null MX\" record als je domeinnaam " +"A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de " +"categorie STARTTLS en DANE en de mailserver-specifieke subtests in de " +"categorieën IPv6 en DNSSEC niet van toepassing." msgid "detail mail ipv6 mx-reach exp" msgstr "" @@ -876,9 +936,7 @@ msgstr "" "\n" "Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar uw server wordt onderschept.\n" "\n" -"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.\n" -"\n" -"*Niveau van vereistheid: Aanbevolen*" +"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd." msgid "detail mail rpki exists label" msgstr "Aanwezigheid van Route Origin Authorisation" @@ -909,9 +967,7 @@ msgstr "" "\n" "Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.\n" "\n" -"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.\n" -"\n" -"*Niveau van vereistheid: Aanbevolen*" +"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd." msgid "detail mail rpki mx-ns-exists label" msgstr "Aanwezigheid van Route Origin Authorisation" @@ -948,20 +1004,18 @@ msgstr "" "\n" "Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.\n" "\n" -"- `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" +"1․ `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" "\n" -"- `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" +"2․ `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" "\n" -" 1. het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" -" 2. het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" -" \n" -"- `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" +"* het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" +"* het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" "\n" -"**Wat te doen als het testresultaat de status Invalid toont?**\n" +"3․ `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" "\n" -"De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. \n" +"**Wat te doen als het testresultaat de status Invalid toont?**\n" "\n" -"*Niveau van vereistheid: Aanbevolen*" +"De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. " msgid "detail mail rpki mx-ns-valid label" msgstr "Geldigheid van route-aankondiging" @@ -992,8 +1046,8 @@ msgstr "" "Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of " "kwaadwillige route-configuratiefout, die wordt veroorzaakt door je " "mailhoster (interne fout) óf door een derde partij (externe fout). In beide " -"gevallen kan het leiden tot de onbereikbaarheid van je server of het " -"onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk " +"gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat " +"internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk " "contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn " "netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om " "de route-configuratiefout te herstellen." @@ -1017,20 +1071,18 @@ msgstr "" "\n" "Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.\n" "\n" -"- `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" +"1․ `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" "\n" -"- `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" +"2․ `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" "\n" -" 1. het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" -" 2. het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" -" \n" -"- `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" +"* het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" +"* het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" "\n" -"**Wat te doen als het testresultaat de status Invalid toont?** \n" +"3․ `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" "\n" -"De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. \n" +"**Wat te doen als het testresultaat de status Invalid toont?**\n" "\n" -"*Niveau van vereistheid: Aanbevolen*" +"De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. " msgid "detail mail rpki valid label" msgstr "Geldigheid van route-aankondiging" @@ -1060,9 +1112,9 @@ msgstr "" "wordt *niet* gematcht door de gepubliceerde RPKI Route Origin Authorisation " "(ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, " "die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde " -"partij (externe fout). In beide gevallen kan het leiden tot de " -"onbereikbaarheid van je server of het onderscheppen van internetverkeer naar" -" je server. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een " +"partij (externe fout). In beide gevallen verhoogt dit het risico dat je " +"server onbereikbaar wordt of dat internetverkeer naar je server wordt " +"onderschept. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een " "interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de " "IP-adressen van je server, vragen om de route-configuratiefout te " "herstellen." @@ -1215,7 +1267,7 @@ msgstr "" "\n" "Als je mailserver alleen 'Goede' ciphers ondersteunt, dan is deze test niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.\n" "\n" -"I. *Server afgedwongen cipher-volgorde*: Ontvangende mailservers dwingen hun cipher-voorkeur af tijdens de onderhandeling met verzendende mailservers, en accepteren geen voorkeur van de verzendende mailservers;\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" "\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" "\n" @@ -1408,6 +1460,8 @@ msgstr "" "\n" "Deze subtest accepteert ook andere combinaties van DANE TLSA records, d.w.z. \"3 x x\" + \"3 x x\" of \"3 x x\" + \"2 x x\". Andere typen dan de bovengenoemde zijn in de regel gevoeliger voor fouten en minder interoperabel.\n" "\n" +"Merk op dat als een mailserver tegelijkertijd twee certificaten aanbiedt (één gebaseerd op RSA en één gebaseerd op ECDSA), een afzonderlijk DANE TLSA rollover schema wordt aanbevolen voor ieder certificaat. De subtest controleert niet op dit scenario. Als er slechts één DANE TLSA-record is geconfigureerd voor elk certificaat, dan geeft deze subtest een vals-positief resultaat.\n" +"\n" "*Niveau van vereistheid: Optioneel*" msgid "detail mail tls dane-rollover label" @@ -1479,15 +1533,15 @@ msgstr "" "\n" "* Voldoende:\n" "\n" -" * [ffdhe4096](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem) (RFC 7919) \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/master/ffdhe3072.pem) (RFC 7919) \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" "\n" "* Uit te faseren:\n" "\n" -" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe2048.pem) (RFC 7919) \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" "\n" "* Onvoldoende: Andere groepen\n" @@ -1601,7 +1655,7 @@ msgstr "" "\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" "\n" -"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/onderwerpen/verbindingsbeveiliging/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn 8-1 en tabel 13.\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" "\n" "*Niveau van vereistheid: Optioneel*\n" "\n" @@ -1665,7 +1719,7 @@ msgstr "" "\n" "*Niet ontvangende domeinnaam*:\n" "\n" -"1. Null MX: Indien je geen mail wenst te ontvangen op je domeinnaam die A/AAAA-records heeft, dan adviseren we om \"Null MX\" (RFC 7505) te gebruiken. Merk op dat een \"Null MX record\" niet gecombineerd dient te worden met een gewoon MX-record dat naar een mail-host wijst.\n" +"1. Null MX: Indien je geen mail wenst te ontvangen op je domeinnaam die A/AAAA-records heeft, dan adviseren we om \"Null MX\" ([RFC 7505](https://www.rfc-editor.org/rfc/rfc7505)) te gebruiken. Merk op dat een \"Null MX record\" niet gecombineerd dient te worden met een gewoon MX-record dat naar een mail-host wijst.\n" "2. Geen MX: In het geval dat je domein geen A/AAAA-records heeft en je er geen mail op wenst te ontvangen, adviseren we je om helemaal geen MX-record te configureren (dus ook geen \"Null MX\" record). \n" "\n" "* Als we een van de twee bovenstaande gevallen ontdekken, zijn de subtesten in de STARTTLS- en DANE-categorie niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtests in de categorieën voor IPv6 en DNSSEC. Andere subtesten van de e-mailtest (bijv. voor DMARC) zijn nog steeds van toepassing.\n" @@ -1695,12 +1749,12 @@ msgstr "" msgid "detail mail tls starttls-exists verdict no-null-mx" msgstr "" -"Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel" -" A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je " -"domeinnaam geen e-mail accepteert door een \"Null MX\" record te publiceren." -" Gebruik geen \"Null MX\"-record en stel een MX in als je wel e-mail wil " -"verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met " -"een ongeldig retouradres kunnen weigeren." +"Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-" +"records heeft en dat een SPF-record heeft met alleen de term `-all`. We " +"raden je aan een \"Null MX\" record in te stellen om expliciet aan te geven " +"dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de " +"subtests in de categorie STARTTLS en DANE en de mailserver-specifieke " +"subtests in de categorieën IPv6 en DNSSEC niet van toepassing." msgid "detail mail tls starttls-exists verdict null-mx" msgstr "" @@ -1728,8 +1782,17 @@ msgstr "Tenminste één van je mailservers is onbereikbaar." msgid "detail mail tls starttls-exists verdict other-2" msgstr "" -"Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die " -"geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. " +"Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden " +"gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen " +"ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail " +"kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden " +"gezien als een indicator voor spam. Als je daarom echt mail vanaf deze " +"domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail " +"wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met " +"alleen de term `-all` en daarnaast een \"Null MX\" record als je domeinnaam " +"A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de " +"categorie STARTTLS en DANE en de mailserver-specifieke subtests in de " +"categorieën IPv6 en DNSSEC niet van toepassing." msgid "detail mail tls version exp" msgstr "" @@ -1902,6 +1965,11 @@ msgstr "" msgid "detail tech data http-referrer-policy values" msgstr "Gevonden policy: {values}" +msgid "detail tech data http-securitytxt bom_in_file" +msgstr "" +"Fout: De Byte Order Mark (\"BOM\") handtekening moet niet voorkomen aan het " +"begin van de inhoud die gecodeerd moet zijn met UTF-8 in Net-Unicode vorm." + msgid "detail tech data http-securitytxt data_after_sig" msgstr "" "Fout: Ondertekende security.txt moet geen gegevens bevatten na de " @@ -1918,6 +1986,12 @@ msgstr "" "Fout: Datum en tijd in het veld 'Expires' moeten niet in het verleden liggen" " (regel {line_no})." +msgid "detail tech data http-securitytxt invalid_cert" +msgstr "" +"Fout: security.txt moet worden geserveerd met een geldig TLS-certificaat.\n" +"\n" +"[Note: this content label is currently not used. See #1046.]" + msgid "detail tech data http-securitytxt invalid_charset" msgstr "" "Fout: Charset parameter in Content-Type header moet 'utf-8' zijn indien " @@ -1931,8 +2005,8 @@ msgstr "" msgid "detail tech data http-securitytxt invalid_lang" msgstr "" "Fout: De waarde in het veld 'Preferred-Languages' moet overeenkomen met één " -"of meer taal-tags zoals gedefinieerd in RFC 5646, gescheiden door komma's " -"(regel {line_no})." +"of meer taal-tags zoals gedefinieerd in [RFC 5646](https://www.rfc-" +"editor.org/rfc/rfc5646), gescheiden door komma's (regel {line_no})." msgid "detail tech data http-securitytxt invalid_line" msgstr "" @@ -1942,6 +2016,12 @@ msgstr "" msgid "detail tech data http-securitytxt invalid_media" msgstr "Fout: Media type in Content-Type header moet 'text/plain' zijn." +msgid "detail tech data http-securitytxt invalid_uri_scheme" +msgstr "" +"Fout: De toegang tot het bestand security.txt moet het HTTPS-schema gebruiken.\n" +"\n" +"[Note: this content label is currently not used. See #1046.]" + msgid "detail tech data http-securitytxt location" msgstr "" "Fout: security.txt stond op het top-level pad (verouderde locatie), maar " @@ -2055,7 +2135,7 @@ msgstr "" "sprake van een typfout in een gestandaardiseerde veldnaam (regel {line_no})." msgid "detail tech data http-securitytxt utf8" -msgstr "Fout: Inhoud moet utf-8 gecodeerd zijn." +msgstr "Fout: Inhoud moet gecodeerd zijn met UTF-8 in Net-Unicode vorm." msgid "detail tech data insecure" msgstr "insecure" @@ -2128,7 +2208,9 @@ msgstr "" "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" "4. Gebruik de HTTP-header voor `Content-Security-Policy-Report-Only` om te experimenteren met je CSP-configuratie door het effect ervan te controleren maar nog niet af te dwingen.\n" -"5. Merk op dat een lege bronnenlijst (d.w.z. een CSP-richtlijn zonder waarde) gelijk is aan een bronnenlijst met `none`. Merk bovendien op dat als er andere bronnen in een bronnenlijst naast `none` staan, het attribuut `none` wordt genegeerd. \n" +"5. Merk op dat een lege bronnenlijst (d.w.z. een CSP-richtlijn zonder waarde) gelijk is aan een bronnenlijst met `none`. Merk bovendien op dat als er andere bronnen in een bronnenlijst naast `none` staan, het attribuut `none` wordt genegeerd.\n" +"\n" +"Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie 'Beveiligingsopties' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.\n" "\n" "Zie ook ['Webapplicatie-richtlijnen van NCSC, Verdieping'](https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties), richtlijn U/PW.03.\n" "\n" @@ -2186,7 +2268,9 @@ msgstr "" "1. Om het lekken van gevoelige gegevens via URL's te voorkomen, moet u ervoor zorgen dat URL's van uw website geen persoonlijke of anderszins gevoelige gegevens bevatten (zoals persoonlijke namen of wachtwoorden).\n" "2. `strict-origin-when-cross-origin` is de default policy-waarde wanneer er geen `Referrer-Policy` is gepubliceerd zoals voorgeschreven in de huidige \"Editor's Draft\" van de `Referrer-Policy` standaard en deze default wordt gebruikt door alle nieuwste grote browsers. Merk op dat sommige gebruikers nog steeds een ander default waarde geconfigureerd kunnen hebben in hun browser.\n" "3. Gebruik de HTTP `Referrer-Policy` header als mechanisme om je referrer policy aan te bieden. We raden *niet* aan om het HTML `` element of het HTML `referrerpolicy` content attribuut te gebruiken om je referrer policy te publiceren, vooral omdat de secties die deze methoden beschrijven in de standaard gemarkeerd zijn als \"niet normatief\". Daarom controleren we niet op een referrer policy die wordt aangeboden via de laatste twee methoden.\n" -"4. Merk op dat een webserver meerdere `Referrer-Policy` headers kan sturen, en dat een `Referrer-Policy` header meerdere waarden kan bevatten. Onbekende waarden worden genegeerd door de browser en alleen de laatst bekende waarde wordt gebruikt. Dit maakt het mogelijk om toekomstig gestandaardiseerde policy-waarden te gebruiken die nog niet door alle browsers worden ondersteund. Op dit moment ondersteunen echter alle nieuwste grote browsers de bovenstaande policy-waarden onder \"Goed\" en \"Waarschuwing\". \n" +"4. Merk op dat een webserver meerdere `Referrer-Policy` headers kan sturen, en dat een `Referrer-Policy` header meerdere waarden kan bevatten. Onbekende waarden worden genegeerd door de browser en alleen de laatst bekende waarde wordt gebruikt. Dit maakt het mogelijk om toekomstig gestandaardiseerde policy-waarden te gebruiken die nog niet door alle browsers worden ondersteund. Op dit moment ondersteunen echter alle nieuwste grote browsers de bovenstaande policy-waarden onder \"Goed\" en \"Waarschuwing\".\n" +"\n" +"Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie 'Beveiligingsopties' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.\n" "\n" "*Niveau van vereistheid: Aanbevolen*" @@ -2231,9 +2315,9 @@ msgstr "" "\n" "Met een redirect doorverwijzen naar een `security.txt` op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale `security.txt`.\n" "\n" -"Met een redirect doorverwijzen naar een `security.txt` op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale `security.txt`.\n" +"Merk op dat `security.txt` bestanden normaal gesproken slechts enkele kilobytes groot zijn. We lezen en evalueren daarom maximaal de eerste 100 kB van een gevonden `security.txt` bestand.\n" "\n" -"Merk op dat `security.txt` bestanden normaal gesproken slechts enkele kilobytes groot zijn. We lezen en evalueren daarom maximaal de eerste 100 kB van een gevonden `security.txt` bestand. \n" +"Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie 'Beveiligingsopties' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.\n" "\n" "*Niveau van vereistheid: Aanbevolen*" @@ -2266,6 +2350,8 @@ msgstr "" "\n" "'MIME type sniffing' is een techniek waarbij de browser de inhoud van een bestand scant om te bepalen wat het formaat van het bestand is, ongeacht het door de webserver gedeclareerde `Content-Type`. Deze techniek is kwetsbaar voor de zogenaamde 'MIME confusion attack' waarbij de aanvaller de content van een bestand zodanig manipuleert dat de browser deze behandelt als een andere `Content-Type`, zoals een executeerbaar bestand.\n" "\n" +"Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie 'Beveiligingsopties' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.\n" +"\n" "*Niveau van vereistheid: Aanbevolen*" msgid "detail web appsecpriv http-x-content-type label" @@ -2291,6 +2377,8 @@ msgstr "" "\n" "Merk op dat `Content-Security-Policy` ([CSP](#control-panel-29)) via `frame-ancestors` vergelijkbare bescherming en daarnaast nog veel meer biedt voor bezoekers met moderne webbrowsers. Maar `X-Frame-Options` kan nog steeds bescherming bieden aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan `X-Frame-Options` waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.\n" "\n" +"Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie 'Beveiligingsopties' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.\n" +"\n" "Zie ook ['Webapplicatie-richtlijnen van NCSC, Verdieping'](https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties), richtlijn U/PW.03.\n" "\n" "*Niveau van vereistheid: Optioneel* " @@ -2435,36 +2523,37 @@ msgstr "Tenminste één van je webservers heeft een IPv6-adres." msgid "detail web ipv6 web-ipv46 exp" msgstr "" -"We vergelijken het antwoord en de inhoud die we van je webserver over IPv6 ontvangen met die over IPv4. \n" +"We vergelijken de beschikbare poorten en aangeboden headers en inhoud van je webserver via IPv6 met die via IPv4.\n" "\n" -"We controleren:\n" +"We controleren of:\n" "\n" -"1. of HTTP (poort 80) en/of HTTPS (poort 443) via IPv4 ook beschikbaar zijn via IPv6;\n" -"2. of HTTP-headers (zoals een redirect-header) via IPv4 ook via IPv6 worden ontvangen;\n" -"3. of HTML-inhoud via IPv4 hetzelfde is via IPv6. Na het strippen van eventuele nonces doen we een vergelijking van de ontvangen inhoud. Het verschil in inhoud mag niet groter zijn dan 10% om voor deze subtest te slagen. De drempel zorgt ervoor dat kleine verschillen (bijvoorbeeld als gevolg van veranderende advertenties) niet leiden tot het falen van deze subtest. Een waargenomen verschil kan bedoeld zijn of te maken hebben met een meetfout. Daarom wordt in dit geval een waarschuwing gegeven en telt dit niet mee in de score.\n" +"1. dezelfde poorten, dat wil zeggen HTTP (poort 80) en/of HTTPS (poort 443), beschikbaar zijn via zowel IPv6 als IPv4;\n" +"2. dezelfde HTTP-headers worden aangeboden via zowel IPv6 als IPv4. Dit omvat HTTP response codes, zoals 'successful responses' (200 – 299) en 'redirection messages' (300 – 399). Bij een 'client error response' (400 - 499) of een 'server error response' (500 - 599) wordt een waarschuwing zonder score-impact gegeven, omdat een dergelijke HTTP response code kan wijzen op een configuratieprobleem;\n" +" 3. dezelfde HTML-inhoud wordt aangeboden via zowel IPv6 als IPv4. We doen dit door de ontvangen inhoud te vergelijken na het strippen van eventuele nonces. Het verschil in inhoud mag niet groter zijn dan 10% om te slagen voor deze subtest. Deze drempel zorgt ervoor dat kleine niet-problematische verschillen (bijvoorbeeld door veranderende advertenties) niet direct leiden tot een onvoldoende voor deze subtest. Een waargenomen verschil kan nog steeds bedoeld zijn of te maken hebben met een meetfout. Daarom leidt dit deel van de subtest in geval van falen alleen tot een waarschuwing zonder score-impact.\n" "\n" -"Als er meerdere IPv6- en IPv4-adressen zijn, kiezen we één IPv6-adres en één IPv4-adres om de subtest uit te voeren. \n" -"Als er alleen een IPv6-adres en geen IPv4-adres beschikbaar is, dan is de subtest niet van toepassing omdat er geen vergelijking kan worden gemaakt." +"Aanvullende opmerkingen:\n" +"- Als er meerdere IPv6- en IPv4-adressen zijn, dan kiezen we één IPv6-adres en één IPv4-adres om de subtest uit te voeren.\n" +"- Als er alleen een IPv6-adres en geen IPv4-adres (of omgekeerd) beschikbaar is, dan is de subtest niet van toepassing omdat er geen vergelijking kan worden gemaakt.\n" +"- Deze subtest volgt redirects en controleert ook alle onderliggende URL's." msgid "detail web ipv6 web-ipv46 label" msgstr "Gelijke website op IPv6 en IPv4" msgid "detail web ipv6 web-ipv46 verdict bad" msgstr "" -"Beschikbare poorten of aangeboden headers van je website over IPv4 zijn " -"*niet* hetzelfde over IPv6." +"Beschikbare poorten of aangeboden headers van je website via IPv4 zijn " +"*niet* hetzelfde via IPv6." msgid "detail web ipv6 web-ipv46 verdict good" -msgstr "Je website op IPv6 lijkt gelijk aan je website op IPv4." +msgstr "Je website via IPv6 lijkt identiek via IPv4." msgid "detail web ipv6 web-ipv46 verdict notice" -msgstr "" -"De HTML-inhoud van je website over IPv4 is *niet* hetzelfde over IPv6. " +msgstr "De HTML-inhoud van je website via IPv4 is *niet* hetzelfde via IPv6. " msgid "detail web ipv6 web-ipv46 verdict notice-status-code" msgstr "" -"Je website op IPv6 lijkt gelijk aan je website op IPv4, maar de HTTP " -"response code is 4xx of 5xx. Dit kan wijzen op een configuratiefout." +"Je website via IPv6 lijkt identiek via IPv4, maar de HTTP response code is " +"4xx of 5xx. Dit kan wijzen op een configuratiefout." msgid "detail web ipv6 web-reach exp" msgstr "" @@ -2496,9 +2585,7 @@ msgstr "" "\n" "Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.\n" "\n" -"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.\n" -"\n" -"*Niveau van vereistheid: Aanbevolen*" +"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd." msgid "detail web rpki exists label" msgstr "Aanwezigheid van Route Origin Authorisation" @@ -2535,20 +2622,18 @@ msgstr "" "\n" "Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.\n" "\n" -"- `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" +"1․ `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" "\n" -"- `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" +"2․ `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" "\n" -" 1. het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" -" 2. het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" +"* het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" +"* het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" "\n" -"- `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" +"3․ `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" "\n" "**Wat te doen als het testresultaat de status Invalid toont?**\n" "\n" -"De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. \n" -"\n" -"*Niveau van vereistheid: Aanbevolen*" +"De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. " msgid "detail web rpki valid label" msgstr "Geldigheid van route-aankondiging" @@ -2577,11 +2662,11 @@ msgstr "" " gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit " "duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt " "veroorzaakt door je webhoster (interne fout) óf door een derde partij " -"(externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van" -" je server of het onderscheppen van internetverkeer naar je server. Neem zo " -"spoedig mogelijk contact op met je webhoster. Bij een interne fout moet je " -"webhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je " -"server, vragen om de route-configuratiefout te herstellen." +"(externe fout). In beide gevallen verhoogt dit het risico dat je server " +"onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept." +" Neem zo spoedig mogelijk contact op met je webhoster. Bij een interne fout" +" moet je webhoster zijn netwerkprovider die eigenaar is van de IP-adressen " +"van je server, vragen om de route-configuratiefout te herstellen." msgid "detail web rpki valid verdict not-routed" msgstr "" @@ -2721,7 +2806,7 @@ msgstr "" "\n" "Als je webserver alleen 'Goede' ciphers ondersteunt, dan is deze subtest niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.\n" "\n" -"I. *Server afgedwongen cipher-volgorde*: De webserver dwingt zijn cipher-voorkeur af tijdens de onderhandeling met een webbrowser, en accepteert geen voorkeur van de webbrowser;\n" +"I. *Server afgedwongen cipher-voorkeur*: De webserver dwingt zijn cipher-voorkeur af tijdens de onderhandeling met een webbrowser, en accepteert geen voorkeur van de webbrowser;\n" "\n" "II. *Voorgeschreven volgorde*: Ciphers worden aangeboden door de webserver in overeenstemming met de voorgeschreven volgorde waarbij *Goede* boven *Voldoende* boven *Uit te faseren* ciphers worden geprefereerd. \n" "\n" @@ -2986,15 +3071,15 @@ msgstr "" "\n" "* Voldoende:\n" "\n" -" * [ffdhe4096](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem) (RFC 7919) \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) \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" " * 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" "\n" "* Uit te faseren:\n" "\n" -" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe2048.pem) (RFC 7919) \n" +" * [ffdhe2048](https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe2048.pem) ([RFC 7919](https://www.rfc-editor.org/rfc/rfc7919)) \n" " sha256 checksum: `9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b`\n" "\n" "* Onvoldoende: Andere groepen\n" @@ -3067,9 +3152,11 @@ msgid "detail web tls https-exists exp" msgstr "" "We testen of je website bereikbaar is via HTTPS. \n" "\n" -"Als dat het geval is, dan testen we in de navolgende subtesten of HTTPS ook veilig is geconfigureerd conform de ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/onderwerpen/verbindingsbeveiliging/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1).\n" +"Als dat het geval is, dan testen we in de navolgende subtesten of HTTPS ook veilig is geconfigureerd conform de ['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).\n" +"\n" +"HTTPS garandeert de vertrouwelijkheid en integriteit van uitgewisselde informatie. Omdat het van de situatie afhangt hoe (privacy-)gevoelig en waardevol informatie is, een bezoeker van je website bepaalt 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" -"HTTPS garandeert de vertrouwelijkheid en integriteit van uitgewisselde informatie. Omdat het van de situatie afhangt hoe (privacy-)gevoelig en waardevol informatie is, een bezoeker van je website bepaalt 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. Let op: vanwege performance-redenen worden de testen in het HTTPS-testonderdeel alleen uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres." +"Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie 'Beveiligde verbinding (HTTPS)' alleen uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres." msgid "detail web tls https-exists label" msgstr "HTTPS beschikbaar" @@ -3252,7 +3339,7 @@ msgstr "" "\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 webserver 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" "\n" -"Zie ['ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1'](https://www.ncsc.nl/onderwerpen/verbindingsbeveiliging/documenten/publicaties/2021/januari/19/ict-beveiligingsrichtlijnen-voor-transport-layer-security-2.1) van NCSC, richtlijn 8-1 en tabel 13.\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" "\n" "*Niveau van vereistheid: Optioneel*\n" "\n" @@ -3424,9 +3511,7 @@ msgstr "" "\n" "Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.\n" "\n" -"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.\n" -"\n" -"*Niveau van vereistheid: Aanbevolen*" +"Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (`Invalid`) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd." msgid "detail web-mail rpki ns-exists label" msgstr "Aanwezigheid van Route Origin Authorisation" @@ -3463,18 +3548,18 @@ msgstr "" "\n" "Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.\n" "\n" -"- `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" +"1․ `Valid`: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het `maxLength` attribuut). \n" "\n" -"- `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" +"2․ `Invalid`: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht *niet*. Er zijn twee mogelijke oorzaken: \n" "\n" -" 1. het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" -" 2. het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" +"* het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie *niet* is geautoriseerd (resultaat in onderstaande tabel: \"invalid (as)\");\n" +"* het IP-adresblok (Route Prefix) dat wordt aangekondigd is *kleiner* dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van `maxLength` waarde (resultaat in onderstaande tabel: \"invalid (length)\").\n" "\n" -" Let op: De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. \n" -" \n" -"- `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" +"3․ `NotFound`: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.\n" "\n" -"*Niveau van vereistheid: Aanbevolen*" +"**Wat te doen als het testresultaat de status Invalid toont?**\n" +"\n" +"De status `Invalid` duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. " msgid "detail web-mail rpki ns-valid label" msgstr "Geldigheid van route-aankondiging" @@ -3503,9 +3588,9 @@ msgstr "" " gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit " "duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt " "veroorzaakt door je nameserver-hoster (interne fout) óf door een derde " -"partij (externe fout). In beide gevallen kan het leiden tot de " -"onbereikbaarheid van je server of het onderscheppen van internetverkeer naar" -" je server. Neem zo spoedig mogelijk contact op met je nameserver-hoster. " +"partij (externe fout). In beide gevallen verhoogt dit het risico dat je " +"server onbereikbaar wordt of dat internetverkeer naar je server wordt " +"onderschept. Neem zo spoedig mogelijk contact op met je nameserver-hoster. " "Bij een interne fout moet je nameserver-hoster zijn netwerkprovider die " "eigenaar is van de IP-adressen van je server, vragen om de route-" "configuratiefout te herstellen." @@ -3613,11 +3698,11 @@ msgstr "" "### X-Frame-Options\n" "- [\"7.6 The X-Frame-Options header\" in HTML Living Standard](https://html.spec.whatwg.org/multipage/document-lifecycle.html#x-frame-options)\n" "- [RFC 7034: HTTP Header Field X-Frame-Options](https://www.rfc-editor.org/rfc/rfc7034)\n" -"- [X-Frame-Options, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)\n" +"- [X-Frame-Options, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options)\n" "\n" "### X-Content-Type-Options \n" -"- [Blog 'IE8 Security Part VI: Beta 2 Update'](https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/)\n" -"- [X-Content-Type-Options, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)\n" +"- [X-Content-Type-Options, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options)\n" +"- [Blog 'IE8 Security Part VI: Beta 2 Update'](https://learn.microsoft.com/nl-nl/archive/blogs/ie/ie8-security-part-vi-beta-2-update)\n" "\n" "### X-XSS-Protection (vervallen)\n" "- [X-XSS-Protection test verwijderd van Internet.nl](/article/x-xss-protection-removed-and-improvement-for-no-mx-domains/)\n" @@ -3625,13 +3710,13 @@ msgstr "" "### Content-Security-Policy (CSP)\n" "- [Content Security Policy Level 3, W3C Working Draft](https://www.w3.org/TR/CSP3/) (In overeenstemming met CSP3 beschouwen we `frame-src` *niet* als 'deprecated'.)\n" "- [Content Security Policy Level 2, W3C Recommendation](https://www.w3.org/TR/CSP2/)\n" -"- [Content-Security-Policy, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n" +"- [Content-Security-Policy, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)\n" "- [Mozilla's Laboratory (Content Security Policy / CSP Toolkit)](https://addons.mozilla.org/nl/firefox/addon/laboratory-by-mozilla/)\n" "\n" "### Referrer-Policy\n" "- [Referrer Policy, W3C Candidate Recommendation, 26 January 2017](https://www.w3.org/TR/referrer-policy/)\n" "- [Referrer Policy, Editor’s Draft](https://w3c.github.io/webappsec-referrer-policy/)\n" -"- [Referrer-Policy, MDN webdocs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)\n" +"- [Referrer-Policy, MDN Web Docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)\n" "\n" "## Andere beveiligingsopties \n" "\n" @@ -3665,6 +3750,22 @@ msgstr "" msgid "faqs badges title" msgstr "Gebruik van 100%-badges" +msgid "faqs batch-and-dashboard content" +msgstr "" +"Behalve de website voor het testen van losse domeinnamen, biedt Internet.nl ook de volgende tooling aan die kan worden gebruikt voor het testen van meerdere domeinnamen:\n" +"\n" +"- [Batch API](https://github.com/internetstandards/Internet.nl-API-docs)\n" +"- [Webgebaseerd dashboard](https://dashboard.internet.nl)\n" +"\n" +"## Voorbeelden van gebruik\n" +"Voor een aantal voorbeelden van organisaties die gebruik maken van de API en het webgebaseerde dashboard van Internet.nl zie [\"Metingen met Internet.nl\"](/faqs/measurements/).\n" +"\n" +"## Naamsvermelding\n" +"Als je de testresultaten van Internet.nl hergebruikt in je eigen website of dienst, dan vragen we je vriendelijk om naamsvermelding. Voor meer informatie zie [\"gebruiksvoorwaarden\"](https://github.com/internetstandards/Internet.nl-API-docs/blob/main/terms-of-use.md) en [\"auteursrecht\"](/copyright/)." + +msgid "faqs batch-and-dashboard title" +msgstr "Batch API en webgebaseerd dashboard" + #, md-format msgid "faqs content" msgstr "" @@ -3685,7 +3786,11 @@ msgstr "" "## Testrapport, badges, en hall of fame\n" "* [Toelichting op testrapport](/faqs/report/)\n" "* [Gebruik van de 100%-badges](/faqs/badges/)\n" -"* [Criteria voor 'Hall of Fame voor Hosters'](/faqs/halloffame/)" +"* [Criteria voor 'Hall of Fame voor Hosters'](/faqs/halloffame/)\n" +"\n" +"## Testen van meerdere domeinnamen\n" +"* [Batch API en webgebaseerd dashboard](/faqs/batch-and-dashboard/)\n" +"* [Metingen met Internet.nl](/faqs/measurements/)" #, md-format msgid "faqs dnssec content" @@ -3696,7 +3801,7 @@ msgstr "" "* [\"Cache-poisoning attack snares top Brazilian bank\"](https://www.theregister.co.uk/2009/04/22/bandesco_cache_poisoning_attack/)\n" "* [\"Eircom reveals ‘cache poisoning’ attack by hacker led to outages\"](https://www.siliconrepublic.com/enterprise/eircom-reveals-cache-poisoning-attack-by-hacker-led-to-outages)\n" "* [\"DNS cache poisonings foist malware attacks on Brazilians\"](https://www.theregister.co.uk/2011/11/07/brazilian_dns_cache_poisoing_attacks/)\n" -"* [\"Probable Cache Poisoning of Mail Handling Domains\"](https://www.cert.org/blogs/certcc/post.cfm?EntryID=206)\n" +"* [\"Cache Poisoning of Mail Handling Domains Revisited\"](https://insights.sei.cmu.edu/blog/cache-poisoning-of-mail-handling-domains-revisited/)\n" "* [\"Neither Snow Nor Rain Nor MITM... An Empirical Analysis of Email Delivery Security\"](https://dl.acm.org/citation.cfm?id=2815695)\n" "\n" "Hieronder volgt een citaat uit de laatstgenoemde onderzoekspublicatie:\n" @@ -3704,6 +3809,7 @@ msgstr "" "> Mail security, like that of many other protocols, is intrinsically tangled with the security of DNS resolution. Rather than target the SMTP protocol, an active network attacker can spoof the DNS records of a destination mail server to redirect SMTP connections to a server under the attacker’s control. [...] We find evidence that 178,439 out of 8,860,639(2.01%) publicly accessible DNS servers provided invalid IPs or MX records for one or more of these domains.\n" "\n" "## Gebruiksstatistieken\n" +"* [Pulse - DNSSEC metric](https://pulse.internetsociety.org/en/technologies/#metric-dnssec) door Internet Society\n" "* [.nl-statistieken over DNSSEC](https://stats.sidnlabs.nl/nl/) door SIDN Labs\n" "* [DNSSEC Validation Measurement](https://stats.labs.apnic.net/dnssec) door APNIC\n" "* [DNSSEC Deployment Report](https://dnssec-deployment.icann.org/dctld/)\n" @@ -3771,6 +3877,7 @@ msgstr "" "* [.nl-statistieken over HTTPS](https://stats.sidnlabs.nl/nl/) door SIDN Labs\n" "* [\"Percentage of Web Pages Loaded by Firefox Using HTTPS\"](https://letsencrypt.org/de/stats/#percent-pageloads)\n" "* [\"HTTPS Usage\" by Google](https://www.google.com/transparencyreport/https/metrics/?hl=en)\n" +"* [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" @@ -3794,16 +3901,16 @@ msgstr "Beveiligde websiteverbinding (HTTPS)" msgid "faqs ipv6 content" msgstr "" "## Waarom\n" -"* [\"Three reasons why ISPs should deploy IPv6 now\"](https://internetnz.nz/blog/three-reasons-why-isps-should-deploy-ipv6-now) door George Michaelson (APNIC)\n" -"* [\"Making a Strong Case for IPv6\"](https://www.baselinemag.com/networking/making-a-strong-case-for-ipv6.html) door John Curran (ARIN)\n" -"* [\"IPv6: It's time to get on board\"](https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-board/) door Paul Saab (Facebook)\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" "## Gebruiksstatistieken\n" +"* [Pulse - IPv6 metric](https://pulse.internetsociety.org/en/technologies/#metric-ipv6) door Internet Society\n" "* [.nl-statistieken over IPv6](https://stats.sidnlabs.nl/nl/) door SIDN Labs\n" "* [APNIC IPv6-metingen](https://stats.labs.apnic.net/ipv6/)\n" "* [World IPv6 Launch](https://www.worldipv6launch.org/measurements/)\n" -"* [Akamai IPv6-adoptie](https://www.akamai.com/us/en/about/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp)\n" "* [Google IPv6-statistieken](https://www.google.com/intl/en/ipv6/statistics.html)\n" "* [Cisco IPv6-statistieken](https://6lab.cisco.com/stats/)\n" "* [IPv6 RIPEness informatie](https://ipv6ripeness.ripe.net/)\n" @@ -3811,7 +3918,7 @@ msgstr "" "## Achtergrondinformatie\n" "* [FAQ over IPv6](https://www.sidn.nl/moderne-internetstandaarden/ipv6) door SIDN\n" "* [ISOC's Deploy360 over IPv6](https://www.internetsociety.org/deploy360/ipv6/)\n" -"* [IPv6 Info Centre van RIPE](https://www.ripe.net/publications/ipv6-info-centre/)\n" +"* [IPv6 Info Centre van RIPE NCC](https://www.ripe.net/publications/ipv6-info-centre/)\n" "* [Wikipedia over IPv6](https://en.wikipedia.org/wiki/IPv6)\n" "* [\"Policy Issues for Receiving Email in a World with IPv6 Hosts\"](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf) door M³AAWG\n" "\n" @@ -3851,12 +3958,30 @@ msgstr "" msgid "faqs mailauth title" msgstr "Protectie tegen e-mailphishing (DMARC, DKIM en SPF)" +msgid "faqs measurements content" +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" +"- [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" +"- [Internet Society Portugal: Observatório de Tecnologias da Internet Portuguesa](https://observatory.isoc.pt/)\n" +"- [Register Internetdomeinen Overheid](https://organisaties.overheid.nl/domeinen)" + +msgid "faqs measurements title" +msgstr "Metingen met Internet.nl" + #, md-format msgid "faqs report score content" msgstr "" "### Welke norm hanteert Internet.nl?\n" "Internet.nl controleert de correcte toepassing van moderne Internetstandaarden die de betrouwbaarheid van online diensten vergroten. Een score van 100% betekent dat een website, e-mailvoorziening of internetverbinding volledig voldoet aan de norm waartegen we testen. Deze norm is gebaseerd op de internetstandaarden op de 'pas toe of leg uit'-lijst van Forum Standaardisatie, op veiligheidsadviezen van NCSC, en op relevante RFC's van IETF.\n" "\n" +"### Betekent een 100%-score dat is voldaan aan alle verplichte internetstandaarden?\n" +"Houd er rekening mee dat een 100%-score niet noodzakelijkerwijs betekent dat wordt voldaan aan alle voor Nederlandse overheidsorganisaties verplichte internetstandaarden. Niet alle verplichte internetstandaarden worden namelijk (volledig) getest, ook omdat dat soms onmogelijk of heel moeilijk is. Bovendien kan het zo zijn dat bepaalde verplichte standaarden wel worden getest maar nog niet meewegen in de score.\n" +"\n" "### Wordt de norm ook aangepast?\n" "De norm van Internet.nl wordt met enige regelmaat aangepast omdat de stand der techniek verandert. Aanpassingen kondigen we van te voren aan via nieuwsberichten op deze website. Nieuwe subtesten zullen na introductie (meestal) niet direct meetellen in de eindscore, en hebben de status van 'AANBEVOLEN' of 'OPTIONEEL'. In de toekomst kunnen deze onderdelen de status krijgen van 'VEREIST' en wel meetellen voor de eindscore.\n" "\n" @@ -3876,9 +4001,11 @@ msgstr "" "\n" "### Hoe is de procentuele score opgebouwd?\n" "- Iedere hoofdtest resulteert in een procentuele totaalscore. \n" -"- Iedere testcategorie van een hoofdtest weegt min of meer gelijk mee in de procentuele totaalscore. Dus als een hoofdtest bestaat uit vier testcategorieën, dan is de maximale score per testcategorie 25%.\n" +"- Iedere testcategorie van een hoofdtest weegt gelijk mee in de procentuele totaalscore. Dus als een hoofdtest bestaat uit vier testcategorieën, dan is de maximale score per testcategorie 20%.\n" "- Alleen de subtesten met de status 'VEREIST' wegen mee in de score per testcategorie en in de procentuele eindscore.\n" -"- Websites met een score van 100% worden opgenomen in de [Hall of Fame](/halloffame/)." +"- Websites met een score van 100% worden opgenomen in de [Hall of Fame](/halloffame/).\n" +"\n" +"Zie de [documentatie over scoren](https://github.com/internetstandards/Internet.nl/blob/main/documentation/scoring.md) van Internet.nl voor meer details." msgid "faqs report score title" msgstr "Norm en score" @@ -3957,9 +4084,9 @@ msgstr "" "* [RFC 7908: Problem Definition and Classification of BGP Route Leaks](https://www.rfc-editor.org/rfc/rfc7908)\n" "\n" "## Gebruiksstatistieken\n" +"* Pulse [RPKI ROV metric](https://pulse.internetsociety.org/en/technologies/#metric-route-validation) en [RPKI ROA metric](https://pulse.internetsociety.org/en/technologies/#metric-roa-coverage) door Internet Society\n" "* [Route Origin Authorisation (ROA) statistieken](https://roa-stats.manrs.org/) door MANRS\n" -"* [Route Origin Authorisation (ROA) statistieken](https://rpki-maps.nlnetlabs.nl) door NLnet Labs\n" -"* [.nl-statistieken voor Route Origin Authorisation (ROA)](https://stats.sidnlabs.nl/nl/security.html#domeinnamen%20beveiligd%20met%20rpki) door SIDN Labs\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" "\n" "## Achtergrondinformatie\n" @@ -3969,8 +4096,7 @@ msgstr "" "## Specificaties\n" "* [RFC 3779: X.509 Extensions for IP Addresses and AS Identifiers](https://www.rfc-editor.org/rfc/rfc3779)\n" "* [RFC 6482: A Profile for Route Origin Authorizations (ROAs)](https://www.rfc-editor.org/rfc/rfc6482)\n" -"* [RFC 6811: BGP Prefix Origin Validation](https://www.rfc-editor.org/rfc/rfc6811)\n" -"* [RPKI RFCs Graph](https://rpki-rfc.routingsecurity.net/)" +"* [RFC 6811: BGP Prefix Origin Validation](https://www.rfc-editor.org/rfc/rfc6811)" msgid "faqs rpki title" msgstr "Autorisatie voor routering (RPKI)" @@ -3981,7 +4107,7 @@ msgstr "" "## Waarom\n" "* [\"Opportunistic Security: Some Protection Most of the Time\"](https://www.rfc-editor.org/rfc/rfc7435) door V. Dukhovni\n" "* [\"New e-mail security protocols mandatory within government\"](https://www.sidnlabs.nl/a/weblog/new-e-mail-security-protocols-mandatory-within-government?language_id=2) door Marco Davids (SIDN)\n" -"* [\"The sad state of SMTP encryption\"](https://blog.filippo.io/the-sad-state-of-smtp-encryption/) door Filippo Valsorda\n" +"* [\"The sad state of SMTP encryption\"](https://words.filippo.io/the-sad-state-of-smtp-encryption/) door Filippo Valsorda\n" "\n" "## Gebruiksstatistieken\n" "* [DANE trend graphs](https://stats.dnssec-tools.org/#/graphs?top=dane)\n" @@ -4151,7 +4277,7 @@ msgid "privacy content" msgstr "" "# Privacyverklaring\n" "\n" -"*Herzien op 24 oktober 2023*\n" +"*Herzien op 28 januari 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" @@ -4207,14 +4333,16 @@ msgstr "" "- Het gebruikte e-mailadres en andere ‘mail header data’ (zoals tijdstip);\n" "- Andere persoonsgegevens die door de verzender zijn opgenomen in het mailbericht.\n" "\n" +"We gebruiken een lokaal gehoste instantie van [Zammad](https://zammad.org/) als helpdesksysteem.\n" +"\n" "## Welke diensten van derde partijen worden gebruikt?\n" "\n" "### WHOIS\n" "In de website- en e-mailtest wordt via WHOIS de registrar van het geteste domein opgevraagd. Daarvoor wordt met het WHOIS-protocol (plain text op TCP port 43) een bevraging gedaan van de [IANA WHOIS Service](https://www.iana.org/whois) en van de WHOIS Service van de desbetreffende TLD registry (bijv. de [WHOIS Service van SIDN](https://www.sidn.nl/whois)).\n" "\n" "### Team Cymru\n" -"* In het RPKI-testonderdeel van de website- en e-mailtest wordt voor ieder gevonden IP-adres het bijbehorende BGP Origin ASN opgevraagd met behulp van de [\"IP to ASN Mapping Service\"](https://team-cymru.com/community-services/ip-asn-mapping/) van Team Cymru.\n" -"* In de verbindingstest wordt voor de IP-adressen van je client en van je DNS-provider de ASN Description (t.b.v. de naam van de internetprovider en de DNS-provider) opgevraagd met behulp van de [\"IP to ASN Mapping Service\"](https://team-cymru.com/community-services/ip-asn-mapping/) van Team Cymru.\n" +"* In het RPKI-testonderdeel van de website- en e-mailtest wordt voor ieder gevonden IP-adres het bijbehorende BGP Origin ASN opgevraagd met behulp van de [\"IP to ASN Mapping Service\"](https://www.team-cymru.com/ip-asn-mapping) van Team Cymru.\n" +"* In de verbindingstest wordt voor de IP-adressen van je client en van je DNS-provider de ASN Description (t.b.v. de naam van de internetprovider en de DNS-provider) opgevraagd met behulp van de [\"IP to ASN Mapping Service\"](https://www.team-cymru.com/ip-asn-mapping) van Team Cymru.\n" "\n" "IP-adressen worden voorafgaand aan de bevraging zoveel mogelijk geanonimiseerd (voor IPv4 op een /24, voor IPv6 op een /48). De bevraging vindt plaats via DNS op UDP port 53. \n" "\n" @@ -4230,7 +4358,7 @@ msgstr "" "## Welke maatregelen zijn genomen om de verzamelde data te beveiligen?\n" "\n" "### Toegang en derde partijen\n" -"Onze diensten draaien op servers die worden gehost door Prolocation ([single test website](https://internet.nl) en [batch test API](https://batch.internet.nl)) en door TransIP ([dashboard](https://dashboard.internet.nl)). ECP voert het inhoudelijk beheer over de mailbox. Verzamelde data en ontvangen informatie kan gedeeld worden met andere [leden van het Platform Internetstandaarden](/about/) maar alleen om vragen te beantwoorden, problemen op te lossen of om de diensten te verbeteren.\n" +"Onze diensten draaien op servers die worden gehost door Prolocation ([single test website](https://internet.nl), [batch test API](https://batch.internet.nl), onze e-mail en ons helpdesksysteem) en door TransIP ([dashboard](https://dashboard.internet.nl)). ECP voert het inhoudelijk beheer over de mailbox. Verzamelde data en ontvangen informatie kan gedeeld worden met andere [leden van het Platform Internetstandaarden](/about/) maar alleen om vragen te beantwoorden, problemen op te lossen of om de diensten te verbeteren.\n" "\n" "Behalve de diensten genoemd onder \"Welke diensten van derde partijen worden gebruikt?\", worden er geen diensten van andere partijen (zoals externe gebruikersanalyse-tooling of web fonts) gebruikt. We geven op geen enkele manier persoonsgegevens die door ons zijn verzameld door aan derde partijen (d.w.z. buiten het Platform Internetstandaarden), tenzij we juridisch daartoe verplicht zijn (bijvoorbeeld als autoriteiten met een juridische grondslag ons verzoeken om data).\n" "\n" @@ -4253,13 +4381,13 @@ msgstr "" "- Applicatie: Omdat we de geanonimiseerde IP-adressen en aanverwante gegevens niet direct kunnen worden gerelateerd aan een persoon, houden we geen specifieke bewaartermijn aan voor gegevens in onze applicatiedatabase. \n" "- Serverlogs: Gegevens die zijn verzameld in onze serverlogs worden verwijderd na drie kalendermaanden.\n" "- Gebruikersanalyse: Individuele gebruikersgegevens (inclusief het geanonimiseerde IP-adres) in onze gebruikersanalyse-tooling worden na 90 dagen verwijderd.\n" -"- Email: Het verwerken van emails is een kern activiteit van Platform Internetstandaarden. Op basis van de [eisen](https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/ondernemen/administratie/administratie_opzetten/wat_hoort_er_allemaal_bij_uw_administratie) gesteld door De Belastingdienst, wordt email correspondentie na zeven jaar verwijderd.\n" +"- Email: In overeenstemming met de [eisen](https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/ondernemen/administratie/#hoelang-gegevens-bewaren) gesteld door de Belastingdienst, wordt email-correspondentie tenminste zeven jaar bewaard.\n" "\n" "## Inspectie, correctie en verwijdering van gegevens\n" "Op basis van de Europese Algemene verordening gegevensbescherming heb je het recht om op verzoek toegang te krijgen tot je persoonsgegevens, en indien noodzakelijk, om deze aan te passen of te verwijderen. Neem [contact](/about/) met ons op als je dat graag wenst. Omdat we je volledige IP-adres slechts tijdelijk bewaren in onze serverlogs, kan het nodig zijn dat je ons additionele informatie dient te verschaffen, zoals over je apparaat en browser en het bezoektijdstip, zodat we aan je verzoek kunnen voldoen.\n" "\n" "## Herziening privacyverklaring\n" -"We kunnen de privacyverklaring herzien. Veranderingen zullen we aankondigen op onze website. Oude versies van onze privacyverklaring worden gearchiveerd. Stuur ons een e-mail als je deze wil inzien." +"We kunnen de privacyverklaring herzien. Nieuwe versies zullen we publiceren op onze website. Oude versies van onze privacyverklaring worden gearchiveerd. Stuur ons een e-mail als je deze wil inzien." msgid "probes auto-redirect" msgstr "" @@ -4354,7 +4482,7 @@ msgstr "" " - [IP6.nl](https://ip6.nl/)\n" " - [IP address visibility](https://stat.ripe.net/widget/visibility)\n" "- ### DNSSEC:\n" -" - [DNSViz](http://dnsviz.net/)\n" +" - [DNSViz](https://dnsviz.net/)\n" " - [Zonemaster](https://zonemaster.net)\n" "- ### DMARC, DKIM en SPF :\n" " - [MECSA - EU Commissie](https://mecsa.jrc.ec.europa.eu/) (ook STARTTLS+DANE)\n" @@ -4385,7 +4513,7 @@ msgstr "" " - [SSL Labs](https://www.ssllabs.com/ssltest/)\n" "- ### Security options:\n" " - [CSP Evaluator](https://csp-evaluator.withgoogle.com/)\n" -" - [Analyze your CSP](https://report-uri.com/home/analyse/)\n" +" - [Analyse your CSP](https://report-uri.com/home/analyse/)\n" "- ### RPKI:\n" " - [Routinator](https://routinator.nlnetlabs.nl/) \n" " - [IRR explorer](https://irrexplorer.nlnog.net/)\n" @@ -4735,6 +4863,14 @@ msgid "test mailipv6 warning summary" msgstr "" "*Niet* bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)" +msgid "test mailrpki error description" +msgstr "" +"De test kan nog niet worden uitgevoerd. Probeer het later nog eens. Sorry " +"voor het ongemak." + +msgid "test mailrpki error summary" +msgstr "Test niet klaar om uit te voeren (RPKI)" + msgid "test mailrpki failed description" msgstr "" "Helaas! Ten minste één van de IP-adressen van je ontvangende mailserver(s) " @@ -4742,12 +4878,12 @@ msgstr "" "gematcht door de gepubliceerde route-autorisatie ([RPKI](/faqs/rpki/)). Dit " "duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt " "veroorzaakt door je mailhoster of je nameserver-hoster (interne fout) óf " -"door een derde partij (externe fout). In beide gevallen kan het leiden tot " -"de onbereikbaarheid van je server of het onderscheppen van internetverkeer " -"naar je server. Neem zo spoedig mogelijk contact op met je mailhoster of " -"nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die " -"eigenaar is van de IP-adressen van je server, vragen om de route-" -"configuratiefout te herstellen." +"door een derde partij (externe fout). In beide gevallen verhoogt dit het " +"risico dat je server onbereikbaar wordt of dat internetverkeer naar je " +"server wordt onderschept. Neem zo spoedig mogelijk contact op met je " +"mailhoster of nameserver-hoster. Bij een interne fout moeten zij hun " +"netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om " +"de route-configuratiefout te herstellen." msgid "test mailrpki failed summary" msgstr "*Ongeautoriseerde* route-aankondiging (RPKI)" @@ -4783,17 +4919,16 @@ msgstr "Route-autorisatie?" msgid "test mailrpki warning description" msgstr "" -"Waarschuwing! Ten minste één van de IP-adressen van je mailserver en " -"bijbehorende nameservers heeft een route-aankondiging waarvoor *geen* route-" -"autorisatie is gepubliceerd ([RPKI](/faqs/rpki/)). Daardoor is het " -"e-mailtransport tussen verzendende mailservers met ingeschakelde route-" -"validatie en jouw ontvangende mailserver(s) *niet* (volledig) beschermd " -"tegen diverse onbedoelde of kwaadwillige route-configuratiefouten, die " -"kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping " -"van internetverkeer naar je servers. Neem hierover contact op met je " -"mailhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar" -" is van de IP-adressen van je server vragen om route-autorisaties te " -"publiceren." +"Helaas! Ten minste één van de IP-adressen van je mailserver en bijbehorende " +"nameservers heeft een route-aankondiging waarvoor *geen* route-autorisatie " +"is gepubliceerd ([RPKI](/faqs/rpki/)). Daardoor is het e-mailtransport " +"tussen verzendende mailservers met ingeschakelde route-validatie en jouw " +"ontvangende mailserver(s) *niet* (volledig) beschermd tegen diverse " +"onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot " +"de onbereikbaarheid van je servers of de onderschepping van internetverkeer " +"naar je servers. Neem hierover contact op met je mailhoster of nameserver-" +"hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen " +"van je server vragen om route-autorisaties te publiceren." msgid "test mailrpki warning summary" msgstr "Route-autorisatie *niet* gepubliceerd (RPKI)" @@ -4839,12 +4974,17 @@ msgstr "Beveiligde mailserver-verbinding (STARTTLS en DANE)" msgid "test mailtls no-mx description" msgstr "" -"Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je " -"domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail " -"wilt ontvangen. Merk op dat je in dit geval *geen* 'Null MX' record nodig " -"hebt. Door je configuratie zijn de subtesten in de categorieën voor STARTTLS" -" en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke " -"subtesten in de categorieën voor IPv6 en DNSSEC." +"Ter informatie: Het SPF-record op je domeinnaam geeft aan dat je domeinnaam " +"kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft " +"echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je " +"verzonden e-mail kan belemmeren omdat het ontbreken van een MX door " +"ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt" +" mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je " +"echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een " +"SPF-record met alleen de term `-all` en daarnaast een \"Null MX\" record als" +" je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de " +"subtests in de categorie STARTTLS en DANE en de mailserver-specifieke " +"subtests in de categorieën IPv6 en DNSSEC niet van toepassing." msgid "test mailtls no-mx summary" msgstr "Goed geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)" @@ -4852,11 +4992,12 @@ msgstr "Goed geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)" msgid "test mailtls no-null-mx description" msgstr "" "Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je " -"domeinnaam die A/AAAA records heeft. We raden je aan om expliciet aan te " -"geven dat je domeinnaam geen e-mail accepteert door een \"Null MX\" record " -"te configureren. Door je huidige configuratie zijn de subtesten in de " -"categorieën voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de" -" mailserver-specifieke subtesten in de categorieën voor IPv6 en DNSSEC." +"domein dat A/AAAA-records heeft en dat een SPF-record heeft met alleen de " +"term `-all`. We raden je aan een \"Null MX\" record in te stellen om " +"expliciet aan te geven dat je domein geen e-mail accepteert. Vanwege je " +"configuratie zijn de subtests in de categorie STARTTLS en DANE en de " +"mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van " +"toepassing." msgid "test mailtls no-null-mx summary" msgstr "" @@ -4948,13 +5089,14 @@ msgstr "" "headers en security.txt, zijn ingesteld voor je website " "([Beveiligingsopties](/faqs/appsecpriv/)). Met security headers kan je " "browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met " -"bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-" -"bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben " -"gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability " -"Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste " -"beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-" -"Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 " -"HTTP Status Code)." +"bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn " +"ook relevant voor domeinen met HTTP response codes zoals '301 Redirect' en " +"'404 Not Found', omdat ze hun eigen browsercontext creëren (MIME type " +"'text/html') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een " +"security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je " +"systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated " +"Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor " +"alle geteste beveiligingsopties." msgid "test siteappsecpriv failed summary" msgstr "" @@ -4967,13 +5109,14 @@ msgstr "" "security headers en security.txt, zijn ingesteld voor je website " "([Beveiligingsopties](/faqs/appsecpriv/)). Met security headers kan je " "browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met " -"bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-" -"bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben " -"gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability " -"Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste " -"beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-" -"Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 " -"HTTP Status Code)." +"bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn " +"ook relevant voor domeinen met HTTP response codes zoals '301 Redirect' en " +"'404 Not Found', omdat ze hun eigen browsercontext creëren (MIME type " +"'text/html') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een " +"security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je " +"systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated " +"Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor " +"alle geteste beveiligingsopties." msgid "test siteappsecpriv info summary" msgstr "" @@ -4989,13 +5132,14 @@ msgstr "" "security.txt, zijn ingesteld voor je website " "([Beveiligingsopties](/faqs/appsecpriv/)). Met security headers kan je " "browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met " -"bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-" -"bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben " -"gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability " -"Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste " -"beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-" -"Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 " -"HTTP Status Code)." +"bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn " +"ook relevant voor domeinen met HTTP response codes zoals '301 Redirect' en " +"'404 Not Found', omdat ze hun eigen browsercontext creëren (MIME type " +"'text/html') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een " +"security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je " +"systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated " +"Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor " +"alle geteste beveiligingsopties." msgid "test siteappsecpriv passed summary" msgstr "Alle beveiligingsopties ingesteld (Beveiligingsopties)" @@ -5009,13 +5153,14 @@ msgstr "" "security headers en security.txt, zijn ingesteld voor je website " "([Beveiligingsopties](/faqs/appsecpriv/)). Met security headers kan je " "browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met " -"bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-" -"bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben " -"gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability " -"Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste " -"beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-" -"Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 " -"HTTP Status Code)." +"bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn " +"ook relevant voor domeinen met HTTP response codes zoals '301 Redirect' en " +"'404 Not Found', omdat ze hun eigen browsercontext creëren (MIME type " +"'text/html') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een " +"security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je " +"systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated " +"Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor " +"alle geteste beveiligingsopties." msgid "test siteappsecpriv warning summary" msgstr "" @@ -5119,6 +5264,14 @@ msgid "test siteipv6 warning summary" msgstr "" "*Niet* bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)" +msgid "test siterpki error description" +msgstr "" +"De test kan nog niet worden uitgevoerd. Probeer het later nog eens. Sorry " +"voor het ongemak." + +msgid "test siterpki error summary" +msgstr "Test niet klaar om uit te voeren (RPKI)" + msgid "test siterpki failed description" msgstr "" "Helaas! Ten minste één van de IP-adressen van je ontvangende webserver en " @@ -5126,12 +5279,12 @@ msgstr "" "gematcht door de gepubliceerde route-autorisatie ([RPKI](/faqs/rpki/)). Dit " "duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt " "veroorzaakt door je webhoster of je nameserver-hoster (interne fout) óf " -"door een derde partij (externe fout). In beide gevallen kan het leiden tot " -"de onbereikbaarheid van je server of het onderscheppen van internetverkeer " -"naar je server. Neem zo spoedig mogelijk contact op met je webhoster of " -"nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die " -"eigenaar is van de IP-adressen van je server, vragen om de route-" -"configuratiefout te herstellen." +"door een derde partij (externe fout). In beide gevallen verhoogt dit het " +"risico dat je server onbereikbaar wordt of dat internetverkeer naar je " +"server wordt onderschept. Neem zo spoedig mogelijk contact op met je " +"webhoster of nameserver-hoster. Bij een interne fout moeten zij hun " +"netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om " +"de route-configuratiefout te herstellen." msgid "test siterpki failed summary" msgstr "*Ongeautoriseerde* route-aankondiging (RPKI)" @@ -5166,11 +5319,11 @@ msgstr "Route-autorisatie?" msgid "test siterpki warning description" msgstr "" -"Waarschuwing! Ten minste één van de IP-adressen van je webserver en " -"bijbehorende nameservers heeft een route-aankondiging waarvoor *geen* route-" -"autorisatie is gepubliceerd ([RPKI](/faqs/rpki/)). Als gevolg daarvan zijn " -"bezoekers met ingeschakelde routevalidatie *niet* (volledig) beschermd tegen" -" verschillende onbedoelde of kwaadwillige route-configuratiefouten, die " +"Helaas! Ten minste één van de IP-adressen van je webserver en bijbehorende " +"nameservers heeft een route-aankondiging waarvoor *geen* route-autorisatie " +"is gepubliceerd ([RPKI](/faqs/rpki/)). Als gevolg daarvan zijn bezoekers met" +" ingeschakelde routevalidatie *niet* (volledig) beschermd tegen " +"verschillende onbedoelde of kwaadwillige route-configuratiefouten, die " "kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping " "van internetverkeer naar je servers. Neem hierover contact op met je " "webhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar " diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.js b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.js index fc5c9e26..f21fd28d 100644 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.js +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.js @@ -46,16 +46,16 @@ const internet_nl_messages = { detail_conn_dnssec_validation_tech_table: 'DNS provider', detail_conn_dnssec_validation_verdict_bad: 'You are not protected by DNSSEC signature validation.', detail_conn_dnssec_validation_verdict_good: 'You are protected by DNSSEC signature validation.', - detail_conn_ipv6_connection_exp: 'We check if your device through its current internet connection is able to connect directly (i.e. without DNS translation) with our webserver using our corresponding IPv6 address.

Some browser add-ons and routers offer functionality for domain filtering in order to enhance privacy or restrict internet use. To prevent circumvention this kind of functionality often blocks connecting to IP addresses directly, making your internet connection fail for this subtest.', + detail_conn_ipv6_connection_exp: 'We check if your device through its current internet connection is able to connect directly (i.e. without DNS translation) with our web server using our corresponding IPv6 address.

Some browser add-ons and routers offer functionality for domain filtering in order to enhance privacy or restrict internet use. To prevent circumvention this kind of functionality often blocks connecting to IP addresses directly, making your internet connection fail for this subtest.', detail_conn_ipv6_connection_label: 'IPv6 connectivity (direct)', detail_conn_ipv6_connection_tech_table: 'Anonymized IPv6 address|Reverse name|Internet provider', detail_conn_ipv6_connection_verdict_bad: 'You are not able to reach computers directly on their IPv6 address.', detail_conn_ipv6_connection_verdict_good: 'You are able to reach computers directly on their IPv6 address.', - detail_conn_ipv6_dns_conn_exp: 'We check if your device through its current internet connection is able to connect to our webserver via IPv6. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv6 address.', + detail_conn_ipv6_dns_conn_exp: 'We check if your device through its current internet connection is able to connect to our web server via IPv6. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv6 address.', detail_conn_ipv6_dns_conn_label: 'IPv6 connectivity (via DNS)', detail_conn_ipv6_dns_conn_verdict_bad: 'You are not able to reach computers via DNS on their IPv6 address.', detail_conn_ipv6_dns_conn_verdict_good: 'You are able to reach computers via DNS on their IPv6 address.', - detail_conn_ipv6_ipv4_conn_exp: 'We check if your device through its current internet connection is able to connect to our webserver via IPv4. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv4 address.

Requirement level: Optional', + detail_conn_ipv6_ipv4_conn_exp: 'We check if your device through its current internet connection is able to connect to our web server via IPv4. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv4 address.

Requirement level: Optional', detail_conn_ipv6_ipv4_conn_label: 'IPv4 connection (via DNS)', detail_conn_ipv6_ipv4_conn_tech_table: 'Anonymized IPv4 address|Reverse name|Internet provider', detail_conn_ipv6_ipv4_conn_verdict_bad: 'You are not able to reach computers via DNS on their IPv4 address.', @@ -68,7 +68,7 @@ const internet_nl_messages = { detail_conn_ipv6_resolver_conn_label: 'IPv6 connectivity of DNS resolver', detail_conn_ipv6_resolver_conn_verdict_bad: 'Your DNS resolver is not able to reach name servers over IPv6.', detail_conn_ipv6_resolver_conn_verdict_good: 'Your DNS resolver is able to reach name servers over IPv6.', - detail_mail_auth_dkim_exp: 'We check if your domain supports DKIM records. A receiving mail server canuse the public key in your DKIM record to validate the signature in an email with a user from your domain as sender and determine its authenticity.

  • Currently we are not able to query and evaluate the public key in your DKIM record,because we would need the DKIM selector (that should be in the mails you send) to do so.
  • To pass this test we expect your name server to answer NOERROR to our query for_domainkey.example.nl. When _domainkey.example.nl is an \'empty non-terminal\' some name servers that are not conformant with the standardRFC 2308 incorrectly answer NXDOMAIN instead of NOERROR. This makes itimpossible for us to detect support for DKIM records.
  • For this test we assume \'strict alignment\' which is conformant with DMARC. The given domain is considered to be the sender domain in the mail body domain (From:) and this must be identical to the DKIM domain (d=) and the SPF domain (envelope sender, i.e. return-path that shows up in MAIL FROM).

For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.', + detail_mail_auth_dkim_exp: '

We check if your domain supports DKIM records. A receiving mail server canuse the public key in your DKIM record to validate the signature in an email with a user from your domain as sender and determine its authenticity.

  • Currently we are not able to query and evaluate the public key in your DKIM record,because we would need the DKIM selector (that should be in the mails you send) to do so.
  • To pass this test we expect your name server to answer NOERROR to our query for_domainkey.example.nl. When _domainkey.example.nl is an \'empty non-terminal\' some name servers that are not conformant with the standardRFC 2308 incorrectly answer NXDOMAIN instead of NOERROR. This makes itimpossible for us to detect support for DKIM records.
  • For this test we assume \'strict alignment\' which is conformant with DMARC. The given domain is considered to be the sender domain in the mail body domain (From:) and this must be identical to the DKIM domain (d=) and the SPF domain (envelope sender, i.e. return-path that shows up in MAIL FROM).

Additional notes:

  • Some mail systems modify email in transit, potentially invalidating a DKIM signature. In many cases these modifications are harmless. Examples are whitespace replacement and header field line rewrapping. If you are a DKIM signing sender then you can choose whether or not to tolerate these types of changes, both for the header and the body of emails. The simple setting tolerates almost no modifications, and relaxed tolerates common modifications. If no setting is specified it defaults to simple for both header and body. In particular, header modifications are a common cause of a DKIM signature unintentionally becoming invalid, thus hindering deliverability. Using relaxed for the header while keeping simple for the body (c=relaxed/simple), can mitigate these kind of issues.
  • For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.
', detail_mail_auth_dkim_label: 'DKIM existence', detail_mail_auth_dkim_verdict_bad: 'Your domain does not support DKIM records.', detail_mail_auth_dkim_verdict_good: 'Your domain supports DKIM records.', @@ -78,7 +78,7 @@ const internet_nl_messages = { detail_mail_auth_dmarc_tech_table: 'DMARC record|Found on', detail_mail_auth_dmarc_verdict_bad: 'Your domain does not have a DMARC record.', detail_mail_auth_dmarc_verdict_good: 'Your domain has a DMARC record.', - detail_mail_auth_dmarc_policy_exp: '

We check if the syntax of your DMARC record is correct and if it contains a sufficiently strict policy (p=quarantine or p=reject) in order to prevent abuse of your domain by phishers and spammers. Even without a strict policy, DMARC can be useful to get more insight in legitimate and illegitimate outbound mail flows through DMARC reports. However to be effective against abuse of your domain, a liberal policy (p=none) is insufficient.

We also check whether the mail addresses under rua= and ruf= are valid. In case they contain an external mail address we check whether the external domain is authorised to receive DMARC reports. Make sure that the DMARC authorisation record on the external domain contains at least "v=DMARC1;".

The test permits the use of the experimental np tag (RFC 9091).

Good practice for domains without mail:

  • Non-sending: Use the most strict DMARC policy (p=reject) and SPF policy (-all) for your domain that you do not use for sending mail in order to prevent abuse (\'spoofing\'). Note that DKIM is not necessary in this case.
  • Non-receiving: For more information on "Null MX" and "No MX" see the explanation of the "STARTTLS available" subtest.

Below you will find two basic example DNS configurations for domain names that are not used to send and receive mail.

A. Single domain without A or AAAA record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Single no-mail domain with A or AAAA record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', + detail_mail_auth_dmarc_policy_exp: '

We check if the syntax of your DMARC record is correct and if it contains a sufficiently strict policy (p=quarantine or p=reject) in order to prevent abuse of your domain by phishers and spammers. Even without a strict policy, DMARC can be useful to get more insight in legitimate and illegitimate outbound mail flows through DMARC reports. However to be effective against abuse of your domain, a liberal policy (p=none) is insufficient.

We also check whether the mail addresses under rua= and ruf= are valid. In case they contain an external mail address we check whether the external domain is authorised to receive DMARC reports. Make sure that the DMARC authorisation record on the external domain contains at least "v=DMARC1;".

The test permits the use of the experimental np tag (RFC 9091).

Good practice for domains without mail:

  • Non-sending: Use the most strict DMARC policy (p=reject) and SPF policy (-all) for your domain that you do not use for sending mail in order to prevent abuse (\'spoofing\'). Note that DKIM is not necessary in this case.
  • Non-receiving: For more information on "Null MX" and "No MX" see the explanation of the "STARTTLS available" subtest.

Below you will find two basic example DNS configurations for domain names that are not used to send and receive mail.

A. Single domain without A or AAAA record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Single no-mail domain with A or AAAA record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', detail_mail_auth_dmarc_policy_label: 'DMARC policy', detail_mail_auth_dmarc_policy_verdict_bad: 'Your DMARC policy is not syntactically correct.', detail_mail_auth_dmarc_policy_verdict_external: 'The domain of the external mail address following rua= and/or ruf= has no (valid) authorisation record for receiving DMARC reports for the tested domain. ', @@ -98,20 +98,20 @@ const internet_nl_messages = { detail_mail_auth_spf_policy_verdict_include: 'Your SPF policy is not sufficiently strict. The \'include\' mechanism in your SPF record points to an insufficiently strict SPF policy or a non-existing SPF record.', detail_mail_auth_spf_policy_verdict_max_lookups: 'Your SPF policy is not effective as it requires more than the allowed 10 DNS lookups. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. The SPF terms all, ip4, ip6 and exp do not count as DNS lookups.', detail_mail_auth_spf_policy_verdict_redirect: 'Your SPF policy is not sufficiently strict. The \'redirect\' modifier in your SPF record points to an insufficiently strict SPF policy or a non-existing SPF record.', - detail_mail_dnssec_exists_exp: 'We check if your domain, more specifically its SOA record, is DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply that contains your mail server domains (MX). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to the attacker\'s mailserver domain.

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

Note: the validity of the signature is not part of this subtest, but part of the next subtest.', + detail_mail_dnssec_exists_exp: 'We check if your domain, more specifically its SOA record, is DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply that contains your mail server domains (MX). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to the attacker\'s mail server domain.

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

Note: the validity of the signature is not part of this subtest, but part of the next subtest.', detail_mail_dnssec_exists_label: 'DNSSEC existence', detail_mail_dnssec_exists_tech_table: 'Email address domain|Registrar', detail_mail_dnssec_exists_verdict_bad: 'Your email address domain is insecure, because it is not DNSSEC signed.', detail_mail_dnssec_exists_verdict_good: 'Your email address domain is DNSSEC signed.', detail_mail_dnssec_exists_verdict_resolver_error: 'Unfortunately an error occurred in Internet.nl\'s resolver. Please contact us.', detail_mail_dnssec_exists_verdict_servfail: 'The name servers of your email address domain are broken. They returned an error (SERVFAIL) to our queries for a DNSSEC signature. Please contact your name server operator (often your hosting provider and/or registrar) to fix this soon.', - detail_mail_dnssec_mx_exists_exp: 'We check if the domains of your mail servers (MX), more specifically their SOA records, are DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply containing the IP addresses and DANE records of your mailserver(s). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to an IP address controlled by the attacker or to eavesdrop on the secured mail server connection.

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

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.

The validity of the signature is not part of this subtest, but part of the next subtest.', + detail_mail_dnssec_mx_exists_exp: 'We check if the domains of your mail servers (MX), more specifically their SOA records, are DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply containing the IP addresses and DANE records of your mail server(s). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to an IP address controlled by the attacker or to eavesdrop on the secured mail server connection.

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

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.

The validity of the signature is not part of this subtest, but part of the next subtest.', detail_mail_dnssec_mx_exists_label: 'DNSSEC existence', detail_mail_dnssec_mx_exists_tech_table: 'Domain of mail server (MX)|DNSSEC existent', detail_mail_dnssec_mx_exists_verdict_bad: 'At least one of your mail server domains is insecure, because it is not DNSSEC signed.', detail_mail_dnssec_mx_exists_verdict_good: 'All your mail server domains are DNSSEC signed.', detail_mail_dnssec_mx_exists_verdict_invalid_null_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', - detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email.', + detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_dnssec_mx_exists_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_dnssec_mx_exists_verdict_null_mx: 'Your domain name that has A/AAAA records clearly indicates with a "Null MX" record that it does not accept e-mail. This is fine if you do not want to receive email. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_dnssec_mx_exists_verdict_null_mx_with_other_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', @@ -136,41 +136,41 @@ const internet_nl_messages = { detail_mail_ipv6_mx_aaaa_verdict_bad: 'At least one receiving mail server on your domain does not have an IPv6 address.', detail_mail_ipv6_mx_aaaa_verdict_good: 'All receiving mail servers on your domain have an IPv6 address.', detail_mail_ipv6_mx_aaaa_verdict_invalid_null_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', - detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', + detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records and has an SPF record with only the term -all. We recommend you to set a "Null MX" record to explicitly indicate that your domain does not accept email. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_ipv6_mx_aaaa_verdict_null_mx: 'Your domain name that has A/AAAA records clearly indicates with a "Null MX" record that it does not accept e-mail. This is fine if you do not want to receive email. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_with_other_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_without_a_aaaa: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, your domain does not have A/AAAA records, making the "Null MX" record unnecessary.', - detail_mail_ipv6_mx_aaaa_verdict_other: 'No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email.', + detail_mail_ipv6_mx_aaaa_verdict_other: 'The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_ipv6_mx_reach_exp: 'We check if we can connect to your mail servers (MX) over IPv6 on port 25. We test all IPv6 addresses that we receive from the name servers of your mail server domain(s). A partial score will be given if not all IPv6 addresses are reachable. If an IPv6 address is (syntactically) invalid, we consider it unreachable.', detail_mail_ipv6_mx_reach_label: 'IPv6 reachability of mail server(s)', detail_mail_ipv6_mx_reach_tech_table: 'Mail server (MX)|Unreachable IPv6 address', detail_mail_ipv6_mx_reach_verdict_bad: 'At least one of your receiving mail servers with an IPv6 address is not reachable over IPv6.', detail_mail_ipv6_mx_reach_verdict_good: 'All your receiving mail servers with an IPv6 address are reachable over IPv6.', - detail_mail_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_mail_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_mail_rpki_exists_label: 'Route Origin Authorisation existence', detail_mail_rpki_exists_tech_table: 'Mail server|IP address|RPKI Route Origin Authorization', detail_mail_rpki_exists_verdict_bad: 'For at least one of the IP addresses of your receiving mail server(s) no RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_exists_verdict_good: 'For all IP addresses of your receiving mail server(s) an RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_exists_verdict_no_addresses: 'Your domain does not contain any receiving mail servers. Therefore, this subtest could not be performed.', - detail_mail_rpki_mx_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_mail_rpki_mx_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_mail_rpki_mx_ns_exists_label: 'Route Origin Authorisation existence', detail_mail_rpki_mx_ns_exists_tech_table: 'Name server of MX|IP address|RPKI Route Origin Authorization', detail_mail_rpki_mx_ns_exists_verdict_bad: 'For at least one of the IP addresses of the name servers of your mail server(s) no RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_mx_ns_exists_verdict_good: 'For all IP addresses of the name servers of your mail server(s) an RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_mx_ns_exists_verdict_no_addresses: 'Your domain does not contain any mail servers. Therefore, this subtest could not be performed.', - detail_mail_rpki_mx_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

Requirement level: Recommended', + detail_mail_rpki_mx_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error. ', detail_mail_rpki_mx_ns_valid_label: 'Route announcement validity', detail_mail_rpki_mx_ns_valid_tech_table: 'Name server of MX|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_mail_rpki_mx_ns_valid_verdict_bad: 'At least one IP address of the name servers of your receiving mail servers has a NotFound validation state. There is no RPKI Route Origin Authorization (ROA) published for the route announcement of each of the affected IP addresses.', detail_mail_rpki_mx_ns_valid_verdict_good: 'All IP addresses of the name servers of your receiving mail servers have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_mx_ns_valid_verdict_invalid: 'At least one IP address of the name servers of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_mail_rpki_mx_ns_valid_verdict_invalid: 'At least one IP address of the name servers of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_mail_rpki_mx_ns_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', - detail_mail_rpki_valid_exp: 'We check if the validation status for all IP addresses of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

Requirement level: Recommended', + detail_mail_rpki_valid_exp: 'We check if the validation status for all IP addresses of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_mail_rpki_valid_label: 'Route announcement validity', detail_mail_rpki_valid_tech_table: 'Mail server|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_mail_rpki_valid_verdict_bad: 'At least one IP address of your receiving mail servers has a NotFound validation state. There is no RPKI Route Origin Authorization (ROA) published for the route announcement of each of the affected IP addresses.', detail_mail_rpki_valid_verdict_good: 'All IP addresses of your receiving mail servers have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_valid_verdict_invalid: 'At least one IP address of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_mail_rpki_valid_verdict_invalid: 'At least one IP address of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_mail_rpki_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', detail_mail_tls_cert_hostmatch_exp: 'We check if the domain name of each of your receiving mail servers (MX) matches the domain name on the presented certificates.

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

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

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

Requirement level: Optional / Required (only when DANE-TA is used)', detail_mail_tls_cert_hostmatch_label: 'Domain name on certificate', @@ -196,7 +196,7 @@ const internet_nl_messages = { detail_mail_tls_cipher_order_exp: 'We check if your receiving mail servers (MX) enforce their own cipher preference (\'I\'), and offer ciphers in accordance with the prescribed ordering (\'II\').

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

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

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.

In the above table with technical details only the first found out of prescribed order algorithm selections are listed.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B2-5.', detail_mail_tls_cipher_order_label: 'Cipher order', detail_mail_tls_cipher_order_tech_table: 'Mail server (MX)|First found affected cipher pair|Violated rule # (\'II-B\')', - detail_mail_tls_cipher_order_verdict_bad: 'At least one of your mailservers does not enforce its own cipher preference (\'I\').', + detail_mail_tls_cipher_order_verdict_bad: 'At least one of your mail servers does not enforce its own cipher preference (\'I\').', detail_mail_tls_cipher_order_verdict_good: 'All your mail servers enforce their own cipher preference (\'I\'), and offer ciphers in accordance with the prescribed ordering (\'II\').', detail_mail_tls_cipher_order_verdict_na: 'This subtest is not applicable as your mail server supports \'Good\' ciphers only.', detail_mail_tls_cipher_order_verdict_seclevel_bad: 'At least one of your mail servers does not prefer \'Good\' over \'Sufficient\' over \'Phase out\' ciphers (\'II\').', @@ -218,7 +218,7 @@ const internet_nl_messages = { detail_mail_tls_dane_exists_verdict_bad: 'At least one of your mail server domains does not provide a TLSA record for DANE.', detail_mail_tls_dane_exists_verdict_bogus: 'At least one of your mail server domains does not provide DNSSEC proof that DANE TLSA records do not exist. This could lead to non-deliverability of mail sent to you by DANE validating mail senders. You should ask your name server operator to fix this issue.', detail_mail_tls_dane_exists_verdict_good: 'All your mail server domains provide a TLSA record for DANE.', - detail_mail_tls_dane_rollover_exp: 'We check if there is an active scheme with at least two DANE TLSA records to reliably handle certificate rollovers on your receiving mail servers (MX).

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

We recommend you to apply one of the following two schemes with double DANE TLSA records:

  1. Current + Next ("3 1 1" + "3 1 1"): Publish two "DANE-EE(3) SPKI(1) SHA2-256(1)" records, one for the current and one for the next TLS certificate of your mail server.
  2. Current + Issuer CA ("3 1 1" + "2 1 1"): Publish a "DANE-EE(3) SPKI(1) SHA2-256(1)" record for the current TLS certificate of your mail server, and also a "DANE-TA(2) SPKI(1) SHA2-256(1)" record for the current root or intermediate certificate of the (not necessarily public) certificate authority.

The test also accepts other combinations of DANE TLSA records i.e. "3 x x" + "3 x x" or "3 x x" + "2 x x". However other types than the above will generally be more error prone and less interoperable.

Requirement level: Optional', + detail_mail_tls_dane_rollover_exp: 'We check if there is an active scheme with at least two DANE TLSA records to reliably handle certificate rollovers on your receiving mail servers (MX).

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

We recommend you to apply one of the following two schemes with double DANE TLSA records:

  1. Current + Next ("3 1 1" + "3 1 1"): Publish two "DANE-EE(3) SPKI(1) SHA2-256(1)" records, one for the current and one for the next TLS certificate of your mail server.
  2. Current + Issuer CA ("3 1 1" + "2 1 1"): Publish a "DANE-EE(3) SPKI(1) SHA2-256(1)" record for the current TLS certificate of your mail server, and also a "DANE-TA(2) SPKI(1) SHA2-256(1)" record for the current root or intermediate certificate of the (not necessarily public) certificate authority.

The test also accepts other combinations of DANE TLSA records i.e. "3 x x" + "3 x x" or "3 x x" + "2 x x". However other types than the above will generally be more error prone and less interoperable.

Note that if a mail server simultaneously offers two certificates (one based on RSA and one based on ECDSA), a separate DANE TLSA rollover scheme is recommended for each certificate. The subtest does not check for this scenario. If only one DANE TLSA record is configured for each certificate, this subtest gives a false-positive result.

Requirement level: Optional', detail_mail_tls_dane_rollover_label: 'DANE rollover scheme', detail_mail_tls_dane_rollover_tech_table: 'Mail server (MX)|DANE rollover scheme', detail_mail_tls_dane_rollover_verdict_bad: 'At least one of your mail server domains does not have an active DANE scheme for a reliable rollover of certificate keys.', @@ -226,9 +226,9 @@ const internet_nl_messages = { detail_mail_tls_dane_valid_exp: 'We check if the DANE fingerprints presented by your mail server domains are valid for your mail server certificates.

DANE allows you to publish information about your mail server certificates in a special DNS record, called TLSA record. Sending mail servers can check the authenticity of your certificates not only through the certificate authority but also through the TLSA records. A sending mail server can also use the TLSA record as a signal to only connect via STARTTLS (and not unencrypted). When the DANE fingerprint of a receiving mail server is checked by the sending mail server, an active attacker who is able to manipulate the mail traffic cannot strip STARTTLS encryption. ', detail_mail_tls_dane_valid_label: 'DANE validity', detail_mail_tls_dane_valid_tech_table: 'Mail server (MX)|DANE TLSA record valid', - detail_mail_tls_dane_valid_verdict_bad: 'At least one of your mailservers does not have any valid DANE fingerprints. Either someone manipulated the response of your mail server, or your mail server has a serious DANE configuration error. The latter makes your domain unreachable for any sending mail server that checks DANE fingerprints. You should contact your mail provider as soon as possible.', - detail_mail_tls_dane_valid_verdict_good: 'Each of your mailservers has at least one valid DANE fingerprint. This allows sending mail servers that support DANE verification to set up an authenticated encrypted transport connection with your receiving mail servers.', - detail_mail_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your receiving mail servers (MX) are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', + detail_mail_tls_dane_valid_verdict_bad: 'At least one of your mail servers does not have any valid DANE fingerprints. Either someone manipulated the response of your mail server, or your mail server has a serious DANE configuration error. The latter makes your domain unreachable for any sending mail server that checks DANE fingerprints. You should contact your mail provider as soon as possible.', + detail_mail_tls_dane_valid_verdict_good: 'Each of your mail servers has at least one valid DANE fingerprint. This allows sending mail servers that support DANE verification to set up an authenticated encrypted transport connection with your receiving mail servers.', + detail_mail_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your receiving mail servers (MX) are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', detail_mail_tls_fs_params_label: 'Key exchange parameters', detail_mail_tls_fs_params_tech_table: 'Mail server (MX)|Affected parameters|Security level', detail_mail_tls_fs_params_verdict_bad: 'At least one of your mail servers supports insufficiently secure parameters for Diffie-Hellman key exchange.', @@ -239,7 +239,7 @@ const internet_nl_messages = { detail_mail_tls_kex_hash_func_label: 'Hash function for key exchange', detail_mail_tls_kex_hash_func_tech_table: 'Mail server (MX)|SHA2 support for signatures', detail_mail_tls_kex_hash_func_verdict_good: 'All your mail servers support secure hash functions for key exchange.', - detail_mail_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by at least one of your mail servers. This could be because the cipher combination used has no signature for certificate verification (e.g it uses RSA key exchange or is anonymous i.e. anon).', + detail_mail_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by at least one of your mail servers. This could be because the cipher combination used has no signature for certificate verification (e.g. it uses RSA key exchange or is anonymous i.e. anon).', detail_mail_tls_kex_hash_func_verdict_phase_out: '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.', detail_mail_tls_ocsp_stapling_exp: 'OUTDATED TEXT; TEST NOT USED
We check if your receiving mail server supports the TLS Certificate Status extension aka OCSP stapling. With OCSP stapling your mail server can provide OCSP responses itself which removes the need for the TLS client to verify the validity of the mail server certificate directly with the certificate supplier, and thus avoids exposing potentially privacy sensitive data about the client to the certificate supplier. It also does not require connectivity between client and certificate supplier and is faster. See \'IT Security Guidelines for Transport Layer Security (TLS)\', guideline B9-1 (in English).

When connecting to your mail server we use the TLS Certificate Status extension to request OCSP data be included in the server response. If your mail server includes OCSP data in the response we then verify that the OCSP data is signed by a known certificate authority.', detail_mail_tls_ocsp_stapling_label: 'OUTDATED TEXT; TEST NOT USED
OCSP stapling', @@ -263,12 +263,12 @@ const internet_nl_messages = { detail_mail_tls_starttls_exists_verdict_bad: 'At least one of your mail servers does not offer STARTTLS.', detail_mail_tls_starttls_exists_verdict_good: 'All your mail servers offer STARTTLS.', detail_mail_tls_starttls_exists_verdict_invalid_null_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', - detail_mail_tls_starttls_exists_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', + detail_mail_tls_starttls_exists_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records and has an SPF record with only the term -all. We recommend you to set a "Null MX" record to explicitly indicate that your domain does not accept email. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_tls_starttls_exists_verdict_null_mx: 'Your domain name that has A/AAAA records clearly indicates with a "Null MX" record that it does not accept e-mail. This is fine if you do not want to receive email. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_tls_starttls_exists_verdict_null_mx_with_other_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', detail_mail_tls_starttls_exists_verdict_null_mx_without_a_aaaa: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, your domain does not have A/AAAA records, making the "Null MX" record unnecessary.', detail_mail_tls_starttls_exists_verdict_other: 'At least one of your mail servers is unreachable.', - detail_mail_tls_starttls_exists_verdict_other_2: 'No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email. ', + detail_mail_tls_starttls_exists_verdict_other_2: 'The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_tls_version_exp: '

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

A mail server may support more than one TLS version.

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.

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

Version

  • Good: TLS 1.3
  • Sufficient: TLS 1.2
  • Phase out: TLS 1.1 and 1.0
  • Insufficient: SSL 3.0, 2.0 and 1.0
', detail_mail_tls_version_label: 'TLS version', detail_mail_tls_version_tech_table: 'Mail server (MX)|TLS versions|Status', @@ -307,15 +307,18 @@ const internet_nl_messages = { detail_tech_data_http_referrer_policy_recommendation_strict_origin: 'Recommendation: \'strict-origin\' should not be used.', detail_tech_data_http_referrer_policy_recommendation_strict_origin_when_cross_origin: 'Recommendation: \'strict-origin-when-cross-origin\' should not be used.', detail_tech_data_http_referrer_policy_values: 'Found policy: {values}', + detail_tech_data_http_securitytxt_bom_in_file: 'Error: The Byte Order Mark ("BOM") signature must not appear at the beginning of the content that must be encoded using UTF-8 in Net-Unicode form.', detail_tech_data_http_securitytxt_data_after_sig: 'Error: Signed security.txt must not contain data after the signature (line {line_no}).', detail_tech_data_http_securitytxt_empty_key: 'Error: Field name must not be empty (line {line_no}).', detail_tech_data_http_securitytxt_empty_value: 'Error: Field value must not be empty (line {line_no}).', detail_tech_data_http_securitytxt_expired: 'Error: Date and time in \'Expires\' field must not be in the past (line {line_no}).', + detail_tech_data_http_securitytxt_invalid_cert: 'Error: security.txt must be served with a valid TLS certificate.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_invalid_charset: 'Error: Charset parameter in Content-Type header must be \'utf-8\' if present.', detail_tech_data_http_securitytxt_invalid_expiry: 'Error: Date and time in \'Expires\' field must be formatted according to ISO 8601 (line {line_no}).', - detail_tech_data_http_securitytxt_invalid_lang: 'Error: Value in \'Preferred-Languages\' field must match one or more language tags as defined in RFC 5646, separated by commas (line {line_no}).', + detail_tech_data_http_securitytxt_invalid_lang: 'Error: Value in \'Preferred-Languages\' field must match one or more language tags as defined in RFC 5646, separated by commas (line {line_no}).', detail_tech_data_http_securitytxt_invalid_line: 'Error: Line must contain a field name and value, unless the line is blank or contains a comment (line {line_no}).', detail_tech_data_http_securitytxt_invalid_media: 'Error: Media type in Content-Type header must be \'text/plain\'.', + detail_tech_data_http_securitytxt_invalid_uri_scheme: 'Error: The security.txt file access must use the HTTPS scheme.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_location: 'Error: security.txt was located on the top-level path (legacy place), but must be placed under the \'/.well-known/\' path.', detail_tech_data_http_securitytxt_long_expiry: 'Recommendation: Date and time in \'Expires\' field should be less than a year into the future (line {line_no}).', detail_tech_data_http_securitytxt_multi_expire: 'Error: \'Expires\' field must not appear more than once.', @@ -342,7 +345,7 @@ const internet_nl_messages = { detail_tech_data_http_securitytxt_retrieved_from: 'security.txt retrieved from {hostname}.', detail_tech_data_http_securitytxt_signed_format_issue: 'Error: Signed security.txt must start with the header \'-----BEGIN PGP SIGNED MESSAGE-----\'.', detail_tech_data_http_securitytxt_unknown_field: 'Notification: security.txt contains an unknown field. Either this is a custom field which may not be widely supported, or there is a typo in a standardised field name (line {line_no}).', - detail_tech_data_http_securitytxt_utf8: 'Error: Content must be utf-8 encoded.', + detail_tech_data_http_securitytxt_utf8: 'Error: Content must encoded using UTF-8 in Net-Unicode form.', detail_tech_data_insecure: 'insecure', detail_tech_data_insufficient: 'insufficient', detail_tech_data_no: 'no', @@ -356,29 +359,29 @@ const internet_nl_messages = { detail_tech_data_yes: 'yes', detail_verdict_could_not_test: 'Test error. Please try again later.', detail_verdict_not_tested: 'This subtest did not run, because either a parent test that this subtest depends on gave a negative result, or not enough information was available to run this subtest.', - detail_web_appsecpriv_http_csp_exp: 'We check if your web server provides an HTTP header for Content-Security-Policy (CSP). Furthermore we check for several secure CSP settings, although we do not exhaustively test the effectiveness of your CSP configuration.

CSP guards a website against content injection attacks including cross-site scripting (XSS). By using CSP to configure an \'allowlist\' with sources of approved content, you prevent browsers from loading malicious content of attackers.

We test for the rules below that are based on good practices for a secure CSP configuration.

  1. The default-src directive should be defined and its value should be be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This is to have a restrictive default fallback policy for source types that are used in your website for which no specific policy is defined. Next to the mentioned values \'report-sample\' could be there in case you want code samples to be sent together with the \'violation reports\'.
  2. The base-uri directive should be defined and its value should be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This restricts the baseURI in order to block the injection of a manipulated <base> element. This limits the ability of attackers to manipulate the locations of sources (e.g. scripts) that are loaded from relative URLs.
  3. The frame-src directive should be used (either by definition or by relying on the fallback to sequentially child-src and default-src) and its value should be either \'none\', or \'self\'and/or one or more specific URLs. This prevents content from unauthorized locations to be framed or embedded in your website (with HTML elements such as <frame> and <iframe>).
  4. The frame-ancestors directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This prevents unauthorized websites from framing or embedding your website (with HTML elements <frame>, <iframe>, <object>, <embed>, or <applet>).
  5. The form-action directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This restricts the URLs which can be used as the target of form submissions.
  6. The source values unsafe-eval, unsafe-inline and unsafe-hashes should not be used, because these enable XSS attacks.
  7. The data: scheme should not be used in the default-src, script-src and object-src directives, because this enables XSS attacks.
  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.
  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).
  10. 127.0.0.1 should not be used in any directive, because it enables content injection attacks in a compromised system.

Additional recommendations:

  1. Only use domains in CSP directives as specific as possible, which is tested automatically to some extent in this subtest for CSP.

    • Do not allow all domains under a TLD (*.nl) or SLD (*.gov.uk), although we currently do not test for this.
    • 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.

  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.

  3. Use the HTTP header as a mechanism for serving your CSP policy. Do not use the HTML <meta> element to serve your CSP policy. The latter is less secure and does not support all CSP directives (e.g. the required frame-ancestors). Therfore we do not check for CSP that is offered via the HTML <meta> element.
  4. Use the HTTP header for Content-Security-Policy-Report-Only to experiment with your CSP configuration by monitoring its effect without enforcing it.
  5. Note that an empty source list (i.e. a CSP directive without a value) is equivalent to a source list containing none. Besides, note that if other sources are listed in a source list next to none, then the attribute none is ignored.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Requirement level: Recommended', + detail_web_appsecpriv_http_csp_exp: 'We check if your web server provides an HTTP header for Content-Security-Policy (CSP). Furthermore we check for several secure CSP settings, although we do not exhaustively test the effectiveness of your CSP configuration.

CSP guards a website against content injection attacks including cross-site scripting (XSS). By using CSP to configure an \'allowlist\' with sources of approved content, you prevent browsers from loading malicious content of attackers.

We test for the rules below that are based on good practices for a secure CSP configuration.

  1. The default-src directive should be defined and its value should be be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This is to have a restrictive default fallback policy for source types that are used in your website for which no specific policy is defined. Next to the mentioned values \'report-sample\' could be there in case you want code samples to be sent together with the \'violation reports\'.
  2. The base-uri directive should be defined and its value should be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This restricts the baseURI in order to block the injection of a manipulated <base> element. This limits the ability of attackers to manipulate the locations of sources (e.g. scripts) that are loaded from relative URLs.
  3. The frame-src directive should be used (either by definition or by relying on the fallback to sequentially child-src and default-src) and its value should be either \'none\', or \'self\'and/or one or more specific URLs. This prevents content from unauthorized locations to be framed or embedded in your website (with HTML elements such as <frame> and <iframe>).
  4. The frame-ancestors directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This prevents unauthorized websites from framing or embedding your website (with HTML elements <frame>, <iframe>, <object>, <embed>, or <applet>).
  5. The form-action directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This restricts the URLs which can be used as the target of form submissions.
  6. The source values unsafe-eval, unsafe-inline and unsafe-hashes should not be used, because these enable XSS attacks.
  7. The data: scheme should not be used in the default-src, script-src and object-src directives, because this enables XSS attacks.
  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.
  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).
  10. 127.0.0.1 should not be used in any directive, because it enables content injection attacks in a compromised system.

Additional recommendations:

  1. Only use domains in CSP directives as specific as possible, which is tested automatically to some extent in this subtest for CSP.

    • Do not allow all domains under a TLD (*.nl) or SLD (*.gov.uk), although we currently do not test for this.
    • 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.

  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.

  3. Use the HTTP header as a mechanism for serving your CSP policy. Do not use the HTML <meta> 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 <meta> element.
  4. Use the HTTP header for Content-Security-Policy-Report-Only to experiment with your CSP configuration by monitoring its effect without enforcing it.
  5. Note that an empty source list (i.e. a CSP directive without a value) is equivalent to a source list containing none. Besides, note that if other sources are listed in a source list next to none, then the attribute none is ignored.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Requirement level: Recommended', detail_web_appsecpriv_http_csp_label: 'Content-Security-Policy', detail_web_appsecpriv_http_csp_tech_table: 'Web server IP address|Findings', detail_web_appsecpriv_http_csp_verdict_bad: 'Your web server does not offer Content-Security-Policy (CSP), or does offer CSP with certain insecure settings. ', detail_web_appsecpriv_http_csp_verdict_good: 'Your web server offers Content-Security-Policy (CSP) and does not use certain insecure CSP settings.', - detail_web_appsecpriv_http_referrer_policy_exp: 'We check if your web server provides an HTTP header for Referrer-Policy with a sufficiently secure and privacy-protecting policy value. With this policy your webserver instructs browsers if, what and when referrer data should be sent to the website the user is navigating to from your website. This referrer data is sent in the Referer header by the browser to the website the user is navigating to. This navigation does not necessarily have to be cross-domain.

The data in the Referer header is usually used for analytics and logging. However there can be privacy and security risks. The data could be used e.g. for user tracking and the data could leak to third parties who eavesdrop the connection. The HTTP header for Referrer-Policy allows you to mitigate these risks by controlling and even minimizing the sending of referrer data.

We suggest to make an informed decision, with privacy and security risks in mind, on using one of the policy values from the first two categories below.

1. Good

  • no-referrer
  • same-origin

With these policy values no sensitive referrer data is sent to third parties.

2. Warning

  • strict-origin
  • strict-origin-when-cross-origin (browser\'s default value; see also under additional note 2)

With these policy values basic referrer data, which may be sensitive, is sent to third parties only via secure connections (HTTPS). Therefore these values should only to be used where necessary and permitted by law.

3. Bad

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

With these policy values any or basic referrer data, which may be sensitive, is sent to third parties possibly via insecure connections (HTTP). Therefore these values must not be used.

Additional notes:

  1. To prevent leaking of sensitive data through URLs, please make sure URLs of your website do not contain personal or otherwise sensitive data (like personal names or passwords).
  2. strict-origin-when-cross-origin is the default policy value when no Referrer-Policy is published as prescribed in the current "Editor\'s Draft" of the Referrer-Policy standard and this default is used by all latest major browsers. Note that some users may still have a different default value configured in their browser.
  3. Use the HTTP Referrer-Policy header as a mechanism for serving your referrer policy. We do not recommend to use the HTML <meta> element or the HTML referrerpolicy content attribute to publish your referrer policy, especially because the sections that describe these methods in the standard are marked as "not normative". Therefore we do not check for a referrer policy that is offered via the latter two methods.
  4. Note that a web server may send multiple Referrer-Policy headers, and a Referrer-Policy header may contain multiple values. Unknown values will be ignored by the browser and only the last known value will be used. This makes it possible to use future standardised policy values that are not supported by all browsers yet. However, currently all latest major browsers support the above mentioned policy values under "Good" and "Warning".

Requirement level: Recommended', + detail_web_appsecpriv_http_referrer_policy_exp: 'We check if your web server provides an HTTP header for Referrer-Policy with a sufficiently secure and privacy-protecting policy value. With this policy your web server instructs browsers if, what and when referrer data should be sent to the website the user is navigating to from your website. This referrer data is sent in the Referer header by the browser to the website the user is navigating to. This navigation does not necessarily have to be cross-domain.

The data in the Referer header is usually used for analytics and logging. However there can be privacy and security risks. The data could be used e.g. for user tracking and the data could leak to third parties who eavesdrop the connection. The HTTP header for Referrer-Policy allows you to mitigate these risks by controlling and even minimizing the sending of referrer data.

We suggest to make an informed decision, with privacy and security risks in mind, on using one of the policy values from the first two categories below.

1. Good

  • no-referrer
  • same-origin

With these policy values no sensitive referrer data is sent to third parties.

2. Warning

  • strict-origin
  • strict-origin-when-cross-origin (browser\'s default value; see also under additional note 2)

With these policy values basic referrer data, which may be sensitive, is sent to third parties only via secure connections (HTTPS). Therefore these values should only to be used where necessary and permitted by law.

3. Bad

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

With these policy values any or basic referrer data, which may be sensitive, is sent to third parties possibly via insecure connections (HTTP). Therefore these values must not be used.

Additional notes:

  1. To prevent leaking of sensitive data through URLs, please make sure URLs of your website do not contain personal or otherwise sensitive data (like personal names or passwords).
  2. strict-origin-when-cross-origin is the default policy value when no Referrer-Policy is published as prescribed in the current "Editor\'s Draft" of the Referrer-Policy standard and this default is used by all latest major browsers. Note that some users may still have a different default value configured in their browser.
  3. Use the HTTP Referrer-Policy header as a mechanism for serving your referrer policy. We do not recommend to use the HTML <meta> element or the HTML referrerpolicy content attribute to publish your referrer policy, especially because the sections that describe these methods in the standard are marked as "not normative". Therefore we do not check for a referrer policy that is offered via the latter two methods.
  4. Note that a web server may send multiple Referrer-Policy headers, and a Referrer-Policy header may contain multiple values. Unknown values will be ignored by the browser and only the last known value will be used. This makes it possible to use future standardised policy values that are not supported by all browsers yet. However, currently all latest major browsers support the above mentioned policy values under "Good" and "Warning".

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Recommended', detail_web_appsecpriv_http_referrer_policy_label: 'Referrer-Policy', detail_web_appsecpriv_http_referrer_policy_tech_table: 'Web server IP address|Findings', detail_web_appsecpriv_http_referrer_policy_verdict_bad: 'Your web server offers a Referrer-Policy with a policy value that is not sufficiently secure and privacy-protecting.', detail_web_appsecpriv_http_referrer_policy_verdict_good: 'Your web server offers a Referrer-Policy with a policy value that is sufficiently secure and privacy-protecting.', detail_web_appsecpriv_http_referrer_policy_verdict_recommendations: 'Your web server either does not offer a Referrer-Policy and thus relies on the default browser policy, or your web server offers a Referrer-Policy with a policy value that should be used with caution because of its potential impact on security and privacy.', - detail_web_appsecpriv_http_securitytxt_exp: 'We check if your web server provides a security.txt file in the right location, whether it could be retrieved, and whether its content is syntactically valid.

security.txt is a text file with contact information that you place on your web server. Security researchers can use this information to directly contact the right department or person within your organization about vulnerabilities that they found in your website or IT systems. This can speed up the fixing of found vulnerabilities, reducing the opportunity for malicious parties to exploit.

The syntax of the file is intended to be machine- and human-readable. The contact information can be an email address, a phone number, and/or a web page (e.g. a web form). Note that published contact information is public and can also be abused, for example, to send spam to a published e-mail address.

Besides contact infomation, the security.txt file must also contain an expiry date. To avoid staleness it is recommended that the date be less than a year into the future. It is optional to also include other relevant information for security researchers, like a link to your policy on dealing with security vulnerabilities reports (usually called a Coordinated Vulnerability Disclosure policy).

It is recommended to PGP sign the security.txt file while including the web URI on which the file is located in a Canonical field. We check if the security.txt file is signed. However, we do not validate the signature because, unfortunately, there is no standardised place to retrieve a public PGP key (which is required for signature validation).

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.

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.

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.

Note that security.txt files are normally just a few kilobytes in size. We therefore read and evaluate at maximum the first 100 kB of a found security.txt file.

Requirement level: Recommended', + detail_web_appsecpriv_http_securitytxt_exp: 'We check if your web server provides a security.txt file in the right location, whether it could be retrieved, and whether its content is syntactically valid.

security.txt is a text file with contact information that you place on your web server. Security researchers can use this information to directly contact the right department or person within your organization about vulnerabilities that they found in your website or IT systems. This can speed up the fixing of found vulnerabilities, reducing the opportunity for malicious parties to exploit.

The syntax of the file is intended to be machine- and human-readable. The contact information can be an email address, a phone number, and/or a web page (e.g. a web form). Note that published contact information is public and can also be abused, for example, to send spam to a published e-mail address.

Besides contact information, the security.txt file must also contain an expiry date. To avoid staleness it is recommended that the date be less than a year into the future. It is optional to also include other relevant information for security researchers, like a link to your policy on dealing with security vulnerabilities reports (usually called a Coordinated Vulnerability Disclosure policy).

It is recommended to PGP sign the security.txt file while including the web URI on which the file is located in a Canonical field. We check if the security.txt file is signed. However, we do not validate the signature because, unfortunately, there is no standardised place to retrieve a public PGP key (which is required for signature validation).

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.

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.

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.

Note that security.txt files are normally just a few kilobytes in size. We therefore read and evaluate at maximum the first 100 kB of a found security.txt file.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Recommended', detail_web_appsecpriv_http_securitytxt_label: 'security.txt', detail_web_appsecpriv_http_securitytxt_tech_table: 'Web server IP address|Findings', detail_web_appsecpriv_http_securitytxt_verdict_bad: 'Your web server does not offer a security.txt file in the right location, it could not be retrieved, or its content is not syntactically valid.', detail_web_appsecpriv_http_securitytxt_verdict_good: 'Your web server offers a security.txt file in the right location and its content is syntactically valid.', detail_web_appsecpriv_http_securitytxt_verdict_recommendations: 'Your web server offers a security.txt file in the right location and its content is syntactically valid. However, there are one or more recommendations for improvement.', - detail_web_appsecpriv_http_x_content_type_exp: 'We check if your web server provides an HTTP header for X-Content-Type-Options. With this HTTP header you let web browsers know that they must not do \'MIME type sniffing\' and always follow the Content-Type as declared by your web server. The only valid value for this HTTP header is nosniff. When enabled, a browser will block requests for style and script when they do not have a corresponding Content-Type (i.e. text/css or a \'JavaScript MIME type\' like application/javascript).

\'MIME type sniffing\' is a technique where the browser scans the content of a file to detect the format of a file regardless of the declared Content-Type by the web server. This technique is vulnerable to the so-called \'MIME confusion attack\' in which the attacker manipulates the content of a file in a way that it is treated by the browser as a different Content-Type, like an executable.

Requirement level: Recommended ', + detail_web_appsecpriv_http_x_content_type_exp: 'We check if your web server provides an HTTP header for X-Content-Type-Options. With this HTTP header you let web browsers know that they must not do \'MIME type sniffing\' and always follow the Content-Type as declared by your web server. The only valid value for this HTTP header is nosniff. When enabled, a browser will block requests for style and script when they do not have a corresponding Content-Type (i.e. text/css or a \'JavaScript MIME type\' like application/javascript).

\'MIME type sniffing\' is a technique where the browser scans the content of a file to detect the format of a file regardless of the declared Content-Type by the web server. This technique is vulnerable to the so-called \'MIME confusion attack\' in which the attacker manipulates the content of a file in a way that it is treated by the browser as a different Content-Type, like an executable.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Recommended ', detail_web_appsecpriv_http_x_content_type_label: 'X-Content-Type-Options', detail_web_appsecpriv_http_x_content_type_tech_table: 'Web server IP address|X-Content-Type-Options value', detail_web_appsecpriv_http_x_content_type_verdict_bad: 'Your web server does not offer X-Content-Type-Options.', detail_web_appsecpriv_http_x_content_type_verdict_good: 'Your web server offers X-Content-Type-Options.', - detail_web_appsecpriv_http_x_frame_exp: 'We check if your web server provides an HTTP header for X-Frame-Options that has a sufficiently secure policy. With this HTTP header you let web browsers know whether you want to allow your website to be framed or not. Prevention of framing defends visitors against attacks like clickjacking. We consider the following values to be sufficiently secure:

  • DENY (framing not allowed); or
  • SAMEORIGIN (only framing by your own website allowed).

Although the value ALLOW-FROM (only allow specific websites to frame your website) is part of the X-Frame-Options specification (RFC 7034), it is not supported by most modern web browsers. Therefore we do not consider this value as sufficiently secure.

Note that Content-Security-Policy (CSP) offers similar protection through frame-ancestors and besides much more for visitors with modern web browsers. However X-Frame-Options could still protect visitors of older web browsers that do not support CSP. Furthermore X-Frame-Options could offer valuable protection for all visitors when CSP is not (properly) configured for the website concerned.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Requirement level: Optional ', + detail_web_appsecpriv_http_x_frame_exp: 'We check if your web server provides an HTTP header for X-Frame-Options that has a sufficiently secure policy. With this HTTP header you let web browsers know whether you want to allow your website to be framed or not. Prevention of framing defends visitors against attacks like clickjacking. We consider the following values to be sufficiently secure:

  • DENY (framing not allowed); or
  • SAMEORIGIN (only framing by your own website allowed).

Although the value ALLOW-FROM (only allow specific websites to frame your website) is part of the X-Frame-Options specification (RFC 7034), it is not supported by most modern web browsers. Therefore we do not consider this value as sufficiently secure.

Note that Content-Security-Policy (CSP) offers similar protection through frame-ancestors and besides much more for visitors with modern web browsers. However X-Frame-Options could still protect visitors of older web browsers that do not support CSP. Furthermore X-Frame-Options could offer valuable protection for all visitors when CSP is not (properly) configured for the website concerned.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Optional ', detail_web_appsecpriv_http_x_frame_label: 'X-Frame-Options', detail_web_appsecpriv_http_x_frame_tech_table: 'Web server IP address|X-Frame-Options value', detail_web_appsecpriv_http_x_frame_verdict_bad: 'Your web server does not offer securely configured X-Frame-Options.', @@ -406,29 +409,29 @@ const internet_nl_messages = { detail_web_ipv6_web_aaaa_tech_table: 'Web server|IPv6 address|IPv4 address', detail_web_ipv6_web_aaaa_verdict_bad: 'None of your web servers has an IPv6 address.', detail_web_ipv6_web_aaaa_verdict_good: 'At least one of your web servers has an IPv6 address.', - detail_web_ipv6_web_ipv46_exp: 'We compare the response and content received from your web server over IPv6 with that received over IPv4.

We check:

  1. if HTTP (port 80) and/or HTTPS (port 443) over IPv4 are also available over IPv6;
  2. if HTTP headers (such as a redirect header) over IPv4 are also received over IPv6;
  3. if HTML content over IPv4 is the same over IPv6. After stripping eventual nonces we do a comparison of the received content. The content difference must not be higher than 10% to pass this subtest. The treshold makes sure that small differences (for example due to changing ads) do not lead to a fail of this subtest as well. An observed difference may be intended or due to a measurement error. Therefore, in this case, a warning is given and it is not weighed into the score.

Note that in case there are multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4 address to perform the subtest. If only an IPv6 address and no IPv4 address is available, the subtest is not applicable because no comparison can be made.', + detail_web_ipv6_web_ipv46_exp: '

We compare the available ports and offered headers and content of your web server via IPv6 with those via IPv4.

We check if:

  1. the same ports, i.e. HTTP (port 80) and/or HTTPS (port 443), are available via both IPv6 and IPv4;
  2. the same HTTP headers are offered via both IPv6 and IPv4. This includes HTTP response codes, like successful responses (200 – 299) and redirection messages (300 – 399). In cases of a client error response (400 - 499) or a server error response (500 - 599) a warning without score impact is given, because such a HTTP response code may indicate a configuration issue;
  3. the same HTML content is offered via both IPv6 and IPv4. We do this by comparing the content received after stripping any nonces. The content difference must not be higher than 10% to pass this subtest. This threshold ensures that small non-problematic differences (for example due to changing advertisements) do not immediately result in a failing result for this subtest. An observed difference may still be intended or due to measurement error. Therefore, in case of failure, this part of the subtest results only in a warning with no score impact.

Additional notes:

  • In case there are multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4 address to perform the subtest.
  • If only an IPv6 address and no IPv4 address (or vice versa) is available, the subtest is not applicable because no comparison can be made.
  • This subtest follows redirects and also checks all underlying URLs.
', detail_web_ipv6_web_ipv46_label: 'Same website on IPv6 and IPv4', - detail_web_ipv6_web_ipv46_verdict_bad: 'Available ports or offered headers of your website over IPv4 are not the same over IPv6.', - detail_web_ipv6_web_ipv46_verdict_good: 'Your website on IPv6 seems to be the same as your website on IPv4.', - detail_web_ipv6_web_ipv46_verdict_notice: 'The HTML content of your website over IPv4 is not the same over IPv6. ', - detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Your website on IPv6 seems to be the same as your website on IPv4, but the HTTP response code is in the 4xx or 5xx range. This may indicate a configuration issue.', + detail_web_ipv6_web_ipv46_verdict_bad: 'Available ports or offered headers of your website via IPv4 are not the same via IPv6.', + detail_web_ipv6_web_ipv46_verdict_good: 'Your website via IPv6 looks identical via IPv4.', + detail_web_ipv6_web_ipv46_verdict_notice: 'The HTML content of your website via IPv4 is not the same via IPv6. ', + detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Your website via IPv6 looks identical via IPv4, but the HTTP response code is in the 4xx or 5xx range. This may indicate a configuration issue.', detail_web_ipv6_web_reach_exp: 'We check if we can connect to your web server(s) over IPv6 on any available ports (80 and/or 443). We test all IPv6 addresses that we receive from your name servers. A partial score will be given if not all IPv6 addresses are reachable. If an IPv6 address is (syntactically) invalid, we consider it unreachable.', detail_web_ipv6_web_reach_label: 'IPv6 reachability of web server', detail_web_ipv6_web_reach_tech_table: 'Web server|Unreachable IPv6 address', detail_web_ipv6_web_reach_verdict_bad: 'At least one of your web servers with an IPv6 address is not reachable over IPv6.', detail_web_ipv6_web_reach_verdict_good: 'All your web servers with an IPv6 address are reachable over IPv6.', - detail_web_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your web server.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_web_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your web server.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_web_rpki_exists_label: 'Route Origin Authorisation existence', - detail_web_rpki_exists_tech_table: 'Webserver|IP address|RPKI Route Origin Authorization', + detail_web_rpki_exists_tech_table: 'Web server|IP address|RPKI Route Origin Authorization', detail_web_rpki_exists_verdict_bad: 'For at least one of the IP addresses of your web server no RPKI Route Origin Authorisation (ROA) is published.', detail_web_rpki_exists_verdict_good: 'For all IP addresses of your web server an RPKI Route Origin Authorisation (ROA) is published.', detail_web_rpki_exists_verdict_no_addresses: 'Your domain does not contain any web server IP addresses. Therefore, this subtest could not be performed.', - detail_web_rpki_valid_exp: 'We check if the validation status for all IP addresses of your web server is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

Requirement level: Recommended', + detail_web_rpki_valid_exp: 'We check if the validation status for all IP addresses of your web server is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error. ', detail_web_rpki_valid_label: 'Route announcement validity', detail_web_rpki_valid_tech_table: 'Web server|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_web_rpki_valid_verdict_bad: 'At least one IP address of your web server has a NotFound validation state. There is no RPKI Route Origin Authorization (ROA) published for the route announcement of each of the affected IP addresses.', detail_web_rpki_valid_verdict_good: 'All IP addresses of your web server have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_web_rpki_valid_verdict_invalid: 'At least one IP address of your web server has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your web hoster as soon as possible. In the case of an internal error, your web hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_web_rpki_valid_verdict_invalid: 'At least one IP address of your web server has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your web hoster as soon as possible. In the case of an internal error, your web hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_web_rpki_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', detail_web_tls_cert_hostmatch_exp: 'We check if the domain name of your website matches the domain name on the certificate.

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

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B3-1 (in English).', detail_web_tls_cert_hostmatch_label: 'Domain name on certificate', @@ -486,19 +489,19 @@ const internet_nl_messages = { detail_web_tls_dane_valid_tech_table: 'Web server IP address|DANE TLSA record valid', detail_web_tls_dane_valid_verdict_bad: 'The DANE fingerprint on your domain is not valid for your web certificate. Either someone manipulated the response from your name server, or your domain has a serious DANE configuration error. The latter makes your website unreachable for any user who check DANE fingerprints. You should contact your name server operator and/or your hosting provider as soon as possible.', detail_web_tls_dane_valid_verdict_good: 'The DANE fingerprint on your domain is valid for your web certificate.', - detail_web_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your web server are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', + detail_web_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your web server are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', detail_web_tls_fs_params_label: 'Key exchange parameters', detail_web_tls_fs_params_tech_table: 'Web server IP address|Affected parameters|Status', detail_web_tls_fs_params_verdict_bad: 'Your web server supports insufficiently secure parameters for Diffie-Hellman key exchange.', detail_web_tls_fs_params_verdict_good: 'Your web server supports secure parameters for Diffie-Hellman key exchange.', - detail_web_tls_fs_params_verdict_na: 'This subtest is not applicable as your webserver does not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.', + detail_web_tls_fs_params_verdict_na: 'This subtest is not applicable as your web server does not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.', detail_web_tls_fs_params_verdict_phase_out: '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.', - detail_web_tls_http_compression_exp: '

We test if your web server supports HTTP compression.

HTTP compression makes the secure connection with your webserver vulnerable for the BREACH attack. However HTTP compression is commonly used to make more efficient use of available bandwidth. Consider the trade-offs involved with HTTP compression. If you choose to use HTTP compression, verify if it is possible to mitigate related attacks at the application level. An example of such a measure is limiting the extent to which an attacker can influence the response of a server.

This subtest checks if the web server on root directory level supports HTTP compression. However it does not check additional website sources like images and scripts.

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

Requirement level: Optional

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
', + detail_web_tls_http_compression_exp: '

We test if your web server supports HTTP compression.

HTTP compression makes the secure connection with your web server vulnerable for the BREACH attack. However HTTP compression is commonly used to make more efficient use of available bandwidth. Consider the trade-offs involved with HTTP compression. If you choose to use HTTP compression, verify if it is possible to mitigate related attacks at the application level. An example of such a measure is limiting the extent to which an attacker can influence the response of a server.

This subtest checks if the web server on root directory level supports HTTP compression. However it does not check additional website sources like images and scripts.

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

Requirement level: Optional

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
', detail_web_tls_http_compression_label: 'HTTP compression', detail_web_tls_http_compression_tech_table: 'Web server IP address|HTTP compression', detail_web_tls_http_compression_verdict_bad: 'Your web server supports HTTP compression, which could be a security risk.', detail_web_tls_http_compression_verdict_good: 'Your web server does not support HTTP compression.', - detail_web_tls_https_exists_exp: 'We check if your website is reachable on HTTPS.

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

HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user. Note: for performance reasons the tests in the HTTPS test section only run for the first available IPv6 and IPv4 address.', + detail_web_tls_https_exists_exp: 'We check if your website is reachable on HTTPS.

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

HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Secure connection (HTTPS)\' only run for the first available IPv6 and IPv4 address.', detail_web_tls_https_exists_label: 'HTTPS available', detail_web_tls_https_exists_tech_table: 'Web server IP address|HTTPS existent', detail_web_tls_https_exists_verdict_bad: 'Your website does not offer HTTPS.', @@ -521,7 +524,7 @@ const internet_nl_messages = { detail_web_tls_kex_hash_func_label: 'Hash function for key exchange', detail_web_tls_kex_hash_func_tech_table: 'Web server IP address|SHA2 support for signatures', detail_web_tls_kex_hash_func_verdict_good: 'Your web server supports a secure hash function for key exchange.', - detail_web_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by your webserver. This could be because the cipher combination used has no signature for certificate verification (e.g it uses RSA key exchange or is anonymous i.e. anon).', + detail_web_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by your web server. This could be because the cipher combination used has no signature for certificate verification (e.g. it uses RSA key exchange or is anonymous i.e. anon).', detail_web_tls_kex_hash_func_verdict_phase_out: 'Your web server 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.', detail_web_tls_ocsp_stapling_exp: '

We check if your web server supports the TLS Certificate Status extension also known as OCSP stapling.

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.

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.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, table 15 (in English).

Requirement level: Optional

OCSP stapling

  • Good: On
  • Sufficient: Off
', detail_web_tls_ocsp_stapling_label: 'OCSP stapling', @@ -550,7 +553,7 @@ const internet_nl_messages = { detail_web_tls_zero_rtt_tech_table: 'Web server IP address|0-RTT', detail_web_tls_zero_rtt_verdict_bad: 'Your web server supports 0-RTT, which is not secure.', detail_web_tls_zero_rtt_verdict_good: 'Your web server does not support 0-RTT.', - detail_web_tls_zero_rtt_verdict_na: 'This subtest is not applicable as your webserver does not support TLS 1.3.', + detail_web_tls_zero_rtt_verdict_na: 'This subtest is not applicable as your web server does not support TLS 1.3.', detail_web_mail_ipv6_ns_aaaa_exp: 'We check if your domain name has at least two name servers with an IPv6 address.

This is consistent with the "Technical requirements for the registration and use of .nl domain names" d.d. 13 November 2017 by SIDN (.nl TLD registry) that require each .nl domain to have at least two name servers.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginning with ::ffff:) will fail in this test, as they do not provide IPv6 connectivity.', detail_web_mail_ipv6_ns_aaaa_label: 'IPv6 addresses for name servers', detail_web_mail_ipv6_ns_aaaa_tech_table: 'Name server|IPv6 address|IPv4 address', @@ -562,29 +565,31 @@ const internet_nl_messages = { detail_web_mail_ipv6_ns_reach_tech_table: 'Name server|Unreachable IPv6 address', detail_web_mail_ipv6_ns_reach_verdict_bad: 'Not all name servers that have an IPv6 address are reachable over IPv6.', detail_web_mail_ipv6_ns_reach_verdict_good: 'All name servers that have an IPv6 address are reachable over IPv6.', - detail_web_mail_rpki_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your domain.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_web_mail_rpki_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your domain.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_web_mail_rpki_ns_exists_label: 'Route Origin Authorisation existence', detail_web_mail_rpki_ns_exists_tech_table: 'Name server|IP address|RPKI Route Origin Authorization', detail_web_mail_rpki_ns_exists_verdict_bad: 'For at least one of the IP addresses of your name servers no RPKI Route Origin Authorisation (ROA) is published.', detail_web_mail_rpki_ns_exists_verdict_good: 'For all IP addresses of your name servers an RPKI Route Origin Authorisation (ROA) is published.', detail_web_mail_rpki_ns_exists_verdict_no_addresses: 'Your domain does not contain any name servers. Therefore, this subtest could not be performed.', - detail_web_mail_rpki_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your domain is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

Note: The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

Requirement level: Recommended', + detail_web_mail_rpki_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your domain is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error. ', detail_web_mail_rpki_ns_valid_label: 'Route announcement validity', detail_web_mail_rpki_ns_valid_tech_table: 'Name server|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_web_mail_rpki_ns_valid_verdict_bad: 'At least one IP address of your name servers has a NotFound validation state. There is no RPKI Route Origin Authorisation (ROA) is published for its route announcement.', detail_web_mail_rpki_ns_valid_verdict_good: 'All IP addresses of your name servers have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_web_mail_rpki_ns_valid_verdict_invalid: 'At least one IP address of your name servers has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your name server hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your name server hoster as soon as possible. In the case of an internal error, your name server hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_web_mail_rpki_ns_valid_verdict_invalid: 'At least one IP address of your name servers has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your name server hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your name server hoster as soon as possible. In the case of an internal error, your name server hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_web_mail_rpki_ns_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', domain_pagetitle: 'Website test:', domain_title: 'Website test: {{prettyaddr}}', domain_tweetmessage: 'The%20website%20{{report.domain}}%20scores%20{{score}}%25%20in%20the%20website%20test%20of%20%40Internet_nl%3A', faqs_appsecpriv_title: 'Security options', faqs_badges_title: 'Using the 100% badges', + faqs_batch_and_dashboard_title: 'Batch API and web-based dashboard', faqs_dnssec_title: 'Domain signature (DNSSEC)', faqs_halloffame_title: 'Criteria for \'Hall of Fame for Hosters\'', faqs_https_title: 'Secure website connection (HTTPS)', faqs_ipv6_title: 'Modern address (IPv6)', faqs_mailauth_title: 'Protection against email phishing (DMARC, DKIM and SPF)', + faqs_measurements_title: 'Measurements using Internet.nl', faqs_report_score_title: 'Norm and score', faqs_report_subtest_bad: 'Bad: fail on REQUIRED subtest ⇒ null score', faqs_report_subtest_error: 'Test error: error encountered during testing ⇒ null score', @@ -635,7 +640,7 @@ const internet_nl_messages = { page_gotofooter: 'Go to the footer', page_gotomainmenu: 'Go to the main menu', page_metadescription: 'Test for modern Internet Standards IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI and security.txt', - page_metakeywords: 'IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, test tool, check, validation, Internet, Internet Standards, open standards, modern standards, security, internet security, mail, email security, website, website security, internet connection, secure connection, email authentication, encryption, ciphers, cipher suites, PKI, SSL certificate, TLS certificate, website certificaat, Internet Standards Platform', + page_metakeywords: 'IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, test tool, check, validation, Internet, Internet Standards, open standards, modern standards, security, internet security, mail, email security, website, website security, internet connection, secure connection, email authentication, encryption, ciphers, cipher suites, PKI, SSL certificate, TLS certificate, website certificate, Internet Standards Platform', page_sitedescription: 'Is your Internet up-to-date?', page_sitetitle: 'Internet.nl', page404_title: 'Page not found!', @@ -745,7 +750,9 @@ const internet_nl_messages = { test_mailipv6_title: 'Reachable via modern internet address?', test_mailipv6_warning_description: 'Too bad! Your mail server can not be reached by senders using modern addresses (IPv6), or improvement is possible. Therefore your mail server is not part of the modern Internet yet. You should ask your email provider to fully enable IPv6.', test_mailipv6_warning_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_mailrpki_failed_description: 'Too bad! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster or your name server hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your mail hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', + test_mailrpki_error_description: 'Test not ready to run yet. Please try again later. Sorry for the inconvenience.', + test_mailrpki_error_summary: 'Test not ready to run (RPKI)', + test_mailrpki_failed_description: 'Too bad! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster or your name server hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your mail hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', test_mailrpki_failed_summary: 'Unauthorised route announcement (RPKI)', test_mailrpki_info_description: 'Informational: Your domain does not contain any name servers and thus contains no receiving mail server(s). There are no routable IP addresses that could be tested (RPKI).', test_mailrpki_info_summary: 'No routable IP addresses found (RPKI)', @@ -753,7 +760,7 @@ const internet_nl_messages = { test_mailrpki_passed_description: 'Well done! All IP addresses of your receiving mail server(s) and associated name servers have a route announcement that is matched by the published route authorisation (RPKI). As a result, email transport between sending mail servers with enabled route validation and your receiving mail server(s) is better protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers.', test_mailrpki_passed_summary: 'Authorised route announcement (RPKI)', test_mailrpki_title: 'Route authorisation?', - test_mailrpki_warning_description: 'Warning! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, email transport between sending mail servers with enabled route validation and your receiving mail server(s) is not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', + test_mailrpki_warning_description: 'Too bad! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, email transport between sending mail servers with enabled route validation and your receiving mail server(s) is not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', test_mailrpki_warning_summary: 'Route authorisation not published (RPKI)', test_mailtls_failed_description: 'Too bad! Sending mail servers that support secure email transport (STARTTLS and DANE) can establish no or an insufficiently secure connection with your receiving mail server(s). Passive and/or active attackers will therefore be able to read emails in transit to you. You should ask your mail provider to enable STARTTLS and DANE, and configure it securely.', test_mailtls_failed_summary: 'Mail server connection not or insufficiently secured (STARTTLS and DANE)', @@ -762,9 +769,9 @@ const internet_nl_messages = { test_mailtls_invalid_null_mx_description: 'Warning: Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting. ', test_mailtls_invalid_null_mx_summary: 'Inconsistently configured non-receiving mail domain (STARTTLS and DANE)', test_mailtls_label: 'Secure mail server connection (STARTTLS and DANE)', - test_mailtls_no_mx_description: 'Informational: No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email. Note that you do not need a \'Null MX\' record in this case. Your configuration makes the subtests in the STARTTLS and DANE category not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. ', + test_mailtls_no_mx_description: 'Informational: The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', test_mailtls_no_mx_summary: 'Properly configured non-receiving mail domain (STARTTLS and DANE)', - test_mailtls_no_null_mx_description: 'Informational: No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Your current configuration makes the subtests in the STARTTLS and DANE category not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. ', + test_mailtls_no_null_mx_description: 'Informational: No receiving mail servers (MX) are set on your domain that has A/AAAA records and has an SPF record with only the term -all. We recommend you to set a "Null MX" record to explicitly indicate that your domain does not accept email. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', test_mailtls_no_null_mx_summary: 'Not explicitly configured non-receiving mail domain (STARTTLS and DANE)', test_mailtls_null_mx_description: 'Informational: Your domain that has A/AAAA records, clearly indicates that it does not accept email by advertising a "Null MX" record. This is fine if you do not want to receive email. Your configuration makes the subtests in the STARTTLS and DANE category not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC.', test_mailtls_null_mx_summary: 'Properly configured non-receiving mail domain (STARTTLS and DANE)', @@ -775,21 +782,21 @@ const internet_nl_messages = { test_mailtls_passed_description: 'Well done! Sending mail servers supporting secure email transport (STARTTLS and DANE) can establish a secure connection with your receiving mail server(s). STARTTLS prevents passive attackers from reading emails in transit to you. DANE protects against active attackers stripping STARTTLS encryption by manipulating the mail traffic.', test_mailtls_passed_summary: 'Mail server connection sufficiently secured (STARTTLS and DANE)', test_mailtls_title: 'Secure mail server connection?', - test_mailtls_unreachable_description: 'Test error: at least one of your receiving mail servers was not reachable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by network connectivity problems or by the mailserver(s) not accepting connections.', + test_mailtls_unreachable_description: 'Test error: at least one of your receiving mail servers was not reachable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by network connectivity problems or by the mail server(s) not accepting connections.', test_mailtls_unreachable_summary: 'Unreachable receiving mail server (STARTTLS and DANE)', - test_mailtls_untestable_description: 'Test error: at least one of your receiving mail servers was not testable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by, among other things, SMTP errors and ratelimiting measures engaging and dropping connections.', + test_mailtls_untestable_description: 'Test error: at least one of your receiving mail servers was not testable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by, among other things, SMTP errors and rate limiting measures engaging and dropping connections.', test_mailtls_untestable_summary: 'Untestable mail server (STARTTLS and DANE)', test_mailtls_warning_description: 'Too bad! Sending mail servers that support secure email transport (STARTTLS and DANE) can establish no or an insufficiently secure connection with your receiving mail server(s). Passive and/or active attackers will therefore be able to read emails in transit to you. You should ask your mail provider to enable STARTTLS and DANE, and configure it securely.', test_mailtls_warning_summary: 'Mail server connection not or insufficiently secured (STARTTLS and DANE)', - test_siteappsecpriv_failed_description: 'Too bad! Not all required security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code). ', + test_siteappsecpriv_failed_description: 'Too bad! Not all required security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options.', test_siteappsecpriv_failed_summary: 'One or more required security options not set (Security options)', - test_siteappsecpriv_info_description: 'Informational: Not all optional security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code).', + test_siteappsecpriv_info_description: 'Informational: Not all optional security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with HTTP response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options.', test_siteappsecpriv_info_summary: 'One or more optional security options not set (Security options)', test_siteappsecpriv_label: 'Security options', - test_siteappsecpriv_passed_description: 'Well done! All security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code). ', + test_siteappsecpriv_passed_description: 'Well done! All security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with HTTP response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options.', test_siteappsecpriv_passed_summary: 'All security options set (Security options) ', test_siteappsecpriv_title: 'Security options set?', - test_siteappsecpriv_warning_description: 'Warning: Not all recommended security options, , i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code). ', + test_siteappsecpriv_warning_description: 'Warning: Not all recommended security options, , i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with HTTP response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. ', test_siteappsecpriv_warning_summary: 'One or more recommended security options not set (Security options)', test_sitednssec_failed_description: 'Too bad! Your domain is not signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are not protected against manipulated translation from your domain into rogue internet addresses. You should ask your name server operator (often your registrar and/or hosting provider) to enable DNSSEC.', test_sitednssec_failed_summary: 'Domain name not signed (DNSSEC)', @@ -811,7 +818,9 @@ const internet_nl_messages = { test_siteipv6_title: 'Reachable via modern address?', test_siteipv6_warning_description: 'Too bad! Your website is not reachable for visitors using a modern internet address (IPv6), or improvement is possible. Therefore your website is not part of the modern Internet yet. You should ask your hosting provider to fully enable IPv6.', test_siteipv6_warning_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_siterpki_failed_description: 'Too bad! At least one of the IP addresses of your web server and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster or your name server hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your web hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', + test_siterpki_error_description: 'Test not ready to run yet. Please try again later. Sorry for the inconvenience.', + test_siterpki_error_summary: 'Test not ready to run (RPKI)', + test_siterpki_failed_description: 'Too bad! At least one of the IP addresses of your web server and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster or your name server hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your web hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', test_siterpki_failed_summary: 'Unauthorised route announcement (RPKI)', test_siterpki_info_description: 'Informational: Your domain does not contain any name servers and thus contains no web server IP addresses. There are no routable IP addresses that could be tested (RPKI).', test_siterpki_info_summary: 'No routable IP addresses found (RPKI)', @@ -819,7 +828,7 @@ const internet_nl_messages = { test_siterpki_passed_description: 'Well done! All IP addresses of your web server and associated name servers have a route announcement that is matched by the published route authorisation (RPKI). As a result, visitors with enabled route validation are better protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers.', test_siterpki_passed_summary: 'Authorised route announcement (RPKI)', test_siterpki_title: 'Route authorisation?', - test_siterpki_warning_description: 'Warning! At least one of the IP addresses of your web server and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, visitors with enabled route validation are not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', + test_siterpki_warning_description: 'Too bad! At least one of the IP addresses of your web server and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, visitors with enabled route validation are not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', test_siterpki_warning_summary: 'Route authorisation not published (RPKI)', test_sitetls_failed_description: 'Too bad! The connection with your website is not or insufficientlysecured (HTTPS). Therefore information in transit between your website and its visitors is not sufficiently protected against eavesdropping and tampering. You should ask your hosting provider to enable HTTPS and to configure it securely.', test_sitetls_failed_summary: 'Connection not or insufficiently secured (HTTPS)', @@ -829,11 +838,11 @@ const internet_nl_messages = { test_sitetls_passed_description: 'Well done! The connection with your website is sufficiently secured (HTTPS). Therefore information in transit between your website and its visitors is protected against eavesdropping and tampering.', test_sitetls_passed_summary: 'Connection sufficiently secured (HTTPS)', test_sitetls_title: 'Secure connection?', - test_sitetls_unreachable_description: 'Your webserver was not reachable for us, making it impossible to (fully) test for HTTPS. This could be caused by network connectivity problems or by the webserver not accepting connections.', - test_sitetls_unreachable_summary: 'Unreachable webserver (HTTPS)', + test_sitetls_unreachable_description: 'Your web server was not reachable for us, making it impossible to (fully) test for HTTPS. This could be caused by network connectivity problems or by the web server not accepting connections.', + test_sitetls_unreachable_summary: 'Unreachable web server (HTTPS)', test_sitetls_warning_description: 'Too bad! The connection with your website is not or insufficientlysecured (HTTPS). Therefore information in transit between your website and its visitors is not sufficiently protected against eavesdropping and tampering. You should ask your hosting provider to enable HTTPS and to configure it securely.', test_sitetls_warning_summary: 'Connection not or insufficiently secured (HTTPS)', - widget_content_notes: '

Notes

  • Logo: We recommend you to save and use our logo on your own web server. In that way there will not be any contact with our web server when your website is visited.
  • Content-Security-Policy (CSP): In case you are using a CSP policy for your website you would also need to add internet.nl to the rules for form-action and possibly also for img-src in case you link to the logo on our webserver.
', + widget_content_notes: '

Notes

  • Logo: We recommend you to save and use our logo on your own web server. In that way there will not be any contact with our web server when your website is visited.
  • Content-Security-Policy (CSP): In case you are using a CSP policy for your website you would also need to add internet.nl to the rules for form-action and possibly also for img-src in case you link to the logo on our web server.
', widget_mail_html_block: 'Test your email', widget_mail_intro: '

Email test widget

Would you like visitors of your website to be able to directly start an email test?
Copy the HTML and CSS code from the text fields below into the source code of your website.

', widget_site_html_block: 'Test your website', diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js index b945ea10..8db61d67 100644 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js @@ -68,7 +68,7 @@ const internet_nl_messages = { detail_conn_ipv6_resolver_conn_label: 'IPv6-connectiviteit van DNS-resolver', detail_conn_ipv6_resolver_conn_verdict_bad: 'Je DNS-resolver kan niet nameservers via IPv6 bereiken.', detail_conn_ipv6_resolver_conn_verdict_good: 'Je DNS-resolver kan nameservers via IPv6 bereiken.', - detail_mail_auth_dkim_exp: 'We testen of je domeinnaam DKIM ondersteunt. Een ontvangende mailserver kande publieke sleutel in je DKIM-record gebruiken om de handtekening in eene-mail met een gebruiker van jouw domein als afzender te controleren en deauthenticiteit van de e-mail te bepalen.

  • Om te slagen voor deze test verwachten we dat je nameserver NOERROR antwoordt op onze bevragingvoor _domainkey.example.nl. Als _domainkey.example.nl een \'empty non-terminal\' is, dan zullen sommige nameservers die zich niet houden aan destandaard RFC 2308, foutief antwoorden met NXDOMAIN in plaats vanNOERROR. Dit maakt het detecteren van het DKIM-record voor ons onmogelijk.
  • Op dit moment zijn we niet in staat om de publieke sleutel in je DKIM-record op te vragen en te beoordelen, omdat we daarvoor een e-mail van jouw domein zouden moeten ontvangen.
  • Bij deze test gaan we uit van \'strict alignment\' hetgeen conform DMARC is. Het geteste domein wordt beschouwd als het verzenddomein in het mailbericht (From:) en moet gelijk zijn aan zowel het DKIM-domein (d=) als het SPF-domein (envelope sender, d.w.z. return-path dat terugkomt in MAIL FROM).

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', + detail_mail_auth_dkim_exp: '

We testen of je domeinnaam DKIM ondersteunt. Een ontvangende mailserver kande publieke sleutel in je DKIM-record gebruiken om de handtekening in eene-mail met een gebruiker van jouw domein als afzender te controleren en deauthenticiteit van de e-mail te bepalen.

  • Om te slagen voor deze test verwachten we dat je nameserver NOERROR antwoordt op onze bevragingvoor _domainkey.example.nl. Als _domainkey.example.nl een \'empty non-terminal\' is, dan zullen sommige nameservers die zich niet houden aan destandaard RFC 2308, foutief antwoorden met NXDOMAIN in plaats vanNOERROR. Dit maakt het detecteren van het DKIM-record voor ons onmogelijk.
  • Op dit moment zijn we niet in staat om de publieke sleutel in je DKIM-record op te vragen en te beoordelen, omdat we daarvoor een e-mail van jouw domein zouden moeten ontvangen.
  • Bij deze test gaan we uit van \'strict alignment\' hetgeen conform DMARC is. Het geteste domein wordt beschouwd als het verzenddomein in het mailbericht (From:) en moet gelijk zijn aan zowel het DKIM-domein (d=) als het SPF-domein (envelope sender, d.w.z. return-path dat terugkomt in MAIL FROM).

Aanvullende opmerkingen:

  • Sommige e-mailsystemen wijzigen e-mail tijdens het transport, waardoor een DKIM-handtekening mogelijk ongeldig wordt. In veel gevallen zijn deze wijzigingen onschuldig. Voorbeelden zijn het vervangen van witruimte en het herordenen van headervelden. Als u een DKIM-ondertekenende verzender bent, dan kunt u kiezen of u dit soort wijzigingen wel of niet tolereert, zowel voor de header als voor de body van e-mails. De simple instelling tolereert bijna geen wijzigingen en relaxed tolereert veel voorkomende wijzigingen. Als er geen instelling is opgegeven, wordt standaard simple gebruikt voor zowel de header als de body. Met name headerwijzigingen zijn een veelvoorkomende oorzaak dat een DKIM-handtekening onbedoeld ongeldig wordt, waardoor de bezorgbaarheid wordt belemmerd. Het gebruik van relaxed voor de header en simple voor de body (c=relaxed/simple) kan dit soort problemen verminderen.
  • Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.
', detail_mail_auth_dkim_label: 'DKIM aanwezigheid', detail_mail_auth_dkim_verdict_bad: 'Je domeinnaam ondersteunt geen DKIM-records.', detail_mail_auth_dkim_verdict_good: 'Je domeinnaam ondersteunt DKIM-records.', @@ -78,7 +78,7 @@ const internet_nl_messages = { detail_mail_auth_dmarc_tech_table: 'DMARC-record|Gevonden op', detail_mail_auth_dmarc_verdict_bad: 'Je domeinnaam heeft geen DMARC-record.', detail_mail_auth_dmarc_verdict_good: 'Je domeinnaam heeft een DMARC-record.', - detail_mail_auth_dmarc_policy_exp: '

We controleren of de syntax van je DMARC-record correct is en of deze een voldoende strikte policy bevat (p=quarantine of p=reject) om misbruik van je domein door phishers en spammers tegen te gaan. Zelfs zonder een strikte policy kan DMARC nuttig zijn om met behulp van DMARC-rapporten meer inzicht te verkrijgen in legale en illegale uitgaande e-mailstromen. Maar om DMARC effectief te laten zijn tegen misbruik van je domein, is een liberale policy (p=none) niet voldoende.

We controleren ook of de mailadressen onder rua= en ruf= geldig zijn. Als deze een extern e-mailadres bevatten dan controleren we of het externe domein geautoriseerd is om DMARC-rapportages te ontvangen. Zorg ervoor dat het DMARC-autorisatierecord op het externe domein ten minste "v=DMARC1;" bevat.

De test staat het gebruik van de experimentele np tag toe (RFC 9091).

Good practice voor domeinnaam zonder mail:

  • Niet-verzendend: Gebruik de meest strikte DMARC policy (p=reject) en SPF policy (-all) voor (sub-)domeinnamen die je niet gebruikt om mail vanaf te versturen, om misbruik (\'spoofing\') tegen te gaan. Merk op dat DKIM in dit geval niet noodzakelijk is.
  • Niet-ontvangend: Voor meer informatie over "Null MX" en "No MX" zie de uitleg van de "STARTTLS beschikbaar" subtest.

Hieronder volgen twee basisvoorbeelden van de DNS-configuratie voor een domeinnaam die niet gebruikt wordt voor het verzenden en ontvangen van mail.

A. Enkele domeinnaam zonder A- of AAAA-record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Enkele domeinnaam met A- of AAAA-record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', + detail_mail_auth_dmarc_policy_exp: '

We controleren of de syntax van je DMARC-record correct is en of deze een voldoende strikte policy bevat (p=quarantine of p=reject) om misbruik van je domein door phishers en spammers tegen te gaan. Zelfs zonder een strikte policy kan DMARC nuttig zijn om met behulp van DMARC-rapporten meer inzicht te verkrijgen in legale en illegale uitgaande e-mailstromen. Maar om DMARC effectief te laten zijn tegen misbruik van je domein, is een liberale policy (p=none) niet voldoende.

We controleren ook of de mailadressen onder rua= en ruf= geldig zijn. Als deze een extern e-mailadres bevatten dan controleren we of het externe domein geautoriseerd is om DMARC-rapportages te ontvangen. Zorg ervoor dat het DMARC-autorisatierecord op het externe domein ten minste "v=DMARC1;" bevat.

De test staat het gebruik van de experimentele np tag toe (RFC 9091).

Good practice voor domeinnaam zonder mail:

  • Niet-verzendend: Gebruik de meest strikte DMARC policy (p=reject) en SPF policy (-all) voor (sub-)domeinnamen die je niet gebruikt om mail vanaf te versturen, om misbruik (\'spoofing\') tegen te gaan. Merk op dat DKIM in dit geval niet noodzakelijk is.
  • Niet-ontvangend: Voor meer informatie over "Null MX" en "No MX" zie de uitleg van de "STARTTLS beschikbaar" subtest.

Hieronder volgen twee basisvoorbeelden van de DNS-configuratie voor een domeinnaam die niet gebruikt wordt voor het verzenden en ontvangen van mail.

A. Enkele domeinnaam zonder A- of AAAA-record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Enkele domeinnaam met A- of AAAA-record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', detail_mail_auth_dmarc_policy_label: 'DMARC policy', detail_mail_auth_dmarc_policy_verdict_bad: 'Je DMARC-policy is syntactisch niet correct.', detail_mail_auth_dmarc_policy_verdict_external: 'De domeinnaam van het mailadres na rua= en/of ruf= bevat geen (geldig) autorisatie-record om DMARC-rapporten te ontvangen voor de geteste domeinnaam. ', @@ -111,7 +111,7 @@ const internet_nl_messages = { detail_mail_dnssec_mx_exists_verdict_bad: 'Tenminste één van jouw mailserverdomeinen is onveilig oftewel \'insecure\', omdat deze niet ondertekend is met DNSSEC.', detail_mail_dnssec_mx_exists_verdict_good: 'Al je mailserverdomeinen zijn ondertekend met DNSSEC.', detail_mail_dnssec_mx_exists_verdict_invalid_null_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', - detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. ', + detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_dnssec_mx_exists_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je domeinnaam geen e-mail accepteert door een "Null MX" record te publiceren. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_dnssec_mx_exists_verdict_null_mx: 'Je domeinnaam die A/AAAA-records heeft, geeft met een "Null MX" record duidelijk aan geen e-mail te accepteren. Dat is prima als je geen e-mail wilt ontvangen. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_dnssec_mx_exists_verdict_null_mx_with_other_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', @@ -136,41 +136,41 @@ const internet_nl_messages = { detail_mail_ipv6_mx_aaaa_verdict_bad: 'Tenminste één ontvangende mailserver op jouw domeinnaam heeft geen IPv6-adres.', detail_mail_ipv6_mx_aaaa_verdict_good: 'Alle ontvangende mailservers op jouw domeinnaam hebben een IPv6-adres.', detail_mail_ipv6_mx_aaaa_verdict_invalid_null_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld met een ander MX record, waardoor de "Null MX" tegenstrijdig is.', - detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je domeinnaam geen e-mail accepteert door een "Null MX" record te publiceren. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', + detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-records heeft en dat een SPF-record heeft met alleen de term -all. We raden je aan een "Null MX" record in te stellen om expliciet aan te geven dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_ipv6_mx_aaaa_verdict_null_mx: 'Je domeinnaam die A/AAAA-records heeft, geeft met een "Null MX" record duidelijk aan geen e-mail te accepteren. Dat is prima als je geen e-mail wilt ontvangen. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_with_other_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_without_a_aaaa: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is.', - detail_mail_ipv6_mx_aaaa_verdict_other: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. ', + detail_mail_ipv6_mx_aaaa_verdict_other: 'Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_ipv6_mx_reach_exp: 'We testen of we je mailservers (MX) kunnen bereiken via IPv6 op poort 25. We testen alle IPv6-adressen die we ontvangen van de nameservers van je mailserverdomein(en). Een deelscore wordt gegeven als niet alle IPv6-adressen bereikbaar zijn. Als een IPv6-adres (syntactisch) ongeldig is, dan beschouwen we dat als onbereikbaar.', detail_mail_ipv6_mx_reach_label: 'IPv6-bereikbaarheid van mailserver(s)', detail_mail_ipv6_mx_reach_tech_table: 'Mailserver (MX)|Onbereikbaar IPv6-adres', detail_mail_ipv6_mx_reach_verdict_bad: 'Tenminste één van je ontvangende mailservers met een IPv6-adres is niet bereikbaar via IPv6.', detail_mail_ipv6_mx_reach_verdict_good: 'Al je ontvangende mailservers met een IPv6-adres zijn bereikbaar via IPv6.', - detail_mail_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar uw server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar uw server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_mail_rpki_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_mail_rpki_exists_tech_table: 'Mailserver|IP-adres|RPKI Route Origin Authorization', detail_mail_rpki_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van je ontvangende mailserver(s) is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_exists_verdict_good: 'Voor alle IP-adressen van je ontvangende mailserver(s) is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_exists_verdict_no_addresses: 'Je domein bevat geen ontvangende mailservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_mail_rpki_mx_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_mx_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_mail_rpki_mx_ns_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_mail_rpki_mx_ns_exists_tech_table: 'Nameserver van MX|IP-adres|RPKI Route Origin Authorization', detail_mail_rpki_mx_ns_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van de nameservers van je mailserver(s) is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_mx_ns_exists_verdict_good: 'Voor alle IP-adressen van de nameservers van je mailserver(s) is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_mx_ns_exists_verdict_no_addresses: 'Je domein bevat geen mailservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_mail_rpki_mx_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_mx_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_mail_rpki_mx_ns_valid_label: 'Geldigheid van route-aankondiging', detail_mail_rpki_mx_ns_valid_tech_table: 'Nameserver van MX|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_mail_rpki_mx_ns_valid_verdict_bad: 'Ten minste één IP-adres van de nameservers van je ontvangende mailservers heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorization (ROA) gepubliceerd voor de route-aankondiging van ieder van de desbetreffende IP-adressen.', detail_mail_rpki_mx_ns_valid_verdict_good: 'Alle IP-adressen van de nameservers van je ontvangende mailservers hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_mx_ns_valid_verdict_invalid: 'Tenminste één IP-adres van de nameservers van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_mail_rpki_mx_ns_valid_verdict_invalid: 'Tenminste één IP-adres van de nameservers van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_mail_rpki_mx_ns_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', - detail_mail_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_mail_rpki_valid_label: 'Geldigheid van route-aankondiging', detail_mail_rpki_valid_tech_table: 'Mailserver|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_mail_rpki_valid_verdict_bad: 'Ten minste één IP-adres van je ontvangende mailservers heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorization (ROA) gepubliceerd voor de route-aankondiging van ieder van de desbetreffende IP-adressen.', detail_mail_rpki_valid_verdict_good: 'Alle IP-adressen van je ontvangende mailservers hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_mail_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_mail_rpki_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', detail_mail_tls_cert_hostmatch_exp: 'We testen of de domeinnaam van ieder van je ontvangende mailservers (MX) overeenkomt met de domeinnaam op het gepresenteerde certificaat.

Verzendende mailservers negeren doorgaans het domein op het certificaat. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor voegt de controle of de domeinnaam op het certificaat overeenkomt met het mailserverdomeinnaam geen enkele authenticiteitswaarde toe. 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. 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).

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B3-1.

Niveau van vereistheid: Optioneel / Vereist (alleen als DANE-TA wordt gebruikt)', detail_mail_tls_cert_hostmatch_label: 'Domeinnaam op certificaat', @@ -193,7 +193,7 @@ const internet_nl_messages = { detail_mail_tls_cert_trust_tech_table: 'Mailserver (MX)|Onvertrouwde certificaatketen', detail_mail_tls_cert_trust_verdict_bad: 'De vertrouwensketen van tenminste één van je mailserver-certificaten is niet compleet en/of niet ondertekend door een vertrouwde certificaatautoriteit.', detail_mail_tls_cert_trust_verdict_good: 'De vertrouwensketen van al je mailserver-certificaten is compleet én ondertekend door een vertrouwde certificaatautoriteit.', - detail_mail_tls_cipher_order_exp: 'We testen of je ontvangende mailservers (MX) hun eigen cipher-voorkeur afdwingen (\'I\'), en ciphers aanbieden conform de voorgeschreven volgorde (\'II\').

Als je mailserver alleen \'Goede\' ciphers ondersteunt, dan is deze test niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

I. Server afgedwongen cipher-volgorde: Ontvangende mailservers dwingen hun cipher-voorkeur af tijdens de onderhandeling met verzendende mailservers, en accepteren geen voorkeur van de verzendende mailservers;

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.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', + detail_mail_tls_cipher_order_exp: 'We testen of je ontvangende mailservers (MX) hun eigen cipher-voorkeur afdwingen (\'I\'), en ciphers aanbieden conform de voorgeschreven volgorde (\'II\').

Als je mailserver alleen \'Goede\' ciphers ondersteunt, dan is deze test niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

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;

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.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', detail_mail_tls_cipher_order_label: 'Cipher-volgorde', detail_mail_tls_cipher_order_tech_table: 'Mail server (MX)|Eerst gevonden getroffen cipher-paren|Overtreden regel # (\'II-B\')', detail_mail_tls_cipher_order_verdict_bad: 'Tenminste één van je mailservers dwingt niet zijn eigen cipher-voorkeur af (\'I\').', @@ -218,7 +218,7 @@ const internet_nl_messages = { detail_mail_tls_dane_exists_verdict_bad: 'Tenminste één van je mailserverdomeinen bevat geen TLSA-record voor DANE.', detail_mail_tls_dane_exists_verdict_bogus: 'Tenminste één van je mailserverdomeinen bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Dit kan leiden tot afleveringsproblemen van mail die aan aan jou gericht is door DANE-validerende mailverstuurders. Vraag je nameserver-beheerder om deze fout op te lossen.', detail_mail_tls_dane_exists_verdict_good: 'Al je mailserverdomeinen bevatten een TLSA-record voor DANE.', - detail_mail_tls_dane_rollover_exp: 'We testen of er een actief schema met tenminste twee DANE TLSA records is om de vervanging van certificaten op je ontvangende mailservers (MX) betrouwbaar te kunnen uitvoeren.

Een dergelijk schema is vooral handig bij het vervangen van je mailserver-certificaten. Het kan voorkomen dat DANE tijdens de vervangingsperiode ongeldig raakt waardoor aan jouw domein gerichte mail niet afgeleverd wordt. Een vervangingsschema voor DANE kan maar hoeft niet continu \'actief\' te zijn.

We adviseren je om één van de twee volgende schema\'s met dubbele DANE TLSA records toe te passen:

  1. Huidige + Volgende ("3 1 1" + "3 1 1"): Publiceer twee "DANE-EE(3) SPKI(1) SHA2-256(1)" records, één voor het huidige en één voor het volgende TLS-certificaat van je mailserver.
  2. Huidige + Uitgever CA ("3 1 1" + "2 1 1"): Publiceer een "DANE-EE(3) SPKI(1) SHA2-256(1)" record voor het huidige TLS-certificaat van je mailserver, en daarnaast een "DANE-TA(2) SPKI(1) SHA2-256(1)" record voor het huidige bovenliggende certificaat van de (niet noodzakelijkerwijs publieke) certificaatautoriteit.

Deze subtest accepteert ook andere combinaties van DANE TLSA records, d.w.z. "3 x x" + "3 x x" of "3 x x" + "2 x x". Andere typen dan de bovengenoemde zijn in de regel gevoeliger voor fouten en minder interoperabel.

Niveau van vereistheid: Optioneel', + detail_mail_tls_dane_rollover_exp: 'We testen of er een actief schema met tenminste twee DANE TLSA records is om de vervanging van certificaten op je ontvangende mailservers (MX) betrouwbaar te kunnen uitvoeren.

Een dergelijk schema is vooral handig bij het vervangen van je mailserver-certificaten. Het kan voorkomen dat DANE tijdens de vervangingsperiode ongeldig raakt waardoor aan jouw domein gerichte mail niet afgeleverd wordt. Een vervangingsschema voor DANE kan maar hoeft niet continu \'actief\' te zijn.

We adviseren je om één van de twee volgende schema\'s met dubbele DANE TLSA records toe te passen:

  1. Huidige + Volgende ("3 1 1" + "3 1 1"): Publiceer twee "DANE-EE(3) SPKI(1) SHA2-256(1)" records, één voor het huidige en één voor het volgende TLS-certificaat van je mailserver.
  2. Huidige + Uitgever CA ("3 1 1" + "2 1 1"): Publiceer een "DANE-EE(3) SPKI(1) SHA2-256(1)" record voor het huidige TLS-certificaat van je mailserver, en daarnaast een "DANE-TA(2) SPKI(1) SHA2-256(1)" record voor het huidige bovenliggende certificaat van de (niet noodzakelijkerwijs publieke) certificaatautoriteit.

Deze subtest accepteert ook andere combinaties van DANE TLSA records, d.w.z. "3 x x" + "3 x x" of "3 x x" + "2 x x". Andere typen dan de bovengenoemde zijn in de regel gevoeliger voor fouten en minder interoperabel.

Merk op dat als een mailserver tegelijkertijd twee certificaten aanbiedt (één gebaseerd op RSA en één gebaseerd op ECDSA), een afzonderlijk DANE TLSA rollover schema wordt aanbevolen voor ieder certificaat. De subtest controleert niet op dit scenario. Als er slechts één DANE TLSA-record is geconfigureerd voor elk certificaat, dan geeft deze subtest een vals-positief resultaat.

Niveau van vereistheid: Optioneel', detail_mail_tls_dane_rollover_label: 'DANE-vervangingsschema', detail_mail_tls_dane_rollover_tech_table: 'Mailserver (MX)|DANE-vervangingsschema', detail_mail_tls_dane_rollover_verdict_bad: 'Tenminste een van je mailserver-domeinen heeft geen actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.', @@ -228,7 +228,7 @@ const internet_nl_messages = { detail_mail_tls_dane_valid_tech_table: 'Mailserver (MX)|DANE TLSA-record geldig', detail_mail_tls_dane_valid_verdict_bad: 'Tenminste één van je mailservers heeft geen geldige DANE-fingerprints. Óf iemand manipuleerde het antwoord van je mailserver, óf je mailserver heeft een ernstige DANE-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor verzendende mailservers die DANE-fingerprints controleren. Neem zo spoedig mogelijk contact op met je mailprovider.', detail_mail_tls_dane_valid_verdict_good: 'Ieder van je mailservers heeft tenminste één geldige DANE-fingerprint. Daardoor kunnen verzendende mailservers die DANE-verificatie ondersteunen, een geauthenticeerde versleutelde transportverbinding met je ontvangende mailserver(s) opzetten.', - detail_mail_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je mailservers (MX), veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', + detail_mail_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je mailservers (MX), veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', detail_mail_tls_fs_params_label: 'Sleuteluitwisselingsparameters', detail_mail_tls_fs_params_tech_table: 'Mailserver (MX)|Getroffen parameters|Veiligheidsniveau', detail_mail_tls_fs_params_verdict_bad: 'Tenminste één van je mailservers ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', @@ -247,7 +247,7 @@ const internet_nl_messages = { detail_mail_tls_ocsp_stapling_verdict_bad: 'OUTDATED TEXT; TEST NOT USED
TODO', detail_mail_tls_ocsp_stapling_verdict_good: 'OUTDATED TEXT; TEST NOT USED
TODO', detail_mail_tls_ocsp_stapling_verdict_ok: 'OUTDATED TEXT; TEST NOT USED
TODO', - detail_mail_tls_renegotiation_client_exp: '

We testen of een verzendende mailserver een renegotiation kan initiëren met jouw ontvangende mailservers (MX).

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', + detail_mail_tls_renegotiation_client_exp: '

We testen of een verzendende mailserver een renegotiation kan initiëren met jouw ontvangende mailservers (MX).

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', detail_mail_tls_renegotiation_client_label: 'Client-initiated renegotiation', detail_mail_tls_renegotiation_client_tech_table: 'Mailserver (MX)|Client-initiated renegotiation', detail_mail_tls_renegotiation_client_verdict_bad: 'Tenminste één van je mailservers staat client-initiated renegotiation toe, wat een negatieve invloed kan hebben op de beschikbaarheid van je mailserver.', @@ -257,18 +257,18 @@ const internet_nl_messages = { detail_mail_tls_renegotiation_secure_tech_table: 'Mailserver (MX)|Secure renegotiation', detail_mail_tls_renegotiation_secure_verdict_bad: 'Tenminste één van je mailservers ondersteunt insecure renegotiation, wat uiteraard niet veilig is.', detail_mail_tls_renegotiation_secure_verdict_good: 'Al je mailservers ondersteunen secure renegotiation.', - detail_mail_tls_starttls_exists_exp: 'We testen of je ontvangende mailservers (MX) ondersteuning bieden voor STARTTLS. Als dat het geval is, dan testen we in de subtesten van deze testcategorie of STARTTLS ook voldoende veilig is geconfigureerd.

Vanwege performance-redenen worden maximaal tien mailservers via of IPv6 of IPv4 getest voor STARTTLS en DANE.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.

Niet ontvangende domeinnaam:

  1. Null MX: Indien je geen mail wenst te ontvangen op je domeinnaam die A/AAAA-records heeft, dan adviseren we om "Null MX" (RFC 7505) te gebruiken. Merk op dat een "Null MX record" niet gecombineerd dient te worden met een gewoon MX-record dat naar een mail-host wijst.

  2. Geen MX: In het geval dat je domein geen A/AAAA-records heeft en je er geen mail op wenst te ontvangen, adviseren we je om helemaal geen MX-record te configureren (dus ook geen "Null MX" record).

  3. Als we een van de twee bovenstaande gevallen ontdekken, zijn de subtesten in de STARTTLS- en DANE-categorie niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtests in de categorieën voor IPv6 en DNSSEC. Andere subtesten van de e-mailtest (bijv. voor DMARC) zijn nog steeds van toepassing.

  4. Merk op dat het hebben van een "Null MX"-record of geen MX-record ook van invloed kan zijn op het verzenden van e-mail, omdat ontvangende servers e-mail kunnen weigeren die een ongeldig retouradres heeft.

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', + detail_mail_tls_starttls_exists_exp: 'We testen of je ontvangende mailservers (MX) ondersteuning bieden voor STARTTLS. Als dat het geval is, dan testen we in de subtesten van deze testcategorie of STARTTLS ook voldoende veilig is geconfigureerd.

Vanwege performance-redenen worden maximaal tien mailservers via of IPv6 of IPv4 getest voor STARTTLS en DANE.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.

Niet ontvangende domeinnaam:

  1. Null MX: Indien je geen mail wenst te ontvangen op je domeinnaam die A/AAAA-records heeft, dan adviseren we om "Null MX" (RFC 7505) te gebruiken. Merk op dat een "Null MX record" niet gecombineerd dient te worden met een gewoon MX-record dat naar een mail-host wijst.

  2. Geen MX: In het geval dat je domein geen A/AAAA-records heeft en je er geen mail op wenst te ontvangen, adviseren we je om helemaal geen MX-record te configureren (dus ook geen "Null MX" record).

  3. Als we een van de twee bovenstaande gevallen ontdekken, zijn de subtesten in de STARTTLS- en DANE-categorie niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtests in de categorieën voor IPv6 en DNSSEC. Andere subtesten van de e-mailtest (bijv. voor DMARC) zijn nog steeds van toepassing.

  4. Merk op dat het hebben van een "Null MX"-record of geen MX-record ook van invloed kan zijn op het verzenden van e-mail, omdat ontvangende servers e-mail kunnen weigeren die een ongeldig retouradres heeft.

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', detail_mail_tls_starttls_exists_label: 'STARTTLS beschikbaar', detail_mail_tls_starttls_exists_tech_table: 'Mailserver (MX)|STARTTLS', detail_mail_tls_starttls_exists_verdict_bad: 'Tenminste één van je mailservers biedt geen STARTTLS aan.', detail_mail_tls_starttls_exists_verdict_good: 'Al je mailservers bieden STARTTLS aan.', detail_mail_tls_starttls_exists_verdict_invalid_null_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', - detail_mail_tls_starttls_exists_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je domeinnaam geen e-mail accepteert door een "Null MX" record te publiceren. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', + detail_mail_tls_starttls_exists_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-records heeft en dat een SPF-record heeft met alleen de term -all. We raden je aan een "Null MX" record in te stellen om expliciet aan te geven dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_tls_starttls_exists_verdict_null_mx: 'Je domeinnaam die A/AAAA-records heeft, geeft met een "Null MX" record duidelijk aan geen e-mail te accepteren. Dat is prima als je geen e-mail wilt ontvangen. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_tls_starttls_exists_verdict_null_mx_with_other_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', detail_mail_tls_starttls_exists_verdict_null_mx_without_a_aaaa: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is.', detail_mail_tls_starttls_exists_verdict_other: 'Tenminste één van je mailservers is onbereikbaar.', - detail_mail_tls_starttls_exists_verdict_other_2: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. ', + detail_mail_tls_starttls_exists_verdict_other_2: 'Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_tls_version_exp: '

We testen of je ontvangende mailservers (MX) alleen veilige TLS-versies ondersteunen.

Een mailserver kan meer dan één TLS-versie ondersteunen.

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B1-1 en tabel 1

Versie

  • Goed: TLS 1.3
  • Voldoende: TLS 1.2
  • Uit te faseren: TLS 1.1 en 1.0
  • Onvoldoende: SSL 3.0, 2.0 en 1.0
', detail_mail_tls_version_label: 'TLS-versie', detail_mail_tls_version_tech_table: 'Mailserver (MX)|TLS-versies|Status', @@ -307,15 +307,18 @@ const internet_nl_messages = { detail_tech_data_http_referrer_policy_recommendation_strict_origin: 'Aanbeveling: \'strict-origin\' zou niet gebruikt moeten worden.', detail_tech_data_http_referrer_policy_recommendation_strict_origin_when_cross_origin: 'Aanbeveling: \'strict-origin-when-cross-origin\' zou niet gebruikt moeten worden.', detail_tech_data_http_referrer_policy_values: 'Gevonden policy: {values}', + detail_tech_data_http_securitytxt_bom_in_file: 'Fout: De Byte Order Mark ("BOM") handtekening moet niet voorkomen aan het begin van de inhoud die gecodeerd moet zijn met UTF-8 in Net-Unicode vorm.', detail_tech_data_http_securitytxt_data_after_sig: 'Fout: Ondertekende security.txt moet geen gegevens bevatten na de handtekening (regel {line_no}).', detail_tech_data_http_securitytxt_empty_key: 'Fout: Veldnaam moet niet leeg zijn (regel {line_no}).', detail_tech_data_http_securitytxt_empty_value: 'Fout: Veldwaarde moet niet leeg zijn (regel {line_no}).', detail_tech_data_http_securitytxt_expired: 'Fout: Datum en tijd in het veld \'Expires\' moeten niet in het verleden liggen (regel {line_no}).', + detail_tech_data_http_securitytxt_invalid_cert: 'Fout: security.txt moet worden geserveerd met een geldig TLS-certificaat.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_invalid_charset: 'Fout: Charset parameter in Content-Type header moet \'utf-8\' zijn indien aanwezig.', detail_tech_data_http_securitytxt_invalid_expiry: 'Fout: Datum en tijd in het veld \'Expires\' moeten worden geformatteerd conform ISO 8601 (regel {line_no}).', - detail_tech_data_http_securitytxt_invalid_lang: 'Fout: De waarde in het veld \'Preferred-Languages\' moet overeenkomen met één of meer taal-tags zoals gedefinieerd in RFC 5646, gescheiden door komma\'s (regel {line_no}).', + detail_tech_data_http_securitytxt_invalid_lang: 'Fout: De waarde in het veld \'Preferred-Languages\' moet overeenkomen met één of meer taal-tags zoals gedefinieerd in RFC 5646, gescheiden door komma\'s (regel {line_no}).', detail_tech_data_http_securitytxt_invalid_line: 'Fout: Regel moet een veldnaam en -waarde bevatten, tenzij de regel leeg is of een commentaar bevat (regel {line_no}).', detail_tech_data_http_securitytxt_invalid_media: 'Fout: Media type in Content-Type header moet \'text/plain\' zijn.', + detail_tech_data_http_securitytxt_invalid_uri_scheme: 'Fout: De toegang tot het bestand security.txt moet het HTTPS-schema gebruiken.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_location: 'Fout: security.txt stond op het top-level pad (verouderde locatie), maar moet geplaatst worden onder het \'/.well-known/\' pad.', detail_tech_data_http_securitytxt_long_expiry: 'Aanbeveling: Datum en tijd in het veld \'Expires\' zouden minder dan een jaar in de toekomst moeten liggen (regel {line_no}).', detail_tech_data_http_securitytxt_multi_expire: 'Fout: Het veld \'Expires\' moet niet meer dan één keer voorkomen.', @@ -342,7 +345,7 @@ const internet_nl_messages = { detail_tech_data_http_securitytxt_retrieved_from: 'security.txt opgehaald van {hostname}.', detail_tech_data_http_securitytxt_signed_format_issue: 'Fout: Ondertekende security.txt moet beginnen met de kop \'-----BEGIN PGP SIGNED MESSAGE-----\'.', detail_tech_data_http_securitytxt_unknown_field: 'Notificatie: security.txt bevat een onbekend veld. Ofwel het gaat om een aangepast veld dat misschien niet algemeen ondersteund wordt, ofwel er is sprake van een typfout in een gestandaardiseerde veldnaam (regel {line_no}).', - detail_tech_data_http_securitytxt_utf8: 'Fout: Inhoud moet utf-8 gecodeerd zijn.', + detail_tech_data_http_securitytxt_utf8: 'Fout: Inhoud moet gecodeerd zijn met UTF-8 in Net-Unicode vorm.', detail_tech_data_insecure: 'insecure', detail_tech_data_insufficient: 'onvoldoende', detail_tech_data_no: 'nee', @@ -356,29 +359,29 @@ const internet_nl_messages = { detail_tech_data_yes: 'ja', detail_verdict_could_not_test: 'Testfout. Graag later opnieuw proberen.', detail_verdict_not_tested: 'Deze subtest is niet uitgevoerd, omdat een bovenliggende test waarvan deze subtest afhankelijk is een negatief testresultaat gaf, of omdat onvoldoende informatie beschikbaar was om de subtest uit te kunnen voeren. ', - detail_web_appsecpriv_http_csp_exp: 'We testen of je webserver een HTTP-header voor Content-Security-Policy (CSP) aanbiedt. Verder controleren we op verschillende veilige CSP-instellingen, hoewel we de effectiviteit van je CSP-configuratie niet uitputtend testen.

CSP beschermt een website tegen aanvallen via content injection zoals cross-site scripting (XSS). Door met CSP een \'allowlist\' met bronnen van goedgekeurde content in te stellen, kan je voorkomen dat browsers die jouw website tonen daarbij kwaadaardige content van aanvallers laden.

We testen op onderstaande regels die gebaseerd zijn op good pracrices voor een veilige CSP-configuratie.

  1. De default-src richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit is om een restrictief default fallback beleid te hebben voor bron-typen die gebruikt worden in je website waarvoor geen specifiek beleid is gedefinieerd. Naast deze waarden kan \'report-sample\' als waarde zijn ingesteld als je wil dat in de \'violation reports\' code-voorbeelden worden opgenomen.
  2. De base-uri richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit limiteert de baseURI zodat de injectie van een gemanipuleerd <base> element wordt geblokkeerd. Dit beperkt de mogelijkheden van aanvallers om de locaties van bronnen (bijv. scripts) die vanaf relatieve URL\'s worden geladen te manipuleren.
  3. De frame-src richtlijn moet zijn gebruikt (hetzij per definitie of via de fallback naar child-src en default-src) en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat inhoud van niet-geautoriseerde locaties wordt geframed of ge-embed in je website (met HTML-elementen zoals <frame> en <iframe>).
  4. De frame-ancestors richtlijn moet zijn gedefinieerd zijn en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat ongeautoriseerde websites je website kunnen framen of embedden (met de HTML-elementen <frame>, <iframe>, <object>, <embed>, of <applet>).
  5. De form-action richtlijn moet zijn gedefinieerd en de waarde ervan moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URLs. Dit limiteert de URL\'s die gebruikt kunnen worden als doel voor formulierverzendingen.
  6. unsafe-inline, unsafe-eval en unsafe-hashes moeten niet gebruikt worden, omdat deze XSS-aanvallen mogelijk maken.
  7. data: moet niet gebruikt worden in default-src, script-src en object-src, omdat dit XSS-aanvallen mogelijk maakt.
  8. Een domein met het http:// schema of een domein zonder schema moet niet worden gebruikt, omdat hiermee bronnen kunnen worden gedownload over een onveilige verbinding. Gebruik in plaats daarvan het https:// schema.
  9. Een wildcard (dat wil zeggen *) voor volledige host-gedeelte van een URL moet niet gebruikt worden in een CSP-richtlijn, omdat daardoor iedere externe bron is toegestaan. Gebruik bovendien niet alleen https: omdat dit gelijk staat aan https://*. Specificeer altijd het hoofddomein (bijvoorbeeld https://scripts.example.nl of https://*.example.nl).
  10. 127.0.0.1 moet niet gebruikt worden in een CSP-richtlijn, omdat dit aanvallen via content injection mogelijk maakt in een gecompromitteerd systeem.

Aanvullende aanbevelingen:

  1. Sta alleen zo specifiek mogelijke domeinen toe in CSP-richtlijnen. Dit wordt in deze subtest voor CSP tot op zekere hoogte automatisch getest.

    • Sta niet alle domeinen onder een TLD (*.nl) of SLD (*.gov.uk) toe, hoewel we hier momenteel niet op testen.
    • 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.

  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.

  3. Gebruik de HTTP-header als mechanisme voor het serveren van je CSP-beleid. Gebruik niet het HTML <meta> 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 <meta>-element.
  4. Gebruik de HTTP-header voor Content-Security-Policy-Report-Only om te experimenteren met je CSP-configuratie door het effect ervan te controleren maar nog niet af te dwingen.
  5. Merk op dat een lege bronnenlijst (d.w.z. een CSP-richtlijn zonder waarde) gelijk is aan een bronnenlijst met none. Merk bovendien op dat als er andere bronnen in een bronnenlijst naast none staan, het attribuut none wordt genegeerd.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_csp_exp: 'We testen of je webserver een HTTP-header voor Content-Security-Policy (CSP) aanbiedt. Verder controleren we op verschillende veilige CSP-instellingen, hoewel we de effectiviteit van je CSP-configuratie niet uitputtend testen.

CSP beschermt een website tegen aanvallen via content injection zoals cross-site scripting (XSS). Door met CSP een \'allowlist\' met bronnen van goedgekeurde content in te stellen, kan je voorkomen dat browsers die jouw website tonen daarbij kwaadaardige content van aanvallers laden.

We testen op onderstaande regels die gebaseerd zijn op good pracrices voor een veilige CSP-configuratie.

  1. De default-src richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit is om een restrictief default fallback beleid te hebben voor bron-typen die gebruikt worden in je website waarvoor geen specifiek beleid is gedefinieerd. Naast deze waarden kan \'report-sample\' als waarde zijn ingesteld als je wil dat in de \'violation reports\' code-voorbeelden worden opgenomen.
  2. De base-uri richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit limiteert de baseURI zodat de injectie van een gemanipuleerd <base> element wordt geblokkeerd. Dit beperkt de mogelijkheden van aanvallers om de locaties van bronnen (bijv. scripts) die vanaf relatieve URL\'s worden geladen te manipuleren.
  3. De frame-src richtlijn moet zijn gebruikt (hetzij per definitie of via de fallback naar child-src en default-src) en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat inhoud van niet-geautoriseerde locaties wordt geframed of ge-embed in je website (met HTML-elementen zoals <frame> en <iframe>).
  4. De frame-ancestors richtlijn moet zijn gedefinieerd zijn en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat ongeautoriseerde websites je website kunnen framen of embedden (met de HTML-elementen <frame>, <iframe>, <object>, <embed>, of <applet>).
  5. De form-action richtlijn moet zijn gedefinieerd en de waarde ervan moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URLs. Dit limiteert de URL\'s die gebruikt kunnen worden als doel voor formulierverzendingen.
  6. unsafe-inline, unsafe-eval en unsafe-hashes moeten niet gebruikt worden, omdat deze XSS-aanvallen mogelijk maken.
  7. data: moet niet gebruikt worden in default-src, script-src en object-src, omdat dit XSS-aanvallen mogelijk maakt.
  8. Een domein met het http:// schema of een domein zonder schema moet niet worden gebruikt, omdat hiermee bronnen kunnen worden gedownload over een onveilige verbinding. Gebruik in plaats daarvan het https:// schema.
  9. Een wildcard (dat wil zeggen *) voor volledige host-gedeelte van een URL moet niet gebruikt worden in een CSP-richtlijn, omdat daardoor iedere externe bron is toegestaan. Gebruik bovendien niet alleen https: omdat dit gelijk staat aan https://*. Specificeer altijd het hoofddomein (bijvoorbeeld https://scripts.example.nl of https://*.example.nl).
  10. 127.0.0.1 moet niet gebruikt worden in een CSP-richtlijn, omdat dit aanvallen via content injection mogelijk maakt in een gecompromitteerd systeem.

Aanvullende aanbevelingen:

  1. Sta alleen zo specifiek mogelijke domeinen toe in CSP-richtlijnen. Dit wordt in deze subtest voor CSP tot op zekere hoogte automatisch getest.

    • Sta niet alle domeinen onder een TLD (*.nl) of SLD (*.gov.uk) toe, hoewel we hier momenteel niet op testen.
    • 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.

  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.

  3. Gebruik de HTTP-header als mechanisme voor het serveren van je CSP-beleid. Gebruik niet het HTML <meta> 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 <meta>-element.
  4. Gebruik de HTTP-header voor Content-Security-Policy-Report-Only om te experimenteren met je CSP-configuratie door het effect ervan te controleren maar nog niet af te dwingen.
  5. Merk op dat een lege bronnenlijst (d.w.z. een CSP-richtlijn zonder waarde) gelijk is aan een bronnenlijst met none. Merk bovendien op dat als er andere bronnen in een bronnenlijst naast none staan, het attribuut none wordt genegeerd.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_csp_label: 'Content-Security-Policy', detail_web_appsecpriv_http_csp_tech_table: 'Webserver-IP-adres|Bevindingen', detail_web_appsecpriv_http_csp_verdict_bad: 'Je webserver biedt geen Content-Security-Policy (CSP) aan, of biedt CSP aan met bepaalde onveilige instellingen .', detail_web_appsecpriv_http_csp_verdict_good: 'Je webserver biedt Content-Security-Policy (CSP) aan en maakt geen gebruik van bepaalde onveilige CSP-instellingen.', - detail_web_appsecpriv_http_referrer_policy_exp: 'We testen of je webserver een HTTP-header voor Referrer-Policy aanbiedt met een voldoende veilige en privacybeschermende policy-waarde. Met deze policy instrueert je webserver browsers of, wat en wanneer referrer-gegevens moeten worden verzonden naar de website waar de gebruiker naartoe navigeert vanaf jouw website. Deze referrer-gegevens worden in de Referer-header door de browser verzonden naar de website waar de gebruiker naartoe navigeert. Deze navigatie hoeft niet per se domeinoverschrijdend te zijn.

De gegevens in de Referer header worden meestal gebruikt voor analytics en logging. Er kunnen echter privacy- en beveiligingsrisico\'s zijn. De gegevens kunnen bijvoorbeeld worden gebruikt voor het volgen van gebruikers en de gegevens kunnen uitlekken naar derden die de verbinding afluisteren. Met de HTTP-header voor Referrer-Policy kun je deze risico\'s beperken door het verzenden van referrer-gegevens te controleren en zelfs te minimaliseren.

We raden je aan om een weloverwogen beslissing te nemen, met privacy- en beveiligingsrisico\'s in gedachten, over het gebruik van een van de policy-waarden uit de eerste twee categorieën hieronder.

1. Goed

  • no-referrer
  • same-origin

Met deze policy-waarden worden er geen gevoelige referrer-gegevens naar derden verzonden.

2. Waarschuwing

  • strict-origin
  • strict-origin-when-cross-origin (default waarde van browsers; zie ook onder aanvullende opmerking 2)

Met deze policy-waarden worden basis referrer-gegevens, die gevoelig kunnen zijn, alleen via beveiligde verbindingen (HTTPS) naar derden verzonden. Daarom zouden deze waarden alleen gebruikt moeten worden als dit noodzakelijk en wettelijk toegestaan is.

3. Slecht

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

Met deze policy-waarden worden alle of alleen basis referrer-gegevens, die gevoelig kunnen zijn, mogelijk via onveilige verbindingen (HTTP) naar derden verzonden. Daarom moeten deze waarden niet worden gebruikt.

Aanvullende opmerkingen:

  1. Om het lekken van gevoelige gegevens via URL\'s te voorkomen, moet u ervoor zorgen dat URL\'s van uw website geen persoonlijke of anderszins gevoelige gegevens bevatten (zoals persoonlijke namen of wachtwoorden).
  2. strict-origin-when-cross-origin is de default policy-waarde wanneer er geen Referrer-Policy is gepubliceerd zoals voorgeschreven in de huidige "Editor\'s Draft" van de Referrer-Policy standaard en deze default wordt gebruikt door alle nieuwste grote browsers. Merk op dat sommige gebruikers nog steeds een ander default waarde geconfigureerd kunnen hebben in hun browser.
  3. Gebruik de HTTP Referrer-Policy header als mechanisme om je referrer policy aan te bieden. We raden niet aan om het HTML <meta> element of het HTML referrerpolicy content attribuut te gebruiken om je referrer policy te publiceren, vooral omdat de secties die deze methoden beschrijven in de standaard gemarkeerd zijn als "niet normatief". Daarom controleren we niet op een referrer policy die wordt aangeboden via de laatste twee methoden.
  4. Merk op dat een webserver meerdere Referrer-Policy headers kan sturen, en dat een Referrer-Policy header meerdere waarden kan bevatten. Onbekende waarden worden genegeerd door de browser en alleen de laatst bekende waarde wordt gebruikt. Dit maakt het mogelijk om toekomstig gestandaardiseerde policy-waarden te gebruiken die nog niet door alle browsers worden ondersteund. Op dit moment ondersteunen echter alle nieuwste grote browsers de bovenstaande policy-waarden onder "Goed" en "Waarschuwing".

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_referrer_policy_exp: 'We testen of je webserver een HTTP-header voor Referrer-Policy aanbiedt met een voldoende veilige en privacybeschermende policy-waarde. Met deze policy instrueert je webserver browsers of, wat en wanneer referrer-gegevens moeten worden verzonden naar de website waar de gebruiker naartoe navigeert vanaf jouw website. Deze referrer-gegevens worden in de Referer-header door de browser verzonden naar de website waar de gebruiker naartoe navigeert. Deze navigatie hoeft niet per se domeinoverschrijdend te zijn.

De gegevens in de Referer header worden meestal gebruikt voor analytics en logging. Er kunnen echter privacy- en beveiligingsrisico\'s zijn. De gegevens kunnen bijvoorbeeld worden gebruikt voor het volgen van gebruikers en de gegevens kunnen uitlekken naar derden die de verbinding afluisteren. Met de HTTP-header voor Referrer-Policy kun je deze risico\'s beperken door het verzenden van referrer-gegevens te controleren en zelfs te minimaliseren.

We raden je aan om een weloverwogen beslissing te nemen, met privacy- en beveiligingsrisico\'s in gedachten, over het gebruik van een van de policy-waarden uit de eerste twee categorieën hieronder.

1. Goed

  • no-referrer
  • same-origin

Met deze policy-waarden worden er geen gevoelige referrer-gegevens naar derden verzonden.

2. Waarschuwing

  • strict-origin
  • strict-origin-when-cross-origin (default waarde van browsers; zie ook onder aanvullende opmerking 2)

Met deze policy-waarden worden basis referrer-gegevens, die gevoelig kunnen zijn, alleen via beveiligde verbindingen (HTTPS) naar derden verzonden. Daarom zouden deze waarden alleen gebruikt moeten worden als dit noodzakelijk en wettelijk toegestaan is.

3. Slecht

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

Met deze policy-waarden worden alle of alleen basis referrer-gegevens, die gevoelig kunnen zijn, mogelijk via onveilige verbindingen (HTTP) naar derden verzonden. Daarom moeten deze waarden niet worden gebruikt.

Aanvullende opmerkingen:

  1. Om het lekken van gevoelige gegevens via URL\'s te voorkomen, moet u ervoor zorgen dat URL\'s van uw website geen persoonlijke of anderszins gevoelige gegevens bevatten (zoals persoonlijke namen of wachtwoorden).
  2. strict-origin-when-cross-origin is de default policy-waarde wanneer er geen Referrer-Policy is gepubliceerd zoals voorgeschreven in de huidige "Editor\'s Draft" van de Referrer-Policy standaard en deze default wordt gebruikt door alle nieuwste grote browsers. Merk op dat sommige gebruikers nog steeds een ander default waarde geconfigureerd kunnen hebben in hun browser.
  3. Gebruik de HTTP Referrer-Policy header als mechanisme om je referrer policy aan te bieden. We raden niet aan om het HTML <meta> element of het HTML referrerpolicy content attribuut te gebruiken om je referrer policy te publiceren, vooral omdat de secties die deze methoden beschrijven in de standaard gemarkeerd zijn als "niet normatief". Daarom controleren we niet op een referrer policy die wordt aangeboden via de laatste twee methoden.
  4. Merk op dat een webserver meerdere Referrer-Policy headers kan sturen, en dat een Referrer-Policy header meerdere waarden kan bevatten. Onbekende waarden worden genegeerd door de browser en alleen de laatst bekende waarde wordt gebruikt. Dit maakt het mogelijk om toekomstig gestandaardiseerde policy-waarden te gebruiken die nog niet door alle browsers worden ondersteund. Op dit moment ondersteunen echter alle nieuwste grote browsers de bovenstaande policy-waarden onder "Goed" en "Waarschuwing".

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_referrer_policy_label: 'Referrer-Policy', detail_web_appsecpriv_http_referrer_policy_tech_table: 'Webserver-IP-adres|Bevindingen', detail_web_appsecpriv_http_referrer_policy_verdict_bad: 'Je webserver biedt een Referrer-Policy aan met een policy-waarde die niet voldoende veilig en privacybeschermend is.', detail_web_appsecpriv_http_referrer_policy_verdict_good: 'Je webserver biedt een Referrer-Policy aan met een policy-waarde die voldoende veilig en privacybeschermend is.', detail_web_appsecpriv_http_referrer_policy_verdict_recommendations: 'Je webserver biedt ofwel geen Referrer-Policy aan en vertrouwt dus op de standaard browserpolicy, óf je webserver biedt een Referrer-Policy aan met een policy-waarde die met terughoudendheid moet worden gebruikt vanwege de mogelijke impact op beveiliging en privacy.', - detail_web_appsecpriv_http_securitytxt_exp: 'We testen of je webserver een security.txt bestand op de juiste locatie aanbiedt, of het opgehaald kan worden, en of de inhoud ervan syntactisch geldig is.

security.txt is een tekstbestand met contactinformatie dat je op je webserver plaatst. Beveiligingsonderzoekers kunnen deze informatie gebruiken om direct contact met de juiste afdeling of persoon binnen je organisatie op te nemen over kwetsbaarheden die zij in je website of IT-systemen hebben gevonden. Dit kan het verhelpen van gevonden kwetsbaarheden versnellen, waardoor kwaadwillenden minder kans hebben om er misbruik van te maken.

Het formaat van het bestand is bedoeld om machinaal en menselijk leesbaar te zijn. De contactinformatie kan een e-mailadres, een telefoonnummer en/of een webpagina (bijvoorbeeld een webformulier) zijn. Merk op dat gepubliceerde contactinformatie openbaar is en ook kan worden misbruikt, bijvoorbeeld om spam te sturen naar een gepubliceerd e-mailadres.

Naast contactinformatie moet het security.txt bestand ook een vervaldatum bevatten. Om te voorkomen dat de informatie niet meer actueel is, wordt aanbevolen een vervaldatum op te nemen die minder dan een jaar in de toekomst ligt. Het is optioneel om ook andere relevante informatie voor beveiligingsonderzoekers op te nemen, zoals een link naar je beleid voor het omgaan met meldingen van beveiligingskwetsbaarheden (meestal Coordinated Vulnerability Disclosure policy genoemd).

Het wordt aanbevolen om het security.txt bestand te ondertekenen met PGP en daarbij de web URI waarop het bestand staat in een Canonical veld op te nemen. We controleren of het security.txt bestand ondertekend is. We valideren de handtekening echter niet, omdat er helaas geen gestandaardiseerde plaats is om een publieke PGP-sleutel (die nodig is voor handtekeningvalidatie) op te halen.

Als een of meer Canonical velden aanwezig zijn, moet de web URI van het security.txt bestand in een Canonical veld staan. Bij het redirecten naar een security.txt bestand moet ten minste de laatste URI van de redirect-keten in een Canonical veld worden vermeld.

Het bestand moet gepubliceerd worden onder het /.well-known/ pad. Merk op dat het plaatsen onder het top-level pad verouderd is. Elk web(sub)domein dient zijn eigen security.txt bestand te hebben. Een voorbeeldbestand is te vinden op https://example.nl/.well-known/security.txt.

Met een redirect doorverwijzen naar een security.txt op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale security.txt.

Met een redirect doorverwijzen naar een security.txt op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale security.txt.

Merk op dat security.txt bestanden normaal gesproken slechts enkele kilobytes groot zijn. We lezen en evalueren daarom maximaal de eerste 100 kB van een gevonden security.txt bestand.

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_securitytxt_exp: 'We testen of je webserver een security.txt bestand op de juiste locatie aanbiedt, of het opgehaald kan worden, en of de inhoud ervan syntactisch geldig is.

security.txt is een tekstbestand met contactinformatie dat je op je webserver plaatst. Beveiligingsonderzoekers kunnen deze informatie gebruiken om direct contact met de juiste afdeling of persoon binnen je organisatie op te nemen over kwetsbaarheden die zij in je website of IT-systemen hebben gevonden. Dit kan het verhelpen van gevonden kwetsbaarheden versnellen, waardoor kwaadwillenden minder kans hebben om er misbruik van te maken.

Het formaat van het bestand is bedoeld om machinaal en menselijk leesbaar te zijn. De contactinformatie kan een e-mailadres, een telefoonnummer en/of een webpagina (bijvoorbeeld een webformulier) zijn. Merk op dat gepubliceerde contactinformatie openbaar is en ook kan worden misbruikt, bijvoorbeeld om spam te sturen naar een gepubliceerd e-mailadres.

Naast contactinformatie moet het security.txt bestand ook een vervaldatum bevatten. Om te voorkomen dat de informatie niet meer actueel is, wordt aanbevolen een vervaldatum op te nemen die minder dan een jaar in de toekomst ligt. Het is optioneel om ook andere relevante informatie voor beveiligingsonderzoekers op te nemen, zoals een link naar je beleid voor het omgaan met meldingen van beveiligingskwetsbaarheden (meestal Coordinated Vulnerability Disclosure policy genoemd).

Het wordt aanbevolen om het security.txt bestand te ondertekenen met PGP en daarbij de web URI waarop het bestand staat in een Canonical veld op te nemen. We controleren of het security.txt bestand ondertekend is. We valideren de handtekening echter niet, omdat er helaas geen gestandaardiseerde plaats is om een publieke PGP-sleutel (die nodig is voor handtekeningvalidatie) op te halen.

Als een of meer Canonical velden aanwezig zijn, moet de web URI van het security.txt bestand in een Canonical veld staan. Bij het redirecten naar een security.txt bestand moet ten minste de laatste URI van de redirect-keten in een Canonical veld worden vermeld.

Het bestand moet gepubliceerd worden onder het /.well-known/ pad. Merk op dat het plaatsen onder het top-level pad verouderd is. Elk web(sub)domein dient zijn eigen security.txt bestand te hebben. Een voorbeeldbestand is te vinden op https://example.nl/.well-known/security.txt.

Met een redirect doorverwijzen naar een security.txt op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale security.txt.

Merk op dat security.txt bestanden normaal gesproken slechts enkele kilobytes groot zijn. We lezen en evalueren daarom maximaal de eerste 100 kB van een gevonden security.txt bestand.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_securitytxt_label: 'security.txt', detail_web_appsecpriv_http_securitytxt_tech_table: 'Webserver-IP-adres|Bevindingen', detail_web_appsecpriv_http_securitytxt_verdict_bad: 'Je webserver biedt geen security.txt-bestand op de juiste plaats aan, het kon niet worden opgehaald, of de inhoud ervan is syntactisch niet geldig.', detail_web_appsecpriv_http_securitytxt_verdict_good: 'Je webserver biedt een security.txt-bestand op de juiste plaats aan en de inhoud ervan is syntactisch geldig.', detail_web_appsecpriv_http_securitytxt_verdict_recommendations: 'Je webserver biedt een security.txt-bestand op de juiste plaats aan en de inhoud ervan is syntactisch geldig. Echter, er zijn een of meer aanbevelingen voor verbetering.', - detail_web_appsecpriv_http_x_content_type_exp: 'We testen of je webserver een HTTP header voor X-Content-Type-Options aanbiedt. Met deze HTTP header kan je webbrowsers laten weten dat zij geen \'MIME type sniffing\' mogen uitvoeren en altijd het Content-Type zoals gedeclareerd door jouw webserver moeten volgen. De enige geldige waarde voor deze HTTP header is nosniff. Indien actief, dan zal een browser verzoeken voor style en script blokkeren als deze geen corresponderende Content-Type (dat wil zeggen text/css of een \'Javascript MIME type\' zoals application/javascript) hebben.

\'MIME type sniffing\' is een techniek waarbij de browser de inhoud van een bestand scant om te bepalen wat het formaat van het bestand is, ongeacht het door de webserver gedeclareerde Content-Type. Deze techniek is kwetsbaar voor de zogenaamde \'MIME confusion attack\' waarbij de aanvaller de content van een bestand zodanig manipuleert dat de browser deze behandelt als een andere Content-Type, zoals een executeerbaar bestand.

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_x_content_type_exp: 'We testen of je webserver een HTTP header voor X-Content-Type-Options aanbiedt. Met deze HTTP header kan je webbrowsers laten weten dat zij geen \'MIME type sniffing\' mogen uitvoeren en altijd het Content-Type zoals gedeclareerd door jouw webserver moeten volgen. De enige geldige waarde voor deze HTTP header is nosniff. Indien actief, dan zal een browser verzoeken voor style en script blokkeren als deze geen corresponderende Content-Type (dat wil zeggen text/css of een \'Javascript MIME type\' zoals application/javascript) hebben.

\'MIME type sniffing\' is een techniek waarbij de browser de inhoud van een bestand scant om te bepalen wat het formaat van het bestand is, ongeacht het door de webserver gedeclareerde Content-Type. Deze techniek is kwetsbaar voor de zogenaamde \'MIME confusion attack\' waarbij de aanvaller de content van een bestand zodanig manipuleert dat de browser deze behandelt als een andere Content-Type, zoals een executeerbaar bestand.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_x_content_type_label: 'X-Content-Type-Options', detail_web_appsecpriv_http_x_content_type_tech_table: 'Webserver-IP-adres|X-Content-Type-Options waarde', detail_web_appsecpriv_http_x_content_type_verdict_bad: 'Je webserver biedt geen X-Content-Type-Options aan.', detail_web_appsecpriv_http_x_content_type_verdict_good: 'Je webserver biedt X-Content-Type-Options aan.', - detail_web_appsecpriv_http_x_frame_exp: 'We testen of je webserver een HTTP header voor X-Frame-Options aanbiedt die een voldoende veilige instelling heeft. Met deze HTTP header kan je webbrowsers laten weten of het toegestaan is om jouw website te \'framen\'. Het voorkomen van \'framen\' beschermt bezoekers tegen aanvallen zoals clickjacking. We beschouwen de volgende waarden als voldoende veilig:

  • DENY (\'framen\' niet toegestaan); of
  • SAMEORIGIN (\'framen\' alleen door je eigen website toegestaan).

Alhoewel de waarde ALLOW-FROM (alleen genoemde websites mogen jouw website \'framen\') onderdeel is van de specificatie voorX-Frame-Options (RFC 7034), wordt deze niet ondersteund door moderne webbrowsers. Om die reden beschouwen we deze waarde niet als voldoende veilig.

Merk op dat Content-Security-Policy (CSP) via frame-ancestors vergelijkbare bescherming en daarnaast nog veel meer biedt voor bezoekers met moderne webbrowsers. Maar X-Frame-Options kan nog steeds bescherming bieden aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-Frame-Options waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Optioneel ', + detail_web_appsecpriv_http_x_frame_exp: 'We testen of je webserver een HTTP header voor X-Frame-Options aanbiedt die een voldoende veilige instelling heeft. Met deze HTTP header kan je webbrowsers laten weten of het toegestaan is om jouw website te \'framen\'. Het voorkomen van \'framen\' beschermt bezoekers tegen aanvallen zoals clickjacking. We beschouwen de volgende waarden als voldoende veilig:

  • DENY (\'framen\' niet toegestaan); of
  • SAMEORIGIN (\'framen\' alleen door je eigen website toegestaan).

Alhoewel de waarde ALLOW-FROM (alleen genoemde websites mogen jouw website \'framen\') onderdeel is van de specificatie voorX-Frame-Options (RFC 7034), wordt deze niet ondersteund door moderne webbrowsers. Om die reden beschouwen we deze waarde niet als voldoende veilig.

Merk op dat Content-Security-Policy (CSP) via frame-ancestors vergelijkbare bescherming en daarnaast nog veel meer biedt voor bezoekers met moderne webbrowsers. Maar X-Frame-Options kan nog steeds bescherming bieden aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-Frame-Options waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Optioneel ', detail_web_appsecpriv_http_x_frame_label: 'X-Frame-Options', detail_web_appsecpriv_http_x_frame_tech_table: 'Webserver-IP-adres|X-Frame-Options waarde', detail_web_appsecpriv_http_x_frame_verdict_bad: 'Je webserver biedt geen veilig ingestelde X-Frame-Options aan.', @@ -406,29 +409,29 @@ const internet_nl_messages = { detail_web_ipv6_web_aaaa_tech_table: 'Webserver|IPv6-adres|IPv4-adres', detail_web_ipv6_web_aaaa_verdict_bad: 'Geen van je webservers heeft een IPv6-adres.', detail_web_ipv6_web_aaaa_verdict_good: 'Tenminste één van je webservers heeft een IPv6-adres.', - detail_web_ipv6_web_ipv46_exp: 'We vergelijken het antwoord en de inhoud die we van je webserver over IPv6 ontvangen met die over IPv4.

We controleren:

  1. of HTTP (poort 80) en/of HTTPS (poort 443) via IPv4 ook beschikbaar zijn via IPv6;
  2. of HTTP-headers (zoals een redirect-header) via IPv4 ook via IPv6 worden ontvangen;
  3. of HTML-inhoud via IPv4 hetzelfde is via IPv6. Na het strippen van eventuele nonces doen we een vergelijking van de ontvangen inhoud. Het verschil in inhoud mag niet groter zijn dan 10% om voor deze subtest te slagen. De drempel zorgt ervoor dat kleine verschillen (bijvoorbeeld als gevolg van veranderende advertenties) niet leiden tot het falen van deze subtest. Een waargenomen verschil kan bedoeld zijn of te maken hebben met een meetfout. Daarom wordt in dit geval een waarschuwing gegeven en telt dit niet mee in de score.

Als er meerdere IPv6- en IPv4-adressen zijn, kiezen we één IPv6-adres en één IPv4-adres om de subtest uit te voeren. Als er alleen een IPv6-adres en geen IPv4-adres beschikbaar is, dan is de subtest niet van toepassing omdat er geen vergelijking kan worden gemaakt.', + detail_web_ipv6_web_ipv46_exp: 'We vergelijken de beschikbare poorten en aangeboden headers en inhoud van je webserver via IPv6 met die via IPv4.

We controleren of:

  1. dezelfde poorten, dat wil zeggen HTTP (poort 80) en/of HTTPS (poort 443), beschikbaar zijn via zowel IPv6 als IPv4;
  2. dezelfde HTTP-headers worden aangeboden via zowel IPv6 als IPv4. Dit omvat HTTP response codes, zoals \'successful responses\' (200 – 299) en \'redirection messages\' (300 – 399). Bij een \'client error response\' (400 - 499) of een \'server error response\' (500 - 599) wordt een waarschuwing zonder score-impact gegeven, omdat een dergelijke HTTP response code kan wijzen op een configuratieprobleem;
  3. dezelfde HTML-inhoud wordt aangeboden via zowel IPv6 als IPv4. We doen dit door de ontvangen inhoud te vergelijken na het strippen van eventuele nonces. Het verschil in inhoud mag niet groter zijn dan 10% om te slagen voor deze subtest. Deze drempel zorgt ervoor dat kleine niet-problematische verschillen (bijvoorbeeld door veranderende advertenties) niet direct leiden tot een onvoldoende voor deze subtest. Een waargenomen verschil kan nog steeds bedoeld zijn of te maken hebben met een meetfout. Daarom leidt dit deel van de subtest in geval van falen alleen tot een waarschuwing zonder score-impact.

Aanvullende opmerkingen:- Als er meerdere IPv6- en IPv4-adressen zijn, dan kiezen we één IPv6-adres en één IPv4-adres om de subtest uit te voeren.- Als er alleen een IPv6-adres en geen IPv4-adres (of omgekeerd) beschikbaar is, dan is de subtest niet van toepassing omdat er geen vergelijking kan worden gemaakt.- Deze subtest volgt redirects en controleert ook alle onderliggende URL\'s.', detail_web_ipv6_web_ipv46_label: 'Gelijke website op IPv6 en IPv4', - detail_web_ipv6_web_ipv46_verdict_bad: 'Beschikbare poorten of aangeboden headers van je website over IPv4 zijn niet hetzelfde over IPv6.', - detail_web_ipv6_web_ipv46_verdict_good: 'Je website op IPv6 lijkt gelijk aan je website op IPv4.', - detail_web_ipv6_web_ipv46_verdict_notice: 'De HTML-inhoud van je website over IPv4 is niet hetzelfde over IPv6. ', - detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Je website op IPv6 lijkt gelijk aan je website op IPv4, maar de HTTP response code is 4xx of 5xx. Dit kan wijzen op een configuratiefout.', + detail_web_ipv6_web_ipv46_verdict_bad: 'Beschikbare poorten of aangeboden headers van je website via IPv4 zijn niet hetzelfde via IPv6.', + detail_web_ipv6_web_ipv46_verdict_good: 'Je website via IPv6 lijkt identiek via IPv4.', + detail_web_ipv6_web_ipv46_verdict_notice: 'De HTML-inhoud van je website via IPv4 is niet hetzelfde via IPv6. ', + detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Je website via IPv6 lijkt identiek via IPv4, maar de HTTP response code is 4xx of 5xx. Dit kan wijzen op een configuratiefout.', detail_web_ipv6_web_reach_exp: 'We testen of we je webserver(s) kunnen bereiken via IPv6 op alle beschikbare poorten (80 en/of 443). We testen alle IPv6-adressen die we ontvangen van je nameservers. Een deelscore wordt gegeven als niet alle IPv6-adressen bereikbaar zijn. Als een IPv6-adres (syntactisch) ongeldig is, dan beschouwen we dat als onbereikbaar.', detail_web_ipv6_web_reach_label: 'IPv6-bereikbaarheid van webserver', detail_web_ipv6_web_reach_tech_table: 'Webserver|Onbereikbaar IPv6-adres', detail_web_ipv6_web_reach_verdict_bad: 'Tenminste één van jouw webservers met een IPv6-adres, is niet bereikbaar via IPv6.', detail_web_ipv6_web_reach_verdict_good: 'Al je webservers met een IPv6-adres zijn bereikbaar via IPv6.', - detail_web_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je webserver.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_web_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je webserver.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_web_rpki_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_web_rpki_exists_tech_table: 'Webserver|IP-adres|RPKI Route Origin Authorization', detail_web_rpki_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van je webserver is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_rpki_exists_verdict_good: 'Voor alle IP-adressen van je webserver is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_rpki_exists_verdict_no_addresses: 'Je domein bevat geen IP-adressen van webservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_web_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je webserver Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

Niveau van vereistheid: Aanbevolen', + detail_web_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je webserver Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_web_rpki_valid_label: 'Geldigheid van route-aankondiging', detail_web_rpki_valid_tech_table: 'Webserver|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_web_rpki_valid_verdict_bad: 'Ten minste één IP-adres van je webserver heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorization (ROA) gepubliceerd voor de route-aankondiging van ieder van de desbetreffende IP-adressen.', detail_web_rpki_valid_verdict_good: 'Alle IP-adressen van je webserver hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_web_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je webserver heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je webhoster. Bij een interne fout moet je webhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_web_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je webserver heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je webhoster. Bij een interne fout moet je webhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_web_rpki_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', detail_web_tls_cert_hostmatch_exp: 'We testen of de domeinnaam van je website overeenkomt met de domeinnaam op het certificaat.

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B3-1.', detail_web_tls_cert_hostmatch_label: 'Domeinnaam op certificaat', @@ -451,7 +454,7 @@ const internet_nl_messages = { detail_web_tls_cert_trust_tech_table: 'Webserver-IP-adres|Onvertrouwde certificaatketen', detail_web_tls_cert_trust_verdict_bad: 'De vertrouwensketen van je websitecertificaat is niet compleet en/of niet ondertekend door een vertrouwde certificaatautoriteit.', detail_web_tls_cert_trust_verdict_good: 'De vertrouwensketen van je websitecertificaat is compleet en ondertekend door een vertrouwde certificaatautoriteit.', - detail_web_tls_cipher_order_exp: 'We testen of je webserver zijn eigen cipher-voorkeur afdwingt (\'I\'), en ciphers aanbiedt conform de voorgeschreven volgorde (\'II\').

Als je webserver alleen \'Goede\' ciphers ondersteunt, dan is deze subtest niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

I. Server afgedwongen cipher-volgorde: De webserver dwingt zijn cipher-voorkeur af tijdens de onderhandeling met een webbrowser, en accepteert geen voorkeur van de webbrowser;

II. Voorgeschreven volgorde: Ciphers worden aangeboden door de webserver in overeenstemming met de voorgeschreven volgorde waarbij Goede boven Voldoende boven Uit te faseren ciphers worden geprefereerd.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', + detail_web_tls_cipher_order_exp: 'We testen of je webserver zijn eigen cipher-voorkeur afdwingt (\'I\'), en ciphers aanbiedt conform de voorgeschreven volgorde (\'II\').

Als je webserver alleen \'Goede\' ciphers ondersteunt, dan is deze subtest niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

I. Server afgedwongen cipher-voorkeur: De webserver dwingt zijn cipher-voorkeur af tijdens de onderhandeling met een webbrowser, en accepteert geen voorkeur van de webbrowser;

II. Voorgeschreven volgorde: Ciphers worden aangeboden door de webserver in overeenstemming met de voorgeschreven volgorde waarbij Goede boven Voldoende boven Uit te faseren ciphers worden geprefereerd.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', detail_web_tls_cipher_order_label: 'Cipher-volgorde', detail_web_tls_cipher_order_tech_table: 'Webserver IP-adres|Eerst gevonden getroffen cipher-paren|Overtreden regel # (\'II-B\')', detail_web_tls_cipher_order_verdict_bad: 'Je webserver dwingt niet zijn eigen cipher-voorkeur af (\'I\').', @@ -486,7 +489,7 @@ const internet_nl_messages = { detail_web_tls_dane_valid_tech_table: 'Webserver-IP-adres|DANE TLSA-record geldig', detail_web_tls_dane_valid_verdict_bad: 'De DANE-fingerprint op je domeinnaam is niet geldig voor je websitecertificaat. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DANE-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DANE-fingerprints controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder en/of hostingprovider.', detail_web_tls_dane_valid_verdict_good: 'De DANE-fingerprint op je domeinnaam is geldig voor je websitecertificaat.', - detail_web_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je webserver, veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', + detail_web_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je webserver, veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', detail_web_tls_fs_params_label: 'Sleuteluitwisselingsparameters', detail_web_tls_fs_params_tech_table: 'Webserver-IP-adres|Getroffen parameters|Status', detail_web_tls_fs_params_verdict_bad: 'Je webserver ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', @@ -498,7 +501,7 @@ const internet_nl_messages = { detail_web_tls_http_compression_tech_table: 'Webserver-IP-adres|HTTP-compressie', detail_web_tls_http_compression_verdict_bad: 'Je webserver ondersteunt HTTP-compressie, wat een beveiligingsrisico kan vormen.', detail_web_tls_http_compression_verdict_good: 'Je webserver ondersteunt geen HTTP-compressie.', - detail_web_tls_https_exists_exp: 'We testen of je website bereikbaar is via HTTPS.

Als dat het geval is, dan testen we in de navolgende subtesten of HTTPS ook veilig is geconfigureerd conform de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\'.

HTTPS garandeert de vertrouwelijkheid en integriteit van uitgewisselde informatie. Omdat het van de situatie afhangt hoe (privacy-)gevoelig en waardevol informatie is, een bezoeker van je website bepaalt 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. Let op: vanwege performance-redenen worden de testen in het HTTPS-testonderdeel alleen uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres.', + detail_web_tls_https_exists_exp: 'We testen of je website bereikbaar is via HTTPS.

Als dat het geval is, dan testen we in de navolgende subtesten of HTTPS ook veilig is geconfigureerd conform de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\'.

HTTPS garandeert de vertrouwelijkheid en integriteit van uitgewisselde informatie. Omdat het van de situatie afhangt hoe (privacy-)gevoelig en waardevol informatie is, een bezoeker van je website bepaalt 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.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligde verbinding (HTTPS)\' alleen uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres.', detail_web_tls_https_exists_label: 'HTTPS beschikbaar', detail_web_tls_https_exists_tech_table: 'Webserver-IP-adres|HTTPS aanwezig', detail_web_tls_https_exists_verdict_bad: 'Je website biedt geen HTTPS aan.', @@ -529,7 +532,7 @@ const internet_nl_messages = { detail_web_tls_ocsp_stapling_verdict_bad: 'Je webserver ondersteunt OCSP maar de data in het antwoord is niet valide.', detail_web_tls_ocsp_stapling_verdict_good: 'Je webserver ondersteunt OCSP en de data in het antwoord is valide.', detail_web_tls_ocsp_stapling_verdict_ok: 'Je webserver ondersteunt OCSP niet.', - detail_web_tls_renegotiation_client_exp: '

We testen of een client (doorgaans een webbrowser) een renegotiation kan initiëren met jouw webserver.

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

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', + detail_web_tls_renegotiation_client_exp: '

We testen of een client (doorgaans een webbrowser) een renegotiation kan initiëren met jouw webserver.

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

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', detail_web_tls_renegotiation_client_label: 'Client-initiated renegotiation', detail_web_tls_renegotiation_client_tech_table: 'Webserver-IP-adres|Client-initiated renegotiation', detail_web_tls_renegotiation_client_verdict_bad: 'Je webserver staat client-initiated renegotiation toe, wat een negatieve invloed kan hebben op de beschikbaarheid van je website.', @@ -562,29 +565,31 @@ const internet_nl_messages = { detail_web_mail_ipv6_ns_reach_tech_table: 'Nameserver|Onbereikbaar IPv6-adres', detail_web_mail_ipv6_ns_reach_verdict_bad: 'Niet alle nameservers die een IPv6-adres hebben zijn bereikbaar via IPv6.', detail_web_mail_ipv6_ns_reach_verdict_good: 'Alle nameservers die een IPv6-adres hebben zijn bereikbaar via IPv6.', - detail_web_mail_rpki_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je domein.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_web_mail_rpki_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je domein.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_web_mail_rpki_ns_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_web_mail_rpki_ns_exists_tech_table: 'Nameserver|IP-adres|RPKI Route Origin Authorization', detail_web_mail_rpki_ns_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van je nameservers is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_mail_rpki_ns_exists_verdict_good: 'Voor alle IP-adressen van je nameservers is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_mail_rpki_ns_exists_verdict_no_addresses: 'Je domein bevat geen nameservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_web_mail_rpki_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je domein Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

Let op: De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Niveau van vereistheid: Aanbevolen', + detail_web_mail_rpki_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je domein Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_web_mail_rpki_ns_valid_label: 'Geldigheid van route-aankondiging', detail_web_mail_rpki_ns_valid_tech_table: 'Nameserver|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_web_mail_rpki_ns_valid_verdict_bad: 'Ten minste één IP-adres van je nameservers heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorisation (ROA) gepubliceerd voor zijn route-aankondiging.', detail_web_mail_rpki_ns_valid_verdict_good: 'Alle IP-adressen van je nameservers hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_web_mail_rpki_ns_valid_verdict_invalid: 'Tenminste één IP-adres van je nameservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je nameserver-hoster. Bij een interne fout moet je nameserver-hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_web_mail_rpki_ns_valid_verdict_invalid: 'Tenminste één IP-adres van je nameservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je nameserver-hoster. Bij een interne fout moet je nameserver-hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_web_mail_rpki_ns_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', domain_pagetitle: 'Websitetest:', domain_title: 'Websitetest: {{prettyaddr}} ', domain_tweetmessage: 'De%20website%20{{report.domain}}%20scoort%20{{score}}%25%20in%20de%20websitetest%20van%20%40Internet_nl%3A', faqs_appsecpriv_title: 'Beveiligingsopties', faqs_badges_title: 'Gebruik van 100%-badges', + faqs_batch_and_dashboard_title: 'Batch API en webgebaseerd dashboard', faqs_dnssec_title: 'Domeinnaamhandtekening (DNSSEC)', faqs_halloffame_title: 'Criteria voor \'Hall of Fame voor Hosters\'', faqs_https_title: 'Beveiligde websiteverbinding (HTTPS)', faqs_ipv6_title: 'Modern adres (IPv6)', faqs_mailauth_title: 'Protectie tegen e-mailphishing (DMARC, DKIM en SPF)', + faqs_measurements_title: 'Metingen met Internet.nl', faqs_report_score_title: 'Norm en score', faqs_report_subtest_bad: 'Slecht: gezakt voor VEREISTE subtest ⇒ nulscore', faqs_report_subtest_error: 'Testfout: uitvoeringsfout tijdens testen ⇒ nulscore', @@ -745,7 +750,9 @@ const internet_nl_messages = { test_mailipv6_title: 'Bereikbaar via modern internetadres?', test_mailipv6_warning_description: 'Helaas! Je mailserver is niet bereikbaar voor verzenders met moderne adressen (IPv6), of er is verbetering mogelijk. Daardoor maakt je mailserver nog geen onderdeel uit van het moderne internet. Vraag je e-mailprovider om IPv6 volledig aan te zetten.', test_mailipv6_warning_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_mailrpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende mailserver(s) en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je mailhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + test_mailrpki_error_description: 'De test kan nog niet worden uitgevoerd. Probeer het later nog eens. Sorry voor het ongemak.', + test_mailrpki_error_summary: 'Test niet klaar om uit te voeren (RPKI)', + test_mailrpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende mailserver(s) en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je mailhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', test_mailrpki_failed_summary: 'Ongeautoriseerde route-aankondiging (RPKI)', test_mailrpki_info_description: 'Ter informatie: Je domein bevat geen nameservers en dus ook geen ontvangende mailserver(s). Er zijn geen routeerbare IP-adressen die kunnen worden getest (RPKI).', test_mailrpki_info_summary: 'Geen routeerbare IP-adressen gevonden (RPKI)', @@ -753,7 +760,7 @@ const internet_nl_messages = { test_mailrpki_passed_description: 'Goed gedaan! Alle IP-adressen van je ontvangende mailserver(s) en bijbehorende nameservers hebben een route-aankondiging die wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Daardoor is het e-mailtransport tussen verzendende mailservers met ingeschakelde route-validatie en jouw ontvangende mailserver(s) beter beschermd tegen diverse onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers.', test_mailrpki_passed_summary: 'Geautoriseerde route-aankondiging (RPKI)', test_mailrpki_title: 'Route-autorisatie?', - test_mailrpki_warning_description: 'Waarschuwing! Ten minste één van de IP-adressen van je mailserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Daardoor is het e-mailtransport tussen verzendende mailservers met ingeschakelde route-validatie en jouw ontvangende mailserver(s) niet (volledig) beschermd tegen diverse onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je mailhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', + test_mailrpki_warning_description: 'Helaas! Ten minste één van de IP-adressen van je mailserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Daardoor is het e-mailtransport tussen verzendende mailservers met ingeschakelde route-validatie en jouw ontvangende mailserver(s) niet (volledig) beschermd tegen diverse onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je mailhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', test_mailrpki_warning_summary: 'Route-autorisatie niet gepubliceerd (RPKI)', test_mailtls_failed_description: 'Helaas! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) geen of een onvoldoende beveiligde verbinding opzetten. Passieve en/of actieve aanvallers kunnen daardoor e-mails onderweg naar jou lezen. Vraag je mailprovider om STARTTLS en DANE te activeren, en veilig in te stellen. ', test_mailtls_failed_summary: 'Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)', @@ -762,9 +769,9 @@ const internet_nl_messages = { test_mailtls_invalid_null_mx_description: 'Waarschuwing: Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', test_mailtls_invalid_null_mx_summary: 'Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)', test_mailtls_label: 'Beveiligde mailserver-verbinding (STARTTLS en DANE)', - test_mailtls_no_mx_description: 'Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. Merk op dat je in dit geval geen \'Null MX\' record nodig hebt. Door je configuratie zijn de subtesten in de categorieën voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorieën voor IPv6 en DNSSEC.', + test_mailtls_no_mx_description: 'Ter informatie: Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', test_mailtls_no_mx_summary: 'Goed geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)', - test_mailtls_no_null_mx_description: 'Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die A/AAAA records heeft. We raden je aan om expliciet aan te geven dat je domeinnaam geen e-mail accepteert door een "Null MX" record te configureren. Door je huidige configuratie zijn de subtesten in de categorieën voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorieën voor IPv6 en DNSSEC.', + test_mailtls_no_null_mx_description: 'Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-records heeft en dat een SPF-record heeft met alleen de term -all. We raden je aan een "Null MX" record in te stellen om expliciet aan te geven dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', test_mailtls_no_null_mx_summary: 'Niet expliciet geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)', test_mailtls_null_mx_description: 'Ter informatie: Je domeinnaam die A/AAAA-records heeft, geeft duidelijk aan dat het geen e-mail accepteert door een "Null MX" record te adverteren. Dat is prima als je geen e-mail wilt ontvangen. Je configuratie maakt de subtesten in de categorieën voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorieën voor IPv6 en DNSSEC.', test_mailtls_null_mx_summary: 'Goed geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)', @@ -781,15 +788,15 @@ const internet_nl_messages = { test_mailtls_untestable_summary: 'Niet-testbare mailserver (STARTTLS en DANE)', test_mailtls_warning_description: 'Helaas! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) geen of een onvoldoende beveiligde verbinding opzetten. Passieve en/of actieve aanvallers kunnen daardoor e-mails onderweg naar jou lezen. Vraag je mailprovider om STARTTLS en DANE te activeren, en veilig in te stellen. ', test_mailtls_warning_summary: 'Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)', - test_siteappsecpriv_failed_description: 'Helaas! Niet alle vereiste beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_failed_description: 'Helaas! Niet alle vereiste beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_failed_summary: 'Een of meer vereiste beveiligingsopties niet ingesteld (Beveiligingsopties) ', - test_siteappsecpriv_info_description: 'Ter informatie: Niet alle optionele beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_info_description: 'Ter informatie: Niet alle optionele beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_info_summary: 'Een of meer optionele beveiligingsopties niet ingesteld (Beveiligingsopties) ', test_siteappsecpriv_label: 'Beveiligingsopties', - test_siteappsecpriv_passed_description: 'Goed gedaan! Alle beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_passed_description: 'Goed gedaan! Alle beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_passed_summary: 'Alle beveiligingsopties ingesteld (Beveiligingsopties)', test_siteappsecpriv_title: 'Beveiligingsopties ingesteld?', - test_siteappsecpriv_warning_description: 'Waarschuwing: Niet alle aanbevolen beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_warning_description: 'Waarschuwing: Niet alle aanbevolen beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_warning_summary: 'Een of meer aanbevolen beveiligingsopties niet ingesteld (Beveiligingsopties) ', test_sitednssec_failed_description: 'Helaas! Je domeinnaam is niet ondertekend met een geldige handtekening (DNSSEC). Daardoor zijn bezoekers die controle van domein-handtekeningen geactiveerd hebben, niet beschermd tegen gemanipuleerde vertaling van jouw domeinnaam naar kwaadaardige internetadressen. Vraag je nameserver-beheerder (vaak je registrar en/of hostingprovider) om DNSSEC te activeren.', test_sitednssec_failed_summary: 'Domeinnaam niet ondertekend (DNSSEC)', @@ -811,7 +818,9 @@ const internet_nl_messages = { test_siteipv6_title: 'Bereikbaar via modern adres?', test_siteipv6_warning_description: 'Helaas! Je website is niet bereikbaar voor bezoekers die een modern internetadres (IPv6) gebruiken, of er is verbetering mogelijk. Daardoor maakt je website nog geen onderdeel uit van het moderne internet. Vraag je hostingprovider om IPv6 volledig aan te zetten.', test_siteipv6_warning_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_siterpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende webserver en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je webhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + test_siterpki_error_description: 'De test kan nog niet worden uitgevoerd. Probeer het later nog eens. Sorry voor het ongemak.', + test_siterpki_error_summary: 'Test niet klaar om uit te voeren (RPKI)', + test_siterpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende webserver en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je webhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', test_siterpki_failed_summary: 'Ongeautoriseerde route-aankondiging (RPKI)', test_siterpki_info_description: 'Ter informatie: Je domein bevat geen nameservers en dus ook geen IP-adressen van webservers. Er zijn geen routeerbare IP-adressen die kunnen worden getest (RPKI).', test_siterpki_info_summary: 'Geen routeerbare IP-adressen gevonden (RPKI)', @@ -819,7 +828,7 @@ const internet_nl_messages = { test_siterpki_passed_description: 'Goed gedaan! Alle IP-adressen van je webserver en bijbehorende nameservers hebben een route-aankondiging die wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Daardoor zijn bezoekers met ingeschakelde route-validatie beter beschermd tegen verschillende onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers.', test_siterpki_passed_summary: 'Geautoriseerde route-aankondiging (RPKI)', test_siterpki_title: 'Route-autorisatie?', - test_siterpki_warning_description: 'Waarschuwing! Ten minste één van de IP-adressen van je webserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Als gevolg daarvan zijn bezoekers met ingeschakelde routevalidatie niet (volledig) beschermd tegen verschillende onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je webhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', + test_siterpki_warning_description: 'Helaas! Ten minste één van de IP-adressen van je webserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Als gevolg daarvan zijn bezoekers met ingeschakelde routevalidatie niet (volledig) beschermd tegen verschillende onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je webhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', test_siterpki_warning_summary: 'Route-autorisatie niet gepubliceerd (RPKI)', test_sitetls_failed_description: 'Helaas! De verbinding met je website is niet of onvoldoende beveiligd (HTTPS). Gegevens die onderweg zijn tussen je website en haar bezoekers, zijn daardoor niet voldoende beschermd tegen afluisteren en manipulatie. Vraag je hostingprovider om HTTPS aan te zetten en veilig te configureren.', test_sitetls_failed_summary: 'Verbinding niet of onvoldoende beveiligd (HTTPS)', @@ -888,16 +897,16 @@ const internet_nl_messages = { detail_conn_dnssec_validation_tech_table: 'DNS provider', detail_conn_dnssec_validation_verdict_bad: 'You are not protected by DNSSEC signature validation.', detail_conn_dnssec_validation_verdict_good: 'You are protected by DNSSEC signature validation.', - detail_conn_ipv6_connection_exp: 'We check if your device through its current internet connection is able to connect directly (i.e. without DNS translation) with our webserver using our corresponding IPv6 address.

Some browser add-ons and routers offer functionality for domain filtering in order to enhance privacy or restrict internet use. To prevent circumvention this kind of functionality often blocks connecting to IP addresses directly, making your internet connection fail for this subtest.', + detail_conn_ipv6_connection_exp: 'We check if your device through its current internet connection is able to connect directly (i.e. without DNS translation) with our web server using our corresponding IPv6 address.

Some browser add-ons and routers offer functionality for domain filtering in order to enhance privacy or restrict internet use. To prevent circumvention this kind of functionality often blocks connecting to IP addresses directly, making your internet connection fail for this subtest.', detail_conn_ipv6_connection_label: 'IPv6 connectivity (direct)', detail_conn_ipv6_connection_tech_table: 'Anonymized IPv6 address|Reverse name|Internet provider', detail_conn_ipv6_connection_verdict_bad: 'You are not able to reach computers directly on their IPv6 address.', detail_conn_ipv6_connection_verdict_good: 'You are able to reach computers directly on their IPv6 address.', - detail_conn_ipv6_dns_conn_exp: 'We check if your device through its current internet connection is able to connect to our webserver via IPv6. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv6 address.', + detail_conn_ipv6_dns_conn_exp: 'We check if your device through its current internet connection is able to connect to our web server via IPv6. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv6 address.', detail_conn_ipv6_dns_conn_label: 'IPv6 connectivity (via DNS)', detail_conn_ipv6_dns_conn_verdict_bad: 'You are not able to reach computers via DNS on their IPv6 address.', detail_conn_ipv6_dns_conn_verdict_good: 'You are able to reach computers via DNS on their IPv6 address.', - detail_conn_ipv6_ipv4_conn_exp: 'We check if your device through its current internet connection is able to connect to our webserver via IPv4. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv4 address.

Requirement level: Optional', + detail_conn_ipv6_ipv4_conn_exp: 'We check if your device through its current internet connection is able to connect to our web server via IPv4. For this test we provide a domain name and we expect your resolver to resolve the domain name to the appropriate IPv4 address.

Requirement level: Optional', detail_conn_ipv6_ipv4_conn_label: 'IPv4 connection (via DNS)', detail_conn_ipv6_ipv4_conn_tech_table: 'Anonymized IPv4 address|Reverse name|Internet provider', detail_conn_ipv6_ipv4_conn_verdict_bad: 'You are not able to reach computers via DNS on their IPv4 address.', @@ -910,7 +919,7 @@ const internet_nl_messages = { detail_conn_ipv6_resolver_conn_label: 'IPv6 connectivity of DNS resolver', detail_conn_ipv6_resolver_conn_verdict_bad: 'Your DNS resolver is not able to reach name servers over IPv6.', detail_conn_ipv6_resolver_conn_verdict_good: 'Your DNS resolver is able to reach name servers over IPv6.', - detail_mail_auth_dkim_exp: 'We check if your domain supports DKIM records. A receiving mail server canuse the public key in your DKIM record to validate the signature in an email with a user from your domain as sender and determine its authenticity.

  • Currently we are not able to query and evaluate the public key in your DKIM record,because we would need the DKIM selector (that should be in the mails you send) to do so.
  • To pass this test we expect your name server to answer NOERROR to our query for_domainkey.example.nl. When _domainkey.example.nl is an \'empty non-terminal\' some name servers that are not conformant with the standardRFC 2308 incorrectly answer NXDOMAIN instead of NOERROR. This makes itimpossible for us to detect support for DKIM records.
  • For this test we assume \'strict alignment\' which is conformant with DMARC. The given domain is considered to be the sender domain in the mail body domain (From:) and this must be identical to the DKIM domain (d=) and the SPF domain (envelope sender, i.e. return-path that shows up in MAIL FROM).

For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.', + detail_mail_auth_dkim_exp: '

We check if your domain supports DKIM records. A receiving mail server canuse the public key in your DKIM record to validate the signature in an email with a user from your domain as sender and determine its authenticity.

  • Currently we are not able to query and evaluate the public key in your DKIM record,because we would need the DKIM selector (that should be in the mails you send) to do so.
  • To pass this test we expect your name server to answer NOERROR to our query for_domainkey.example.nl. When _domainkey.example.nl is an \'empty non-terminal\' some name servers that are not conformant with the standardRFC 2308 incorrectly answer NXDOMAIN instead of NOERROR. This makes itimpossible for us to detect support for DKIM records.
  • For this test we assume \'strict alignment\' which is conformant with DMARC. The given domain is considered to be the sender domain in the mail body domain (From:) and this must be identical to the DKIM domain (d=) and the SPF domain (envelope sender, i.e. return-path that shows up in MAIL FROM).

Additional notes:

  • Some mail systems modify email in transit, potentially invalidating a DKIM signature. In many cases these modifications are harmless. Examples are whitespace replacement and header field line rewrapping. If you are a DKIM signing sender then you can choose whether or not to tolerate these types of changes, both for the header and the body of emails. The simple setting tolerates almost no modifications, and relaxed tolerates common modifications. If no setting is specified it defaults to simple for both header and body. In particular, header modifications are a common cause of a DKIM signature unintentionally becoming invalid, thus hindering deliverability. Using relaxed for the header while keeping simple for the body (c=relaxed/simple), can mitigate these kind of issues.
  • For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.
', detail_mail_auth_dkim_label: 'DKIM existence', detail_mail_auth_dkim_verdict_bad: 'Your domain does not support DKIM records.', detail_mail_auth_dkim_verdict_good: 'Your domain supports DKIM records.', @@ -920,7 +929,7 @@ const internet_nl_messages = { detail_mail_auth_dmarc_tech_table: 'DMARC record|Found on', detail_mail_auth_dmarc_verdict_bad: 'Your domain does not have a DMARC record.', detail_mail_auth_dmarc_verdict_good: 'Your domain has a DMARC record.', - detail_mail_auth_dmarc_policy_exp: '

We check if the syntax of your DMARC record is correct and if it contains a sufficiently strict policy (p=quarantine or p=reject) in order to prevent abuse of your domain by phishers and spammers. Even without a strict policy, DMARC can be useful to get more insight in legitimate and illegitimate outbound mail flows through DMARC reports. However to be effective against abuse of your domain, a liberal policy (p=none) is insufficient.

We also check whether the mail addresses under rua= and ruf= are valid. In case they contain an external mail address we check whether the external domain is authorised to receive DMARC reports. Make sure that the DMARC authorisation record on the external domain contains at least "v=DMARC1;".

The test permits the use of the experimental np tag (RFC 9091).

Good practice for domains without mail:

  • Non-sending: Use the most strict DMARC policy (p=reject) and SPF policy (-all) for your domain that you do not use for sending mail in order to prevent abuse (\'spoofing\'). Note that DKIM is not necessary in this case.
  • Non-receiving: For more information on "Null MX" and "No MX" see the explanation of the "STARTTLS available" subtest.

Below you will find two basic example DNS configurations for domain names that are not used to send and receive mail.

A. Single domain without A or AAAA record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Single no-mail domain with A or AAAA record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', + detail_mail_auth_dmarc_policy_exp: '

We check if the syntax of your DMARC record is correct and if it contains a sufficiently strict policy (p=quarantine or p=reject) in order to prevent abuse of your domain by phishers and spammers. Even without a strict policy, DMARC can be useful to get more insight in legitimate and illegitimate outbound mail flows through DMARC reports. However to be effective against abuse of your domain, a liberal policy (p=none) is insufficient.

We also check whether the mail addresses under rua= and ruf= are valid. In case they contain an external mail address we check whether the external domain is authorised to receive DMARC reports. Make sure that the DMARC authorisation record on the external domain contains at least "v=DMARC1;".

The test permits the use of the experimental np tag (RFC 9091).

Good practice for domains without mail:

  • Non-sending: Use the most strict DMARC policy (p=reject) and SPF policy (-all) for your domain that you do not use for sending mail in order to prevent abuse (\'spoofing\'). Note that DKIM is not necessary in this case.
  • Non-receiving: For more information on "Null MX" and "No MX" see the explanation of the "STARTTLS available" subtest.

Below you will find two basic example DNS configurations for domain names that are not used to send and receive mail.

A. Single domain without A or AAAA record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Single no-mail domain with A or AAAA record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', detail_mail_auth_dmarc_policy_label: 'DMARC policy', detail_mail_auth_dmarc_policy_verdict_bad: 'Your DMARC policy is not syntactically correct.', detail_mail_auth_dmarc_policy_verdict_external: 'The domain of the external mail address following rua= and/or ruf= has no (valid) authorisation record for receiving DMARC reports for the tested domain. ', @@ -940,20 +949,20 @@ const internet_nl_messages = { detail_mail_auth_spf_policy_verdict_include: 'Your SPF policy is not sufficiently strict. The \'include\' mechanism in your SPF record points to an insufficiently strict SPF policy or a non-existing SPF record.', detail_mail_auth_spf_policy_verdict_max_lookups: 'Your SPF policy is not effective as it requires more than the allowed 10 DNS lookups. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. The SPF terms all, ip4, ip6 and exp do not count as DNS lookups.', detail_mail_auth_spf_policy_verdict_redirect: 'Your SPF policy is not sufficiently strict. The \'redirect\' modifier in your SPF record points to an insufficiently strict SPF policy or a non-existing SPF record.', - detail_mail_dnssec_exists_exp: 'We check if your domain, more specifically its SOA record, is DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply that contains your mail server domains (MX). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to the attacker\'s mailserver domain.

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

Note: the validity of the signature is not part of this subtest, but part of the next subtest.', + detail_mail_dnssec_exists_exp: 'We check if your domain, more specifically its SOA record, is DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply that contains your mail server domains (MX). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to the attacker\'s mail server domain.

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

Note: the validity of the signature is not part of this subtest, but part of the next subtest.', detail_mail_dnssec_exists_label: 'DNSSEC existence', detail_mail_dnssec_exists_tech_table: 'Email address domain|Registrar', detail_mail_dnssec_exists_verdict_bad: 'Your email address domain is insecure, because it is not DNSSEC signed.', detail_mail_dnssec_exists_verdict_good: 'Your email address domain is DNSSEC signed.', detail_mail_dnssec_exists_verdict_resolver_error: 'Unfortunately an error occurred in Internet.nl\'s resolver. Please contact us.', detail_mail_dnssec_exists_verdict_servfail: 'The name servers of your email address domain are broken. They returned an error (SERVFAIL) to our queries for a DNSSEC signature. Please contact your name server operator (often your hosting provider and/or registrar) to fix this soon.', - detail_mail_dnssec_mx_exists_exp: 'We check if the domains of your mail servers (MX), more specifically their SOA records, are DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply containing the IP addresses and DANE records of your mailserver(s). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to an IP address controlled by the attacker or to eavesdrop on the secured mail server connection.

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

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.

The validity of the signature is not part of this subtest, but part of the next subtest.', + detail_mail_dnssec_mx_exists_exp: 'We check if the domains of your mail servers (MX), more specifically their SOA records, are DNSSEC signed. With a DNSSEC signature senders who validate domain signatures can verify the authenticity of the DNS reply containing the IP addresses and DANE records of your mail server(s). This prevents an attacker from manipulating the DNS answer in order to redirect mails sent to you to an IP address controlled by the attacker or to eavesdrop on the secured mail server connection.

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

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.

The validity of the signature is not part of this subtest, but part of the next subtest.', detail_mail_dnssec_mx_exists_label: 'DNSSEC existence', detail_mail_dnssec_mx_exists_tech_table: 'Domain of mail server (MX)|DNSSEC existent', detail_mail_dnssec_mx_exists_verdict_bad: 'At least one of your mail server domains is insecure, because it is not DNSSEC signed.', detail_mail_dnssec_mx_exists_verdict_good: 'All your mail server domains are DNSSEC signed.', detail_mail_dnssec_mx_exists_verdict_invalid_null_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', - detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email.', + detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_dnssec_mx_exists_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_dnssec_mx_exists_verdict_null_mx: 'Your domain name that has A/AAAA records clearly indicates with a "Null MX" record that it does not accept e-mail. This is fine if you do not want to receive email. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_dnssec_mx_exists_verdict_null_mx_with_other_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', @@ -978,41 +987,41 @@ const internet_nl_messages = { detail_mail_ipv6_mx_aaaa_verdict_bad: 'At least one receiving mail server on your domain does not have an IPv6 address.', detail_mail_ipv6_mx_aaaa_verdict_good: 'All receiving mail servers on your domain have an IPv6 address.', detail_mail_ipv6_mx_aaaa_verdict_invalid_null_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', - detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', + detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records and has an SPF record with only the term -all. We recommend you to set a "Null MX" record to explicitly indicate that your domain does not accept email. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_ipv6_mx_aaaa_verdict_null_mx: 'Your domain name that has A/AAAA records clearly indicates with a "Null MX" record that it does not accept e-mail. This is fine if you do not want to receive email. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_with_other_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_without_a_aaaa: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, your domain does not have A/AAAA records, making the "Null MX" record unnecessary.', - detail_mail_ipv6_mx_aaaa_verdict_other: 'No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email.', + detail_mail_ipv6_mx_aaaa_verdict_other: 'The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_ipv6_mx_reach_exp: 'We check if we can connect to your mail servers (MX) over IPv6 on port 25. We test all IPv6 addresses that we receive from the name servers of your mail server domain(s). A partial score will be given if not all IPv6 addresses are reachable. If an IPv6 address is (syntactically) invalid, we consider it unreachable.', detail_mail_ipv6_mx_reach_label: 'IPv6 reachability of mail server(s)', detail_mail_ipv6_mx_reach_tech_table: 'Mail server (MX)|Unreachable IPv6 address', detail_mail_ipv6_mx_reach_verdict_bad: 'At least one of your receiving mail servers with an IPv6 address is not reachable over IPv6.', detail_mail_ipv6_mx_reach_verdict_good: 'All your receiving mail servers with an IPv6 address are reachable over IPv6.', - detail_mail_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_mail_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_mail_rpki_exists_label: 'Route Origin Authorisation existence', detail_mail_rpki_exists_tech_table: 'Mail server|IP address|RPKI Route Origin Authorization', detail_mail_rpki_exists_verdict_bad: 'For at least one of the IP addresses of your receiving mail server(s) no RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_exists_verdict_good: 'For all IP addresses of your receiving mail server(s) an RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_exists_verdict_no_addresses: 'Your domain does not contain any receiving mail servers. Therefore, this subtest could not be performed.', - detail_mail_rpki_mx_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_mail_rpki_mx_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your mail server(s) (MX).

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_mail_rpki_mx_ns_exists_label: 'Route Origin Authorisation existence', detail_mail_rpki_mx_ns_exists_tech_table: 'Name server of MX|IP address|RPKI Route Origin Authorization', detail_mail_rpki_mx_ns_exists_verdict_bad: 'For at least one of the IP addresses of the name servers of your mail server(s) no RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_mx_ns_exists_verdict_good: 'For all IP addresses of the name servers of your mail server(s) an RPKI Route Origin Authorisation (ROA) is published.', detail_mail_rpki_mx_ns_exists_verdict_no_addresses: 'Your domain does not contain any mail servers. Therefore, this subtest could not be performed.', - detail_mail_rpki_mx_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

Requirement level: Recommended', + detail_mail_rpki_mx_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error. ', detail_mail_rpki_mx_ns_valid_label: 'Route announcement validity', detail_mail_rpki_mx_ns_valid_tech_table: 'Name server of MX|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_mail_rpki_mx_ns_valid_verdict_bad: 'At least one IP address of the name servers of your receiving mail servers has a NotFound validation state. There is no RPKI Route Origin Authorization (ROA) published for the route announcement of each of the affected IP addresses.', detail_mail_rpki_mx_ns_valid_verdict_good: 'All IP addresses of the name servers of your receiving mail servers have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_mx_ns_valid_verdict_invalid: 'At least one IP address of the name servers of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_mail_rpki_mx_ns_valid_verdict_invalid: 'At least one IP address of the name servers of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_mail_rpki_mx_ns_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', - detail_mail_rpki_valid_exp: 'We check if the validation status for all IP addresses of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

Requirement level: Recommended', + detail_mail_rpki_valid_exp: 'We check if the validation status for all IP addresses of your mail servers (MX) is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_mail_rpki_valid_label: 'Route announcement validity', detail_mail_rpki_valid_tech_table: 'Mail server|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_mail_rpki_valid_verdict_bad: 'At least one IP address of your receiving mail servers has a NotFound validation state. There is no RPKI Route Origin Authorization (ROA) published for the route announcement of each of the affected IP addresses.', detail_mail_rpki_valid_verdict_good: 'All IP addresses of your receiving mail servers have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_valid_verdict_invalid: 'At least one IP address of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_mail_rpki_valid_verdict_invalid: 'At least one IP address of your receiving mail servers has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your mail hoster as soon as possible. In the case of an internal error, your mail hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_mail_rpki_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', detail_mail_tls_cert_hostmatch_exp: 'We check if the domain name of each of your receiving mail servers (MX) matches the domain name on the presented certificates.

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

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

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

Requirement level: Optional / Required (only when DANE-TA is used)', detail_mail_tls_cert_hostmatch_label: 'Domain name on certificate', @@ -1038,7 +1047,7 @@ const internet_nl_messages = { detail_mail_tls_cipher_order_exp: 'We check if your receiving mail servers (MX) enforce their own cipher preference (\'I\'), and offer ciphers in accordance with the prescribed ordering (\'II\').

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

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

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.

In the above table with technical details only the first found out of prescribed order algorithm selections are listed.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B2-5.', detail_mail_tls_cipher_order_label: 'Cipher order', detail_mail_tls_cipher_order_tech_table: 'Mail server (MX)|First found affected cipher pair|Violated rule # (\'II-B\')', - detail_mail_tls_cipher_order_verdict_bad: 'At least one of your mailservers does not enforce its own cipher preference (\'I\').', + detail_mail_tls_cipher_order_verdict_bad: 'At least one of your mail servers does not enforce its own cipher preference (\'I\').', detail_mail_tls_cipher_order_verdict_good: 'All your mail servers enforce their own cipher preference (\'I\'), and offer ciphers in accordance with the prescribed ordering (\'II\').', detail_mail_tls_cipher_order_verdict_na: 'This subtest is not applicable as your mail server supports \'Good\' ciphers only.', detail_mail_tls_cipher_order_verdict_seclevel_bad: 'At least one of your mail servers does not prefer \'Good\' over \'Sufficient\' over \'Phase out\' ciphers (\'II\').', @@ -1060,7 +1069,7 @@ const internet_nl_messages = { detail_mail_tls_dane_exists_verdict_bad: 'At least one of your mail server domains does not provide a TLSA record for DANE.', detail_mail_tls_dane_exists_verdict_bogus: 'At least one of your mail server domains does not provide DNSSEC proof that DANE TLSA records do not exist. This could lead to non-deliverability of mail sent to you by DANE validating mail senders. You should ask your name server operator to fix this issue.', detail_mail_tls_dane_exists_verdict_good: 'All your mail server domains provide a TLSA record for DANE.', - detail_mail_tls_dane_rollover_exp: 'We check if there is an active scheme with at least two DANE TLSA records to reliably handle certificate rollovers on your receiving mail servers (MX).

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

We recommend you to apply one of the following two schemes with double DANE TLSA records:

  1. Current + Next ("3 1 1" + "3 1 1"): Publish two "DANE-EE(3) SPKI(1) SHA2-256(1)" records, one for the current and one for the next TLS certificate of your mail server.
  2. Current + Issuer CA ("3 1 1" + "2 1 1"): Publish a "DANE-EE(3) SPKI(1) SHA2-256(1)" record for the current TLS certificate of your mail server, and also a "DANE-TA(2) SPKI(1) SHA2-256(1)" record for the current root or intermediate certificate of the (not necessarily public) certificate authority.

The test also accepts other combinations of DANE TLSA records i.e. "3 x x" + "3 x x" or "3 x x" + "2 x x". However other types than the above will generally be more error prone and less interoperable.

Requirement level: Optional', + detail_mail_tls_dane_rollover_exp: 'We check if there is an active scheme with at least two DANE TLSA records to reliably handle certificate rollovers on your receiving mail servers (MX).

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

We recommend you to apply one of the following two schemes with double DANE TLSA records:

  1. Current + Next ("3 1 1" + "3 1 1"): Publish two "DANE-EE(3) SPKI(1) SHA2-256(1)" records, one for the current and one for the next TLS certificate of your mail server.
  2. Current + Issuer CA ("3 1 1" + "2 1 1"): Publish a "DANE-EE(3) SPKI(1) SHA2-256(1)" record for the current TLS certificate of your mail server, and also a "DANE-TA(2) SPKI(1) SHA2-256(1)" record for the current root or intermediate certificate of the (not necessarily public) certificate authority.

The test also accepts other combinations of DANE TLSA records i.e. "3 x x" + "3 x x" or "3 x x" + "2 x x". However other types than the above will generally be more error prone and less interoperable.

Note that if a mail server simultaneously offers two certificates (one based on RSA and one based on ECDSA), a separate DANE TLSA rollover scheme is recommended for each certificate. The subtest does not check for this scenario. If only one DANE TLSA record is configured for each certificate, this subtest gives a false-positive result.

Requirement level: Optional', detail_mail_tls_dane_rollover_label: 'DANE rollover scheme', detail_mail_tls_dane_rollover_tech_table: 'Mail server (MX)|DANE rollover scheme', detail_mail_tls_dane_rollover_verdict_bad: 'At least one of your mail server domains does not have an active DANE scheme for a reliable rollover of certificate keys.', @@ -1068,9 +1077,9 @@ const internet_nl_messages = { detail_mail_tls_dane_valid_exp: 'We check if the DANE fingerprints presented by your mail server domains are valid for your mail server certificates.

DANE allows you to publish information about your mail server certificates in a special DNS record, called TLSA record. Sending mail servers can check the authenticity of your certificates not only through the certificate authority but also through the TLSA records. A sending mail server can also use the TLSA record as a signal to only connect via STARTTLS (and not unencrypted). When the DANE fingerprint of a receiving mail server is checked by the sending mail server, an active attacker who is able to manipulate the mail traffic cannot strip STARTTLS encryption. ', detail_mail_tls_dane_valid_label: 'DANE validity', detail_mail_tls_dane_valid_tech_table: 'Mail server (MX)|DANE TLSA record valid', - detail_mail_tls_dane_valid_verdict_bad: 'At least one of your mailservers does not have any valid DANE fingerprints. Either someone manipulated the response of your mail server, or your mail server has a serious DANE configuration error. The latter makes your domain unreachable for any sending mail server that checks DANE fingerprints. You should contact your mail provider as soon as possible.', - detail_mail_tls_dane_valid_verdict_good: 'Each of your mailservers has at least one valid DANE fingerprint. This allows sending mail servers that support DANE verification to set up an authenticated encrypted transport connection with your receiving mail servers.', - detail_mail_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your receiving mail servers (MX) are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', + detail_mail_tls_dane_valid_verdict_bad: 'At least one of your mail servers does not have any valid DANE fingerprints. Either someone manipulated the response of your mail server, or your mail server has a serious DANE configuration error. The latter makes your domain unreachable for any sending mail server that checks DANE fingerprints. You should contact your mail provider as soon as possible.', + detail_mail_tls_dane_valid_verdict_good: 'Each of your mail servers has at least one valid DANE fingerprint. This allows sending mail servers that support DANE verification to set up an authenticated encrypted transport connection with your receiving mail servers.', + detail_mail_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your receiving mail servers (MX) are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', detail_mail_tls_fs_params_label: 'Key exchange parameters', detail_mail_tls_fs_params_tech_table: 'Mail server (MX)|Affected parameters|Security level', detail_mail_tls_fs_params_verdict_bad: 'At least one of your mail servers supports insufficiently secure parameters for Diffie-Hellman key exchange.', @@ -1081,7 +1090,7 @@ const internet_nl_messages = { detail_mail_tls_kex_hash_func_label: 'Hash function for key exchange', detail_mail_tls_kex_hash_func_tech_table: 'Mail server (MX)|SHA2 support for signatures', detail_mail_tls_kex_hash_func_verdict_good: 'All your mail servers support secure hash functions for key exchange.', - detail_mail_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by at least one of your mail servers. This could be because the cipher combination used has no signature for certificate verification (e.g it uses RSA key exchange or is anonymous i.e. anon).', + detail_mail_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by at least one of your mail servers. This could be because the cipher combination used has no signature for certificate verification (e.g. it uses RSA key exchange or is anonymous i.e. anon).', detail_mail_tls_kex_hash_func_verdict_phase_out: '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.', detail_mail_tls_ocsp_stapling_exp: 'OUTDATED TEXT; TEST NOT USED
We check if your receiving mail server supports the TLS Certificate Status extension aka OCSP stapling. With OCSP stapling your mail server can provide OCSP responses itself which removes the need for the TLS client to verify the validity of the mail server certificate directly with the certificate supplier, and thus avoids exposing potentially privacy sensitive data about the client to the certificate supplier. It also does not require connectivity between client and certificate supplier and is faster. See \'IT Security Guidelines for Transport Layer Security (TLS)\', guideline B9-1 (in English).

When connecting to your mail server we use the TLS Certificate Status extension to request OCSP data be included in the server response. If your mail server includes OCSP data in the response we then verify that the OCSP data is signed by a known certificate authority.', detail_mail_tls_ocsp_stapling_label: 'OUTDATED TEXT; TEST NOT USED
OCSP stapling', @@ -1105,12 +1114,12 @@ const internet_nl_messages = { detail_mail_tls_starttls_exists_verdict_bad: 'At least one of your mail servers does not offer STARTTLS.', detail_mail_tls_starttls_exists_verdict_good: 'All your mail servers offer STARTTLS.', detail_mail_tls_starttls_exists_verdict_invalid_null_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', - detail_mail_tls_starttls_exists_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', + detail_mail_tls_starttls_exists_verdict_no_null_mx: 'No receiving mail servers (MX) are set on your domain that has A/AAAA records and has an SPF record with only the term -all. We recommend you to set a "Null MX" record to explicitly indicate that your domain does not accept email. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_tls_starttls_exists_verdict_null_mx: 'Your domain name that has A/AAAA records clearly indicates with a "Null MX" record that it does not accept e-mail. This is fine if you do not want to receive email. Do not use a "Null MX" record and set an MX if you do want to send email from this domain name, as receiving servers may reject email that has an invalid return address.', detail_mail_tls_starttls_exists_verdict_null_mx_with_other_mx: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting.', detail_mail_tls_starttls_exists_verdict_null_mx_without_a_aaaa: 'Your domain advertises a "Null MX" record indicating that it does not accept email. However, your domain does not have A/AAAA records, making the "Null MX" record unnecessary.', detail_mail_tls_starttls_exists_verdict_other: 'At least one of your mail servers is unreachable.', - detail_mail_tls_starttls_exists_verdict_other_2: 'No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email. ', + detail_mail_tls_starttls_exists_verdict_other_2: 'The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', detail_mail_tls_version_exp: '

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

A mail server may support more than one TLS version.

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.

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

Version

  • Good: TLS 1.3
  • Sufficient: TLS 1.2
  • Phase out: TLS 1.1 and 1.0
  • Insufficient: SSL 3.0, 2.0 and 1.0
', detail_mail_tls_version_label: 'TLS version', detail_mail_tls_version_tech_table: 'Mail server (MX)|TLS versions|Status', @@ -1149,15 +1158,18 @@ const internet_nl_messages = { detail_tech_data_http_referrer_policy_recommendation_strict_origin: 'Recommendation: \'strict-origin\' should not be used.', detail_tech_data_http_referrer_policy_recommendation_strict_origin_when_cross_origin: 'Recommendation: \'strict-origin-when-cross-origin\' should not be used.', detail_tech_data_http_referrer_policy_values: 'Found policy: {values}', + detail_tech_data_http_securitytxt_bom_in_file: 'Error: The Byte Order Mark ("BOM") signature must not appear at the beginning of the content that must be encoded using UTF-8 in Net-Unicode form.', detail_tech_data_http_securitytxt_data_after_sig: 'Error: Signed security.txt must not contain data after the signature (line {line_no}).', detail_tech_data_http_securitytxt_empty_key: 'Error: Field name must not be empty (line {line_no}).', detail_tech_data_http_securitytxt_empty_value: 'Error: Field value must not be empty (line {line_no}).', detail_tech_data_http_securitytxt_expired: 'Error: Date and time in \'Expires\' field must not be in the past (line {line_no}).', + detail_tech_data_http_securitytxt_invalid_cert: 'Error: security.txt must be served with a valid TLS certificate.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_invalid_charset: 'Error: Charset parameter in Content-Type header must be \'utf-8\' if present.', detail_tech_data_http_securitytxt_invalid_expiry: 'Error: Date and time in \'Expires\' field must be formatted according to ISO 8601 (line {line_no}).', - detail_tech_data_http_securitytxt_invalid_lang: 'Error: Value in \'Preferred-Languages\' field must match one or more language tags as defined in RFC 5646, separated by commas (line {line_no}).', + detail_tech_data_http_securitytxt_invalid_lang: 'Error: Value in \'Preferred-Languages\' field must match one or more language tags as defined in RFC 5646, separated by commas (line {line_no}).', detail_tech_data_http_securitytxt_invalid_line: 'Error: Line must contain a field name and value, unless the line is blank or contains a comment (line {line_no}).', detail_tech_data_http_securitytxt_invalid_media: 'Error: Media type in Content-Type header must be \'text/plain\'.', + detail_tech_data_http_securitytxt_invalid_uri_scheme: 'Error: The security.txt file access must use the HTTPS scheme.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_location: 'Error: security.txt was located on the top-level path (legacy place), but must be placed under the \'/.well-known/\' path.', detail_tech_data_http_securitytxt_long_expiry: 'Recommendation: Date and time in \'Expires\' field should be less than a year into the future (line {line_no}).', detail_tech_data_http_securitytxt_multi_expire: 'Error: \'Expires\' field must not appear more than once.', @@ -1184,7 +1196,7 @@ const internet_nl_messages = { detail_tech_data_http_securitytxt_retrieved_from: 'security.txt retrieved from {hostname}.', detail_tech_data_http_securitytxt_signed_format_issue: 'Error: Signed security.txt must start with the header \'-----BEGIN PGP SIGNED MESSAGE-----\'.', detail_tech_data_http_securitytxt_unknown_field: 'Notification: security.txt contains an unknown field. Either this is a custom field which may not be widely supported, or there is a typo in a standardised field name (line {line_no}).', - detail_tech_data_http_securitytxt_utf8: 'Error: Content must be utf-8 encoded.', + detail_tech_data_http_securitytxt_utf8: 'Error: Content must encoded using UTF-8 in Net-Unicode form.', detail_tech_data_insecure: 'insecure', detail_tech_data_insufficient: 'insufficient', detail_tech_data_no: 'no', @@ -1198,29 +1210,29 @@ const internet_nl_messages = { detail_tech_data_yes: 'yes', detail_verdict_could_not_test: 'Test error. Please try again later.', detail_verdict_not_tested: 'This subtest did not run, because either a parent test that this subtest depends on gave a negative result, or not enough information was available to run this subtest.', - detail_web_appsecpriv_http_csp_exp: 'We check if your web server provides an HTTP header for Content-Security-Policy (CSP). Furthermore we check for several secure CSP settings, although we do not exhaustively test the effectiveness of your CSP configuration.

CSP guards a website against content injection attacks including cross-site scripting (XSS). By using CSP to configure an \'allowlist\' with sources of approved content, you prevent browsers from loading malicious content of attackers.

We test for the rules below that are based on good practices for a secure CSP configuration.

  1. The default-src directive should be defined and its value should be be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This is to have a restrictive default fallback policy for source types that are used in your website for which no specific policy is defined. Next to the mentioned values \'report-sample\' could be there in case you want code samples to be sent together with the \'violation reports\'.
  2. The base-uri directive should be defined and its value should be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This restricts the baseURI in order to block the injection of a manipulated <base> element. This limits the ability of attackers to manipulate the locations of sources (e.g. scripts) that are loaded from relative URLs.
  3. The frame-src directive should be used (either by definition or by relying on the fallback to sequentially child-src and default-src) and its value should be either \'none\', or \'self\'and/or one or more specific URLs. This prevents content from unauthorized locations to be framed or embedded in your website (with HTML elements such as <frame> and <iframe>).
  4. The frame-ancestors directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This prevents unauthorized websites from framing or embedding your website (with HTML elements <frame>, <iframe>, <object>, <embed>, or <applet>).
  5. The form-action directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This restricts the URLs which can be used as the target of form submissions.
  6. The source values unsafe-eval, unsafe-inline and unsafe-hashes should not be used, because these enable XSS attacks.
  7. The data: scheme should not be used in the default-src, script-src and object-src directives, because this enables XSS attacks.
  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.
  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).
  10. 127.0.0.1 should not be used in any directive, because it enables content injection attacks in a compromised system.

Additional recommendations:

  1. Only use domains in CSP directives as specific as possible, which is tested automatically to some extent in this subtest for CSP.

    • Do not allow all domains under a TLD (*.nl) or SLD (*.gov.uk), although we currently do not test for this.
    • 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.

  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.

  3. Use the HTTP header as a mechanism for serving your CSP policy. Do not use the HTML <meta> element to serve your CSP policy. The latter is less secure and does not support all CSP directives (e.g. the required frame-ancestors). Therfore we do not check for CSP that is offered via the HTML <meta> element.
  4. Use the HTTP header for Content-Security-Policy-Report-Only to experiment with your CSP configuration by monitoring its effect without enforcing it.
  5. Note that an empty source list (i.e. a CSP directive without a value) is equivalent to a source list containing none. Besides, note that if other sources are listed in a source list next to none, then the attribute none is ignored.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Requirement level: Recommended', + detail_web_appsecpriv_http_csp_exp: 'We check if your web server provides an HTTP header for Content-Security-Policy (CSP). Furthermore we check for several secure CSP settings, although we do not exhaustively test the effectiveness of your CSP configuration.

CSP guards a website against content injection attacks including cross-site scripting (XSS). By using CSP to configure an \'allowlist\' with sources of approved content, you prevent browsers from loading malicious content of attackers.

We test for the rules below that are based on good practices for a secure CSP configuration.

  1. The default-src directive should be defined and its value should be be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This is to have a restrictive default fallback policy for source types that are used in your website for which no specific policy is defined. Next to the mentioned values \'report-sample\' could be there in case you want code samples to be sent together with the \'violation reports\'.
  2. The base-uri directive should be defined and its value should be either \'none\', or \'self\' and/or one or more URLs of the domain itself (including its subdomain or superdomain). This restricts the baseURI in order to block the injection of a manipulated <base> element. This limits the ability of attackers to manipulate the locations of sources (e.g. scripts) that are loaded from relative URLs.
  3. The frame-src directive should be used (either by definition or by relying on the fallback to sequentially child-src and default-src) and its value should be either \'none\', or \'self\'and/or one or more specific URLs. This prevents content from unauthorized locations to be framed or embedded in your website (with HTML elements such as <frame> and <iframe>).
  4. The frame-ancestors directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This prevents unauthorized websites from framing or embedding your website (with HTML elements <frame>, <iframe>, <object>, <embed>, or <applet>).
  5. The form-action directive should be defined and its value should be either \'none\', or \'self\' and/or one or more specific URLs. This restricts the URLs which can be used as the target of form submissions.
  6. The source values unsafe-eval, unsafe-inline and unsafe-hashes should not be used, because these enable XSS attacks.
  7. The data: scheme should not be used in the default-src, script-src and object-src directives, because this enables XSS attacks.
  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.
  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).
  10. 127.0.0.1 should not be used in any directive, because it enables content injection attacks in a compromised system.

Additional recommendations:

  1. Only use domains in CSP directives as specific as possible, which is tested automatically to some extent in this subtest for CSP.

    • Do not allow all domains under a TLD (*.nl) or SLD (*.gov.uk), although we currently do not test for this.
    • 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.

  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.

  3. Use the HTTP header as a mechanism for serving your CSP policy. Do not use the HTML <meta> 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 <meta> element.
  4. Use the HTTP header for Content-Security-Policy-Report-Only to experiment with your CSP configuration by monitoring its effect without enforcing it.
  5. Note that an empty source list (i.e. a CSP directive without a value) is equivalent to a source list containing none. Besides, note that if other sources are listed in a source list next to none, then the attribute none is ignored.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Requirement level: Recommended', detail_web_appsecpriv_http_csp_label: 'Content-Security-Policy', detail_web_appsecpriv_http_csp_tech_table: 'Web server IP address|Findings', detail_web_appsecpriv_http_csp_verdict_bad: 'Your web server does not offer Content-Security-Policy (CSP), or does offer CSP with certain insecure settings. ', detail_web_appsecpriv_http_csp_verdict_good: 'Your web server offers Content-Security-Policy (CSP) and does not use certain insecure CSP settings.', - detail_web_appsecpriv_http_referrer_policy_exp: 'We check if your web server provides an HTTP header for Referrer-Policy with a sufficiently secure and privacy-protecting policy value. With this policy your webserver instructs browsers if, what and when referrer data should be sent to the website the user is navigating to from your website. This referrer data is sent in the Referer header by the browser to the website the user is navigating to. This navigation does not necessarily have to be cross-domain.

The data in the Referer header is usually used for analytics and logging. However there can be privacy and security risks. The data could be used e.g. for user tracking and the data could leak to third parties who eavesdrop the connection. The HTTP header for Referrer-Policy allows you to mitigate these risks by controlling and even minimizing the sending of referrer data.

We suggest to make an informed decision, with privacy and security risks in mind, on using one of the policy values from the first two categories below.

1. Good

  • no-referrer
  • same-origin

With these policy values no sensitive referrer data is sent to third parties.

2. Warning

  • strict-origin
  • strict-origin-when-cross-origin (browser\'s default value; see also under additional note 2)

With these policy values basic referrer data, which may be sensitive, is sent to third parties only via secure connections (HTTPS). Therefore these values should only to be used where necessary and permitted by law.

3. Bad

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

With these policy values any or basic referrer data, which may be sensitive, is sent to third parties possibly via insecure connections (HTTP). Therefore these values must not be used.

Additional notes:

  1. To prevent leaking of sensitive data through URLs, please make sure URLs of your website do not contain personal or otherwise sensitive data (like personal names or passwords).
  2. strict-origin-when-cross-origin is the default policy value when no Referrer-Policy is published as prescribed in the current "Editor\'s Draft" of the Referrer-Policy standard and this default is used by all latest major browsers. Note that some users may still have a different default value configured in their browser.
  3. Use the HTTP Referrer-Policy header as a mechanism for serving your referrer policy. We do not recommend to use the HTML <meta> element or the HTML referrerpolicy content attribute to publish your referrer policy, especially because the sections that describe these methods in the standard are marked as "not normative". Therefore we do not check for a referrer policy that is offered via the latter two methods.
  4. Note that a web server may send multiple Referrer-Policy headers, and a Referrer-Policy header may contain multiple values. Unknown values will be ignored by the browser and only the last known value will be used. This makes it possible to use future standardised policy values that are not supported by all browsers yet. However, currently all latest major browsers support the above mentioned policy values under "Good" and "Warning".

Requirement level: Recommended', + detail_web_appsecpriv_http_referrer_policy_exp: 'We check if your web server provides an HTTP header for Referrer-Policy with a sufficiently secure and privacy-protecting policy value. With this policy your web server instructs browsers if, what and when referrer data should be sent to the website the user is navigating to from your website. This referrer data is sent in the Referer header by the browser to the website the user is navigating to. This navigation does not necessarily have to be cross-domain.

The data in the Referer header is usually used for analytics and logging. However there can be privacy and security risks. The data could be used e.g. for user tracking and the data could leak to third parties who eavesdrop the connection. The HTTP header for Referrer-Policy allows you to mitigate these risks by controlling and even minimizing the sending of referrer data.

We suggest to make an informed decision, with privacy and security risks in mind, on using one of the policy values from the first two categories below.

1. Good

  • no-referrer
  • same-origin

With these policy values no sensitive referrer data is sent to third parties.

2. Warning

  • strict-origin
  • strict-origin-when-cross-origin (browser\'s default value; see also under additional note 2)

With these policy values basic referrer data, which may be sensitive, is sent to third parties only via secure connections (HTTPS). Therefore these values should only to be used where necessary and permitted by law.

3. Bad

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

With these policy values any or basic referrer data, which may be sensitive, is sent to third parties possibly via insecure connections (HTTP). Therefore these values must not be used.

Additional notes:

  1. To prevent leaking of sensitive data through URLs, please make sure URLs of your website do not contain personal or otherwise sensitive data (like personal names or passwords).
  2. strict-origin-when-cross-origin is the default policy value when no Referrer-Policy is published as prescribed in the current "Editor\'s Draft" of the Referrer-Policy standard and this default is used by all latest major browsers. Note that some users may still have a different default value configured in their browser.
  3. Use the HTTP Referrer-Policy header as a mechanism for serving your referrer policy. We do not recommend to use the HTML <meta> element or the HTML referrerpolicy content attribute to publish your referrer policy, especially because the sections that describe these methods in the standard are marked as "not normative". Therefore we do not check for a referrer policy that is offered via the latter two methods.
  4. Note that a web server may send multiple Referrer-Policy headers, and a Referrer-Policy header may contain multiple values. Unknown values will be ignored by the browser and only the last known value will be used. This makes it possible to use future standardised policy values that are not supported by all browsers yet. However, currently all latest major browsers support the above mentioned policy values under "Good" and "Warning".

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Recommended', detail_web_appsecpriv_http_referrer_policy_label: 'Referrer-Policy', detail_web_appsecpriv_http_referrer_policy_tech_table: 'Web server IP address|Findings', detail_web_appsecpriv_http_referrer_policy_verdict_bad: 'Your web server offers a Referrer-Policy with a policy value that is not sufficiently secure and privacy-protecting.', detail_web_appsecpriv_http_referrer_policy_verdict_good: 'Your web server offers a Referrer-Policy with a policy value that is sufficiently secure and privacy-protecting.', detail_web_appsecpriv_http_referrer_policy_verdict_recommendations: 'Your web server either does not offer a Referrer-Policy and thus relies on the default browser policy, or your web server offers a Referrer-Policy with a policy value that should be used with caution because of its potential impact on security and privacy.', - detail_web_appsecpriv_http_securitytxt_exp: 'We check if your web server provides a security.txt file in the right location, whether it could be retrieved, and whether its content is syntactically valid.

security.txt is a text file with contact information that you place on your web server. Security researchers can use this information to directly contact the right department or person within your organization about vulnerabilities that they found in your website or IT systems. This can speed up the fixing of found vulnerabilities, reducing the opportunity for malicious parties to exploit.

The syntax of the file is intended to be machine- and human-readable. The contact information can be an email address, a phone number, and/or a web page (e.g. a web form). Note that published contact information is public and can also be abused, for example, to send spam to a published e-mail address.

Besides contact infomation, the security.txt file must also contain an expiry date. To avoid staleness it is recommended that the date be less than a year into the future. It is optional to also include other relevant information for security researchers, like a link to your policy on dealing with security vulnerabilities reports (usually called a Coordinated Vulnerability Disclosure policy).

It is recommended to PGP sign the security.txt file while including the web URI on which the file is located in a Canonical field. We check if the security.txt file is signed. However, we do not validate the signature because, unfortunately, there is no standardised place to retrieve a public PGP key (which is required for signature validation).

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.

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.

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.

Note that security.txt files are normally just a few kilobytes in size. We therefore read and evaluate at maximum the first 100 kB of a found security.txt file.

Requirement level: Recommended', + detail_web_appsecpriv_http_securitytxt_exp: 'We check if your web server provides a security.txt file in the right location, whether it could be retrieved, and whether its content is syntactically valid.

security.txt is a text file with contact information that you place on your web server. Security researchers can use this information to directly contact the right department or person within your organization about vulnerabilities that they found in your website or IT systems. This can speed up the fixing of found vulnerabilities, reducing the opportunity for malicious parties to exploit.

The syntax of the file is intended to be machine- and human-readable. The contact information can be an email address, a phone number, and/or a web page (e.g. a web form). Note that published contact information is public and can also be abused, for example, to send spam to a published e-mail address.

Besides contact information, the security.txt file must also contain an expiry date. To avoid staleness it is recommended that the date be less than a year into the future. It is optional to also include other relevant information for security researchers, like a link to your policy on dealing with security vulnerabilities reports (usually called a Coordinated Vulnerability Disclosure policy).

It is recommended to PGP sign the security.txt file while including the web URI on which the file is located in a Canonical field. We check if the security.txt file is signed. However, we do not validate the signature because, unfortunately, there is no standardised place to retrieve a public PGP key (which is required for signature validation).

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.

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.

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.

Note that security.txt files are normally just a few kilobytes in size. We therefore read and evaluate at maximum the first 100 kB of a found security.txt file.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Recommended', detail_web_appsecpriv_http_securitytxt_label: 'security.txt', detail_web_appsecpriv_http_securitytxt_tech_table: 'Web server IP address|Findings', detail_web_appsecpriv_http_securitytxt_verdict_bad: 'Your web server does not offer a security.txt file in the right location, it could not be retrieved, or its content is not syntactically valid.', detail_web_appsecpriv_http_securitytxt_verdict_good: 'Your web server offers a security.txt file in the right location and its content is syntactically valid.', detail_web_appsecpriv_http_securitytxt_verdict_recommendations: 'Your web server offers a security.txt file in the right location and its content is syntactically valid. However, there are one or more recommendations for improvement.', - detail_web_appsecpriv_http_x_content_type_exp: 'We check if your web server provides an HTTP header for X-Content-Type-Options. With this HTTP header you let web browsers know that they must not do \'MIME type sniffing\' and always follow the Content-Type as declared by your web server. The only valid value for this HTTP header is nosniff. When enabled, a browser will block requests for style and script when they do not have a corresponding Content-Type (i.e. text/css or a \'JavaScript MIME type\' like application/javascript).

\'MIME type sniffing\' is a technique where the browser scans the content of a file to detect the format of a file regardless of the declared Content-Type by the web server. This technique is vulnerable to the so-called \'MIME confusion attack\' in which the attacker manipulates the content of a file in a way that it is treated by the browser as a different Content-Type, like an executable.

Requirement level: Recommended ', + detail_web_appsecpriv_http_x_content_type_exp: 'We check if your web server provides an HTTP header for X-Content-Type-Options. With this HTTP header you let web browsers know that they must not do \'MIME type sniffing\' and always follow the Content-Type as declared by your web server. The only valid value for this HTTP header is nosniff. When enabled, a browser will block requests for style and script when they do not have a corresponding Content-Type (i.e. text/css or a \'JavaScript MIME type\' like application/javascript).

\'MIME type sniffing\' is a technique where the browser scans the content of a file to detect the format of a file regardless of the declared Content-Type by the web server. This technique is vulnerable to the so-called \'MIME confusion attack\' in which the attacker manipulates the content of a file in a way that it is treated by the browser as a different Content-Type, like an executable.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Recommended ', detail_web_appsecpriv_http_x_content_type_label: 'X-Content-Type-Options', detail_web_appsecpriv_http_x_content_type_tech_table: 'Web server IP address|X-Content-Type-Options value', detail_web_appsecpriv_http_x_content_type_verdict_bad: 'Your web server does not offer X-Content-Type-Options.', detail_web_appsecpriv_http_x_content_type_verdict_good: 'Your web server offers X-Content-Type-Options.', - detail_web_appsecpriv_http_x_frame_exp: 'We check if your web server provides an HTTP header for X-Frame-Options that has a sufficiently secure policy. With this HTTP header you let web browsers know whether you want to allow your website to be framed or not. Prevention of framing defends visitors against attacks like clickjacking. We consider the following values to be sufficiently secure:

  • DENY (framing not allowed); or
  • SAMEORIGIN (only framing by your own website allowed).

Although the value ALLOW-FROM (only allow specific websites to frame your website) is part of the X-Frame-Options specification (RFC 7034), it is not supported by most modern web browsers. Therefore we do not consider this value as sufficiently secure.

Note that Content-Security-Policy (CSP) offers similar protection through frame-ancestors and besides much more for visitors with modern web browsers. However X-Frame-Options could still protect visitors of older web browsers that do not support CSP. Furthermore X-Frame-Options could offer valuable protection for all visitors when CSP is not (properly) configured for the website concerned.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Requirement level: Optional ', + detail_web_appsecpriv_http_x_frame_exp: 'We check if your web server provides an HTTP header for X-Frame-Options that has a sufficiently secure policy. With this HTTP header you let web browsers know whether you want to allow your website to be framed or not. Prevention of framing defends visitors against attacks like clickjacking. We consider the following values to be sufficiently secure:

  • DENY (framing not allowed); or
  • SAMEORIGIN (only framing by your own website allowed).

Although the value ALLOW-FROM (only allow specific websites to frame your website) is part of the X-Frame-Options specification (RFC 7034), it is not supported by most modern web browsers. Therefore we do not consider this value as sufficiently secure.

Note that Content-Security-Policy (CSP) offers similar protection through frame-ancestors and besides much more for visitors with modern web browsers. However X-Frame-Options could still protect visitors of older web browsers that do not support CSP. Furthermore X-Frame-Options could offer valuable protection for all visitors when CSP is not (properly) configured for the website concerned.

Also see \'Web application guidelines from NCSC-NL\', guideline U/PW.03 (in Dutch).

Note on IPv6/IPv4: for performance reasons all tests in the category \'Security options\' only run for the first available IPv6 and IPv4 address.

Requirement level: Optional ', detail_web_appsecpriv_http_x_frame_label: 'X-Frame-Options', detail_web_appsecpriv_http_x_frame_tech_table: 'Web server IP address|X-Frame-Options value', detail_web_appsecpriv_http_x_frame_verdict_bad: 'Your web server does not offer securely configured X-Frame-Options.', @@ -1248,29 +1260,29 @@ const internet_nl_messages = { detail_web_ipv6_web_aaaa_tech_table: 'Web server|IPv6 address|IPv4 address', detail_web_ipv6_web_aaaa_verdict_bad: 'None of your web servers has an IPv6 address.', detail_web_ipv6_web_aaaa_verdict_good: 'At least one of your web servers has an IPv6 address.', - detail_web_ipv6_web_ipv46_exp: 'We compare the response and content received from your web server over IPv6 with that received over IPv4.

We check:

  1. if HTTP (port 80) and/or HTTPS (port 443) over IPv4 are also available over IPv6;
  2. if HTTP headers (such as a redirect header) over IPv4 are also received over IPv6;
  3. if HTML content over IPv4 is the same over IPv6. After stripping eventual nonces we do a comparison of the received content. The content difference must not be higher than 10% to pass this subtest. The treshold makes sure that small differences (for example due to changing ads) do not lead to a fail of this subtest as well. An observed difference may be intended or due to a measurement error. Therefore, in this case, a warning is given and it is not weighed into the score.

Note that in case there are multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4 address to perform the subtest. If only an IPv6 address and no IPv4 address is available, the subtest is not applicable because no comparison can be made.', + detail_web_ipv6_web_ipv46_exp: '

We compare the available ports and offered headers and content of your web server via IPv6 with those via IPv4.

We check if:

  1. the same ports, i.e. HTTP (port 80) and/or HTTPS (port 443), are available via both IPv6 and IPv4;
  2. the same HTTP headers are offered via both IPv6 and IPv4. This includes HTTP response codes, like successful responses (200 – 299) and redirection messages (300 – 399). In cases of a client error response (400 - 499) or a server error response (500 - 599) a warning without score impact is given, because such a HTTP response code may indicate a configuration issue;
  3. the same HTML content is offered via both IPv6 and IPv4. We do this by comparing the content received after stripping any nonces. The content difference must not be higher than 10% to pass this subtest. This threshold ensures that small non-problematic differences (for example due to changing advertisements) do not immediately result in a failing result for this subtest. An observed difference may still be intended or due to measurement error. Therefore, in case of failure, this part of the subtest results only in a warning with no score impact.

Additional notes:

  • In case there are multiple IPv6 and IPv4 addresses, we pick one IPv6 address and one IPv4 address to perform the subtest.
  • If only an IPv6 address and no IPv4 address (or vice versa) is available, the subtest is not applicable because no comparison can be made.
  • This subtest follows redirects and also checks all underlying URLs.
', detail_web_ipv6_web_ipv46_label: 'Same website on IPv6 and IPv4', - detail_web_ipv6_web_ipv46_verdict_bad: 'Available ports or offered headers of your website over IPv4 are not the same over IPv6.', - detail_web_ipv6_web_ipv46_verdict_good: 'Your website on IPv6 seems to be the same as your website on IPv4.', - detail_web_ipv6_web_ipv46_verdict_notice: 'The HTML content of your website over IPv4 is not the same over IPv6. ', - detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Your website on IPv6 seems to be the same as your website on IPv4, but the HTTP response code is in the 4xx or 5xx range. This may indicate a configuration issue.', + detail_web_ipv6_web_ipv46_verdict_bad: 'Available ports or offered headers of your website via IPv4 are not the same via IPv6.', + detail_web_ipv6_web_ipv46_verdict_good: 'Your website via IPv6 looks identical via IPv4.', + detail_web_ipv6_web_ipv46_verdict_notice: 'The HTML content of your website via IPv4 is not the same via IPv6. ', + detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Your website via IPv6 looks identical via IPv4, but the HTTP response code is in the 4xx or 5xx range. This may indicate a configuration issue.', detail_web_ipv6_web_reach_exp: 'We check if we can connect to your web server(s) over IPv6 on any available ports (80 and/or 443). We test all IPv6 addresses that we receive from your name servers. A partial score will be given if not all IPv6 addresses are reachable. If an IPv6 address is (syntactically) invalid, we consider it unreachable.', detail_web_ipv6_web_reach_label: 'IPv6 reachability of web server', detail_web_ipv6_web_reach_tech_table: 'Web server|Unreachable IPv6 address', detail_web_ipv6_web_reach_verdict_bad: 'At least one of your web servers with an IPv6 address is not reachable over IPv6.', detail_web_ipv6_web_reach_verdict_good: 'All your web servers with an IPv6 address are reachable over IPv6.', - detail_web_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your web server.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_web_rpki_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of your web server.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_web_rpki_exists_label: 'Route Origin Authorisation existence', - detail_web_rpki_exists_tech_table: 'Webserver|IP address|RPKI Route Origin Authorization', + detail_web_rpki_exists_tech_table: 'Web server|IP address|RPKI Route Origin Authorization', detail_web_rpki_exists_verdict_bad: 'For at least one of the IP addresses of your web server no RPKI Route Origin Authorisation (ROA) is published.', detail_web_rpki_exists_verdict_good: 'For all IP addresses of your web server an RPKI Route Origin Authorisation (ROA) is published.', detail_web_rpki_exists_verdict_no_addresses: 'Your domain does not contain any web server IP addresses. Therefore, this subtest could not be performed.', - detail_web_rpki_valid_exp: 'We check if the validation status for all IP addresses of your web server is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

Requirement level: Recommended', + detail_web_rpki_valid_exp: 'We check if the validation status for all IP addresses of your web server is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error. ', detail_web_rpki_valid_label: 'Route announcement validity', detail_web_rpki_valid_tech_table: 'Web server|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_web_rpki_valid_verdict_bad: 'At least one IP address of your web server has a NotFound validation state. There is no RPKI Route Origin Authorization (ROA) published for the route announcement of each of the affected IP addresses.', detail_web_rpki_valid_verdict_good: 'All IP addresses of your web server have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_web_rpki_valid_verdict_invalid: 'At least one IP address of your web server has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your web hoster as soon as possible. In the case of an internal error, your web hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_web_rpki_valid_verdict_invalid: 'At least one IP address of your web server has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your web hoster as soon as possible. In the case of an internal error, your web hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_web_rpki_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', detail_web_tls_cert_hostmatch_exp: 'We check if the domain name of your website matches the domain name on the certificate.

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

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B3-1 (in English).', detail_web_tls_cert_hostmatch_label: 'Domain name on certificate', @@ -1328,19 +1340,19 @@ const internet_nl_messages = { detail_web_tls_dane_valid_tech_table: 'Web server IP address|DANE TLSA record valid', detail_web_tls_dane_valid_verdict_bad: 'The DANE fingerprint on your domain is not valid for your web certificate. Either someone manipulated the response from your name server, or your domain has a serious DANE configuration error. The latter makes your website unreachable for any user who check DANE fingerprints. You should contact your name server operator and/or your hosting provider as soon as possible.', detail_web_tls_dane_valid_verdict_good: 'The DANE fingerprint on your domain is valid for your web certificate.', - detail_web_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your web server are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', + detail_web_tls_fs_params_exp: 'We check if the public parameters used in Diffie-Hellman key exchange by your web server are secure.

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.

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. Self-generated groups are \'Insufficient\'.

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

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.

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

Elliptic curve for ECDHE

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

Finite field group for DHE

  • Sufficient:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • Note that we also test for ffdhe8192 and ffdhe6144. However their limited gain in security rarely outweighs the loss in performance.

  • Phase out:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Insufficient: Other groups

Note: the above names are based on the IANA naming conventions. Sometimes alternative names are used to refer to the same curves, like prime256v1 (ANSI) and NIST P-256 for secp256r1.', detail_web_tls_fs_params_label: 'Key exchange parameters', detail_web_tls_fs_params_tech_table: 'Web server IP address|Affected parameters|Status', detail_web_tls_fs_params_verdict_bad: 'Your web server supports insufficiently secure parameters for Diffie-Hellman key exchange.', detail_web_tls_fs_params_verdict_good: 'Your web server supports secure parameters for Diffie-Hellman key exchange.', - detail_web_tls_fs_params_verdict_na: 'This subtest is not applicable as your webserver does not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.', + detail_web_tls_fs_params_verdict_na: 'This subtest is not applicable as your web server does not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.', detail_web_tls_fs_params_verdict_phase_out: '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.', - detail_web_tls_http_compression_exp: '

We test if your web server supports HTTP compression.

HTTP compression makes the secure connection with your webserver vulnerable for the BREACH attack. However HTTP compression is commonly used to make more efficient use of available bandwidth. Consider the trade-offs involved with HTTP compression. If you choose to use HTTP compression, verify if it is possible to mitigate related attacks at the application level. An example of such a measure is limiting the extent to which an attacker can influence the response of a server.

This subtest checks if the web server on root directory level supports HTTP compression. However it does not check additional website sources like images and scripts.

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

Requirement level: Optional

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
', + detail_web_tls_http_compression_exp: '

We test if your web server supports HTTP compression.

HTTP compression makes the secure connection with your web server vulnerable for the BREACH attack. However HTTP compression is commonly used to make more efficient use of available bandwidth. Consider the trade-offs involved with HTTP compression. If you choose to use HTTP compression, verify if it is possible to mitigate related attacks at the application level. An example of such a measure is limiting the extent to which an attacker can influence the response of a server.

This subtest checks if the web server on root directory level supports HTTP compression. However it does not check additional website sources like images and scripts.

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

Requirement level: Optional

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
', detail_web_tls_http_compression_label: 'HTTP compression', detail_web_tls_http_compression_tech_table: 'Web server IP address|HTTP compression', detail_web_tls_http_compression_verdict_bad: 'Your web server supports HTTP compression, which could be a security risk.', detail_web_tls_http_compression_verdict_good: 'Your web server does not support HTTP compression.', - detail_web_tls_https_exists_exp: 'We check if your website is reachable on HTTPS.

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

HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user. Note: for performance reasons the tests in the HTTPS test section only run for the first available IPv6 and IPv4 address.', + detail_web_tls_https_exists_exp: 'We check if your website is reachable on HTTPS.

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

HTTPS guarantees the confidentiality and integrity of the exchanged information. Because it is situation depended how (privacy) sensitive and valuable information is, a secure HTTPS configuration is important for every website. Even trivial, public information could be extremely sensitive and valuable for a user.

Note on IPv6/IPv4: for performance reasons all tests in the category \'Secure connection (HTTPS)\' only run for the first available IPv6 and IPv4 address.', detail_web_tls_https_exists_label: 'HTTPS available', detail_web_tls_https_exists_tech_table: 'Web server IP address|HTTPS existent', detail_web_tls_https_exists_verdict_bad: 'Your website does not offer HTTPS.', @@ -1363,7 +1375,7 @@ const internet_nl_messages = { detail_web_tls_kex_hash_func_label: 'Hash function for key exchange', detail_web_tls_kex_hash_func_tech_table: 'Web server IP address|SHA2 support for signatures', detail_web_tls_kex_hash_func_verdict_good: 'Your web server supports a secure hash function for key exchange.', - detail_web_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by your webserver. This could be because the cipher combination used has no signature for certificate verification (e.g it uses RSA key exchange or is anonymous i.e. anon).', + detail_web_tls_kex_hash_func_verdict_other: 'We were unable to determine the hash function used by your web server. This could be because the cipher combination used has no signature for certificate verification (e.g. it uses RSA key exchange or is anonymous i.e. anon).', detail_web_tls_kex_hash_func_verdict_phase_out: 'Your web server 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.', detail_web_tls_ocsp_stapling_exp: '

We check if your web server supports the TLS Certificate Status extension also known as OCSP stapling.

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.

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.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, table 15 (in English).

Requirement level: Optional

OCSP stapling

  • Good: On
  • Sufficient: Off
', detail_web_tls_ocsp_stapling_label: 'OCSP stapling', @@ -1392,7 +1404,7 @@ const internet_nl_messages = { detail_web_tls_zero_rtt_tech_table: 'Web server IP address|0-RTT', detail_web_tls_zero_rtt_verdict_bad: 'Your web server supports 0-RTT, which is not secure.', detail_web_tls_zero_rtt_verdict_good: 'Your web server does not support 0-RTT.', - detail_web_tls_zero_rtt_verdict_na: 'This subtest is not applicable as your webserver does not support TLS 1.3.', + detail_web_tls_zero_rtt_verdict_na: 'This subtest is not applicable as your web server does not support TLS 1.3.', detail_web_mail_ipv6_ns_aaaa_exp: 'We check if your domain name has at least two name servers with an IPv6 address.

This is consistent with the "Technical requirements for the registration and use of .nl domain names" d.d. 13 November 2017 by SIDN (.nl TLD registry) that require each .nl domain to have at least two name servers.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginning with ::ffff:) will fail in this test, as they do not provide IPv6 connectivity.', detail_web_mail_ipv6_ns_aaaa_label: 'IPv6 addresses for name servers', detail_web_mail_ipv6_ns_aaaa_tech_table: 'Name server|IPv6 address|IPv4 address', @@ -1404,29 +1416,31 @@ const internet_nl_messages = { detail_web_mail_ipv6_ns_reach_tech_table: 'Name server|Unreachable IPv6 address', detail_web_mail_ipv6_ns_reach_verdict_bad: 'Not all name servers that have an IPv6 address are reachable over IPv6.', detail_web_mail_ipv6_ns_reach_verdict_good: 'All name servers that have an IPv6 address are reachable over IPv6.', - detail_web_mail_rpki_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your domain.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.

Requirement level: Recommended', + detail_web_mail_rpki_ns_exists_exp: 'We check if an RPKI Route Origin Authorization (ROA) has been published for all IP addresses of the name servers of your domain.

Your hoster (or its network provider) announces through the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. Other network providers use these route announcements to determine via which route to send traffic for your server\'s IP addresses.

However, a route announcement can be faked. In fact, another network provider may be able to connect the IP address block of your IP address to its network and thus potentially receive Internet traffic that is actually intended for your network provider. The cause may be accidental or malicious. In either case, this can result in your server becoming unreachable or in Internet traffic to your server being intercepted.

Resource Public Key Infrastructure (RPKI) significantly improves protection against this. With RPKI, the rightful holder of a block of IP addresses can publish a digitally signed statement with route authorization (Route Origin Authorisation; ROA for short). Another network provider that wants to send Internet traffic to a particular IP address, can use the corresponding statement to filter out Invalid routes. In this way, the network provider prevents Internet traffic from its network from being sent to unauthorized provider networks.', detail_web_mail_rpki_ns_exists_label: 'Route Origin Authorisation existence', detail_web_mail_rpki_ns_exists_tech_table: 'Name server|IP address|RPKI Route Origin Authorization', detail_web_mail_rpki_ns_exists_verdict_bad: 'For at least one of the IP addresses of your name servers no RPKI Route Origin Authorisation (ROA) is published.', detail_web_mail_rpki_ns_exists_verdict_good: 'For all IP addresses of your name servers an RPKI Route Origin Authorisation (ROA) is published.', detail_web_mail_rpki_ns_exists_verdict_no_addresses: 'Your domain does not contain any name servers. Therefore, this subtest could not be performed.', - detail_web_mail_rpki_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your domain is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

  • Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

  • Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");

  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

Note: The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask his network provider that owns your server\'s IP addresses to fix the route configuration error.

  • NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

Requirement level: Recommended', + detail_web_mail_rpki_ns_valid_exp: 'We check if the validation status for all IP addresses of the name servers of your domain is Valid. If there are multiple overlapping route announcements for the IP address, we test that they are all Valid.

Your hoster (or its network provider) announces via the Border Gateway Protocol (BGP) for which of its IP address blocks it accepts incoming Internet traffic. It does this by associating (parts of) its IP address blocks (Route Prefix) with the unique number of its provider network (Route Origin ASN), and then distributing this routing information. Other network providers use these route announcements to determine via which route to send traffic for the IP addresses.

Additionally, for each route announcement, your hoster (or its network provider) should publish a digitally signed statement with route authorisation (Route Origin Authorisation; abbreviated: ROA) statement using Resource Public Key Infrastructure (RPKI).

Another network provider that is asked to send Internet traffic to your server\'s IP address can cryptographically verify the associated statement. The verified content (Validated ROA Payload; abbreviated: VRP) includes which provider networks (VRP ASN) are authorised to receive Internet traffic for each recorded IP address block (VRP Prefix).

The network provider can then use this content to filter BGP routes. For example, he can reject any Invalid routes, to prevent Internet traffic from its network is sent to unauthorised provider networks.

Checking route announcements against route authorisations (RPKI Origin Validation; abbreviated: ROV) has the following three possible outcomes.

1․ Valid: The route announcement of the considered IP address is matched by at least one published route authorisation. A route authorisation is also matched for more specific route announcements (i.e., for a part of the IP address block contained in the route authorisation), unless they are more specific than the limit specified in the route authorisation (via the maxLength attribute).

2․ Invalid: The route announcement of the considered IP address is covered by a route authorisation, but it does not match. There are two possible causes:

  • the IP address block (Route Prefix) is announced from a provider network (Route Origin ASN) that is not authorised in the route authorisation (result in the table below: "invalid (as)");
  • the IP address block (Route Prefix) that is announced is smaller than is allowed in the route authorisation, i.e. exceeding maxLength value (result in table below: "invalid (length)").

3․ NotFound: No statement with route-authorisation has been found that covers the route announcement of the considered IP address. This makes the routing of Internet traffic to your server less secure. Please contact your hoster about this. He can ask his network provider that owns your server\'s IP addresses to publish route authorisations.

What to do if the test result shows the status Invalid?

The status Invalid indicates an unintentional or malicious route configuration error, that can be caused by your hoster or its network provider (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your hoster as soon as possible. In the case of an internal error, your hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error. ', detail_web_mail_rpki_ns_valid_label: 'Route announcement validity', detail_web_mail_rpki_ns_valid_tech_table: 'Name server|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation state', detail_web_mail_rpki_ns_valid_verdict_bad: 'At least one IP address of your name servers has a NotFound validation state. There is no RPKI Route Origin Authorisation (ROA) is published for its route announcement.', detail_web_mail_rpki_ns_valid_verdict_good: 'All IP addresses of your name servers have a Valid validation state. The route announcement of these IP addresses is matched by the published RPKI Route Origin Authorisation (ROA).', - detail_web_mail_rpki_ns_valid_verdict_invalid: 'At least one IP address of your name servers has an Invalid validation state. The route announcement of the affected IP adresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your name server hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your name server hoster as soon as possible. In the case of an internal error, your name server hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', + detail_web_mail_rpki_ns_valid_verdict_invalid: 'At least one IP address of your name servers has an Invalid validation state. The route announcement of the affected IP addresses is not matched by the published RPKI Route Origin Authorisation (ROA). This indicates an unintentional or malicious route configuration error, that can be caused by your name server hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your name server hoster as soon as possible. In the case of an internal error, your name server hoster should ask its network provider that owns your server\'s IP addresses to fix the route configuration error.', detail_web_mail_rpki_ns_valid_verdict_not_routed: 'This subtest did not run, because no route announcement was available for any of the IP addresses.', domain_pagetitle: 'Website test:', domain_title: 'Website test: {{prettyaddr}}', domain_tweetmessage: 'The%20website%20{{report.domain}}%20scores%20{{score}}%25%20in%20the%20website%20test%20of%20%40Internet_nl%3A', faqs_appsecpriv_title: 'Security options', faqs_badges_title: 'Using the 100% badges', + faqs_batch_and_dashboard_title: 'Batch API and web-based dashboard', faqs_dnssec_title: 'Domain signature (DNSSEC)', faqs_halloffame_title: 'Criteria for \'Hall of Fame for Hosters\'', faqs_https_title: 'Secure website connection (HTTPS)', faqs_ipv6_title: 'Modern address (IPv6)', faqs_mailauth_title: 'Protection against email phishing (DMARC, DKIM and SPF)', + faqs_measurements_title: 'Measurements using Internet.nl', faqs_report_score_title: 'Norm and score', faqs_report_subtest_bad: 'Bad: fail on REQUIRED subtest ⇒ null score', faqs_report_subtest_error: 'Test error: error encountered during testing ⇒ null score', @@ -1477,7 +1491,7 @@ const internet_nl_messages = { page_gotofooter: 'Go to the footer', page_gotomainmenu: 'Go to the main menu', page_metadescription: 'Test for modern Internet Standards IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI and security.txt', - page_metakeywords: 'IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, test tool, check, validation, Internet, Internet Standards, open standards, modern standards, security, internet security, mail, email security, website, website security, internet connection, secure connection, email authentication, encryption, ciphers, cipher suites, PKI, SSL certificate, TLS certificate, website certificaat, Internet Standards Platform', + page_metakeywords: 'IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, test tool, check, validation, Internet, Internet Standards, open standards, modern standards, security, internet security, mail, email security, website, website security, internet connection, secure connection, email authentication, encryption, ciphers, cipher suites, PKI, SSL certificate, TLS certificate, website certificate, Internet Standards Platform', page_sitedescription: 'Is your Internet up-to-date?', page_sitetitle: 'Internet.nl', page404_title: 'Page not found!', @@ -1587,7 +1601,9 @@ const internet_nl_messages = { test_mailipv6_title: 'Reachable via modern internet address?', test_mailipv6_warning_description: 'Too bad! Your mail server can not be reached by senders using modern addresses (IPv6), or improvement is possible. Therefore your mail server is not part of the modern Internet yet. You should ask your email provider to fully enable IPv6.', test_mailipv6_warning_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_mailrpki_failed_description: 'Too bad! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster or your name server hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your mail hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', + test_mailrpki_error_description: 'Test not ready to run yet. Please try again later. Sorry for the inconvenience.', + test_mailrpki_error_summary: 'Test not ready to run (RPKI)', + test_mailrpki_failed_description: 'Too bad! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your mail hoster or your name server hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your mail hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', test_mailrpki_failed_summary: 'Unauthorised route announcement (RPKI)', test_mailrpki_info_description: 'Informational: Your domain does not contain any name servers and thus contains no receiving mail server(s). There are no routable IP addresses that could be tested (RPKI).', test_mailrpki_info_summary: 'No routable IP addresses found (RPKI)', @@ -1595,7 +1611,7 @@ const internet_nl_messages = { test_mailrpki_passed_description: 'Well done! All IP addresses of your receiving mail server(s) and associated name servers have a route announcement that is matched by the published route authorisation (RPKI). As a result, email transport between sending mail servers with enabled route validation and your receiving mail server(s) is better protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers.', test_mailrpki_passed_summary: 'Authorised route announcement (RPKI)', test_mailrpki_title: 'Route authorisation?', - test_mailrpki_warning_description: 'Warning! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, email transport between sending mail servers with enabled route validation and your receiving mail server(s) is not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', + test_mailrpki_warning_description: 'Too bad! At least one of the IP addresses of your receiving mail server(s) and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, email transport between sending mail servers with enabled route validation and your receiving mail server(s) is not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', test_mailrpki_warning_summary: 'Route authorisation not published (RPKI)', test_mailtls_failed_description: 'Too bad! Sending mail servers that support secure email transport (STARTTLS and DANE) can establish no or an insufficiently secure connection with your receiving mail server(s). Passive and/or active attackers will therefore be able to read emails in transit to you. You should ask your mail provider to enable STARTTLS and DANE, and configure it securely.', test_mailtls_failed_summary: 'Mail server connection not or insufficiently secured (STARTTLS and DANE)', @@ -1604,9 +1620,9 @@ const internet_nl_messages = { test_mailtls_invalid_null_mx_description: 'Warning: Your domain advertises a "Null MX" record indicating that it does not accept email. However, either your domain does not have A/AAAA records, making the "Null MX" record unnecessary. Or on your domain a receiving mail server is set by another MX record, making the "Null MX" conflicting. ', test_mailtls_invalid_null_mx_summary: 'Inconsistently configured non-receiving mail domain (STARTTLS and DANE)', test_mailtls_label: 'Secure mail server connection (STARTTLS and DANE)', - test_mailtls_no_mx_description: 'Informational: No receiving mail servers (MX) are set on your domain that does not have A/AAAA records. This is fine if you do not want to receive email. Note that you do not need a \'Null MX\' record in this case. Your configuration makes the subtests in the STARTTLS and DANE category not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. ', + test_mailtls_no_mx_description: 'Informational: The SPF record on your domain indicates that your domain may be used for sending mail. However, your domain does not have a receiving mail server (MX), which could hinder deliverability of your sent mails because not having an MX may be seen by receivers as an indicator for spam. Therefore if you really want to send mail from this domain, configure an MX. However, if you do not want to send mail from this domain, configure an SPF record with the -all term only and besides a "Null MX" record if your domain has A/AAAA records. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', test_mailtls_no_mx_summary: 'Properly configured non-receiving mail domain (STARTTLS and DANE)', - test_mailtls_no_null_mx_description: 'Informational: No receiving mail servers (MX) are set on your domain that has A/AAAA records. We recommend you to explicitly indicate that your domain does not accept email by configuring a "Null MX" record. Your current configuration makes the subtests in the STARTTLS and DANE category not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. ', + test_mailtls_no_null_mx_description: 'Informational: No receiving mail servers (MX) are set on your domain that has A/AAAA records and has an SPF record with only the term -all. We recommend you to set a "Null MX" record to explicitly indicate that your domain does not accept email. Because of your configuration, the subtests in the STARTTLS and DANE category and the mail server specific subtests in the IPv6 and DNSSEC categories are not applicable.', test_mailtls_no_null_mx_summary: 'Not explicitly configured non-receiving mail domain (STARTTLS and DANE)', test_mailtls_null_mx_description: 'Informational: Your domain that has A/AAAA records, clearly indicates that it does not accept email by advertising a "Null MX" record. This is fine if you do not want to receive email. Your configuration makes the subtests in the STARTTLS and DANE category not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC.', test_mailtls_null_mx_summary: 'Properly configured non-receiving mail domain (STARTTLS and DANE)', @@ -1617,21 +1633,21 @@ const internet_nl_messages = { test_mailtls_passed_description: 'Well done! Sending mail servers supporting secure email transport (STARTTLS and DANE) can establish a secure connection with your receiving mail server(s). STARTTLS prevents passive attackers from reading emails in transit to you. DANE protects against active attackers stripping STARTTLS encryption by manipulating the mail traffic.', test_mailtls_passed_summary: 'Mail server connection sufficiently secured (STARTTLS and DANE)', test_mailtls_title: 'Secure mail server connection?', - test_mailtls_unreachable_description: 'Test error: at least one of your receiving mail servers was not reachable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by network connectivity problems or by the mailserver(s) not accepting connections.', + test_mailtls_unreachable_description: 'Test error: at least one of your receiving mail servers was not reachable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by network connectivity problems or by the mail server(s) not accepting connections.', test_mailtls_unreachable_summary: 'Unreachable receiving mail server (STARTTLS and DANE)', - test_mailtls_untestable_description: 'Test error: at least one of your receiving mail servers was not testable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by, among other things, SMTP errors and ratelimiting measures engaging and dropping connections.', + test_mailtls_untestable_description: 'Test error: at least one of your receiving mail servers was not testable for us, making it impossible to (fully) test for STARTTLS and DANE. This could be caused by, among other things, SMTP errors and rate limiting measures engaging and dropping connections.', test_mailtls_untestable_summary: 'Untestable mail server (STARTTLS and DANE)', test_mailtls_warning_description: 'Too bad! Sending mail servers that support secure email transport (STARTTLS and DANE) can establish no or an insufficiently secure connection with your receiving mail server(s). Passive and/or active attackers will therefore be able to read emails in transit to you. You should ask your mail provider to enable STARTTLS and DANE, and configure it securely.', test_mailtls_warning_summary: 'Mail server connection not or insufficiently secured (STARTTLS and DANE)', - test_siteappsecpriv_failed_description: 'Too bad! Not all required security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code). ', + test_siteappsecpriv_failed_description: 'Too bad! Not all required security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options.', test_siteappsecpriv_failed_summary: 'One or more required security options not set (Security options)', - test_siteappsecpriv_info_description: 'Informational: Not all optional security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code).', + test_siteappsecpriv_info_description: 'Informational: Not all optional security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with HTTP response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options.', test_siteappsecpriv_info_summary: 'One or more optional security options not set (Security options)', test_siteappsecpriv_label: 'Security options', - test_siteappsecpriv_passed_description: 'Well done! All security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code). ', + test_siteappsecpriv_passed_description: 'Well done! All security options, i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with HTTP response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options.', test_siteappsecpriv_passed_summary: 'All security options set (Security options) ', test_siteappsecpriv_title: 'Security options set?', - test_siteappsecpriv_warning_description: 'Warning: Not all recommended security options, , i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact infomation and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. Security headers (except for Referrer-Policy) are not relevant for domains that redirect (through a 301/302 HTTP Status Code). ', + test_siteappsecpriv_warning_description: 'Warning: Not all recommended security options, , i.e. security headers and security.txt, are set for your website (Security options). With security headers you can activate browser mechanisms to protect visitors against attacks involving, for example, cross-site scripting (XSS) or framing. Security headers are also relevant for domains with HTTP response codes such as \'301 Redirect\' and \'404 Not Found\', because they create their own browsing context (MIME type \'text/html\') that may be vulnerable to certain attacks. Through a security.txt file you can provide researchers who have found a vulnerability on your systems, with your contact information and your Coordinated Vulnerability Disclosure policy. Note that HTTPS is a prerequisite for all tested security options. ', test_siteappsecpriv_warning_summary: 'One or more recommended security options not set (Security options)', test_sitednssec_failed_description: 'Too bad! Your domain is not signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are not protected against manipulated translation from your domain into rogue internet addresses. You should ask your name server operator (often your registrar and/or hosting provider) to enable DNSSEC.', test_sitednssec_failed_summary: 'Domain name not signed (DNSSEC)', @@ -1653,7 +1669,9 @@ const internet_nl_messages = { test_siteipv6_title: 'Reachable via modern address?', test_siteipv6_warning_description: 'Too bad! Your website is not reachable for visitors using a modern internet address (IPv6), or improvement is possible. Therefore your website is not part of the modern Internet yet. You should ask your hosting provider to fully enable IPv6.', test_siteipv6_warning_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_siterpki_failed_description: 'Too bad! At least one of the IP addresses of your web server and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster or your name server hoster (internal error) or by a third party (external error). In either case, it can lead to the unreachability of your server or the interception of Internet traffic to your server. Contact your web hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', + test_siterpki_error_description: 'Test not ready to run yet. Please try again later. Sorry for the inconvenience.', + test_siterpki_error_summary: 'Test not ready to run (RPKI)', + test_siterpki_failed_description: 'Too bad! At least one of the IP addresses of your web server and associated name servers has a route announcement that is not matched by the published route authorisation (RPKI). This indicates an unintentional or malicious route configuration error, that can be caused by your web hoster or your name server hoster (internal error) or by a third party (external error). In either case, it increases the risk for unreachability of your server or for interception of Internet traffic to your server. Contact your web hoster or name server hoster as soon as possible. In the case of an internal error, they should ask their network provider that owns your server\'s IP addresses to fix the route configuration error.', test_siterpki_failed_summary: 'Unauthorised route announcement (RPKI)', test_siterpki_info_description: 'Informational: Your domain does not contain any name servers and thus contains no web server IP addresses. There are no routable IP addresses that could be tested (RPKI).', test_siterpki_info_summary: 'No routable IP addresses found (RPKI)', @@ -1661,7 +1679,7 @@ const internet_nl_messages = { test_siterpki_passed_description: 'Well done! All IP addresses of your web server and associated name servers have a route announcement that is matched by the published route authorisation (RPKI). As a result, visitors with enabled route validation are better protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers.', test_siterpki_passed_summary: 'Authorised route announcement (RPKI)', test_siterpki_title: 'Route authorisation?', - test_siterpki_warning_description: 'Warning! At least one of the IP addresses of your web server and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, visitors with enabled route validation are not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', + test_siterpki_warning_description: 'Too bad! At least one of the IP addresses of your web server and associated name servers has a route announcement for which no route authorisation is published (RPKI). As a result, visitors with enabled route validation are not (fully) protected against various unintentional or malicious route configuration errors, that can lead to the unreachability of your servers or the interception of Internet traffic to your servers. Contact your mail hoster or name server hoster about this. They can ask their network provider that owns your server\'s IP addresses to publish routing authorizations.', test_siterpki_warning_summary: 'Route authorisation not published (RPKI)', test_sitetls_failed_description: 'Too bad! The connection with your website is not or insufficientlysecured (HTTPS). Therefore information in transit between your website and its visitors is not sufficiently protected against eavesdropping and tampering. You should ask your hosting provider to enable HTTPS and to configure it securely.', test_sitetls_failed_summary: 'Connection not or insufficiently secured (HTTPS)', @@ -1671,11 +1689,11 @@ const internet_nl_messages = { test_sitetls_passed_description: 'Well done! The connection with your website is sufficiently secured (HTTPS). Therefore information in transit between your website and its visitors is protected against eavesdropping and tampering.', test_sitetls_passed_summary: 'Connection sufficiently secured (HTTPS)', test_sitetls_title: 'Secure connection?', - test_sitetls_unreachable_description: 'Your webserver was not reachable for us, making it impossible to (fully) test for HTTPS. This could be caused by network connectivity problems or by the webserver not accepting connections.', - test_sitetls_unreachable_summary: 'Unreachable webserver (HTTPS)', + test_sitetls_unreachable_description: 'Your web server was not reachable for us, making it impossible to (fully) test for HTTPS. This could be caused by network connectivity problems or by the web server not accepting connections.', + test_sitetls_unreachable_summary: 'Unreachable web server (HTTPS)', test_sitetls_warning_description: 'Too bad! The connection with your website is not or insufficientlysecured (HTTPS). Therefore information in transit between your website and its visitors is not sufficiently protected against eavesdropping and tampering. You should ask your hosting provider to enable HTTPS and to configure it securely.', test_sitetls_warning_summary: 'Connection not or insufficiently secured (HTTPS)', - widget_content_notes: '

Notes

  • Logo: We recommend you to save and use our logo on your own web server. In that way there will not be any contact with our web server when your website is visited.
  • Content-Security-Policy (CSP): In case you are using a CSP policy for your website you would also need to add internet.nl to the rules for form-action and possibly also for img-src in case you link to the logo on our webserver.
', + widget_content_notes: '

Notes

  • Logo: We recommend you to save and use our logo on your own web server. In that way there will not be any contact with our web server when your website is visited.
  • Content-Security-Policy (CSP): In case you are using a CSP policy for your website you would also need to add internet.nl to the rules for form-action and possibly also for img-src in case you link to the logo on our web server.
', widget_mail_html_block: 'Test your email', widget_mail_intro: '

Email test widget

Would you like visitors of your website to be able to directly start an email test?
Copy the HTML and CSS code from the text fields below into the source code of your website.

', widget_site_html_block: 'Test your website', diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.js b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.js index 43d58ead..9f24d384 100644 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.js +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.js @@ -68,7 +68,7 @@ const internet_nl_messages = { detail_conn_ipv6_resolver_conn_label: 'IPv6-connectiviteit van DNS-resolver', detail_conn_ipv6_resolver_conn_verdict_bad: 'Je DNS-resolver kan niet nameservers via IPv6 bereiken.', detail_conn_ipv6_resolver_conn_verdict_good: 'Je DNS-resolver kan nameservers via IPv6 bereiken.', - detail_mail_auth_dkim_exp: 'We testen of je domeinnaam DKIM ondersteunt. Een ontvangende mailserver kande publieke sleutel in je DKIM-record gebruiken om de handtekening in eene-mail met een gebruiker van jouw domein als afzender te controleren en deauthenticiteit van de e-mail te bepalen.

  • Om te slagen voor deze test verwachten we dat je nameserver NOERROR antwoordt op onze bevragingvoor _domainkey.example.nl. Als _domainkey.example.nl een \'empty non-terminal\' is, dan zullen sommige nameservers die zich niet houden aan destandaard RFC 2308, foutief antwoorden met NXDOMAIN in plaats vanNOERROR. Dit maakt het detecteren van het DKIM-record voor ons onmogelijk.
  • Op dit moment zijn we niet in staat om de publieke sleutel in je DKIM-record op te vragen en te beoordelen, omdat we daarvoor een e-mail van jouw domein zouden moeten ontvangen.
  • Bij deze test gaan we uit van \'strict alignment\' hetgeen conform DMARC is. Het geteste domein wordt beschouwd als het verzenddomein in het mailbericht (From:) en moet gelijk zijn aan zowel het DKIM-domein (d=) als het SPF-domein (envelope sender, d.w.z. return-path dat terugkomt in MAIL FROM).

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', + detail_mail_auth_dkim_exp: '

We testen of je domeinnaam DKIM ondersteunt. Een ontvangende mailserver kande publieke sleutel in je DKIM-record gebruiken om de handtekening in eene-mail met een gebruiker van jouw domein als afzender te controleren en deauthenticiteit van de e-mail te bepalen.

  • Om te slagen voor deze test verwachten we dat je nameserver NOERROR antwoordt op onze bevragingvoor _domainkey.example.nl. Als _domainkey.example.nl een \'empty non-terminal\' is, dan zullen sommige nameservers die zich niet houden aan destandaard RFC 2308, foutief antwoorden met NXDOMAIN in plaats vanNOERROR. Dit maakt het detecteren van het DKIM-record voor ons onmogelijk.
  • Op dit moment zijn we niet in staat om de publieke sleutel in je DKIM-record op te vragen en te beoordelen, omdat we daarvoor een e-mail van jouw domein zouden moeten ontvangen.
  • Bij deze test gaan we uit van \'strict alignment\' hetgeen conform DMARC is. Het geteste domein wordt beschouwd als het verzenddomein in het mailbericht (From:) en moet gelijk zijn aan zowel het DKIM-domein (d=) als het SPF-domein (envelope sender, d.w.z. return-path dat terugkomt in MAIL FROM).

Aanvullende opmerkingen:

  • Sommige e-mailsystemen wijzigen e-mail tijdens het transport, waardoor een DKIM-handtekening mogelijk ongeldig wordt. In veel gevallen zijn deze wijzigingen onschuldig. Voorbeelden zijn het vervangen van witruimte en het herordenen van headervelden. Als u een DKIM-ondertekenende verzender bent, dan kunt u kiezen of u dit soort wijzigingen wel of niet tolereert, zowel voor de header als voor de body van e-mails. De simple instelling tolereert bijna geen wijzigingen en relaxed tolereert veel voorkomende wijzigingen. Als er geen instelling is opgegeven, wordt standaard simple gebruikt voor zowel de header als de body. Met name headerwijzigingen zijn een veelvoorkomende oorzaak dat een DKIM-handtekening onbedoeld ongeldig wordt, waardoor de bezorgbaarheid wordt belemmerd. Het gebruik van relaxed voor de header en simple voor de body (c=relaxed/simple) kan dit soort problemen verminderen.
  • Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.
', detail_mail_auth_dkim_label: 'DKIM aanwezigheid', detail_mail_auth_dkim_verdict_bad: 'Je domeinnaam ondersteunt geen DKIM-records.', detail_mail_auth_dkim_verdict_good: 'Je domeinnaam ondersteunt DKIM-records.', @@ -78,7 +78,7 @@ const internet_nl_messages = { detail_mail_auth_dmarc_tech_table: 'DMARC-record|Gevonden op', detail_mail_auth_dmarc_verdict_bad: 'Je domeinnaam heeft geen DMARC-record.', detail_mail_auth_dmarc_verdict_good: 'Je domeinnaam heeft een DMARC-record.', - detail_mail_auth_dmarc_policy_exp: '

We controleren of de syntax van je DMARC-record correct is en of deze een voldoende strikte policy bevat (p=quarantine of p=reject) om misbruik van je domein door phishers en spammers tegen te gaan. Zelfs zonder een strikte policy kan DMARC nuttig zijn om met behulp van DMARC-rapporten meer inzicht te verkrijgen in legale en illegale uitgaande e-mailstromen. Maar om DMARC effectief te laten zijn tegen misbruik van je domein, is een liberale policy (p=none) niet voldoende.

We controleren ook of de mailadressen onder rua= en ruf= geldig zijn. Als deze een extern e-mailadres bevatten dan controleren we of het externe domein geautoriseerd is om DMARC-rapportages te ontvangen. Zorg ervoor dat het DMARC-autorisatierecord op het externe domein ten minste "v=DMARC1;" bevat.

De test staat het gebruik van de experimentele np tag toe (RFC 9091).

Good practice voor domeinnaam zonder mail:

  • Niet-verzendend: Gebruik de meest strikte DMARC policy (p=reject) en SPF policy (-all) voor (sub-)domeinnamen die je niet gebruikt om mail vanaf te versturen, om misbruik (\'spoofing\') tegen te gaan. Merk op dat DKIM in dit geval niet noodzakelijk is.
  • Niet-ontvangend: Voor meer informatie over "Null MX" en "No MX" zie de uitleg van de "STARTTLS beschikbaar" subtest.

Hieronder volgen twee basisvoorbeelden van de DNS-configuratie voor een domeinnaam die niet gebruikt wordt voor het verzenden en ontvangen van mail.

A. Enkele domeinnaam zonder A- of AAAA-record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Enkele domeinnaam met A- of AAAA-record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', + detail_mail_auth_dmarc_policy_exp: '

We controleren of de syntax van je DMARC-record correct is en of deze een voldoende strikte policy bevat (p=quarantine of p=reject) om misbruik van je domein door phishers en spammers tegen te gaan. Zelfs zonder een strikte policy kan DMARC nuttig zijn om met behulp van DMARC-rapporten meer inzicht te verkrijgen in legale en illegale uitgaande e-mailstromen. Maar om DMARC effectief te laten zijn tegen misbruik van je domein, is een liberale policy (p=none) niet voldoende.

We controleren ook of de mailadressen onder rua= en ruf= geldig zijn. Als deze een extern e-mailadres bevatten dan controleren we of het externe domein geautoriseerd is om DMARC-rapportages te ontvangen. Zorg ervoor dat het DMARC-autorisatierecord op het externe domein ten minste "v=DMARC1;" bevat.

De test staat het gebruik van de experimentele np tag toe (RFC 9091).

Good practice voor domeinnaam zonder mail:

  • Niet-verzendend: Gebruik de meest strikte DMARC policy (p=reject) en SPF policy (-all) voor (sub-)domeinnamen die je niet gebruikt om mail vanaf te versturen, om misbruik (\'spoofing\') tegen te gaan. Merk op dat DKIM in dit geval niet noodzakelijk is.
  • Niet-ontvangend: Voor meer informatie over "Null MX" en "No MX" zie de uitleg van de "STARTTLS beschikbaar" subtest.

Hieronder volgen twee basisvoorbeelden van de DNS-configuratie voor een domeinnaam die niet gebruikt wordt voor het verzenden en ontvangen van mail.

A. Enkele domeinnaam zonder A- of AAAA-record

example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"_dmarc.example.nl. TXT "v=DMARC1; p=reject;"

 

B. Enkele domeinnaam met A- of AAAA-record

example.nl. AAAA 2a00:d78:0:712:94:198:159:35example.nl. A 94.198.159.35example.nl. MX 0 .example.nl. TXT "v=spf1 -all"*.example.nl. TXT "v=spf1 -all"www.example.nl. CNAME example.nl_dmarc.example.nl. TXT "v=DMARC1; p=reject;"
', detail_mail_auth_dmarc_policy_label: 'DMARC policy', detail_mail_auth_dmarc_policy_verdict_bad: 'Je DMARC-policy is syntactisch niet correct.', detail_mail_auth_dmarc_policy_verdict_external: 'De domeinnaam van het mailadres na rua= en/of ruf= bevat geen (geldig) autorisatie-record om DMARC-rapporten te ontvangen voor de geteste domeinnaam. ', @@ -111,7 +111,7 @@ const internet_nl_messages = { detail_mail_dnssec_mx_exists_verdict_bad: 'Tenminste één van jouw mailserverdomeinen is onveilig oftewel \'insecure\', omdat deze niet ondertekend is met DNSSEC.', detail_mail_dnssec_mx_exists_verdict_good: 'Al je mailserverdomeinen zijn ondertekend met DNSSEC.', detail_mail_dnssec_mx_exists_verdict_invalid_null_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', - detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. ', + detail_mail_dnssec_mx_exists_verdict_no_mailservers: 'Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_dnssec_mx_exists_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je domeinnaam geen e-mail accepteert door een "Null MX" record te publiceren. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_dnssec_mx_exists_verdict_null_mx: 'Je domeinnaam die A/AAAA-records heeft, geeft met een "Null MX" record duidelijk aan geen e-mail te accepteren. Dat is prima als je geen e-mail wilt ontvangen. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_dnssec_mx_exists_verdict_null_mx_with_other_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', @@ -136,41 +136,41 @@ const internet_nl_messages = { detail_mail_ipv6_mx_aaaa_verdict_bad: 'Tenminste één ontvangende mailserver op jouw domeinnaam heeft geen IPv6-adres.', detail_mail_ipv6_mx_aaaa_verdict_good: 'Alle ontvangende mailservers op jouw domeinnaam hebben een IPv6-adres.', detail_mail_ipv6_mx_aaaa_verdict_invalid_null_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld met een ander MX record, waardoor de "Null MX" tegenstrijdig is.', - detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je domeinnaam geen e-mail accepteert door een "Null MX" record te publiceren. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', + detail_mail_ipv6_mx_aaaa_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-records heeft en dat een SPF-record heeft met alleen de term -all. We raden je aan een "Null MX" record in te stellen om expliciet aan te geven dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_ipv6_mx_aaaa_verdict_null_mx: 'Je domeinnaam die A/AAAA-records heeft, geeft met een "Null MX" record duidelijk aan geen e-mail te accepteren. Dat is prima als je geen e-mail wilt ontvangen. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_with_other_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', detail_mail_ipv6_mx_aaaa_verdict_null_mx_without_a_aaaa: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is.', - detail_mail_ipv6_mx_aaaa_verdict_other: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. ', + detail_mail_ipv6_mx_aaaa_verdict_other: 'Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_ipv6_mx_reach_exp: 'We testen of we je mailservers (MX) kunnen bereiken via IPv6 op poort 25. We testen alle IPv6-adressen die we ontvangen van de nameservers van je mailserverdomein(en). Een deelscore wordt gegeven als niet alle IPv6-adressen bereikbaar zijn. Als een IPv6-adres (syntactisch) ongeldig is, dan beschouwen we dat als onbereikbaar.', detail_mail_ipv6_mx_reach_label: 'IPv6-bereikbaarheid van mailserver(s)', detail_mail_ipv6_mx_reach_tech_table: 'Mailserver (MX)|Onbereikbaar IPv6-adres', detail_mail_ipv6_mx_reach_verdict_bad: 'Tenminste één van je ontvangende mailservers met een IPv6-adres is niet bereikbaar via IPv6.', detail_mail_ipv6_mx_reach_verdict_good: 'Al je ontvangende mailservers met een IPv6-adres zijn bereikbaar via IPv6.', - detail_mail_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar uw server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar uw server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_mail_rpki_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_mail_rpki_exists_tech_table: 'Mailserver|IP-adres|RPKI Route Origin Authorization', detail_mail_rpki_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van je ontvangende mailserver(s) is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_exists_verdict_good: 'Voor alle IP-adressen van je ontvangende mailserver(s) is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_exists_verdict_no_addresses: 'Je domein bevat geen ontvangende mailservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_mail_rpki_mx_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_mx_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je mailserver(s) (MX).

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_mail_rpki_mx_ns_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_mail_rpki_mx_ns_exists_tech_table: 'Nameserver van MX|IP-adres|RPKI Route Origin Authorization', detail_mail_rpki_mx_ns_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van de nameservers van je mailserver(s) is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_mx_ns_exists_verdict_good: 'Voor alle IP-adressen van de nameservers van je mailserver(s) is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_mail_rpki_mx_ns_exists_verdict_no_addresses: 'Je domein bevat geen mailservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_mail_rpki_mx_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_mx_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_mail_rpki_mx_ns_valid_label: 'Geldigheid van route-aankondiging', detail_mail_rpki_mx_ns_valid_tech_table: 'Nameserver van MX|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_mail_rpki_mx_ns_valid_verdict_bad: 'Ten minste één IP-adres van de nameservers van je ontvangende mailservers heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorization (ROA) gepubliceerd voor de route-aankondiging van ieder van de desbetreffende IP-adressen.', detail_mail_rpki_mx_ns_valid_verdict_good: 'Alle IP-adressen van de nameservers van je ontvangende mailservers hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_mx_ns_valid_verdict_invalid: 'Tenminste één IP-adres van de nameservers van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_mail_rpki_mx_ns_valid_verdict_invalid: 'Tenminste één IP-adres van de nameservers van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_mail_rpki_mx_ns_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', - detail_mail_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

Niveau van vereistheid: Aanbevolen', + detail_mail_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je mailservers (MX) Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_mail_rpki_valid_label: 'Geldigheid van route-aankondiging', detail_mail_rpki_valid_tech_table: 'Mailserver|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_mail_rpki_valid_verdict_bad: 'Ten minste één IP-adres van je ontvangende mailservers heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorization (ROA) gepubliceerd voor de route-aankondiging van ieder van de desbetreffende IP-adressen.', detail_mail_rpki_valid_verdict_good: 'Alle IP-adressen van je ontvangende mailservers hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_mail_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_mail_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je ontvangende mailservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je mailhoster. Bij een interne fout moet je mailhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_mail_rpki_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', detail_mail_tls_cert_hostmatch_exp: 'We testen of de domeinnaam van ieder van je ontvangende mailservers (MX) overeenkomt met de domeinnaam op het gepresenteerde certificaat.

Verzendende mailservers negeren doorgaans het domein op het certificaat. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor voegt de controle of de domeinnaam op het certificaat overeenkomt met het mailserverdomeinnaam geen enkele authenticiteitswaarde toe. 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. 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).

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B3-1.

Niveau van vereistheid: Optioneel / Vereist (alleen als DANE-TA wordt gebruikt)', detail_mail_tls_cert_hostmatch_label: 'Domeinnaam op certificaat', @@ -193,7 +193,7 @@ const internet_nl_messages = { detail_mail_tls_cert_trust_tech_table: 'Mailserver (MX)|Onvertrouwde certificaatketen', detail_mail_tls_cert_trust_verdict_bad: 'De vertrouwensketen van tenminste één van je mailserver-certificaten is niet compleet en/of niet ondertekend door een vertrouwde certificaatautoriteit.', detail_mail_tls_cert_trust_verdict_good: 'De vertrouwensketen van al je mailserver-certificaten is compleet én ondertekend door een vertrouwde certificaatautoriteit.', - detail_mail_tls_cipher_order_exp: 'We testen of je ontvangende mailservers (MX) hun eigen cipher-voorkeur afdwingen (\'I\'), en ciphers aanbieden conform de voorgeschreven volgorde (\'II\').

Als je mailserver alleen \'Goede\' ciphers ondersteunt, dan is deze test niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

I. Server afgedwongen cipher-volgorde: Ontvangende mailservers dwingen hun cipher-voorkeur af tijdens de onderhandeling met verzendende mailservers, en accepteren geen voorkeur van de verzendende mailservers;

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.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', + detail_mail_tls_cipher_order_exp: 'We testen of je ontvangende mailservers (MX) hun eigen cipher-voorkeur afdwingen (\'I\'), en ciphers aanbieden conform de voorgeschreven volgorde (\'II\').

Als je mailserver alleen \'Goede\' ciphers ondersteunt, dan is deze test niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

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;

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.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', detail_mail_tls_cipher_order_label: 'Cipher-volgorde', detail_mail_tls_cipher_order_tech_table: 'Mail server (MX)|Eerst gevonden getroffen cipher-paren|Overtreden regel # (\'II-B\')', detail_mail_tls_cipher_order_verdict_bad: 'Tenminste één van je mailservers dwingt niet zijn eigen cipher-voorkeur af (\'I\').', @@ -218,7 +218,7 @@ const internet_nl_messages = { detail_mail_tls_dane_exists_verdict_bad: 'Tenminste één van je mailserverdomeinen bevat geen TLSA-record voor DANE.', detail_mail_tls_dane_exists_verdict_bogus: 'Tenminste één van je mailserverdomeinen bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Dit kan leiden tot afleveringsproblemen van mail die aan aan jou gericht is door DANE-validerende mailverstuurders. Vraag je nameserver-beheerder om deze fout op te lossen.', detail_mail_tls_dane_exists_verdict_good: 'Al je mailserverdomeinen bevatten een TLSA-record voor DANE.', - detail_mail_tls_dane_rollover_exp: 'We testen of er een actief schema met tenminste twee DANE TLSA records is om de vervanging van certificaten op je ontvangende mailservers (MX) betrouwbaar te kunnen uitvoeren.

Een dergelijk schema is vooral handig bij het vervangen van je mailserver-certificaten. Het kan voorkomen dat DANE tijdens de vervangingsperiode ongeldig raakt waardoor aan jouw domein gerichte mail niet afgeleverd wordt. Een vervangingsschema voor DANE kan maar hoeft niet continu \'actief\' te zijn.

We adviseren je om één van de twee volgende schema\'s met dubbele DANE TLSA records toe te passen:

  1. Huidige + Volgende ("3 1 1" + "3 1 1"): Publiceer twee "DANE-EE(3) SPKI(1) SHA2-256(1)" records, één voor het huidige en één voor het volgende TLS-certificaat van je mailserver.
  2. Huidige + Uitgever CA ("3 1 1" + "2 1 1"): Publiceer een "DANE-EE(3) SPKI(1) SHA2-256(1)" record voor het huidige TLS-certificaat van je mailserver, en daarnaast een "DANE-TA(2) SPKI(1) SHA2-256(1)" record voor het huidige bovenliggende certificaat van de (niet noodzakelijkerwijs publieke) certificaatautoriteit.

Deze subtest accepteert ook andere combinaties van DANE TLSA records, d.w.z. "3 x x" + "3 x x" of "3 x x" + "2 x x". Andere typen dan de bovengenoemde zijn in de regel gevoeliger voor fouten en minder interoperabel.

Niveau van vereistheid: Optioneel', + detail_mail_tls_dane_rollover_exp: 'We testen of er een actief schema met tenminste twee DANE TLSA records is om de vervanging van certificaten op je ontvangende mailservers (MX) betrouwbaar te kunnen uitvoeren.

Een dergelijk schema is vooral handig bij het vervangen van je mailserver-certificaten. Het kan voorkomen dat DANE tijdens de vervangingsperiode ongeldig raakt waardoor aan jouw domein gerichte mail niet afgeleverd wordt. Een vervangingsschema voor DANE kan maar hoeft niet continu \'actief\' te zijn.

We adviseren je om één van de twee volgende schema\'s met dubbele DANE TLSA records toe te passen:

  1. Huidige + Volgende ("3 1 1" + "3 1 1"): Publiceer twee "DANE-EE(3) SPKI(1) SHA2-256(1)" records, één voor het huidige en één voor het volgende TLS-certificaat van je mailserver.
  2. Huidige + Uitgever CA ("3 1 1" + "2 1 1"): Publiceer een "DANE-EE(3) SPKI(1) SHA2-256(1)" record voor het huidige TLS-certificaat van je mailserver, en daarnaast een "DANE-TA(2) SPKI(1) SHA2-256(1)" record voor het huidige bovenliggende certificaat van de (niet noodzakelijkerwijs publieke) certificaatautoriteit.

Deze subtest accepteert ook andere combinaties van DANE TLSA records, d.w.z. "3 x x" + "3 x x" of "3 x x" + "2 x x". Andere typen dan de bovengenoemde zijn in de regel gevoeliger voor fouten en minder interoperabel.

Merk op dat als een mailserver tegelijkertijd twee certificaten aanbiedt (één gebaseerd op RSA en één gebaseerd op ECDSA), een afzonderlijk DANE TLSA rollover schema wordt aanbevolen voor ieder certificaat. De subtest controleert niet op dit scenario. Als er slechts één DANE TLSA-record is geconfigureerd voor elk certificaat, dan geeft deze subtest een vals-positief resultaat.

Niveau van vereistheid: Optioneel', detail_mail_tls_dane_rollover_label: 'DANE-vervangingsschema', detail_mail_tls_dane_rollover_tech_table: 'Mailserver (MX)|DANE-vervangingsschema', detail_mail_tls_dane_rollover_verdict_bad: 'Tenminste een van je mailserver-domeinen heeft geen actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.', @@ -228,7 +228,7 @@ const internet_nl_messages = { detail_mail_tls_dane_valid_tech_table: 'Mailserver (MX)|DANE TLSA-record geldig', detail_mail_tls_dane_valid_verdict_bad: 'Tenminste één van je mailservers heeft geen geldige DANE-fingerprints. Óf iemand manipuleerde het antwoord van je mailserver, óf je mailserver heeft een ernstige DANE-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor verzendende mailservers die DANE-fingerprints controleren. Neem zo spoedig mogelijk contact op met je mailprovider.', detail_mail_tls_dane_valid_verdict_good: 'Ieder van je mailservers heeft tenminste één geldige DANE-fingerprint. Daardoor kunnen verzendende mailservers die DANE-verificatie ondersteunen, een geauthenticeerde versleutelde transportverbinding met je ontvangende mailserver(s) opzetten.', - detail_mail_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je mailservers (MX), veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', + detail_mail_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je mailservers (MX), veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', detail_mail_tls_fs_params_label: 'Sleuteluitwisselingsparameters', detail_mail_tls_fs_params_tech_table: 'Mailserver (MX)|Getroffen parameters|Veiligheidsniveau', detail_mail_tls_fs_params_verdict_bad: 'Tenminste één van je mailservers ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', @@ -247,7 +247,7 @@ const internet_nl_messages = { detail_mail_tls_ocsp_stapling_verdict_bad: 'OUTDATED TEXT; TEST NOT USED
TODO', detail_mail_tls_ocsp_stapling_verdict_good: 'OUTDATED TEXT; TEST NOT USED
TODO', detail_mail_tls_ocsp_stapling_verdict_ok: 'OUTDATED TEXT; TEST NOT USED
TODO', - detail_mail_tls_renegotiation_client_exp: '

We testen of een verzendende mailserver een renegotiation kan initiëren met jouw ontvangende mailservers (MX).

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', + detail_mail_tls_renegotiation_client_exp: '

We testen of een verzendende mailserver een renegotiation kan initiëren met jouw ontvangende mailservers (MX).

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', detail_mail_tls_renegotiation_client_label: 'Client-initiated renegotiation', detail_mail_tls_renegotiation_client_tech_table: 'Mailserver (MX)|Client-initiated renegotiation', detail_mail_tls_renegotiation_client_verdict_bad: 'Tenminste één van je mailservers staat client-initiated renegotiation toe, wat een negatieve invloed kan hebben op de beschikbaarheid van je mailserver.', @@ -257,18 +257,18 @@ const internet_nl_messages = { detail_mail_tls_renegotiation_secure_tech_table: 'Mailserver (MX)|Secure renegotiation', detail_mail_tls_renegotiation_secure_verdict_bad: 'Tenminste één van je mailservers ondersteunt insecure renegotiation, wat uiteraard niet veilig is.', detail_mail_tls_renegotiation_secure_verdict_good: 'Al je mailservers ondersteunen secure renegotiation.', - detail_mail_tls_starttls_exists_exp: 'We testen of je ontvangende mailservers (MX) ondersteuning bieden voor STARTTLS. Als dat het geval is, dan testen we in de subtesten van deze testcategorie of STARTTLS ook voldoende veilig is geconfigureerd.

Vanwege performance-redenen worden maximaal tien mailservers via of IPv6 of IPv4 getest voor STARTTLS en DANE.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.

Niet ontvangende domeinnaam:

  1. Null MX: Indien je geen mail wenst te ontvangen op je domeinnaam die A/AAAA-records heeft, dan adviseren we om "Null MX" (RFC 7505) te gebruiken. Merk op dat een "Null MX record" niet gecombineerd dient te worden met een gewoon MX-record dat naar een mail-host wijst.

  2. Geen MX: In het geval dat je domein geen A/AAAA-records heeft en je er geen mail op wenst te ontvangen, adviseren we je om helemaal geen MX-record te configureren (dus ook geen "Null MX" record).

  3. Als we een van de twee bovenstaande gevallen ontdekken, zijn de subtesten in de STARTTLS- en DANE-categorie niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtests in de categorieën voor IPv6 en DNSSEC. Andere subtesten van de e-mailtest (bijv. voor DMARC) zijn nog steeds van toepassing.

  4. Merk op dat het hebben van een "Null MX"-record of geen MX-record ook van invloed kan zijn op het verzenden van e-mail, omdat ontvangende servers e-mail kunnen weigeren die een ongeldig retouradres heeft.

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', + detail_mail_tls_starttls_exists_exp: 'We testen of je ontvangende mailservers (MX) ondersteuning bieden voor STARTTLS. Als dat het geval is, dan testen we in de subtesten van deze testcategorie of STARTTLS ook voldoende veilig is geconfigureerd.

Vanwege performance-redenen worden maximaal tien mailservers via of IPv6 of IPv4 getest voor STARTTLS en DANE.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.

Niet ontvangende domeinnaam:

  1. Null MX: Indien je geen mail wenst te ontvangen op je domeinnaam die A/AAAA-records heeft, dan adviseren we om "Null MX" (RFC 7505) te gebruiken. Merk op dat een "Null MX record" niet gecombineerd dient te worden met een gewoon MX-record dat naar een mail-host wijst.

  2. Geen MX: In het geval dat je domein geen A/AAAA-records heeft en je er geen mail op wenst te ontvangen, adviseren we je om helemaal geen MX-record te configureren (dus ook geen "Null MX" record).

  3. Als we een van de twee bovenstaande gevallen ontdekken, zijn de subtesten in de STARTTLS- en DANE-categorie niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtests in de categorieën voor IPv6 en DNSSEC. Andere subtesten van de e-mailtest (bijv. voor DMARC) zijn nog steeds van toepassing.

  4. Merk op dat het hebben van een "Null MX"-record of geen MX-record ook van invloed kan zijn op het verzenden van e-mail, omdat ontvangende servers e-mail kunnen weigeren die een ongeldig retouradres heeft.

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', detail_mail_tls_starttls_exists_label: 'STARTTLS beschikbaar', detail_mail_tls_starttls_exists_tech_table: 'Mailserver (MX)|STARTTLS', detail_mail_tls_starttls_exists_verdict_bad: 'Tenminste één van je mailservers biedt geen STARTTLS aan.', detail_mail_tls_starttls_exists_verdict_good: 'Al je mailservers bieden STARTTLS aan.', detail_mail_tls_starttls_exists_verdict_invalid_null_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', - detail_mail_tls_starttls_exists_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die wel A/AAAA records heeft. We adviseren je om duidelijk te laten zien dat je domeinnaam geen e-mail accepteert door een "Null MX" record te publiceren. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', + detail_mail_tls_starttls_exists_verdict_no_null_mx: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-records heeft en dat een SPF-record heeft met alleen de term -all. We raden je aan een "Null MX" record in te stellen om expliciet aan te geven dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_tls_starttls_exists_verdict_null_mx: 'Je domeinnaam die A/AAAA-records heeft, geeft met een "Null MX" record duidelijk aan geen e-mail te accepteren. Dat is prima als je geen e-mail wilt ontvangen. Gebruik geen "Null MX"-record en stel een MX in als je wel e-mail wil verzenden vanaf deze domeinnaam, aangezien ontvangende servers e-mail met een ongeldig retouradres kunnen weigeren.', detail_mail_tls_starttls_exists_verdict_null_mx_with_other_mx: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', detail_mail_tls_starttls_exists_verdict_null_mx_without_a_aaaa: 'Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is.', detail_mail_tls_starttls_exists_verdict_other: 'Tenminste één van je mailservers is onbereikbaar.', - detail_mail_tls_starttls_exists_verdict_other_2: 'Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. ', + detail_mail_tls_starttls_exists_verdict_other_2: 'Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', detail_mail_tls_version_exp: '

We testen of je ontvangende mailservers (MX) alleen veilige TLS-versies ondersteunen.

Een mailserver kan meer dan één TLS-versie ondersteunen.

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B1-1 en tabel 1

Versie

  • Goed: TLS 1.3
  • Voldoende: TLS 1.2
  • Uit te faseren: TLS 1.1 en 1.0
  • Onvoldoende: SSL 3.0, 2.0 en 1.0
', detail_mail_tls_version_label: 'TLS-versie', detail_mail_tls_version_tech_table: 'Mailserver (MX)|TLS-versies|Status', @@ -307,15 +307,18 @@ const internet_nl_messages = { detail_tech_data_http_referrer_policy_recommendation_strict_origin: 'Aanbeveling: \'strict-origin\' zou niet gebruikt moeten worden.', detail_tech_data_http_referrer_policy_recommendation_strict_origin_when_cross_origin: 'Aanbeveling: \'strict-origin-when-cross-origin\' zou niet gebruikt moeten worden.', detail_tech_data_http_referrer_policy_values: 'Gevonden policy: {values}', + detail_tech_data_http_securitytxt_bom_in_file: 'Fout: De Byte Order Mark ("BOM") handtekening moet niet voorkomen aan het begin van de inhoud die gecodeerd moet zijn met UTF-8 in Net-Unicode vorm.', detail_tech_data_http_securitytxt_data_after_sig: 'Fout: Ondertekende security.txt moet geen gegevens bevatten na de handtekening (regel {line_no}).', detail_tech_data_http_securitytxt_empty_key: 'Fout: Veldnaam moet niet leeg zijn (regel {line_no}).', detail_tech_data_http_securitytxt_empty_value: 'Fout: Veldwaarde moet niet leeg zijn (regel {line_no}).', detail_tech_data_http_securitytxt_expired: 'Fout: Datum en tijd in het veld \'Expires\' moeten niet in het verleden liggen (regel {line_no}).', + detail_tech_data_http_securitytxt_invalid_cert: 'Fout: security.txt moet worden geserveerd met een geldig TLS-certificaat.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_invalid_charset: 'Fout: Charset parameter in Content-Type header moet \'utf-8\' zijn indien aanwezig.', detail_tech_data_http_securitytxt_invalid_expiry: 'Fout: Datum en tijd in het veld \'Expires\' moeten worden geformatteerd conform ISO 8601 (regel {line_no}).', - detail_tech_data_http_securitytxt_invalid_lang: 'Fout: De waarde in het veld \'Preferred-Languages\' moet overeenkomen met één of meer taal-tags zoals gedefinieerd in RFC 5646, gescheiden door komma\'s (regel {line_no}).', + detail_tech_data_http_securitytxt_invalid_lang: 'Fout: De waarde in het veld \'Preferred-Languages\' moet overeenkomen met één of meer taal-tags zoals gedefinieerd in RFC 5646, gescheiden door komma\'s (regel {line_no}).', detail_tech_data_http_securitytxt_invalid_line: 'Fout: Regel moet een veldnaam en -waarde bevatten, tenzij de regel leeg is of een commentaar bevat (regel {line_no}).', detail_tech_data_http_securitytxt_invalid_media: 'Fout: Media type in Content-Type header moet \'text/plain\' zijn.', + detail_tech_data_http_securitytxt_invalid_uri_scheme: 'Fout: De toegang tot het bestand security.txt moet het HTTPS-schema gebruiken.

[Note: this content label is currently not used. See #1046.]', detail_tech_data_http_securitytxt_location: 'Fout: security.txt stond op het top-level pad (verouderde locatie), maar moet geplaatst worden onder het \'/.well-known/\' pad.', detail_tech_data_http_securitytxt_long_expiry: 'Aanbeveling: Datum en tijd in het veld \'Expires\' zouden minder dan een jaar in de toekomst moeten liggen (regel {line_no}).', detail_tech_data_http_securitytxt_multi_expire: 'Fout: Het veld \'Expires\' moet niet meer dan één keer voorkomen.', @@ -342,7 +345,7 @@ const internet_nl_messages = { detail_tech_data_http_securitytxt_retrieved_from: 'security.txt opgehaald van {hostname}.', detail_tech_data_http_securitytxt_signed_format_issue: 'Fout: Ondertekende security.txt moet beginnen met de kop \'-----BEGIN PGP SIGNED MESSAGE-----\'.', detail_tech_data_http_securitytxt_unknown_field: 'Notificatie: security.txt bevat een onbekend veld. Ofwel het gaat om een aangepast veld dat misschien niet algemeen ondersteund wordt, ofwel er is sprake van een typfout in een gestandaardiseerde veldnaam (regel {line_no}).', - detail_tech_data_http_securitytxt_utf8: 'Fout: Inhoud moet utf-8 gecodeerd zijn.', + detail_tech_data_http_securitytxt_utf8: 'Fout: Inhoud moet gecodeerd zijn met UTF-8 in Net-Unicode vorm.', detail_tech_data_insecure: 'insecure', detail_tech_data_insufficient: 'onvoldoende', detail_tech_data_no: 'nee', @@ -356,29 +359,29 @@ const internet_nl_messages = { detail_tech_data_yes: 'ja', detail_verdict_could_not_test: 'Testfout. Graag later opnieuw proberen.', detail_verdict_not_tested: 'Deze subtest is niet uitgevoerd, omdat een bovenliggende test waarvan deze subtest afhankelijk is een negatief testresultaat gaf, of omdat onvoldoende informatie beschikbaar was om de subtest uit te kunnen voeren. ', - detail_web_appsecpriv_http_csp_exp: 'We testen of je webserver een HTTP-header voor Content-Security-Policy (CSP) aanbiedt. Verder controleren we op verschillende veilige CSP-instellingen, hoewel we de effectiviteit van je CSP-configuratie niet uitputtend testen.

CSP beschermt een website tegen aanvallen via content injection zoals cross-site scripting (XSS). Door met CSP een \'allowlist\' met bronnen van goedgekeurde content in te stellen, kan je voorkomen dat browsers die jouw website tonen daarbij kwaadaardige content van aanvallers laden.

We testen op onderstaande regels die gebaseerd zijn op good pracrices voor een veilige CSP-configuratie.

  1. De default-src richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit is om een restrictief default fallback beleid te hebben voor bron-typen die gebruikt worden in je website waarvoor geen specifiek beleid is gedefinieerd. Naast deze waarden kan \'report-sample\' als waarde zijn ingesteld als je wil dat in de \'violation reports\' code-voorbeelden worden opgenomen.
  2. De base-uri richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit limiteert de baseURI zodat de injectie van een gemanipuleerd <base> element wordt geblokkeerd. Dit beperkt de mogelijkheden van aanvallers om de locaties van bronnen (bijv. scripts) die vanaf relatieve URL\'s worden geladen te manipuleren.
  3. De frame-src richtlijn moet zijn gebruikt (hetzij per definitie of via de fallback naar child-src en default-src) en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat inhoud van niet-geautoriseerde locaties wordt geframed of ge-embed in je website (met HTML-elementen zoals <frame> en <iframe>).
  4. De frame-ancestors richtlijn moet zijn gedefinieerd zijn en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat ongeautoriseerde websites je website kunnen framen of embedden (met de HTML-elementen <frame>, <iframe>, <object>, <embed>, of <applet>).
  5. De form-action richtlijn moet zijn gedefinieerd en de waarde ervan moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URLs. Dit limiteert de URL\'s die gebruikt kunnen worden als doel voor formulierverzendingen.
  6. unsafe-inline, unsafe-eval en unsafe-hashes moeten niet gebruikt worden, omdat deze XSS-aanvallen mogelijk maken.
  7. data: moet niet gebruikt worden in default-src, script-src en object-src, omdat dit XSS-aanvallen mogelijk maakt.
  8. Een domein met het http:// schema of een domein zonder schema moet niet worden gebruikt, omdat hiermee bronnen kunnen worden gedownload over een onveilige verbinding. Gebruik in plaats daarvan het https:// schema.
  9. Een wildcard (dat wil zeggen *) voor volledige host-gedeelte van een URL moet niet gebruikt worden in een CSP-richtlijn, omdat daardoor iedere externe bron is toegestaan. Gebruik bovendien niet alleen https: omdat dit gelijk staat aan https://*. Specificeer altijd het hoofddomein (bijvoorbeeld https://scripts.example.nl of https://*.example.nl).
  10. 127.0.0.1 moet niet gebruikt worden in een CSP-richtlijn, omdat dit aanvallen via content injection mogelijk maakt in een gecompromitteerd systeem.

Aanvullende aanbevelingen:

  1. Sta alleen zo specifiek mogelijke domeinen toe in CSP-richtlijnen. Dit wordt in deze subtest voor CSP tot op zekere hoogte automatisch getest.

    • Sta niet alle domeinen onder een TLD (*.nl) of SLD (*.gov.uk) toe, hoewel we hier momenteel niet op testen.
    • 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.

  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.

  3. Gebruik de HTTP-header als mechanisme voor het serveren van je CSP-beleid. Gebruik niet het HTML <meta> 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 <meta>-element.
  4. Gebruik de HTTP-header voor Content-Security-Policy-Report-Only om te experimenteren met je CSP-configuratie door het effect ervan te controleren maar nog niet af te dwingen.
  5. Merk op dat een lege bronnenlijst (d.w.z. een CSP-richtlijn zonder waarde) gelijk is aan een bronnenlijst met none. Merk bovendien op dat als er andere bronnen in een bronnenlijst naast none staan, het attribuut none wordt genegeerd.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_csp_exp: 'We testen of je webserver een HTTP-header voor Content-Security-Policy (CSP) aanbiedt. Verder controleren we op verschillende veilige CSP-instellingen, hoewel we de effectiviteit van je CSP-configuratie niet uitputtend testen.

CSP beschermt een website tegen aanvallen via content injection zoals cross-site scripting (XSS). Door met CSP een \'allowlist\' met bronnen van goedgekeurde content in te stellen, kan je voorkomen dat browsers die jouw website tonen daarbij kwaadaardige content van aanvallers laden.

We testen op onderstaande regels die gebaseerd zijn op good pracrices voor een veilige CSP-configuratie.

  1. De default-src richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit is om een restrictief default fallback beleid te hebben voor bron-typen die gebruikt worden in je website waarvoor geen specifiek beleid is gedefinieerd. Naast deze waarden kan \'report-sample\' als waarde zijn ingesteld als je wil dat in de \'violation reports\' code-voorbeelden worden opgenomen.
  2. De base-uri richtlijn moet zijn gedefinieerd en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer URL\'s van het domein zelf (inclusief het subdomein of superdomein ervan). Dit limiteert de baseURI zodat de injectie van een gemanipuleerd <base> element wordt geblokkeerd. Dit beperkt de mogelijkheden van aanvallers om de locaties van bronnen (bijv. scripts) die vanaf relatieve URL\'s worden geladen te manipuleren.
  3. De frame-src richtlijn moet zijn gebruikt (hetzij per definitie of via de fallback naar child-src en default-src) en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat inhoud van niet-geautoriseerde locaties wordt geframed of ge-embed in je website (met HTML-elementen zoals <frame> en <iframe>).
  4. De frame-ancestors richtlijn moet zijn gedefinieerd zijn en de waarde moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URL\'s. Dit voorkomt dat ongeautoriseerde websites je website kunnen framen of embedden (met de HTML-elementen <frame>, <iframe>, <object>, <embed>, of <applet>).
  5. De form-action richtlijn moet zijn gedefinieerd en de waarde ervan moet zijn óf \'none\', óf \'self\' en/of één of meer specifieke URLs. Dit limiteert de URL\'s die gebruikt kunnen worden als doel voor formulierverzendingen.
  6. unsafe-inline, unsafe-eval en unsafe-hashes moeten niet gebruikt worden, omdat deze XSS-aanvallen mogelijk maken.
  7. data: moet niet gebruikt worden in default-src, script-src en object-src, omdat dit XSS-aanvallen mogelijk maakt.
  8. Een domein met het http:// schema of een domein zonder schema moet niet worden gebruikt, omdat hiermee bronnen kunnen worden gedownload over een onveilige verbinding. Gebruik in plaats daarvan het https:// schema.
  9. Een wildcard (dat wil zeggen *) voor volledige host-gedeelte van een URL moet niet gebruikt worden in een CSP-richtlijn, omdat daardoor iedere externe bron is toegestaan. Gebruik bovendien niet alleen https: omdat dit gelijk staat aan https://*. Specificeer altijd het hoofddomein (bijvoorbeeld https://scripts.example.nl of https://*.example.nl).
  10. 127.0.0.1 moet niet gebruikt worden in een CSP-richtlijn, omdat dit aanvallen via content injection mogelijk maakt in een gecompromitteerd systeem.

Aanvullende aanbevelingen:

  1. Sta alleen zo specifiek mogelijke domeinen toe in CSP-richtlijnen. Dit wordt in deze subtest voor CSP tot op zekere hoogte automatisch getest.

    • Sta niet alle domeinen onder een TLD (*.nl) of SLD (*.gov.uk) toe, hoewel we hier momenteel niet op testen.
    • 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.

  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.

  3. Gebruik de HTTP-header als mechanisme voor het serveren van je CSP-beleid. Gebruik niet het HTML <meta> 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 <meta>-element.
  4. Gebruik de HTTP-header voor Content-Security-Policy-Report-Only om te experimenteren met je CSP-configuratie door het effect ervan te controleren maar nog niet af te dwingen.
  5. Merk op dat een lege bronnenlijst (d.w.z. een CSP-richtlijn zonder waarde) gelijk is aan een bronnenlijst met none. Merk bovendien op dat als er andere bronnen in een bronnenlijst naast none staan, het attribuut none wordt genegeerd.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_csp_label: 'Content-Security-Policy', detail_web_appsecpriv_http_csp_tech_table: 'Webserver-IP-adres|Bevindingen', detail_web_appsecpriv_http_csp_verdict_bad: 'Je webserver biedt geen Content-Security-Policy (CSP) aan, of biedt CSP aan met bepaalde onveilige instellingen .', detail_web_appsecpriv_http_csp_verdict_good: 'Je webserver biedt Content-Security-Policy (CSP) aan en maakt geen gebruik van bepaalde onveilige CSP-instellingen.', - detail_web_appsecpriv_http_referrer_policy_exp: 'We testen of je webserver een HTTP-header voor Referrer-Policy aanbiedt met een voldoende veilige en privacybeschermende policy-waarde. Met deze policy instrueert je webserver browsers of, wat en wanneer referrer-gegevens moeten worden verzonden naar de website waar de gebruiker naartoe navigeert vanaf jouw website. Deze referrer-gegevens worden in de Referer-header door de browser verzonden naar de website waar de gebruiker naartoe navigeert. Deze navigatie hoeft niet per se domeinoverschrijdend te zijn.

De gegevens in de Referer header worden meestal gebruikt voor analytics en logging. Er kunnen echter privacy- en beveiligingsrisico\'s zijn. De gegevens kunnen bijvoorbeeld worden gebruikt voor het volgen van gebruikers en de gegevens kunnen uitlekken naar derden die de verbinding afluisteren. Met de HTTP-header voor Referrer-Policy kun je deze risico\'s beperken door het verzenden van referrer-gegevens te controleren en zelfs te minimaliseren.

We raden je aan om een weloverwogen beslissing te nemen, met privacy- en beveiligingsrisico\'s in gedachten, over het gebruik van een van de policy-waarden uit de eerste twee categorieën hieronder.

1. Goed

  • no-referrer
  • same-origin

Met deze policy-waarden worden er geen gevoelige referrer-gegevens naar derden verzonden.

2. Waarschuwing

  • strict-origin
  • strict-origin-when-cross-origin (default waarde van browsers; zie ook onder aanvullende opmerking 2)

Met deze policy-waarden worden basis referrer-gegevens, die gevoelig kunnen zijn, alleen via beveiligde verbindingen (HTTPS) naar derden verzonden. Daarom zouden deze waarden alleen gebruikt moeten worden als dit noodzakelijk en wettelijk toegestaan is.

3. Slecht

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

Met deze policy-waarden worden alle of alleen basis referrer-gegevens, die gevoelig kunnen zijn, mogelijk via onveilige verbindingen (HTTP) naar derden verzonden. Daarom moeten deze waarden niet worden gebruikt.

Aanvullende opmerkingen:

  1. Om het lekken van gevoelige gegevens via URL\'s te voorkomen, moet u ervoor zorgen dat URL\'s van uw website geen persoonlijke of anderszins gevoelige gegevens bevatten (zoals persoonlijke namen of wachtwoorden).
  2. strict-origin-when-cross-origin is de default policy-waarde wanneer er geen Referrer-Policy is gepubliceerd zoals voorgeschreven in de huidige "Editor\'s Draft" van de Referrer-Policy standaard en deze default wordt gebruikt door alle nieuwste grote browsers. Merk op dat sommige gebruikers nog steeds een ander default waarde geconfigureerd kunnen hebben in hun browser.
  3. Gebruik de HTTP Referrer-Policy header als mechanisme om je referrer policy aan te bieden. We raden niet aan om het HTML <meta> element of het HTML referrerpolicy content attribuut te gebruiken om je referrer policy te publiceren, vooral omdat de secties die deze methoden beschrijven in de standaard gemarkeerd zijn als "niet normatief". Daarom controleren we niet op een referrer policy die wordt aangeboden via de laatste twee methoden.
  4. Merk op dat een webserver meerdere Referrer-Policy headers kan sturen, en dat een Referrer-Policy header meerdere waarden kan bevatten. Onbekende waarden worden genegeerd door de browser en alleen de laatst bekende waarde wordt gebruikt. Dit maakt het mogelijk om toekomstig gestandaardiseerde policy-waarden te gebruiken die nog niet door alle browsers worden ondersteund. Op dit moment ondersteunen echter alle nieuwste grote browsers de bovenstaande policy-waarden onder "Goed" en "Waarschuwing".

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_referrer_policy_exp: 'We testen of je webserver een HTTP-header voor Referrer-Policy aanbiedt met een voldoende veilige en privacybeschermende policy-waarde. Met deze policy instrueert je webserver browsers of, wat en wanneer referrer-gegevens moeten worden verzonden naar de website waar de gebruiker naartoe navigeert vanaf jouw website. Deze referrer-gegevens worden in de Referer-header door de browser verzonden naar de website waar de gebruiker naartoe navigeert. Deze navigatie hoeft niet per se domeinoverschrijdend te zijn.

De gegevens in de Referer header worden meestal gebruikt voor analytics en logging. Er kunnen echter privacy- en beveiligingsrisico\'s zijn. De gegevens kunnen bijvoorbeeld worden gebruikt voor het volgen van gebruikers en de gegevens kunnen uitlekken naar derden die de verbinding afluisteren. Met de HTTP-header voor Referrer-Policy kun je deze risico\'s beperken door het verzenden van referrer-gegevens te controleren en zelfs te minimaliseren.

We raden je aan om een weloverwogen beslissing te nemen, met privacy- en beveiligingsrisico\'s in gedachten, over het gebruik van een van de policy-waarden uit de eerste twee categorieën hieronder.

1. Goed

  • no-referrer
  • same-origin

Met deze policy-waarden worden er geen gevoelige referrer-gegevens naar derden verzonden.

2. Waarschuwing

  • strict-origin
  • strict-origin-when-cross-origin (default waarde van browsers; zie ook onder aanvullende opmerking 2)

Met deze policy-waarden worden basis referrer-gegevens, die gevoelig kunnen zijn, alleen via beveiligde verbindingen (HTTPS) naar derden verzonden. Daarom zouden deze waarden alleen gebruikt moeten worden als dit noodzakelijk en wettelijk toegestaan is.

3. Slecht

  • no-referrer-when-downgrade
  • origin-when-cross-origin
  • origin
  • unsafe-url

Met deze policy-waarden worden alle of alleen basis referrer-gegevens, die gevoelig kunnen zijn, mogelijk via onveilige verbindingen (HTTP) naar derden verzonden. Daarom moeten deze waarden niet worden gebruikt.

Aanvullende opmerkingen:

  1. Om het lekken van gevoelige gegevens via URL\'s te voorkomen, moet u ervoor zorgen dat URL\'s van uw website geen persoonlijke of anderszins gevoelige gegevens bevatten (zoals persoonlijke namen of wachtwoorden).
  2. strict-origin-when-cross-origin is de default policy-waarde wanneer er geen Referrer-Policy is gepubliceerd zoals voorgeschreven in de huidige "Editor\'s Draft" van de Referrer-Policy standaard en deze default wordt gebruikt door alle nieuwste grote browsers. Merk op dat sommige gebruikers nog steeds een ander default waarde geconfigureerd kunnen hebben in hun browser.
  3. Gebruik de HTTP Referrer-Policy header als mechanisme om je referrer policy aan te bieden. We raden niet aan om het HTML <meta> element of het HTML referrerpolicy content attribuut te gebruiken om je referrer policy te publiceren, vooral omdat de secties die deze methoden beschrijven in de standaard gemarkeerd zijn als "niet normatief". Daarom controleren we niet op een referrer policy die wordt aangeboden via de laatste twee methoden.
  4. Merk op dat een webserver meerdere Referrer-Policy headers kan sturen, en dat een Referrer-Policy header meerdere waarden kan bevatten. Onbekende waarden worden genegeerd door de browser en alleen de laatst bekende waarde wordt gebruikt. Dit maakt het mogelijk om toekomstig gestandaardiseerde policy-waarden te gebruiken die nog niet door alle browsers worden ondersteund. Op dit moment ondersteunen echter alle nieuwste grote browsers de bovenstaande policy-waarden onder "Goed" en "Waarschuwing".

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_referrer_policy_label: 'Referrer-Policy', detail_web_appsecpriv_http_referrer_policy_tech_table: 'Webserver-IP-adres|Bevindingen', detail_web_appsecpriv_http_referrer_policy_verdict_bad: 'Je webserver biedt een Referrer-Policy aan met een policy-waarde die niet voldoende veilig en privacybeschermend is.', detail_web_appsecpriv_http_referrer_policy_verdict_good: 'Je webserver biedt een Referrer-Policy aan met een policy-waarde die voldoende veilig en privacybeschermend is.', detail_web_appsecpriv_http_referrer_policy_verdict_recommendations: 'Je webserver biedt ofwel geen Referrer-Policy aan en vertrouwt dus op de standaard browserpolicy, óf je webserver biedt een Referrer-Policy aan met een policy-waarde die met terughoudendheid moet worden gebruikt vanwege de mogelijke impact op beveiliging en privacy.', - detail_web_appsecpriv_http_securitytxt_exp: 'We testen of je webserver een security.txt bestand op de juiste locatie aanbiedt, of het opgehaald kan worden, en of de inhoud ervan syntactisch geldig is.

security.txt is een tekstbestand met contactinformatie dat je op je webserver plaatst. Beveiligingsonderzoekers kunnen deze informatie gebruiken om direct contact met de juiste afdeling of persoon binnen je organisatie op te nemen over kwetsbaarheden die zij in je website of IT-systemen hebben gevonden. Dit kan het verhelpen van gevonden kwetsbaarheden versnellen, waardoor kwaadwillenden minder kans hebben om er misbruik van te maken.

Het formaat van het bestand is bedoeld om machinaal en menselijk leesbaar te zijn. De contactinformatie kan een e-mailadres, een telefoonnummer en/of een webpagina (bijvoorbeeld een webformulier) zijn. Merk op dat gepubliceerde contactinformatie openbaar is en ook kan worden misbruikt, bijvoorbeeld om spam te sturen naar een gepubliceerd e-mailadres.

Naast contactinformatie moet het security.txt bestand ook een vervaldatum bevatten. Om te voorkomen dat de informatie niet meer actueel is, wordt aanbevolen een vervaldatum op te nemen die minder dan een jaar in de toekomst ligt. Het is optioneel om ook andere relevante informatie voor beveiligingsonderzoekers op te nemen, zoals een link naar je beleid voor het omgaan met meldingen van beveiligingskwetsbaarheden (meestal Coordinated Vulnerability Disclosure policy genoemd).

Het wordt aanbevolen om het security.txt bestand te ondertekenen met PGP en daarbij de web URI waarop het bestand staat in een Canonical veld op te nemen. We controleren of het security.txt bestand ondertekend is. We valideren de handtekening echter niet, omdat er helaas geen gestandaardiseerde plaats is om een publieke PGP-sleutel (die nodig is voor handtekeningvalidatie) op te halen.

Als een of meer Canonical velden aanwezig zijn, moet de web URI van het security.txt bestand in een Canonical veld staan. Bij het redirecten naar een security.txt bestand moet ten minste de laatste URI van de redirect-keten in een Canonical veld worden vermeld.

Het bestand moet gepubliceerd worden onder het /.well-known/ pad. Merk op dat het plaatsen onder het top-level pad verouderd is. Elk web(sub)domein dient zijn eigen security.txt bestand te hebben. Een voorbeeldbestand is te vinden op https://example.nl/.well-known/security.txt.

Met een redirect doorverwijzen naar een security.txt op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale security.txt.

Met een redirect doorverwijzen naar een security.txt op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale security.txt.

Merk op dat security.txt bestanden normaal gesproken slechts enkele kilobytes groot zijn. We lezen en evalueren daarom maximaal de eerste 100 kB van een gevonden security.txt bestand.

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_securitytxt_exp: 'We testen of je webserver een security.txt bestand op de juiste locatie aanbiedt, of het opgehaald kan worden, en of de inhoud ervan syntactisch geldig is.

security.txt is een tekstbestand met contactinformatie dat je op je webserver plaatst. Beveiligingsonderzoekers kunnen deze informatie gebruiken om direct contact met de juiste afdeling of persoon binnen je organisatie op te nemen over kwetsbaarheden die zij in je website of IT-systemen hebben gevonden. Dit kan het verhelpen van gevonden kwetsbaarheden versnellen, waardoor kwaadwillenden minder kans hebben om er misbruik van te maken.

Het formaat van het bestand is bedoeld om machinaal en menselijk leesbaar te zijn. De contactinformatie kan een e-mailadres, een telefoonnummer en/of een webpagina (bijvoorbeeld een webformulier) zijn. Merk op dat gepubliceerde contactinformatie openbaar is en ook kan worden misbruikt, bijvoorbeeld om spam te sturen naar een gepubliceerd e-mailadres.

Naast contactinformatie moet het security.txt bestand ook een vervaldatum bevatten. Om te voorkomen dat de informatie niet meer actueel is, wordt aanbevolen een vervaldatum op te nemen die minder dan een jaar in de toekomst ligt. Het is optioneel om ook andere relevante informatie voor beveiligingsonderzoekers op te nemen, zoals een link naar je beleid voor het omgaan met meldingen van beveiligingskwetsbaarheden (meestal Coordinated Vulnerability Disclosure policy genoemd).

Het wordt aanbevolen om het security.txt bestand te ondertekenen met PGP en daarbij de web URI waarop het bestand staat in een Canonical veld op te nemen. We controleren of het security.txt bestand ondertekend is. We valideren de handtekening echter niet, omdat er helaas geen gestandaardiseerde plaats is om een publieke PGP-sleutel (die nodig is voor handtekeningvalidatie) op te halen.

Als een of meer Canonical velden aanwezig zijn, moet de web URI van het security.txt bestand in een Canonical veld staan. Bij het redirecten naar een security.txt bestand moet ten minste de laatste URI van de redirect-keten in een Canonical veld worden vermeld.

Het bestand moet gepubliceerd worden onder het /.well-known/ pad. Merk op dat het plaatsen onder het top-level pad verouderd is. Elk web(sub)domein dient zijn eigen security.txt bestand te hebben. Een voorbeeldbestand is te vinden op https://example.nl/.well-known/security.txt.

Met een redirect doorverwijzen naar een security.txt op een andere domeinnaam is toegestaan. Vooral in het geval van een grote domeinnaamportfolio is het vanuit onderhoudsperspectief aan te raden om de domeinnamen te redirecten naar een centrale security.txt.

Merk op dat security.txt bestanden normaal gesproken slechts enkele kilobytes groot zijn. We lezen en evalueren daarom maximaal de eerste 100 kB van een gevonden security.txt bestand.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_securitytxt_label: 'security.txt', detail_web_appsecpriv_http_securitytxt_tech_table: 'Webserver-IP-adres|Bevindingen', detail_web_appsecpriv_http_securitytxt_verdict_bad: 'Je webserver biedt geen security.txt-bestand op de juiste plaats aan, het kon niet worden opgehaald, of de inhoud ervan is syntactisch niet geldig.', detail_web_appsecpriv_http_securitytxt_verdict_good: 'Je webserver biedt een security.txt-bestand op de juiste plaats aan en de inhoud ervan is syntactisch geldig.', detail_web_appsecpriv_http_securitytxt_verdict_recommendations: 'Je webserver biedt een security.txt-bestand op de juiste plaats aan en de inhoud ervan is syntactisch geldig. Echter, er zijn een of meer aanbevelingen voor verbetering.', - detail_web_appsecpriv_http_x_content_type_exp: 'We testen of je webserver een HTTP header voor X-Content-Type-Options aanbiedt. Met deze HTTP header kan je webbrowsers laten weten dat zij geen \'MIME type sniffing\' mogen uitvoeren en altijd het Content-Type zoals gedeclareerd door jouw webserver moeten volgen. De enige geldige waarde voor deze HTTP header is nosniff. Indien actief, dan zal een browser verzoeken voor style en script blokkeren als deze geen corresponderende Content-Type (dat wil zeggen text/css of een \'Javascript MIME type\' zoals application/javascript) hebben.

\'MIME type sniffing\' is een techniek waarbij de browser de inhoud van een bestand scant om te bepalen wat het formaat van het bestand is, ongeacht het door de webserver gedeclareerde Content-Type. Deze techniek is kwetsbaar voor de zogenaamde \'MIME confusion attack\' waarbij de aanvaller de content van een bestand zodanig manipuleert dat de browser deze behandelt als een andere Content-Type, zoals een executeerbaar bestand.

Niveau van vereistheid: Aanbevolen', + detail_web_appsecpriv_http_x_content_type_exp: 'We testen of je webserver een HTTP header voor X-Content-Type-Options aanbiedt. Met deze HTTP header kan je webbrowsers laten weten dat zij geen \'MIME type sniffing\' mogen uitvoeren en altijd het Content-Type zoals gedeclareerd door jouw webserver moeten volgen. De enige geldige waarde voor deze HTTP header is nosniff. Indien actief, dan zal een browser verzoeken voor style en script blokkeren als deze geen corresponderende Content-Type (dat wil zeggen text/css of een \'Javascript MIME type\' zoals application/javascript) hebben.

\'MIME type sniffing\' is een techniek waarbij de browser de inhoud van een bestand scant om te bepalen wat het formaat van het bestand is, ongeacht het door de webserver gedeclareerde Content-Type. Deze techniek is kwetsbaar voor de zogenaamde \'MIME confusion attack\' waarbij de aanvaller de content van een bestand zodanig manipuleert dat de browser deze behandelt als een andere Content-Type, zoals een executeerbaar bestand.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Niveau van vereistheid: Aanbevolen', detail_web_appsecpriv_http_x_content_type_label: 'X-Content-Type-Options', detail_web_appsecpriv_http_x_content_type_tech_table: 'Webserver-IP-adres|X-Content-Type-Options waarde', detail_web_appsecpriv_http_x_content_type_verdict_bad: 'Je webserver biedt geen X-Content-Type-Options aan.', detail_web_appsecpriv_http_x_content_type_verdict_good: 'Je webserver biedt X-Content-Type-Options aan.', - detail_web_appsecpriv_http_x_frame_exp: 'We testen of je webserver een HTTP header voor X-Frame-Options aanbiedt die een voldoende veilige instelling heeft. Met deze HTTP header kan je webbrowsers laten weten of het toegestaan is om jouw website te \'framen\'. Het voorkomen van \'framen\' beschermt bezoekers tegen aanvallen zoals clickjacking. We beschouwen de volgende waarden als voldoende veilig:

  • DENY (\'framen\' niet toegestaan); of
  • SAMEORIGIN (\'framen\' alleen door je eigen website toegestaan).

Alhoewel de waarde ALLOW-FROM (alleen genoemde websites mogen jouw website \'framen\') onderdeel is van de specificatie voorX-Frame-Options (RFC 7034), wordt deze niet ondersteund door moderne webbrowsers. Om die reden beschouwen we deze waarde niet als voldoende veilig.

Merk op dat Content-Security-Policy (CSP) via frame-ancestors vergelijkbare bescherming en daarnaast nog veel meer biedt voor bezoekers met moderne webbrowsers. Maar X-Frame-Options kan nog steeds bescherming bieden aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-Frame-Options waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Optioneel ', + detail_web_appsecpriv_http_x_frame_exp: 'We testen of je webserver een HTTP header voor X-Frame-Options aanbiedt die een voldoende veilige instelling heeft. Met deze HTTP header kan je webbrowsers laten weten of het toegestaan is om jouw website te \'framen\'. Het voorkomen van \'framen\' beschermt bezoekers tegen aanvallen zoals clickjacking. We beschouwen de volgende waarden als voldoende veilig:

  • DENY (\'framen\' niet toegestaan); of
  • SAMEORIGIN (\'framen\' alleen door je eigen website toegestaan).

Alhoewel de waarde ALLOW-FROM (alleen genoemde websites mogen jouw website \'framen\') onderdeel is van de specificatie voorX-Frame-Options (RFC 7034), wordt deze niet ondersteund door moderne webbrowsers. Om die reden beschouwen we deze waarde niet als voldoende veilig.

Merk op dat Content-Security-Policy (CSP) via frame-ancestors vergelijkbare bescherming en daarnaast nog veel meer biedt voor bezoekers met moderne webbrowsers. Maar X-Frame-Options kan nog steeds bescherming bieden aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-Frame-Options waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligingsopties\' alleen uitgevoerd voor het eerste beschikbare IPv6- en IPv4-adres.

Zie ook \'Webapplicatie-richtlijnen van NCSC, Verdieping\', richtlijn U/PW.03.

Niveau van vereistheid: Optioneel ', detail_web_appsecpriv_http_x_frame_label: 'X-Frame-Options', detail_web_appsecpriv_http_x_frame_tech_table: 'Webserver-IP-adres|X-Frame-Options waarde', detail_web_appsecpriv_http_x_frame_verdict_bad: 'Je webserver biedt geen veilig ingestelde X-Frame-Options aan.', @@ -406,29 +409,29 @@ const internet_nl_messages = { detail_web_ipv6_web_aaaa_tech_table: 'Webserver|IPv6-adres|IPv4-adres', detail_web_ipv6_web_aaaa_verdict_bad: 'Geen van je webservers heeft een IPv6-adres.', detail_web_ipv6_web_aaaa_verdict_good: 'Tenminste één van je webservers heeft een IPv6-adres.', - detail_web_ipv6_web_ipv46_exp: 'We vergelijken het antwoord en de inhoud die we van je webserver over IPv6 ontvangen met die over IPv4.

We controleren:

  1. of HTTP (poort 80) en/of HTTPS (poort 443) via IPv4 ook beschikbaar zijn via IPv6;
  2. of HTTP-headers (zoals een redirect-header) via IPv4 ook via IPv6 worden ontvangen;
  3. of HTML-inhoud via IPv4 hetzelfde is via IPv6. Na het strippen van eventuele nonces doen we een vergelijking van de ontvangen inhoud. Het verschil in inhoud mag niet groter zijn dan 10% om voor deze subtest te slagen. De drempel zorgt ervoor dat kleine verschillen (bijvoorbeeld als gevolg van veranderende advertenties) niet leiden tot het falen van deze subtest. Een waargenomen verschil kan bedoeld zijn of te maken hebben met een meetfout. Daarom wordt in dit geval een waarschuwing gegeven en telt dit niet mee in de score.

Als er meerdere IPv6- en IPv4-adressen zijn, kiezen we één IPv6-adres en één IPv4-adres om de subtest uit te voeren. Als er alleen een IPv6-adres en geen IPv4-adres beschikbaar is, dan is de subtest niet van toepassing omdat er geen vergelijking kan worden gemaakt.', + detail_web_ipv6_web_ipv46_exp: 'We vergelijken de beschikbare poorten en aangeboden headers en inhoud van je webserver via IPv6 met die via IPv4.

We controleren of:

  1. dezelfde poorten, dat wil zeggen HTTP (poort 80) en/of HTTPS (poort 443), beschikbaar zijn via zowel IPv6 als IPv4;
  2. dezelfde HTTP-headers worden aangeboden via zowel IPv6 als IPv4. Dit omvat HTTP response codes, zoals \'successful responses\' (200 – 299) en \'redirection messages\' (300 – 399). Bij een \'client error response\' (400 - 499) of een \'server error response\' (500 - 599) wordt een waarschuwing zonder score-impact gegeven, omdat een dergelijke HTTP response code kan wijzen op een configuratieprobleem;
  3. dezelfde HTML-inhoud wordt aangeboden via zowel IPv6 als IPv4. We doen dit door de ontvangen inhoud te vergelijken na het strippen van eventuele nonces. Het verschil in inhoud mag niet groter zijn dan 10% om te slagen voor deze subtest. Deze drempel zorgt ervoor dat kleine niet-problematische verschillen (bijvoorbeeld door veranderende advertenties) niet direct leiden tot een onvoldoende voor deze subtest. Een waargenomen verschil kan nog steeds bedoeld zijn of te maken hebben met een meetfout. Daarom leidt dit deel van de subtest in geval van falen alleen tot een waarschuwing zonder score-impact.

Aanvullende opmerkingen:- Als er meerdere IPv6- en IPv4-adressen zijn, dan kiezen we één IPv6-adres en één IPv4-adres om de subtest uit te voeren.- Als er alleen een IPv6-adres en geen IPv4-adres (of omgekeerd) beschikbaar is, dan is de subtest niet van toepassing omdat er geen vergelijking kan worden gemaakt.- Deze subtest volgt redirects en controleert ook alle onderliggende URL\'s.', detail_web_ipv6_web_ipv46_label: 'Gelijke website op IPv6 en IPv4', - detail_web_ipv6_web_ipv46_verdict_bad: 'Beschikbare poorten of aangeboden headers van je website over IPv4 zijn niet hetzelfde over IPv6.', - detail_web_ipv6_web_ipv46_verdict_good: 'Je website op IPv6 lijkt gelijk aan je website op IPv4.', - detail_web_ipv6_web_ipv46_verdict_notice: 'De HTML-inhoud van je website over IPv4 is niet hetzelfde over IPv6. ', - detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Je website op IPv6 lijkt gelijk aan je website op IPv4, maar de HTTP response code is 4xx of 5xx. Dit kan wijzen op een configuratiefout.', + detail_web_ipv6_web_ipv46_verdict_bad: 'Beschikbare poorten of aangeboden headers van je website via IPv4 zijn niet hetzelfde via IPv6.', + detail_web_ipv6_web_ipv46_verdict_good: 'Je website via IPv6 lijkt identiek via IPv4.', + detail_web_ipv6_web_ipv46_verdict_notice: 'De HTML-inhoud van je website via IPv4 is niet hetzelfde via IPv6. ', + detail_web_ipv6_web_ipv46_verdict_notice_status_code: 'Je website via IPv6 lijkt identiek via IPv4, maar de HTTP response code is 4xx of 5xx. Dit kan wijzen op een configuratiefout.', detail_web_ipv6_web_reach_exp: 'We testen of we je webserver(s) kunnen bereiken via IPv6 op alle beschikbare poorten (80 en/of 443). We testen alle IPv6-adressen die we ontvangen van je nameservers. Een deelscore wordt gegeven als niet alle IPv6-adressen bereikbaar zijn. Als een IPv6-adres (syntactisch) ongeldig is, dan beschouwen we dat als onbereikbaar.', detail_web_ipv6_web_reach_label: 'IPv6-bereikbaarheid van webserver', detail_web_ipv6_web_reach_tech_table: 'Webserver|Onbereikbaar IPv6-adres', detail_web_ipv6_web_reach_verdict_bad: 'Tenminste één van jouw webservers met een IPv6-adres, is niet bereikbaar via IPv6.', detail_web_ipv6_web_reach_verdict_good: 'Al je webservers met een IPv6-adres zijn bereikbaar via IPv6.', - detail_web_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je webserver.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_web_rpki_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van je webserver.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_web_rpki_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_web_rpki_exists_tech_table: 'Webserver|IP-adres|RPKI Route Origin Authorization', detail_web_rpki_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van je webserver is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_rpki_exists_verdict_good: 'Voor alle IP-adressen van je webserver is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_rpki_exists_verdict_no_addresses: 'Je domein bevat geen IP-adressen van webservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_web_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je webserver Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

Niveau van vereistheid: Aanbevolen', + detail_web_rpki_valid_exp: 'We testen of de validatie-status van alle IP-adressen van je webserver Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_web_rpki_valid_label: 'Geldigheid van route-aankondiging', detail_web_rpki_valid_tech_table: 'Webserver|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_web_rpki_valid_verdict_bad: 'Ten minste één IP-adres van je webserver heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorization (ROA) gepubliceerd voor de route-aankondiging van ieder van de desbetreffende IP-adressen.', detail_web_rpki_valid_verdict_good: 'Alle IP-adressen van je webserver hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_web_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je webserver heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je webhoster. Bij een interne fout moet je webhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_web_rpki_valid_verdict_invalid: 'Tenminste één IP-adres van je webserver heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je webhoster. Bij een interne fout moet je webhoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_web_rpki_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', detail_web_tls_cert_hostmatch_exp: 'We testen of de domeinnaam van je website overeenkomt met de domeinnaam op het certificaat.

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.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B3-1.', detail_web_tls_cert_hostmatch_label: 'Domeinnaam op certificaat', @@ -451,7 +454,7 @@ const internet_nl_messages = { detail_web_tls_cert_trust_tech_table: 'Webserver-IP-adres|Onvertrouwde certificaatketen', detail_web_tls_cert_trust_verdict_bad: 'De vertrouwensketen van je websitecertificaat is niet compleet en/of niet ondertekend door een vertrouwde certificaatautoriteit.', detail_web_tls_cert_trust_verdict_good: 'De vertrouwensketen van je websitecertificaat is compleet en ondertekend door een vertrouwde certificaatautoriteit.', - detail_web_tls_cipher_order_exp: 'We testen of je webserver zijn eigen cipher-voorkeur afdwingt (\'I\'), en ciphers aanbiedt conform de voorgeschreven volgorde (\'II\').

Als je webserver alleen \'Goede\' ciphers ondersteunt, dan is deze subtest niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

I. Server afgedwongen cipher-volgorde: De webserver dwingt zijn cipher-voorkeur af tijdens de onderhandeling met een webbrowser, en accepteert geen voorkeur van de webbrowser;

II. Voorgeschreven volgorde: Ciphers worden aangeboden door de webserver in overeenstemming met de voorgeschreven volgorde waarbij Goede boven Voldoende boven Uit te faseren ciphers worden geprefereerd.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', + detail_web_tls_cipher_order_exp: 'We testen of je webserver zijn eigen cipher-voorkeur afdwingt (\'I\'), en ciphers aanbiedt conform de voorgeschreven volgorde (\'II\').

Als je webserver alleen \'Goede\' ciphers ondersteunt, dan is deze subtest niet van toepassing omdat de volgorde dan geen significant beveiligingsvoordeel oplevert.

I. Server afgedwongen cipher-voorkeur: De webserver dwingt zijn cipher-voorkeur af tijdens de onderhandeling met een webbrowser, en accepteert geen voorkeur van de webbrowser;

II. Voorgeschreven volgorde: Ciphers worden aangeboden door de webserver in overeenstemming met de voorgeschreven volgorde waarbij Goede boven Voldoende boven Uit te faseren ciphers worden geprefereerd.

In de bovenstaande tabel met technische details staan alleen de eerst gevonden algoritmeselecties die niet voldoen aan de voorgeschreven volgorde.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-5.', detail_web_tls_cipher_order_label: 'Cipher-volgorde', detail_web_tls_cipher_order_tech_table: 'Webserver IP-adres|Eerst gevonden getroffen cipher-paren|Overtreden regel # (\'II-B\')', detail_web_tls_cipher_order_verdict_bad: 'Je webserver dwingt niet zijn eigen cipher-voorkeur af (\'I\').', @@ -486,7 +489,7 @@ const internet_nl_messages = { detail_web_tls_dane_valid_tech_table: 'Webserver-IP-adres|DANE TLSA-record geldig', detail_web_tls_dane_valid_verdict_bad: 'De DANE-fingerprint op je domeinnaam is niet geldig voor je websitecertificaat. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DANE-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DANE-fingerprints controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder en/of hostingprovider.', detail_web_tls_dane_valid_verdict_good: 'De DANE-fingerprint op je domeinnaam is geldig voor je websitecertificaat.', - detail_web_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je webserver, veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', + detail_web_tls_fs_params_exp: 'We testen of de publieke parameters, die in de Diffie-Hellman sleuteluitwisseling worden gebruikt door je webserver, veilig zijn.

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.

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. Zelf-gegenereerde groepen zijn \'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.

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\'.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDHE, en richtlijn B6-1 en tabel 10 voor DHE.

Elliptische krommen voor ECDHE

  • Goed: secp384r1, secp256r1, x448, en x25519
  • Uit te faseren: secp224r1
  • Onvoldoende: Andere krommen

Finite field-groepen voor DHE

  • Voldoende:

    • ffdhe4096 (RFC 7919)
      sha256 checksum: 64852d6890ff9e62eecd1ee89c72af9af244dfef5b853bcedea3dfd7aade22b3
    • ffdhe3072 (RFC 7919)
      sha256 checksum: c410cc9c4fd85d2c109f7ebe5930ca5304a52927c0ebcb1a11c5cf6b2386bbab
    • 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.

  • Uit te faseren:

    • ffdhe2048 (RFC 7919)
      sha256 checksum: 9ba6429597aeed2d8617a7705b56e96d044f64b07971659382e426675105654b

  • Onvoldoende: Andere groepen

Let op: de bovenstaande namen zijn gebaseerd op de IANA naamgevingsconventies. Soms worden alternatieve namen gebruikt om te verwijzen naar dezelfde krommen, zoals prime256v1 (ANSI) en NIST P-256 voor secp256r1.', detail_web_tls_fs_params_label: 'Sleuteluitwisselingsparameters', detail_web_tls_fs_params_tech_table: 'Webserver-IP-adres|Getroffen parameters|Status', detail_web_tls_fs_params_verdict_bad: 'Je webserver ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', @@ -498,7 +501,7 @@ const internet_nl_messages = { detail_web_tls_http_compression_tech_table: 'Webserver-IP-adres|HTTP-compressie', detail_web_tls_http_compression_verdict_bad: 'Je webserver ondersteunt HTTP-compressie, wat een beveiligingsrisico kan vormen.', detail_web_tls_http_compression_verdict_good: 'Je webserver ondersteunt geen HTTP-compressie.', - detail_web_tls_https_exists_exp: 'We testen of je website bereikbaar is via HTTPS.

Als dat het geval is, dan testen we in de navolgende subtesten of HTTPS ook veilig is geconfigureerd conform de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\'.

HTTPS garandeert de vertrouwelijkheid en integriteit van uitgewisselde informatie. Omdat het van de situatie afhangt hoe (privacy-)gevoelig en waardevol informatie is, een bezoeker van je website bepaalt 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. Let op: vanwege performance-redenen worden de testen in het HTTPS-testonderdeel alleen uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres.', + detail_web_tls_https_exists_exp: 'We testen of je website bereikbaar is via HTTPS.

Als dat het geval is, dan testen we in de navolgende subtesten of HTTPS ook veilig is geconfigureerd conform de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\'.

HTTPS garandeert de vertrouwelijkheid en integriteit van uitgewisselde informatie. Omdat het van de situatie afhangt hoe (privacy-)gevoelig en waardevol informatie is, een bezoeker van je website bepaalt 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.

Opmerking over IPv6/IPv4: vanwege performance-redenen worden alle testen in de categorie \'Beveiligde verbinding (HTTPS)\' alleen uitgevoerd voor het eerst beschikbare IPv6- en IPv4-adres.', detail_web_tls_https_exists_label: 'HTTPS beschikbaar', detail_web_tls_https_exists_tech_table: 'Webserver-IP-adres|HTTPS aanwezig', detail_web_tls_https_exists_verdict_bad: 'Je website biedt geen HTTPS aan.', @@ -529,7 +532,7 @@ const internet_nl_messages = { detail_web_tls_ocsp_stapling_verdict_bad: 'Je webserver ondersteunt OCSP maar de data in het antwoord is niet valide.', detail_web_tls_ocsp_stapling_verdict_good: 'Je webserver ondersteunt OCSP en de data in het antwoord is valide.', detail_web_tls_ocsp_stapling_verdict_ok: 'Je webserver ondersteunt OCSP niet.', - detail_web_tls_renegotiation_client_exp: '

We testen of een client (doorgaans een webbrowser) een renegotiation kan initiëren met jouw webserver.

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

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', + detail_web_tls_renegotiation_client_exp: '

We testen of een client (doorgaans een webbrowser) een renegotiation kan initiëren met jouw webserver.

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

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn 8-1 en tabel 13.

Niveau van vereistheid: Optioneel

Client-initiated renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Voldoende: Aan
', detail_web_tls_renegotiation_client_label: 'Client-initiated renegotiation', detail_web_tls_renegotiation_client_tech_table: 'Webserver-IP-adres|Client-initiated renegotiation', detail_web_tls_renegotiation_client_verdict_bad: 'Je webserver staat client-initiated renegotiation toe, wat een negatieve invloed kan hebben op de beschikbaarheid van je website.', @@ -562,29 +565,31 @@ const internet_nl_messages = { detail_web_mail_ipv6_ns_reach_tech_table: 'Nameserver|Onbereikbaar IPv6-adres', detail_web_mail_ipv6_ns_reach_verdict_bad: 'Niet alle nameservers die een IPv6-adres hebben zijn bereikbaar via IPv6.', detail_web_mail_ipv6_ns_reach_verdict_good: 'Alle nameservers die een IPv6-adres hebben zijn bereikbaar via IPv6.', - detail_web_mail_rpki_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je domein.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Niveau van vereistheid: Aanbevolen', + detail_web_mail_rpki_ns_exists_exp: 'We testen of er een RPKI Route Origin Authorisation (ROA) is gepubliceerd voor alle IP-adressen van de nameservers van je domein.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen van je server moeten sturen.

Een route-aankondiging is echter te vervalsen. Een andere netwerkprovider kan namelijk in de positie zijn om het IP-adresblok van jouw IP-adres te koppelen aan zijn netwerk en op die manier mogelijk internetverkeer te ontvangen dat eigenlijk voor jouw netwerkprovider bedoeld is. De oorzaak kan per ongeluk of kwaadwillig zijn. In beide gevallen kan het ertoe leiden dat je server onbereikbaar is of dat internetverkeer naar je server wordt onderschept.

Resource Public Key Infrastructure (RPKI) verbetert de bescherming hiertegen aanzienlijk. Met RPKI kan de rechtmatige houder van een blok IP-adressen namelijk een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation; afgekort: ROA) publiceren. Een andere netwerkprovider die internetverkeer wil sturen naar een bepaalde IP-adres, kan de bijbehorende verklaring gebruiken om ongeldige (Invalid) routes te filteren. Daarmee voorkomt de netwerkprovider dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.', detail_web_mail_rpki_ns_exists_label: 'Aanwezigheid van Route Origin Authorisation', detail_web_mail_rpki_ns_exists_tech_table: 'Nameserver|IP-adres|RPKI Route Origin Authorization', detail_web_mail_rpki_ns_exists_verdict_bad: 'Voor tenminste één van de IP-adressen van je nameservers is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_mail_rpki_ns_exists_verdict_good: 'Voor alle IP-adressen van je nameservers is een RPKI Route Origin Authorisation (ROA) gepubliceerd.', detail_web_mail_rpki_ns_exists_verdict_no_addresses: 'Je domein bevat geen nameservers. Daarom kon deze subtest niet worden uitgevoerd.', - detail_web_mail_rpki_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je domein Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

  • Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

  • Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");

  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

Let op: De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.

  • NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Niveau van vereistheid: Aanbevolen', + detail_web_mail_rpki_ns_valid_exp: 'We testen of de validatie-status van alle IP-adressen van de nameservers van je domein Valid is. Als er meerdere overlappende route-aankondigingen voor het IP-adres zijn, dan testen we of die allemaal Valid zijn.

Je hoster (of zijn netwerkprovider) kondigt via het Border Gateway Protocol (BGP) aan voor welke van zijn IP-adresblokken hij inkomend internetverkeer accepteert. Dat doet hij door (delen van) zijn IP-adresblokken (Route Prefix) aan het unieke nummer van zijn providernetwerk (Route Origin ASN) te koppelen, en door deze routeringsinformatie vervolgens te verspreiden. Andere netwerkproviders gebruiken deze route-aankondigingen om te bepalen via welke route ze het verkeer voor de IP-adressen moeten sturen.

Aanvullend kan je hoster (of zijn netwerkprovider) voor iedere route-aankondiging een digitaal ondertekende verklaring met route-autorisatie (Route Origin Authorisation, afgekort: ROA) publiceren met behulp van Resource Public Key Infrastructure (RPKI).

Een andere netwerkprovider die gevraagd wordt om internetverkeer te sturen naar het IP-adres van je server, kan de bijbehorende verklaring cryptografisch controleren. De gecontroleerde inhoud (Validated ROA Payload; afgekort: VRP) omvat welke providernetwerken (VRP ASN) voor ieder opgenomen IP-adresblok (VRP Prefix) geautoriseerd zijn om internetverkeer te ontvangen.

De netwerkprovider kan deze inhoud vervolgens gebruiken om BGP-routes te filteren. Hij kan bijvoorbeeld eventuele Invalid routes weigeren om te voorkomen dat internetverkeer vanuit zijn netwerk naar ongeautoriseerde providernetwerken wordt gestuurd.

Het vergelijken van route-aankondigingen met route-autorisaties (RPKI Origin Validation; afgekort: ROV) kent de onderstaande drie mogelijk uitkomsten.

1․ Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste één gepubliceerde route-autorisatie. Een route-autorisatie is ook matchend voor meer specifieke route-aankondigingen (d.w.z. voor een deel van het IP-adresblok dat in de route-autorisatie staat), tenzij deze meer specifiek zijn dan de limiet die in de route-autorisatie is bepaald (via het maxLength attribuut).

2․ Invalid: De route-aankondiging van het desbetreffende IP-adres is wel afgedekt door een route-autorisatie, maar deze matcht niet. Er zijn twee mogelijke oorzaken:

  • het IP-adresblok (Route Prefix) wordt aangekondigd vanaf een providernetwerk (Route Origin ASN) dat in de route-autorisatie niet is geautoriseerd (resultaat in onderstaande tabel: "invalid (as)");
  • het IP-adresblok (Route Prefix) dat wordt aangekondigd is kleiner dan wordt toegestaan in de route-autorisatie, d.w.z. overschrijding van maxLength waarde (resultaat in onderstaande tabel: "invalid (length)").

3․ NotFound: Er is geen verklaring met route-autorisatie gevonden die de route-aankondiging van het desbetreffende IP-adres afdekt. De routering van internetverkeer naar jouw server is daardoor minder veilig. Neem hierover contact op met je hoster. Deze kan zijn netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.

Wat te doen als het testresultaat de status Invalid toont?

De status Invalid duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je hoster of zijn netwerkprovider (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je hoster. Bij een interne fout moet je hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen. ', detail_web_mail_rpki_ns_valid_label: 'Geldigheid van route-aankondiging', detail_web_mail_rpki_ns_valid_tech_table: 'Nameserver|BGP Route Prefix|BGP Route Origin ASN|RPKI Origin Validation status', detail_web_mail_rpki_ns_valid_verdict_bad: 'Ten minste één IP-adres van je nameservers heeft een NotFound validatie-status. Er is geen RPKI Route Origin Authorisation (ROA) gepubliceerd voor zijn route-aankondiging.', detail_web_mail_rpki_ns_valid_verdict_good: 'Alle IP-adressen van je nameservers hebben een Valid validatie-status. De route-aankondiging van deze IP-adressen wordt gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA).', - detail_web_mail_rpki_ns_valid_verdict_invalid: 'Tenminste één IP-adres van je nameservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je nameserver-hoster. Bij een interne fout moet je nameserver-hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + detail_web_mail_rpki_ns_valid_verdict_invalid: 'Tenminste één IP-adres van je nameservers heeft een Invalid validatie-status. De route-aankondiging van de desbetreffende IP-adressen wordt niet gematcht door de gepubliceerde RPKI Route Origin Authorisation (ROA). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je nameserver-hoster. Bij een interne fout moet je nameserver-hoster zijn netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', detail_web_mail_rpki_ns_valid_verdict_not_routed: 'Deze subtest werd niet uitgevoerd, omdat er voor geen van de IP-adressen een route-aankondiging beschikbaar was.', domain_pagetitle: 'Websitetest:', domain_title: 'Websitetest: {{prettyaddr}} ', domain_tweetmessage: 'De%20website%20{{report.domain}}%20scoort%20{{score}}%25%20in%20de%20websitetest%20van%20%40Internet_nl%3A', faqs_appsecpriv_title: 'Beveiligingsopties', faqs_badges_title: 'Gebruik van 100%-badges', + faqs_batch_and_dashboard_title: 'Batch API en webgebaseerd dashboard', faqs_dnssec_title: 'Domeinnaamhandtekening (DNSSEC)', faqs_halloffame_title: 'Criteria voor \'Hall of Fame voor Hosters\'', faqs_https_title: 'Beveiligde websiteverbinding (HTTPS)', faqs_ipv6_title: 'Modern adres (IPv6)', faqs_mailauth_title: 'Protectie tegen e-mailphishing (DMARC, DKIM en SPF)', + faqs_measurements_title: 'Metingen met Internet.nl', faqs_report_score_title: 'Norm en score', faqs_report_subtest_bad: 'Slecht: gezakt voor VEREISTE subtest ⇒ nulscore', faqs_report_subtest_error: 'Testfout: uitvoeringsfout tijdens testen ⇒ nulscore', @@ -745,7 +750,9 @@ const internet_nl_messages = { test_mailipv6_title: 'Bereikbaar via modern internetadres?', test_mailipv6_warning_description: 'Helaas! Je mailserver is niet bereikbaar voor verzenders met moderne adressen (IPv6), of er is verbetering mogelijk. Daardoor maakt je mailserver nog geen onderdeel uit van het moderne internet. Vraag je e-mailprovider om IPv6 volledig aan te zetten.', test_mailipv6_warning_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_mailrpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende mailserver(s) en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je mailhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + test_mailrpki_error_description: 'De test kan nog niet worden uitgevoerd. Probeer het later nog eens. Sorry voor het ongemak.', + test_mailrpki_error_summary: 'Test niet klaar om uit te voeren (RPKI)', + test_mailrpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende mailserver(s) en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je mailhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je mailhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', test_mailrpki_failed_summary: 'Ongeautoriseerde route-aankondiging (RPKI)', test_mailrpki_info_description: 'Ter informatie: Je domein bevat geen nameservers en dus ook geen ontvangende mailserver(s). Er zijn geen routeerbare IP-adressen die kunnen worden getest (RPKI).', test_mailrpki_info_summary: 'Geen routeerbare IP-adressen gevonden (RPKI)', @@ -753,7 +760,7 @@ const internet_nl_messages = { test_mailrpki_passed_description: 'Goed gedaan! Alle IP-adressen van je ontvangende mailserver(s) en bijbehorende nameservers hebben een route-aankondiging die wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Daardoor is het e-mailtransport tussen verzendende mailservers met ingeschakelde route-validatie en jouw ontvangende mailserver(s) beter beschermd tegen diverse onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers.', test_mailrpki_passed_summary: 'Geautoriseerde route-aankondiging (RPKI)', test_mailrpki_title: 'Route-autorisatie?', - test_mailrpki_warning_description: 'Waarschuwing! Ten minste één van de IP-adressen van je mailserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Daardoor is het e-mailtransport tussen verzendende mailservers met ingeschakelde route-validatie en jouw ontvangende mailserver(s) niet (volledig) beschermd tegen diverse onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je mailhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', + test_mailrpki_warning_description: 'Helaas! Ten minste één van de IP-adressen van je mailserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Daardoor is het e-mailtransport tussen verzendende mailservers met ingeschakelde route-validatie en jouw ontvangende mailserver(s) niet (volledig) beschermd tegen diverse onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je mailhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', test_mailrpki_warning_summary: 'Route-autorisatie niet gepubliceerd (RPKI)', test_mailtls_failed_description: 'Helaas! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) geen of een onvoldoende beveiligde verbinding opzetten. Passieve en/of actieve aanvallers kunnen daardoor e-mails onderweg naar jou lezen. Vraag je mailprovider om STARTTLS en DANE te activeren, en veilig in te stellen. ', test_mailtls_failed_summary: 'Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)', @@ -762,9 +769,9 @@ const internet_nl_messages = { test_mailtls_invalid_null_mx_description: 'Waarschuwing: Je domeinnaam adverteert een "Null MX" record dat aangeeft dat deze geen e-mail accepteert. Echter, óf je domeinnaam heeft geen A/AAAA records, waardoor het "Null MX" record onnodig is. Óf op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de "Null MX" tegenstrijdig is.', test_mailtls_invalid_null_mx_summary: 'Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)', test_mailtls_label: 'Beveiligde mailserver-verbinding (STARTTLS en DANE)', - test_mailtls_no_mx_description: 'Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die geen A/AAAA records heeft. Dat is prima als je geen e-mail wilt ontvangen. Merk op dat je in dit geval geen \'Null MX\' record nodig hebt. Door je configuratie zijn de subtesten in de categorieën voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorieën voor IPv6 en DNSSEC.', + test_mailtls_no_mx_description: 'Ter informatie: Het SPF-record op je domeinnaam geeft aan dat je domeinnaam kan worden gebruikt voor het verzenden van e-mail. Je domeinnaam heeft echter geen ontvangende mailserver (MX), wat de bezorgbaarheid van je verzonden e-mail kan belemmeren omdat het ontbreken van een MX door ontvangers kan worden gezien als een indicator voor spam. Als je daarom echt mail vanaf deze domeinnaam wilt verzenden, configureer dan een MX. Als je echter geen mail wilt versturen vanaf deze domeinnaam, configureer dan een SPF-record met alleen de term -all en daarnaast een "Null MX" record als je domeinnaam A/AAAA-records heeft. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', test_mailtls_no_mx_summary: 'Goed geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)', - test_mailtls_no_null_mx_description: 'Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je domeinnaam die A/AAAA records heeft. We raden je aan om expliciet aan te geven dat je domeinnaam geen e-mail accepteert door een "Null MX" record te configureren. Door je huidige configuratie zijn de subtesten in de categorieën voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorieën voor IPv6 en DNSSEC.', + test_mailtls_no_null_mx_description: 'Ter informatie: Er zijn geen ontvangende mailservers (MX) ingesteld op je domein dat A/AAAA-records heeft en dat een SPF-record heeft met alleen de term -all. We raden je aan een "Null MX" record in te stellen om expliciet aan te geven dat je domein geen e-mail accepteert. Vanwege je configuratie zijn de subtests in de categorie STARTTLS en DANE en de mailserver-specifieke subtests in de categorieën IPv6 en DNSSEC niet van toepassing.', test_mailtls_no_null_mx_summary: 'Niet expliciet geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)', test_mailtls_null_mx_description: 'Ter informatie: Je domeinnaam die A/AAAA-records heeft, geeft duidelijk aan dat het geen e-mail accepteert door een "Null MX" record te adverteren. Dat is prima als je geen e-mail wilt ontvangen. Je configuratie maakt de subtesten in de categorieën voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorieën voor IPv6 en DNSSEC.', test_mailtls_null_mx_summary: 'Goed geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)', @@ -781,15 +788,15 @@ const internet_nl_messages = { test_mailtls_untestable_summary: 'Niet-testbare mailserver (STARTTLS en DANE)', test_mailtls_warning_description: 'Helaas! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) geen of een onvoldoende beveiligde verbinding opzetten. Passieve en/of actieve aanvallers kunnen daardoor e-mails onderweg naar jou lezen. Vraag je mailprovider om STARTTLS en DANE te activeren, en veilig in te stellen. ', test_mailtls_warning_summary: 'Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)', - test_siteappsecpriv_failed_description: 'Helaas! Niet alle vereiste beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_failed_description: 'Helaas! Niet alle vereiste beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_failed_summary: 'Een of meer vereiste beveiligingsopties niet ingesteld (Beveiligingsopties) ', - test_siteappsecpriv_info_description: 'Ter informatie: Niet alle optionele beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_info_description: 'Ter informatie: Niet alle optionele beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_info_summary: 'Een of meer optionele beveiligingsopties niet ingesteld (Beveiligingsopties) ', test_siteappsecpriv_label: 'Beveiligingsopties', - test_siteappsecpriv_passed_description: 'Goed gedaan! Alle beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_passed_description: 'Goed gedaan! Alle beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_passed_summary: 'Alle beveiligingsopties ingesteld (Beveiligingsopties)', test_siteappsecpriv_title: 'Beveiligingsopties ingesteld?', - test_siteappsecpriv_warning_description: 'Waarschuwing: Niet alle aanbevolen beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties. Verder is het zo dat security headers (behalve Referrer-Policy) niet relevant zijn voor domeinen die redirecten (via een 301/302 HTTP Status Code).', + test_siteappsecpriv_warning_description: 'Waarschuwing: Niet alle aanbevolen beveiligingsopties, dat wil zeggen security headers en security.txt, zijn ingesteld voor je website (Beveiligingsopties). Met security headers kan je browsermechanismen activeren om bezoekers te beschermen tegen aanvallen met bijvoorbeeld cross-site scripting (XSS) of framing. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \'301 Redirect\' en \'404 Not Found\', omdat ze hun eigen browsercontext creëren (MIME type \'text/html\') die kwetsbaar kan zijn voor bepaalde aanvallen. Via een security.txt-bestand kan je onderzoekers die een kwetsbaarheid op je systemen hebben gevonden, voorzien van je contactgegevens en je Coordinated Vulnerability Disclosure policy. Merk op dat HTTPS een voorwaarde is voor alle geteste beveiligingsopties.', test_siteappsecpriv_warning_summary: 'Een of meer aanbevolen beveiligingsopties niet ingesteld (Beveiligingsopties) ', test_sitednssec_failed_description: 'Helaas! Je domeinnaam is niet ondertekend met een geldige handtekening (DNSSEC). Daardoor zijn bezoekers die controle van domein-handtekeningen geactiveerd hebben, niet beschermd tegen gemanipuleerde vertaling van jouw domeinnaam naar kwaadaardige internetadressen. Vraag je nameserver-beheerder (vaak je registrar en/of hostingprovider) om DNSSEC te activeren.', test_sitednssec_failed_summary: 'Domeinnaam niet ondertekend (DNSSEC)', @@ -811,7 +818,9 @@ const internet_nl_messages = { test_siteipv6_title: 'Bereikbaar via modern adres?', test_siteipv6_warning_description: 'Helaas! Je website is niet bereikbaar voor bezoekers die een modern internetadres (IPv6) gebruiken, of er is verbetering mogelijk. Daardoor maakt je website nog geen onderdeel uit van het moderne internet. Vraag je hostingprovider om IPv6 volledig aan te zetten.', test_siteipv6_warning_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_siterpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende webserver en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen kan het leiden tot de onbereikbaarheid van je server of het onderscheppen van internetverkeer naar je server. Neem zo spoedig mogelijk contact op met je webhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', + test_siterpki_error_description: 'De test kan nog niet worden uitgevoerd. Probeer het later nog eens. Sorry voor het ongemak.', + test_siterpki_error_summary: 'Test niet klaar om uit te voeren (RPKI)', + test_siterpki_failed_description: 'Helaas! Ten minste één van de IP-adressen van je ontvangende webserver en bijbehorende nameservers heeft een route-aankondiging die niet wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Dit duidt op een onbedoelde of kwaadwillige route-configuratiefout, die wordt veroorzaakt door je webhoster of je nameserver-hoster (interne fout) óf door een derde partij (externe fout). In beide gevallen verhoogt dit het risico dat je server onbereikbaar wordt of dat internetverkeer naar je server wordt onderschept. Neem zo spoedig mogelijk contact op met je webhoster of nameserver-hoster. Bij een interne fout moeten zij hun netwerkprovider die eigenaar is van de IP-adressen van je server, vragen om de route-configuratiefout te herstellen.', test_siterpki_failed_summary: 'Ongeautoriseerde route-aankondiging (RPKI)', test_siterpki_info_description: 'Ter informatie: Je domein bevat geen nameservers en dus ook geen IP-adressen van webservers. Er zijn geen routeerbare IP-adressen die kunnen worden getest (RPKI).', test_siterpki_info_summary: 'Geen routeerbare IP-adressen gevonden (RPKI)', @@ -819,7 +828,7 @@ const internet_nl_messages = { test_siterpki_passed_description: 'Goed gedaan! Alle IP-adressen van je webserver en bijbehorende nameservers hebben een route-aankondiging die wordt gematcht door de gepubliceerde route-autorisatie (RPKI). Daardoor zijn bezoekers met ingeschakelde route-validatie beter beschermd tegen verschillende onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers.', test_siterpki_passed_summary: 'Geautoriseerde route-aankondiging (RPKI)', test_siterpki_title: 'Route-autorisatie?', - test_siterpki_warning_description: 'Waarschuwing! Ten minste één van de IP-adressen van je webserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Als gevolg daarvan zijn bezoekers met ingeschakelde routevalidatie niet (volledig) beschermd tegen verschillende onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je webhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', + test_siterpki_warning_description: 'Helaas! Ten minste één van de IP-adressen van je webserver en bijbehorende nameservers heeft een route-aankondiging waarvoor geen route-autorisatie is gepubliceerd (RPKI). Als gevolg daarvan zijn bezoekers met ingeschakelde routevalidatie niet (volledig) beschermd tegen verschillende onbedoelde of kwaadwillige route-configuratiefouten, die kunnen leiden tot de onbereikbaarheid van je servers of de onderschepping van internetverkeer naar je servers. Neem hierover contact op met je webhoster of nameserver-hoster. Zij kunnen hun netwerkprovider die eigenaar is van de IP-adressen van je server vragen om route-autorisaties te publiceren.', test_siterpki_warning_summary: 'Route-autorisatie niet gepubliceerd (RPKI)', test_sitetls_failed_description: 'Helaas! De verbinding met je website is niet of onvoldoende beveiligd (HTTPS). Gegevens die onderweg zijn tussen je website en haar bezoekers, zijn daardoor niet voldoende beschermd tegen afluisteren en manipulatie. Vraag je hostingprovider om HTTPS aan te zetten en veilig te configureren.', test_sitetls_failed_summary: 'Verbinding niet of onvoldoende beveiligd (HTTPS)',