From aaf65f3f36c7654fb6c7599e9d1c4efe86ae95dc Mon Sep 17 00:00:00 2001 From: stitch1 Date: Fri, 7 Feb 2025 15:07:55 +0100 Subject: [PATCH 1/9] clean up some installation details --- README.md | 8 +- .../management/commands/connect_superusers.py | 27 +++++++ docs/input/1_installation.rst | 75 ++++++++++--------- 3 files changed, 71 insertions(+), 39 deletions(-) create mode 100644 dashboard/internet_nl_dashboard/management/commands/connect_superusers.py diff --git a/README.md b/README.md index 43451ee9..c7211384 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@ -For quick installation: Follow [these quick instructions](https://github.com/internetstandards/Internet.nl-dashboard/blob/50/docs/render/markdown/1_installation.md) -and watch [this 6 minute video](https://github.com/internetstandards/Internet.nl-dashboard/tree/50/docs/input/internet.nl%20dashboard%20installation%20video%20small.mp4). +For quick installation: Follow [these quick instructions](https://github.com/internetstandards/Internet.nl-dashboard/blob/main/docs/render/markdown/1_installation.md) +and watch [this 6 minute video](https://github.com/internetstandards/Internet.nl-dashboard/tree/main/docs/input/internet.nl%20dashboard%20installation%20video%20small.mp4). # Internet.nl Dashboard The internet.nl dashboard allows you to visualize batch scans from the internet.nl API. It allows: @@ -18,8 +18,8 @@ The internet.nl dashboard allows you to visualize batch scans from the internet. ## Setup / installation -For quick installation: Follow [these quick instructions](https://github.com/internetstandards/Internet.nl-dashboard/blob/50/docs/render/markdown/1_installation.md) -and watch [this 6 minute video](https://github.com/internetstandards/Internet.nl-dashboard/tree/50/docs/input/internet.nl%20dashboard%20installation%20video%20small.mp4). +For quick installation: Follow [these quick instructions](https://github.com/internetstandards/Internet.nl-dashboard/blob/main/docs/render/markdown/1_installation.md) +and watch [this 6 minute video](https://github.com/internetstandards/Internet.nl-dashboard/tree/main/docs/input/internet.nl%20dashboard%20installation%20video%20small.mp4). ## Screenshots diff --git a/dashboard/internet_nl_dashboard/management/commands/connect_superusers.py b/dashboard/internet_nl_dashboard/management/commands/connect_superusers.py new file mode 100644 index 00000000..61da73e6 --- /dev/null +++ b/dashboard/internet_nl_dashboard/management/commands/connect_superusers.py @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: Apache-2.0 +import logging + +from django.core.management.base import BaseCommand +from django.contrib.auth.models import User + +from dashboard.internet_nl_dashboard.models import DashboardUser, Account + +log = logging.getLogger(__package__) + + +class Command(BaseCommand): + + def handle(self, *args, **options): + superusers = User.objects.all().filter(is_superuser=True) + + for user in superusers: + if not DashboardUser.objects.filter(user=user).first(): + DashboardUser.objects.create( + user=user, + account=Account.objects.all().first(), # should always exist + mail_preferred_language='en', + mail_send_mail_after_scan_finished=False, + mail_after_mail_unsubscribe_code='', + ) + print(f"Added DashboardUser for superuser {user}") + print("Done") diff --git a/docs/input/1_installation.rst b/docs/input/1_installation.rst index 94f889bd..7a0f060a 100644 --- a/docs/input/1_installation.rst +++ b/docs/input/1_installation.rst @@ -40,6 +40,8 @@ What do you need * Optional: a domain name and SMTP settings +On this machine you need to be running docker, orbstack or something like that. + .. rst-class:: page-break .. raw:: pdf @@ -54,7 +56,7 @@ Installation is mostly configuration work inside the dashboard. Some of the belo is released. -Running the dashboard (during development of 5.0) +Running the dashboard ------------------------------------------------- In the command shell, perform the following commands. @@ -63,32 +65,14 @@ In the command shell, perform the following commands. git clone https://github.com/internetstandards/Internet.nl-dashboard/ cd Internet.nl-dashboard - git checkout 50 docker compose up --build -After a short while your dashboard instance will be ready at :8000. - -You can start and restart the application by running ``docker compose up --build``, use control+c to stop. - - -Running the dashboard (when 5.0 is released) --------------------------------------------- -Download the version you want to run. These can be downloaded from the releases page, here: -https://github.com/internetstandards/Internet.nl-dashboard/releases - -Releases from version 5.0 and over support docker compose. You can also download a release -from the command line, with the following command: - -:: - - mkdir dashboard && cd dashboard - wget https://github.com/internetstandards/Internet.nl-dashboard/archive/refs/tags/v5.0.tar.gz - tar -zxvf v5.0.tar.gz - docker compose up --build +After a short while your dashboard instance will be ready at http://localhost:8000 -After a short while your dashboard instance will be ready at :8000. +Note that on local environments the web application will not work well with the Apple Safari browser due to +CSRF security policies that come out of the box. Please use another browser for testing purposes. -You can start and restart the application by running ``docker compose up --build``, use control+c to stop. +For production environments we recommend running a reverse proxy to this port. Examples include nginx or apache. Load up default configuration @@ -120,21 +104,14 @@ If you also want an example lists to get started, run the following command. Setting up the first user ------------------------- +After setting up the first user administration can be performed via the administrative interface. + Create a new user: ``docker exec -ti internetnl-dashboard-backend-1 dashboard createsuperuser`` - -Associate that user to the default account, assuming the createsuperuser was added with user id 1: - -``docker exec -ti internetnl-dashboard-database-1 psql --user dashboard -c "update internet_nl_dashboard_dashboarduser set account_id=1 where user_id=1;"`` - - -If you get an error that a certain user already exists, this might not be your first attempt to install the dashboard -via this method. The docker installation method shares the same database. -Make sure to associate the newly created super user also is connected to an account. This can be performed with SQL and -via the admin portal. - +Then connect the superuser to a dashboard account. Superusers can join any account through the front-end or admin interface: +``docker exec -ti internetnl-dashboard-backend-1 dashboard connect_superusers`` Logging in ---------- @@ -196,6 +173,15 @@ Use the following commands, of course with your own personal settings:: docker exec -ti internetnl-dashboard-backend-1 dashboard constance set INTERNET_NL_SCAN_TRACKING_NAME "My Dashboard Instance" +Examples of these settings for internet.nl servers are: + + - DASHBOARD_FRONTEND_URL https://dashboard.internet.nl + - INTERNET_NL_API_URL https://batch.internet.nl/api/batch/v2 + - CREDENTIAL_CHECK_URL https://batch.internet.nl/api/batch/v2/requests + - INTERNET_NL_SCAN_TRACKING_NAME "My Internet.nl Dashboard" + - EMAIL_DASHBOARD_ADDRESS https://dashboard.internet.nl + + 4. Setup the API credentials for the account. 1. Go to the account management page @@ -221,6 +207,7 @@ You are now set to perform your first scan. PageBreak + Performing your first scan ========================== @@ -272,7 +259,8 @@ Advanced configuration Setting up e-mail notification after scanning --------------------------------------------- -After a scan completes it's possible to receive an e-mail. An SMTP server has to be configured. +After a scan completes it's possible to receive an e-mail. An SMTP server has to be configured in the admin interface, +here: http://localhost:8000/admin/django_mail_admin/outbox/ 1. Visit the admin interface on ``/admin/`` and log in. @@ -289,6 +277,23 @@ templates is English and several templates are pre-installed to be customized. F check the :ref:`email templates` chapter. + +Setting up subdomain suggestions +-------------------------------- + +It's possible to use subdomain suggestions when managing lists of urls. The exact instructions for running and installing +this feature are to be documented. + +In the admin interface on http://localhost:8000/admin/constance/config/ you will find the possibility to use subdomain +suggestions via a separate installation of the CTLSSA tool. + +The CTLSSA tool can be found here and run via docker: +https://github.com/internetstandards/Internet.nl-ct-log-subdomain-suggestions-api/ + +In the internet.nl dashboard settings, point the SUBDOMAIN_SUGGESTION_SERVER_ADDRESS setting to the CTLSSA instance. + + + .. rst-class:: page-break .. raw:: pdf From c6392a7e8195f191a753f75f6b6f67fd6547b4ca Mon Sep 17 00:00:00 2001 From: stitch1 Date: Fri, 7 Feb 2025 15:16:52 +0100 Subject: [PATCH 2/9] add preliminary release notes --- CHANGELOG.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5720054a..5a6ddaca 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,20 @@ All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## V5.0.0 - t.b.d. +Subdomain suggestions + +### Added +- Subdomain suggestions using the [CTLSSA tool](https://github.com/internetstandards/Internet.nl-ct-log-subdomain-suggestions-api/) (#434) +- Extensive installation guide, [these quick instructions](https://github.com/internetstandards/Internet.nl-dashboard/blob/main/docs/render/markdown/1_installation.md) (#495) +- Added German and French translations via DeepL + translations warnings (these will contain imperfections) + +### Changed +- Major javascript front-end updates to remove vulnerabilities and being able to stay up to date +- Various layout fixes to improve experience of the dashboard on mobile (#472) +- Reworked the translations to support AI translations + + ## V4.4.0 - 22 july 2024 Maintenance release to reduce the amount of disk space used. From 0ad7d0d3d19abd193ddd3f539541546ba17f3278 Mon Sep 17 00:00:00 2001 From: stitch1 Date: Tue, 18 Feb 2025 14:33:39 +0100 Subject: [PATCH 3/9] make it clear what settings come from wsm --- CHANGELOG.md | 2 +- .../management/commands/connect_superusers.py | 8 ++++---- dashboard/settings_constance.py | 20 +++++++++++++++++++ 3 files changed, 25 insertions(+), 5 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 5a6ddaca..36f64dbc 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -13,7 +13,7 @@ Subdomain suggestions - Added German and French translations via DeepL + translations warnings (these will contain imperfections) ### Changed -- Major javascript front-end updates to remove vulnerabilities and being able to stay up to date +- Major javascript front-end rework to remove vulnerabilities and being able to stay up to date - Various layout fixes to improve experience of the dashboard on mobile (#472) - Reworked the translations to support AI translations diff --git a/dashboard/internet_nl_dashboard/management/commands/connect_superusers.py b/dashboard/internet_nl_dashboard/management/commands/connect_superusers.py index 61da73e6..4e5cc818 100644 --- a/dashboard/internet_nl_dashboard/management/commands/connect_superusers.py +++ b/dashboard/internet_nl_dashboard/management/commands/connect_superusers.py @@ -1,10 +1,10 @@ # SPDX-License-Identifier: Apache-2.0 import logging -from django.core.management.base import BaseCommand from django.contrib.auth.models import User +from django.core.management.base import BaseCommand -from dashboard.internet_nl_dashboard.models import DashboardUser, Account +from dashboard.internet_nl_dashboard.models import Account, DashboardUser log = logging.getLogger(__package__) @@ -19,9 +19,9 @@ def handle(self, *args, **options): DashboardUser.objects.create( user=user, account=Account.objects.all().first(), # should always exist - mail_preferred_language='en', + mail_preferred_language="en", mail_send_mail_after_scan_finished=False, - mail_after_mail_unsubscribe_code='', + mail_after_mail_unsubscribe_code="", ) print(f"Added DashboardUser for superuser {user}") print("Done") diff --git a/dashboard/settings_constance.py b/dashboard/settings_constance.py index 6fe8a962..203be0b4 100644 --- a/dashboard/settings_constance.py +++ b/dashboard/settings_constance.py @@ -7,6 +7,8 @@ "json": ["django.forms.fields.JSONField", {"required": False}], } +# A bunch of below settings are duplicates from web security map. In future versions they should just be imported +# from that project. Please do not remove them, they are marked with a warning and a to do to deduplicate them. CONSTANCE_CONFIG = { # general settings "DASHBOARD_FRONTEND_URL": ( @@ -41,11 +43,13 @@ str, ), # scan settings + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "SCAN_AT_ALL": ( True, "This enables or disabled all scans. Note that scans that are picked up will still be processed.", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_API_URL": ( "http://localhost:8080/api/batch/v2", 'The internet address for the Internet.nl API installation. This is commonly called a "batch server".', @@ -58,6 +62,7 @@ "organization name. The maximum length is 40 characters.", str, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "SCANNER_NAMESERVERS": ( [ "193.17.47.1", @@ -111,17 +116,20 @@ str, ), # security.txt + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "SECURITY_TXT_IS_REDIRECTED": ( False, "Security.txt is used to allow security researchers to report vulnerabilities. This can be either set to a " "redirect to an existing security.txt or configured with your own security.txt policy.", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "SECURITY_TXT_REDIRECT_URL": ( "http://localhost:8000/.well-known/security.txt", "The url where the security.txt files redirect to. This is usually an external site.", str, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "SECURITY_TXT_CONTENT": ( "", "The content of the security.txt file, located at .well-known/security.txt. Only " @@ -168,6 +176,7 @@ "SCAN_TIMEOUT_MINUTES_SENDING_MAIL": (1440, "timeout for phase SENDING_MAIL", int), "SCAN_TIMEOUT_MINUTES_SERVER_ERROR": (1440, "timeout for phase SERVER_ERROR", int), # other stuff + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_API_USERNAME": ( "dummy", "Username for the internet.nl API. This option is ignored as every account uses their own credentials. Keep " @@ -175,62 +184,73 @@ str, ), # this is defaulting to dummy as otherwise the scanner wil give an error that no credential has been configured. + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_API_PASSWORD": ( "dummy", "Username for the internet.nl API. This option is ignored as every account uses their own credentials. Keep " "this value set to dummy for legacy reasons.", str, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_MAXIMUM_URLS": ( 1000, "The maximum amount of domains per scan, not relevant for dashboard, only for websecmap.", int, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "SCANNER_LOG_PLANNED_SCANS": ( False, "Used when debugging, logs all changes to planned scans to a separate table. Causes millions of records a day", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "SCANNER_AUTO_PURGE_FINISHED_SCANS": ( True, "Removes the scan record from the planned scan table, which reduces the amount of data stored.", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "CONNECTIVITY_TEST_DOMAIN": ( "internet.nl", "A server that is reachable over IPv4. This is used by a worker to determine what kind of scans it can do. " "Enter an address that you own or manage.", str, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "IPV6_TEST_DOMAIN": ( "internet.nl", "A server that is reachable over IPv6. This is used by a worker to determine " "what kind of scans it can do. Enter an address that you own or manage.", str, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_ADD_CALCULATED_RESULTS_WEBSECMAP": ( False, "Add calculated results for web security map. This is used only for installations by the " "Internet Cleanup Foundation.", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_ADD_CALCULATED_RESULTS_FORUM_STANDAARDISATIE": ( False, "Add calculated results for forum standaardisatie, the internet.nl dashboard. These calculations are created " "on top of the internet.nl metrics. These are used for official publications. You probably do not need these.", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_ADD_CALCULATED_RESULTS_VNG_V6": ( False, "Add calculated results for VNG, obsoleted IPv6 derived conclusions. No need to enable these and will be " "removed in a future release.", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "INTERNET_NL_WEB_ONLY_TOP_LEVEL": ( False, "Do not send in subdomains. To reduce the number of tests while still getting an impression on a broader scope", bool, ), + # This is a setting duplicated from Web Security Map, todo: deduplicate this setting "PROJECT_WEBSITE": ("", "", str), "SUBDOMAIN_SUGGESTION_ENABLED": ( False, From 41427d1e81661d11641cf00219dd33f2d5a928b4 Mon Sep 17 00:00:00 2001 From: stitch1 Date: Tue, 18 Feb 2025 14:45:16 +0100 Subject: [PATCH 4/9] 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)', From 17d5b20ac16a1c48dcac3ab6fd2d20456fd6d9be Mon Sep 17 00:00:00 2001 From: stitch1 Date: Wed, 19 Feb 2025 09:54:24 +0100 Subject: [PATCH 5/9] support translations to json --- .../logic/internet_nl_translations.py | 24 +- .../js/translations/internet_nl.en.json | 848 ++++++++++++++++++ .../js/translations/internet_nl.nl.json | 848 ++++++++++++++++++ 3 files changed, 1717 insertions(+), 3 deletions(-) create mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json create mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json diff --git a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py index 9b06b323..48923d54 100644 --- a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py +++ b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py @@ -1,6 +1,7 @@ # SPDX-License-Identifier: Apache-2.0 import logging import os +import json import tempfile from pathlib import Path from typing import Any, Dict, List, Union @@ -63,11 +64,13 @@ def convert_internet_nl_content_to_vue(): # support a per-language kind of file, in case we're going to do dynamic loading of languages. vue_i18n_content: str = convert_vue_i18n_format(locale, structured_content) + json_content = convert_json_format(locale, structured_content) combined_vue_i18n_content += vue_i18n_content - store_vue_i18n_file(f"internet_nl.{locale}", vue_i18n_content) + store_vue_i18n_file(f"internet_nl.{locale}.js", vue_i18n_content) + store_vue_i18n_file(f"internet_nl.{locale}.json", json.dumps(json_content, indent=2)) # the locales are easiest stored together. This makes language switching a lot easier. - store_vue_i18n_file("internet_nl", combined_vue_i18n_content) + store_vue_i18n_file("internet_nl.js", combined_vue_i18n_content) def get_locale_content(locale: str) -> bytes: @@ -127,6 +130,21 @@ def load_as_po_file(raw_content: bytes) -> List[Any]: return polib.pofile(file.name) + +def convert_json_format(locale: str, po_content: Any) -> dict: + content = {} + + for entry in po_content: + # to save a boatload of data, we're not storing the 'content' from the pages of internet.nl + # we'll just have to point to this content. + if entry.msgid.endswith("content"): + continue + + content[_js_safe_msgid(entry.msgid)] = _js_safe_msgstr(entry.msgstr) + + return content + + def convert_vue_i18n_format(locale: str, po_content: Any) -> str: """ done: will markdown be parsed to html in this method? Or should we do that on the fly, everywhere... @@ -258,7 +276,7 @@ def store_vue_i18n_file(filename: str, content: str) -> None: :param content: :return: """ - with open(f"{VUE_I18N_OUTPUT_PATH}{filename}.js", "w", encoding="UTF-8") as file: + with open(f"{VUE_I18N_OUTPUT_PATH}{filename}", "w", encoding="UTF-8") as file: file.write(content) diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json new file mode 100644 index 00000000..37b1cc8e --- /dev/null +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json @@ -0,0 +1,848 @@ +{ + "about_contact": "

Contact

Internet Standards Platform
c/o ECP
Maanweg 174 (8th floor)
2516 AB The Hague
The Netherlands

CoC number: 27169301

Email

question@internet.nl

PGP public key
Fingerprint: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Expiration date: 19th of March 2025

", + "base_about": "About Internet.nl", + "base_accessibility": "Accessibility", + "base_blogs": "Blogs", + "base_contact": "Contact", + "base_copyright": "Copyright", + "base_disclosure": "Report vulnerability", + "base_faqs": "Knowledge base", + "base_halloffame": "Hall of Fame", + "base_halloffame_champions": "Hall of Fame - Champions!", + "base_halloffame_lead": "{{count}} domains with 2 x 100%
Latest entry: {{latest|date:\\'d-m-Y\\'}}", + "base_halloffame_link": "To Hall of Fame - Champions!", + "base_halloffame_mail": "Hall of Fame - Email", + "base_halloffame_web": "Hall of Fame - Websites", + "base_home": "Home", + "base_info": "Internet.nl is an initiative of the Internet community and the Dutch government.", + "base_news": "News", + "base_newslink": "To the news overview", + "base_privacy": "Privacy statement", + "base_test_connection_explain": "

What is tested?

After you start the connection test, we will check if your currently used internet connection offers support for the modern Internet Standards below.

  • IPv6: are websites with modern internet addresses reachable for you?
  • DNSSEC: are domain signatures validated for you?

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your internet connection. Usually contacting your internet provider on this will be the best next step. In the communication with your internet provider you can use the permalink (i.e. the URL) of the test report.

Test your connection

", + "base_test_connection_label": "Test your connection", + "base_test_connection_text": "Modern addresses reachable?
Domain signatures validated?", + "base_test_connection_title": "About the connection test", + "base_test_explain": "About the test", + "base_test_mail_explain": "

What is tested?

After you enter a domain name of an email service, we will test if the email service offers support for the modern Internet Standards below.

Note: some standards are even relevant if there are no mail servers configured for your domain.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your mail service. Usually contacting your mail hoster on this will be the best next step. In the communication with your mail hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the email test into your own website using our widget code.

Test your email

", + "base_test_mail_input": "Your email address:", + "base_test_mail_label": "Test your email", + "base_test_mail_text": "Modern address? Anti-phishing? Secure transport? Route authorisation?", + "base_test_mail_title": "About the email test", + "base_test_prechecks_invalid_domain": "The given domain is invalid!
Explanation: An A and/or AAAA record is necessary for the website test, and a SOA record for the email test.", + "base_test_start": "Start test", + "base_test_website_explain": "

What is tested?

After you enter a domain name of a website, we will test if the website offers support for the modern Internet Standards below.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your website. Usually contacting your web hoster on this will be the best next step. In the communication with your web hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the website test into your own website using our widget code.

Test your website

", + "base_test_website_input": "Your website domain name:", + "base_test_website_label": "Test your website", + "base_test_website_text": "Modern address? Signed domain? Secure connection? Route authorisation?", + "base_test_website_title": "About the website test", + "base_widget_mail": "Email test widget", + "base_widget_site": "Website test widget", + "connection_pagetitle": "Connection test", + "connection_title": "Connection test", + "detail_conn_dnssec_validation_exp": "We check if the resolvers that you use validate the DNSSEC signatures of our domain name. Resolvers are usually provided by your internet provider. Alternatively you can configure resolvers from another DNS provider. You can even use your own locally installed resolver. Although validation is done in the resolver, the communication from the resolver back to your device (referred to as \\'last mile\\') could still be tampered with by an attacker. Thus the most secure way is to validate close to the end user device (e.g. by using a locally installed resolver), or make sure that the channel between your resolver and your end user device is secured/trusted.", + "detail_conn_dnssec_validation_label": "DNSSEC validation", + "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 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 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 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.", + "detail_conn_ipv6_ipv4_conn_verdict_good": "You are able to reach computers via DNS on their IPv4 address.", + "detail_conn_ipv6_privacy_exp": "We check if your device uses IPv6 Privacy Extensions for SLAAC (or another IPv6 configuration process than SLAAC) in order to prevent leakage of its potentially privacy sensitive MAC address to computers it connects with over IPV6.", + "detail_conn_ipv6_privacy_label": "Privacy Extensions for IPv6", + "detail_conn_ipv6_privacy_verdict_bad": "You are using SLAAC without \\'IPv6 Privacy Extensions\\'.", + "detail_conn_ipv6_privacy_verdict_good": "You have enabled \\'IPv6 Privacy Extensions\\' (or you are not using SLAAC).", + "detail_conn_ipv6_resolver_conn_exp": "We check if at least one of the DNS resolvers that you are using is able to reach our authoritative name servers over IPv6. Usually your internet provider provides the DNS resolver(s).", + "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).

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.", + "detail_mail_auth_dkim_verdict_no_email": "Your domain does not support DKIM records. However because your DMARC and SPF records hint that no mail is sent from your domain, DKIM is not necessary and this subtest is skipped.", + "detail_mail_auth_dmarc_exp": "We check if DMARC is available for your domain. A receiving mail server mayuse your DMARC policy to evaluate how to handle a mail with your domain assender that could not be authenticated with both DKIM and SPF, and it mayuse your mail address from the DMARC record to provide feedback reports onthe authentication to you. Having more than one DMARC record in the same domainis not valid and will lead to a test failure.Note: DMARC requires the SPFdomain (envelope sender, i.e. return-path that shows up in MAIL FROM) andthe DKIM domain (d=) to align with the mail body domain (From:).", + "detail_mail_auth_dmarc_label": "DMARC existence", + "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_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. ", + "detail_mail_auth_dmarc_policy_verdict_good": "Your DMARC policy is sufficiently strict.", + "detail_mail_auth_dmarc_policy_verdict_policy": "Your DMARC policy is not sufficiently strict.", + "detail_mail_auth_spf_exp": "We check if your domain has an SPF record. A receiving mail server can use the IP addresses in your SPF record to authenticate the sending mail server of a received email with your domain as sender. The accompanying policy can be used to take appropriate action if authentication fails. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", + "detail_mail_auth_spf_label": "SPF existence", + "detail_mail_auth_spf_tech_table": "SPF record", + "detail_mail_auth_spf_verdict_bad": "Your domain does not have a valid SPF record.", + "detail_mail_auth_spf_verdict_good": "Your domain has an SPF record.", + "detail_mail_auth_spf_policy_exp": "We check if the syntax of your SPF record is correct and if it contains a sufficiently strict policy i.e. ~all (softfail) or -all (fail) in order to prevent abuse by phishers and spammers. To be effective against abuse of your domain, a liberal policy i.e. +all (pass) or ?all (neutral) is insufficient. If all is missing and a redirect modifier is not present in your SPF record, the default is ?all.

We also follow include and redirect for valid SPF records. In addition, we check that your SPF record does not exceed the allowed number of 10 DNS lookups making it ineffective. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. While the SPF terms all, ip4, ip6 and exp do not count as DNS lookups.

Note that if the include or redirect domain consists of macros, we will not follow them as we do not have the necessary information from an actual mail or mail server connection to expand those macros. This means that we do not evaluate the outcome of macros. Moreover, we do not count DNS lookups caused by macros to determine whether the allowed number of DNS lookups has been exceeded.

For sending domains, using ~all (softfail) instead of -all (fail) is usually preferred. This is because when SPF authentication fails with an SPF fail, a receiving mail server may already block the connection without evaluating the DKIM signature and DMARC policy. This can lead to falsely blocked mails (e.g. when mails are automatically forwarded by the receiving mail server to another receiving mail server). Note that a triggered SPF softfail still ensures that a strict DMARC policy protects your domain if DKIM authentication also fails.

For no-mail domains see the good practice on explanation of the \"DMARC policy\" subtest.", + "detail_mail_auth_spf_policy_label": "SPF policy", + "detail_mail_auth_spf_policy_tech_table": "Domain|SPF record", + "detail_mail_auth_spf_policy_verdict_all": "Your SPF policy is not sufficiently strict.", + "detail_mail_auth_spf_policy_verdict_bad": "Your SPF policy is not syntactically correct.", + "detail_mail_auth_spf_policy_verdict_good": "Your SPF policy is sufficiently strict.", + "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 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 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": "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.", + "detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error": "Unfortunately an error occurred in Internet.nl\\'s resolver. Please contact us.", + "detail_mail_dnssec_mx_exists_verdict_servfail": "The name servers of at least one of your mail server domains are broken. They returned an error (SERVFAIL) to our queries for a DNSSEC signature. Please contact your name server operator (often your mail provider) to fix this soon.", + "detail_mail_dnssec_mx_valid_exp": "We check if the domains of your receiving mail servers (MX), more specifically their SOA records, are signed with a valid signature making them \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", + "detail_mail_dnssec_mx_valid_label": "DNSSEC validity", + "detail_mail_dnssec_mx_valid_tech_table": "Domain of mail server (MX)|Status", + "detail_mail_dnssec_mx_valid_verdict_bad": "At least one of your signed mail server domains is \\'bogus\\', because its DNSSEC signature is not valid. Either someone manipulated the responses from its name servers, or your mail server domain has serious DNSSEC configuration errors. The latter makes your receiving mail server unreachable for any sending mail server that validates DNSSEC signatures. You should contact the name server operator (often your mail provider) as soon as possible.", + "detail_mail_dnssec_mx_valid_verdict_good": "All your signed mail server domains are secure, because their DNSSEC signatures are valid.", + "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "At least one of your mail server domains is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", + "detail_mail_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", + "detail_mail_dnssec_valid_label": "DNSSEC validity", + "detail_mail_dnssec_valid_tech_table": "Email address domain|Status", + "detail_mail_dnssec_valid_verdict_bad": "Your email address domain is \\'bogus\\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", + "detail_mail_dnssec_valid_verdict_good": "Your email address domain is secure, because its DNSSEC signature is valid.", + "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Your email address domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", + "detail_mail_ipv6_mx_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for every receiving mail server (MX). In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.", + "detail_mail_ipv6_mx_aaaa_label": "IPv6 addresses for mail server(s)", + "detail_mail_ipv6_mx_aaaa_tech_table": "Mail server (MX)|IPv6 address|IPv4 address", + "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 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": "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.", + "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.", + "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.

1\u2024 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\u2024 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\u2024 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 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.

1\u2024 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\u2024 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\u2024 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 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", + "detail_mail_tls_cert_hostmatch_tech_table": "Mail server (MX)|Unmatched domains on certificate", + "detail_mail_tls_cert_hostmatch_verdict_bad": "The domain name of at least one of your mail servers does not match the domain name on the mail server certificate.", + "detail_mail_tls_cert_hostmatch_verdict_good": "The domain names of all your mail servers match the domain names on your mail server certificates.", + "detail_mail_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 \u2013 3071 bit
  • Insufficient: Less than 2048 bit
", + "detail_mail_tls_cert_pubkey_label": "Public key of certificate", + "detail_mail_tls_cert_pubkey_tech_table": "Mail server (MX)|Affected signature parameters|Status", + "detail_mail_tls_cert_pubkey_verdict_bad": "The digital signature of at least one of your mail server certificates uses insufficiently secure parameters.", + "detail_mail_tls_cert_pubkey_verdict_good": "The digital signatures of all your mail server certificates use secure parameters.", + "detail_mail_tls_cert_pubkey_verdict_phase_out": "The digital signature of at least one of your mail server certificates uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", + "detail_mail_tls_cert_signature_exp": "

We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", + "detail_mail_tls_cert_signature_label": "Signature of certificate", + "detail_mail_tls_cert_signature_tech_table": "Mail server (MX)|Affected hash algorithm|Status", + "detail_mail_tls_cert_signature_verdict_bad": "At least one of your mail server certificates is signed using a hash algorithm that is insufficiently secure.", + "detail_mail_tls_cert_signature_verdict_good": "All your mail server certificates are signed using a secure hash algorithm.", + "detail_mail_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your mail server certificates.

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

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

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

Requirement level: Optional", + "detail_mail_tls_cert_trust_label": "Trust chain of certificate", + "detail_mail_tls_cert_trust_tech_table": "Mail server (MX)|Untrusted certificate chain", + "detail_mail_tls_cert_trust_verdict_bad": "The trust chain of at least one of your mail server certificates is not complete and/or not signed by a trusted root certificate authority.", + "detail_mail_tls_cert_trust_verdict_good": "The trust chain of all your mail server certificates is complete and signed by a trusted root certificate authority.", + "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 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\\').", + "detail_mail_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

At least one of your mail servers does not offer ciphers in accordance with the prescribed ordering within a particular security level (\\'II-B\\').", + "detail_mail_tls_ciphers_exp": "

We check if your receiving mail servers (MX) only support secure, i.e. \\'Good\\' and/or \\'Sufficient\\', ciphers (also known as algorithm selections).

To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \\'cipher suite\\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \\'cipher suite\\' ambiguous, NCSC-NL uses the term \\'algorithm selection\\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \\'Good\\', \\'Sufficient\\' and \\'Phase out\\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \\'IT Security Guidelines for Transport Layer Security (TLS)\\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \\'Phase out\\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_mail_tls_ciphers_label": "Ciphers (Algorithm selections)", + "detail_mail_tls_ciphers_tech_table": "Mail server (MX)|First found affected cipher|Status", + "detail_mail_tls_ciphers_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure ciphers.", + "detail_mail_tls_ciphers_verdict_good": "All your mail servers support secure ciphers only.", + "detail_mail_tls_ciphers_verdict_phase_out": "At least one of your mail servers supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", + "detail_mail_tls_compression_exp": "

We check if your receiving mail servers (MX) support TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression
  • Insufficient: TLS compression
", + "detail_mail_tls_compression_label": "TLS compression", + "detail_mail_tls_compression_tech_table": "Mail server (MX)|TLS compression", + "detail_mail_tls_compression_verdict_bad": "At least on of your mail servers supports TLS compression, which is not secure.", + "detail_mail_tls_compression_verdict_good": "All your mail servers do not support TLS compression.", + "detail_mail_tls_dane_exists_exp": "We check if the name servers of each of your receiving mail servers (MX) provide a TLSA record for DANE.

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

Note that the test ignores TLSA records of the types PKIX-TA(0) or PKIX-EE(1) as these should not be used for receiving mail servers.

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

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, Appendix A, under \\'Certificate pinning and DANE\\' (in English).", + "detail_mail_tls_dane_exists_label": "DANE existence", + "detail_mail_tls_dane_exists_tech_table": "Mail server (MX)|DANE TLSA record existent", + "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.

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.", + "detail_mail_tls_dane_rollover_verdict_good": "All your mail server domains have an active DANE scheme for a reliable rollover of certificate keys.", + "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 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.", + "detail_mail_tls_fs_params_verdict_good": "All your mail servers support secure parameters for Diffie-Hellman key exchange.", + "detail_mail_tls_fs_params_verdict_na": "This subtest is not applicable as your mail servers do not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.", + "detail_mail_tls_fs_params_verdict_phase_out": "At least one of your mail servers supports parameters for Diffie-Hellman key exchange that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", + "detail_mail_tls_kex_hash_func_exp": "

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

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", + "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_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", + "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mail server (MX)|OCSP stapling", + "detail_mail_tls_ocsp_stapling_verdict_bad": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers supports OCSP stapling but responds with invalid data", + "detail_mail_tls_ocsp_stapling_verdict_good": "OUTDATED TEXT; TEST NOT USED
Your mail servers support OCSP stapling.", + "detail_mail_tls_ocsp_stapling_verdict_ok": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers does not support OCSP stapling.", + "detail_mail_tls_renegotiation_client_exp": "

We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX).

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", + "detail_mail_tls_renegotiation_client_label": "Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_tech_table": "Mail server (MX)|Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_verdict_bad": "At least one of your mail servers allows for client-initiated renegotiation, which could have negative impact on the availability of your mail server.", + "detail_mail_tls_renegotiation_client_verdict_good": "All your mail servers do not allow for client-initiated renegotiation.", + "detail_mail_tls_renegotiation_secure_exp": "

We check if your mail servers (MX) support secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", + "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_mail_tls_renegotiation_secure_tech_table": "Mail server (MX)|Secure renegotiation", + "detail_mail_tls_renegotiation_secure_verdict_bad": "At least one of your mail servers supports insecure renegotiation, which is obviously not secure.", + "detail_mail_tls_renegotiation_secure_verdict_good": "All your mail servers support secure renegotiation.", + "detail_mail_tls_starttls_exists_exp": "We check if your receiving mail servers (MX) support STARTTLS. If so, we also check in the subtests of this test category whether STARTTLS is configured sufficiently secure.

Because of performance reasons at most ten mail servers over either IPv6 or IPv4 are tested for STARTTLS and DANE.

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

Non-receiving domain:

  1. Null MX: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use \"Null MX\" (RFC 7505). Note that a \"Null MX record\" should not be combined with a normal MX record that is pointing to a mail host.

  2. No MX: In case your domain does not have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even not an \"Null MX\" record).

  3. If we detect any of the above two cases, the subtests in the STARTTLS and DANE category are not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. Other subtests of the email test (e.g. for DMARC) are still applicable.

  4. Note that having a \"Null MX\" record or no MX record could also impact sending mail, because receiving servers may reject email that has an invalid return address.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", + "detail_mail_tls_starttls_exists_label": "STARTTLS available", + "detail_mail_tls_starttls_exists_tech_table": "Mail server (MX)|STARTTLS", + "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 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": "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", + "detail_mail_tls_version_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure TLS versions.", + "detail_mail_tls_version_verdict_good": "All your mail servers support secure TLS versions only.", + "detail_mail_tls_version_verdict_phase_out": "At least one of your mail servers supports one or more TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", + "detail_mail_tls_zero_rtt_exp": "

We check if your mail servers (MX) support Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your mail servers do not support TLS 1.3, the test is not applicable.For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLSsession is initiated. The amount ofearly datasupport indicated by themail server is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theEHLO command before the TLS handshake but after the STARTTLS command(i.e. no round trips (0-RTT) needed before application data to the server).If the TLS handshake is completed and the mail server responds,then the mail server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", + "detail_mail_tls_zero_rtt_label": "0-RTT", + "detail_mail_tls_zero_rtt_tech_table": "Mail server (MX)|0-RTT", + "detail_mail_tls_zero_rtt_verdict_bad": "At least one of your mail servers supports 0-RTT, which is not secure.", + "detail_mail_tls_zero_rtt_verdict_good": "None of your mail servers support 0-RTT.", + "detail_mail_tls_zero_rtt_verdict_na": "This subtest is not applicable as your mail servers do not support TLS 1.3.", + "detail_tech_data_bogus": "bogus", + "detail_tech_data_good": "good", + "detail_tech_data_http_csp_has_bare_https": "Recommendation: \\'https:\\' scheme without a specific main domain should not be used (#9).", + "detail_tech_data_http_csp_has_data": "Recommendation: \\'data:\\' scheme should not be used where that is not permitted (#7).", + "detail_tech_data_http_csp_has_host_without_scheme": "Recommendation: A domain without a scheme should not be used (#8).", + "detail_tech_data_http_csp_has_http": "Recommendation: \\'http:\\' scheme should not be used (#8).", + "detail_tech_data_http_csp_has_invalid_host": "Recommendation: A wildcard (i.e. \\'*\\') or \\'127.0.0.1\\' should not be used (#9 and #10).", + "detail_tech_data_http_csp_has_unsafe_eval": "Recommendation: \\'unsafe-eval\\' should not be used (#6).", + "detail_tech_data_http_csp_has_unsafe_hashes": "Recommendation: \\'unsafe-hashes\\' should not be used (#6).", + "detail_tech_data_http_csp_has_unsafe_inline": "Recommendation: \\'unsafe-inline\\' should not be used (#6).", + "detail_tech_data_http_csp_missing_invalid_base_uri": "Recommendation: \\'base-uri\\' with sufficiently secure value should be defined (#2).", + "detail_tech_data_http_csp_missing_invalid_default_src": "Recommendation: \\'default-src\\' with sufficiently secure value should be defined (#1).", + "detail_tech_data_http_csp_missing_invalid_form_action": "Recommendation: \\'form-action\\' with sufficiently secure value should be defined (#5).", + "detail_tech_data_http_csp_missing_invalid_frame_ancestors": "Recommendation: \\'frame-ancestors\\' with sufficiently secure value should be defined (#4).", + "detail_tech_data_http_csp_missing_invalid_frame_src": "Recommendation: \\'frame-src\\' (or child-src\\' or \\'default-src\\' as fallback) with sufficiently secure value should be defined (#3).", + "detail_tech_data_http_csp_no_policy_found": "No CSP found.", + "detail_tech_data_http_csp_policy_found": "Retrieved CSP value: {policy}", + "detail_tech_data_http_referrer_policy_bad_invalid": "Bad: policy value is not valid.", + "detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade": "Bad: \\'no-referrer-when-downgrade\\' must not be used.", + "detail_tech_data_http_referrer_policy_bad_origin": "Bad: \\'origin\\' must not be used.", + "detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin": "Bad: \\'origin-when-cross-origin\\' must not be used.", + "detail_tech_data_http_referrer_policy_bad_unsafe_url": "Bad: \\'unsafe-url\\' must not be used.", + "detail_tech_data_http_referrer_policy_no_policy": "No Referrer-Policy found.", + "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_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.", + "detail_tech_data_http_securitytxt_multi_lang": "Error: \\'Preferred-Languages\\' field must not appear more than once.", + "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Recommendation: Multiple \\'CSAF\\' fields should be brought back to one \\'CSAF\\' field.", + "detail_tech_data_http_securitytxt_no_canonical": "Recommendation: \\'Canonical\\' field should be present in a signed file.", + "detail_tech_data_http_securitytxt_no_canonical_match": "Error: The web URI of security.txt (i.e. when redirecting at least the last URI of the redirect chain) must be listed in a \\'Canonical\\' field if present.", + "detail_tech_data_http_securitytxt_no_contact": "Error: \\'Contact\\' field must appear at least once.", + "detail_tech_data_http_securitytxt_no_content_type": "Error: HTTP Content-Type header must be sent.", + "detail_tech_data_http_securitytxt_no_csaf_file": "Error: Every optional \\'CSAF\\' field must point to a file named \\'provider-metadata.json\\'.", + "detail_tech_data_http_securitytxt_no_encryption": "Recommendation: \\'Encryption\\' field should be present when \\'Contact\\' field contains an email address.", + "detail_tech_data_http_securitytxt_no_expire": "Error: \\'Expires\\' field must be present.", + "detail_tech_data_http_securitytxt_no_https": "Error: Web URI must begin with \\'https://\\' (line {line_no}).", + "detail_tech_data_http_securitytxt_no_line_separators": "Error: Every line must end with either a carriage return and line feed characters or just a line feed character.", + "detail_tech_data_http_securitytxt_no_security_txt_404": "Error: security.txt could not be located.", + "detail_tech_data_http_securitytxt_no_security_txt_other": "Error: security.txt could not be located (unexpected HTTP response code {status_code}).", + "detail_tech_data_http_securitytxt_no_space": "Error: Field separator (colon) must be followed by a space (line {line_no}).", + "detail_tech_data_http_securitytxt_no_uri": "Error: Field value must be a URI (e.g. beginning with \\'mailto:\\') (line {line_no}).", + "detail_tech_data_http_securitytxt_not_signed": "Recommendation: security.txt should be digitally signed.", + "detail_tech_data_http_securitytxt_pgp_data_error": "Error: Signed security.txt must contain a correct ASCII-armored PGP block.", + "detail_tech_data_http_securitytxt_pgp_error": "Error: Decoding or parsing of the signed security.txt must succeed.", + "detail_tech_data_http_securitytxt_prec_ws": "Error: There must be no whitespace before the field separator (colon) (line {line_no}).", + "detail_tech_data_http_securitytxt_requested_from": "security.txt requested from {hostname}.", + "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 encoded using UTF-8 in Net-Unicode form.", + "detail_tech_data_insecure": "insecure", + "detail_tech_data_insufficient": "insufficient", + "detail_tech_data_no": "no", + "detail_tech_data_not_applicable": "not applicable", + "detail_tech_data_not_reachable": "not reachable", + "detail_tech_data_not_testable": "not testable", + "detail_tech_data_not_tested": "not tested", + "detail_tech_data_phase_out": "phase out", + "detail_tech_data_secure": "secure", + "detail_tech_data_sufficient": "sufficient", + "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). 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 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 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.

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

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.", + "detail_web_appsecpriv_http_x_frame_verdict_good": "Your web server offers securely configured X-Frame-Options.", + "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We check if your web server provides an HTTP header for X-XSS-Protection that has a sufficiently secure value (i.e. 1 or 1; mode=block). This HTTP header can be used to activate the protection filter of browsers against reflective cross-site scripting (XSS) attacks. Valid values for the X-XSS-Protection header are:

  • 0 disables the XSS filter. This value should NOT be used.
  • 1 enables the XSS filter. If a cross-site scripting attack is detected, the browser will sanitize the script and remove the unsafe parts. This value is usually the default in browsers when a website does not offer an X-XSS-Protection header.
  • 1; mode=block enables the XSS filter. If a cross-site scripting attack is detected, the browser will block the response and prevent rendering the page. This is the recommended value.

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

Requirement level: Recommended", + "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", + "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|X-XSS-Protection value", + "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your web server does not offer securely configured X-XSS-Protection.", + "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your web server offers securely configured X-XSS-Protection.", + "detail_web_dnssec_exists_exp": "We check if your domain, more specifically its SOA record, is DNSSEC signed.

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_web_dnssec_exists_label": "DNSSEC existence", + "detail_web_dnssec_exists_tech_table": "Domain|Registrar", + "detail_web_dnssec_exists_verdict_bad": "Your domain is insecure, because it is not DNSSEC signed.", + "detail_web_dnssec_exists_verdict_good": "Your domain is DNSSEC signed.", + "detail_web_dnssec_exists_verdict_resolver_error": "Unfortunately an error occurred in Internet.nl\\'s resolver. Please contact us.", + "detail_web_dnssec_exists_verdict_servfail": "The name servers of your 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_web_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", + "detail_web_dnssec_valid_label": "DNSSEC validity", + "detail_web_dnssec_valid_tech_table": "Domain|Status", + "detail_web_dnssec_valid_verdict_bad": "Your domain is \\'bogus\\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", + "detail_web_dnssec_valid_verdict_good": "Your domain is secure, because its DNSSEC signature is valid.", + "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Your domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", + "detail_web_ipv6_web_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for your web server.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.", + "detail_web_ipv6_web_aaaa_label": "IPv6 addresses for web server", + "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 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 \u2013 299) and redirection messages (300 \u2013 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 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.", + "detail_web_rpki_exists_label": "Route Origin Authorisation existence", + "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.

1\u2024 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\u2024 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\u2024 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 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", + "detail_web_tls_cert_hostmatch_tech_table": "Web server IP address|Unmatched domains on certificate", + "detail_web_tls_cert_hostmatch_verdict_bad": "The domain name of your website does not match the domain name on your website certificate.", + "detail_web_tls_cert_hostmatch_verdict_good": "The domain name of your website matches the domain name on your website certificate.", + "detail_web_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 \u2013 3071 bit
  • Insufficient: Less than 2048 bit
", + "detail_web_tls_cert_pubkey_label": "Public key of certificate", + "detail_web_tls_cert_pubkey_tech_table": "Web server IP address|Affected signature parameters|Status", + "detail_web_tls_cert_pubkey_verdict_bad": "The digital signature of your website certificate uses insufficiently secure parameters.", + "detail_web_tls_cert_pubkey_verdict_good": "The digital signature of your website certificate uses secure parameters.", + "detail_web_tls_cert_pubkey_verdict_phase_out": "The digital signature of your website certificate uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", + "detail_web_tls_cert_signature_exp": "

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", + "detail_web_tls_cert_signature_label": "Signature of certificate", + "detail_web_tls_cert_signature_tech_table": "Web server IP address|Affected hash algorithm|Status", + "detail_web_tls_cert_signature_verdict_bad": "Your website certificate is signed using a hash algorithm that is insufficiently secure.", + "detail_web_tls_cert_signature_verdict_good": "Your website certificate is signed using a secure hash algorithm.", + "detail_web_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your website certificate.

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

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B3-4 (in English).", + "detail_web_tls_cert_trust_label": "Trust chain of certificate", + "detail_web_tls_cert_trust_tech_table": "Web server IP address|Untrusted certificate chain", + "detail_web_tls_cert_trust_verdict_bad": "The trust chain of your website certificate is not complete and/or not signed by a trusted root certificate authority.", + "detail_web_tls_cert_trust_verdict_good": "The trust chain of your website certificate is complete and signed by a trusted root certificate authority.", + "detail_web_tls_cipher_order_exp": "We check if your web server enforces its own cipher preference (\\'I\\'), and offers ciphers in accordance with the prescribed ordering (\\'II\\').

When your web server supports \\'Good\\' ciphers only, this subtest is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The web server enforces its own cipher preference while negotiating with a web browser, and does not accept any preference of the web browser;

II. Prescribed ordering: Ciphers are offered by the web server 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_web_tls_cipher_order_label": "Cipher order", + "detail_web_tls_cipher_order_tech_table": "Web server IP address|First found affected cipher pair|Violated rule # (\\'II-B\\')", + "detail_web_tls_cipher_order_verdict_bad": "Your web server does not enforce its own cipher preference (\\'I\\').", + "detail_web_tls_cipher_order_verdict_good": "Your web server enforces its own cipher preference (\\'I\\'), and offers ciphers in accordance with the prescribed ordering (\\'II\\').", + "detail_web_tls_cipher_order_verdict_na": "This subtest is not applicable as your web server supports \\'Good\\' ciphers only.", + "detail_web_tls_cipher_order_verdict_seclevel_bad": "Your web server does not prefer \\'Good\\' over \\'Sufficient\\' over \\'Phase out\\' ciphers (\\'II\\').", + "detail_web_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Your web server does not offer ciphers in accordance with the prescribed ordering within a particular security level (\\'II-B\\').", + "detail_web_tls_ciphers_exp": "

We check if your web server only supports secure, i.e. \\'Good\\' and/or \\'Sufficient\\', ciphers (also known as algorithm selections).

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \\'cipher suite\\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \\'cipher suite\\' ambiguous, NCSC-NL uses the term \\'algorithm selection\\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \\'Good\\', \\'Sufficient\\' and \\'Phase out\\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \\'IT Security Guidelines for Transport Layer Security (TLS)\\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \\'Phase out\\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_web_tls_ciphers_label": "Ciphers (Algorithm selections)", + "detail_web_tls_ciphers_tech_table": "Web server IP address|Affected ciphers|Status", + "detail_web_tls_ciphers_verdict_bad": "Your web server supports one or more insufficiently secure ciphers.", + "detail_web_tls_ciphers_verdict_good": "Your web server supports secure ciphers only.", + "detail_web_tls_ciphers_verdict_phase_out": "Your web server supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", + "detail_web_tls_compression_exp": "

We check if your web server supports TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
", + "detail_web_tls_compression_label": "TLS compression", + "detail_web_tls_compression_tech_table": "Web server IP address|TLS compression", + "detail_web_tls_compression_verdict_bad": "Your web server supports TLS compression, which is not secure.", + "detail_web_tls_compression_verdict_good": "Your web server does not support TLS compression.", + "detail_web_tls_dane_exists_exp": "We check if the name servers of your website domain contain a correctly signed TLSA record for DANE.

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the website domain, or if there are DANE related DNSSEC issues (e.g. no proof of \\'Denial of Existence\\').

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

Requirement level: Optional", + "detail_web_tls_dane_exists_label": "DANE existence", + "detail_web_tls_dane_exists_tech_table": "Web server IP address|DANE TLSA record existent", + "detail_web_tls_dane_exists_verdict_bad": "Your website domain does not contain a TLSA record for DANE.", + "detail_web_tls_dane_exists_verdict_bogus": "Your website domain does not provide DNSSEC proof that DANE TLSA records do not exist. You should ask your name server operator to fix this issue.", + "detail_web_tls_dane_exists_verdict_good": "Your website domain contains a TLSA record for DANE.", + "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", + "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", + "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", + "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", + "detail_web_tls_dane_valid_exp": "We check if the DANE fingerprint presented by your domain is valid for your web certificate.

DANE allows you to publish information about your website certificate in a special DNS record, called TLSA record. Clients, like web browsers, can check the authenticity of your certificate not only through the certificate authority but also through the TLSA record. A client can also use the TLSA record as a signal to only use HTTPS (and not HTTP). DNSSEC is preconditional for DANE. Unfortunately not much web browsers are supporting DANE validation yet.

Requirement level: Recommended (only if subtest for \\'DANE existence\\' is passed)", + "detail_web_tls_dane_valid_label": "DANE validity", + "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_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 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 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 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.", + "detail_web_tls_https_exists_verdict_good": "Your website offers HTTPS.", + "detail_web_tls_https_exists_verdict_other": "Your web server is unreachable.", + "detail_web_tls_https_forced_exp": "We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

  • http://example.nl \u21d2 https://example.nl \u21d2 https://www.example.nl
  • http://www.example.nl \u21d2 https://www.example.nl

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See \\'Web application guidelines, detailed version\\' from NCSC-NL, guideline U/WA.05 (in Dutch).", + "detail_web_tls_https_forced_label": "HTTPS redirect", + "detail_web_tls_https_forced_tech_table": "Web server IP address|HTTPS redirect", + "detail_web_tls_https_forced_verdict_bad": "Your web server does offer support for both HTTP and HTTPS, but does not automatically redirect visitors from HTTP to HTTPS on the same domain.", + "detail_web_tls_https_forced_verdict_good": "Your web server automatically redirects visitors from HTTP to HTTPS on the same domain.", + "detail_web_tls_https_forced_verdict_no_https": "This test could not be performed, because your web server offers either no HTTPS or HTTPS with a very outdated, insecure TLS configuration.", + "detail_web_tls_https_forced_verdict_other": "Your web server only offers support for HTTPS and not for HTTP.", + "detail_web_tls_https_hsts_exp": "We check if your web server supports HSTS.

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period of at least 1 year (max-age=31536000) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired.

The test does not check whether preload is used and whether the domain is included in the HSTS Preload List.

Deployment recommendation

HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will not be reachable by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy.

Therefore we advise you to follow the implementation steps below:

  1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);

  2. Increase the HSTS cache validity period in the stages below. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.

  3. Start with 5 minutes (max-age=300);

  4. Increase it to 1 week (max-age=604800);
  5. Increase it to 1 month (max-age=2592000);

  6. Increase it to 1 year (max-age=31536000) or more.

  7. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use includeSubDomains if you are fully sure that all the (nested) subdomains of your domain properly support HTTPS now and in the future.

  8. Use preload only if you are very sure that you want your domain to be included in the HSTS Preload List. HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.

See \\'Web application guidelines, detailed version\\' from NCSC-NL, guideline U/WA.05 (in Dutch).", + "detail_web_tls_https_hsts_label": "HSTS", + "detail_web_tls_https_hsts_tech_table": "Web server IP address|HSTS policy", + "detail_web_tls_https_hsts_verdict_bad": "Your web server does not offer an HSTS policy.", + "detail_web_tls_https_hsts_verdict_good": "Your web server offers an HSTS policy.", + "detail_web_tls_https_hsts_verdict_other": "Your web server offers an HSTS policy with a cache validity period (max-age) that is not sufficiently long (i.e. less than 1 year).", + "detail_web_tls_kex_hash_func_exp": "

We check if your web server supports secure hash functions to create the digital signature during key exchange.

The web server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The web server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", + "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 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", + "detail_web_tls_ocsp_stapling_tech_table": "Web server IP address|OCSP stapling", + "detail_web_tls_ocsp_stapling_verdict_bad": "Your web server supports OCSP stapling but the data in the response is not valid.", + "detail_web_tls_ocsp_stapling_verdict_good": "Your web server supports OCSP stapling and the data in the response is valid.", + "detail_web_tls_ocsp_stapling_verdict_ok": "Your web server does not support OCSP stapling.", + "detail_web_tls_renegotiation_client_exp": "

We check if a client (usually a web browser) can initiate a renegotiation with your web server.

Allowing clients to initiate renegotiation is generally not necessary and opens a web server to DoS attacks inside a TLS connection. An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", + "detail_web_tls_renegotiation_client_label": "Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_tech_table": "Web server IP address|Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_verdict_bad": "Your web server allows for client-initiated renegotiation, which could have negative impact on the availability of your website.", + "detail_web_tls_renegotiation_client_verdict_good": "Your web server does not allow for client-initiated renegotiation.", + "detail_web_tls_renegotiation_secure_exp": "

We check if your web server supports secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", + "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table": "Web server IP address|Secure renegotiation", + "detail_web_tls_renegotiation_secure_verdict_bad": "Your web server supports insecure renegotiation, which is obviously not secure.", + "detail_web_tls_renegotiation_secure_verdict_good": "Your web server supports secure renegotiation.", + "detail_web_tls_version_exp": "

We check if your web server supports secure TLS versions only.

A web server may support more than one TLS version.

Note that browser makers have announced that they will stop supporting TLS 1.1 and 1.0. This will cause websites that do not support TLS 1.2 and/or 1.3 to be unreachable.

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_web_tls_version_label": "TLS version", + "detail_web_tls_version_tech_table": "Web server IP address|TLS version|Status", + "detail_web_tls_version_verdict_bad": "Your web server supports insufficiently secure TLS versions.", + "detail_web_tls_version_verdict_good": "Your web server supports secure TLS versions only.", + "detail_web_tls_version_verdict_phase_out": "Your web server supports TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", + "detail_web_tls_zero_rtt_exp": "

We check if your web server supports Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the firsthandshake message. 0-RTT does not provide protection against replay attacks atthe TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable.For web servers that support TLS 1.3, the index / page of the website isfetched using TLS 1.3 and the amount ofearly datasupport indicated by theserver is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theHTTP request before the TLS handshake (i.e. no round trips (0-RTT) neededbefore application data to the server). If the TLS handshake is completed andthe web server responds with anynon-HTTP 425 Too Earlyresponse, then the web server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", + "detail_web_tls_zero_rtt_label": "0-RTT", + "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 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", + "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "None of the name servers of your domain has an IPv6 address.", + "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Two or more name servers of your domain have an IPv6 address.", + "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Only one name server of your domain has an IPv6 address.", + "detail_web_mail_ipv6_ns_reach_exp": "We check if all name servers, that have an AAAA record with IPv6 address, are reachable over IPv6.", + "detail_web_mail_ipv6_ns_reach_label": "IPv6 reachability of name servers", + "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.", + "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.

1\u2024 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\u2024 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\u2024 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 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 \u21d2 null score", + "faqs_report_subtest_error": "Test error: error encountered during testing \u21d2 null score", + "faqs_report_subtest_good": "Good: pass on REQUIRED, RECOMMENDED or OPTIONAL subtest \u21d2 first: full score / latter two: no score impact", + "faqs_report_subtest_info": "Informational: fail on OPTIONAL subtest \u21d2 no score impact", + "faqs_report_subtest_not_tested": "Not tested, because already failed related parent subtest \u21d2 null score", + "faqs_report_subtest_title": "Icons per subtest", + "faqs_report_subtest_warning": "Warning: fail on RECOMMENDED subtest \u21d2 no score impact", + "faqs_report_test_bad": "Bad: failed at least one REQUIRED subtest \u21d2 no full score in test category", + "faqs_report_test_error": "Test error: execution error for at least one subtest \u21d2 no result in test category", + "faqs_report_test_good": "Good: passed all subtests \u21d2 full score in test category", + "faqs_report_test_info": "Informational: failed at least one OPTIONAL subtest \u21d2 full score in test category ", + "faqs_report_test_title": "Icons per test category", + "faqs_report_test_warning": "Warning: failed at least one RECOMMENDED subtest \u21d2 full score in test category ", + "faqs_report_title": "Explanation of test report", + "faqs_rpki_title": "Authorisation for routing (RPKI)", + "faqs_starttls_title": "Secure email transport (STARTTLS and DANE)", + "faqs_title": "Knowledge base", + "halloffame_champions_menu": "Champions!", + "halloffame_champions_subtitle": "100% in website and email test", + "halloffame_champions_text": "The {{count}} domains below score 100% in both the website test and the email test. Inductees of this Hall of Fame are allowed to use both 100% badges.", + "halloffame_champions_title": "Hall of Fame - Champions!", + "halloffame_mail_badge": "Badge with text: 100% score in email test", + "halloffame_mail_menu": "Email", + "halloffame_mail_subtitle": "100% in email test", + "halloffame_mail_text": "The {{count}} domains below score 100% in the email test. Inductees of this Hall of Fame are allowed to use the 100% mail badge.", + "halloffame_mail_title": "Hall of Fame - Email", + "halloffame_web_badge": "Badge with text: 100% score in website test", + "halloffame_web_menu": "Websites", + "halloffame_web_subtitle": "100% in website test", + "halloffame_web_text": "The {{count}} domains below score 100% in the website test. Inductees of this Hall of Fame are allowed to use the 100% website badge.", + "halloffame_web_title": "Hall of Fame - Websites", + "home_pagetitle": "Test for modern Internet Standards like IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE.", + "home_stats_connection": "unique connections", + "home_stats_connection_items": "", + "home_stats_header": "Tests in numbers", + "home_stats_mail": "unique mail domains", + "home_stats_mail_items": "", + "home_stats_notpassed": "0-99%:", + "home_stats_passed": "100%:", + "home_stats_website": "unique web domains", + "home_stats_website_items": "", + "home_teaser": "Modern Internet Standards provide for more reliability and further growth of the Internet.
Are you using them?", + "mail_pagetitle": "Email test:", + "mail_title": "Email test: {{prettyaddr}}", + "mail_tweetmessage": "The%20mail%20server%20at%20{{report.domain}}%20scores%20{{score}}%25%20in%20the%20email%20test%20of%20%40Internet_nl%3A", + "page_gotocontents": "Go to the content", + "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 certificate, Internet Standards Platform", + "page_sitedescription": "Is your Internet up-to-date?", + "page_sitetitle": "Internet.nl", + "page404_title": "Page not found!", + "probes_auto_redirect": "You will be automatically redirected to the results page when all tests are finished.", + "probes_no_javascript": "Check if the test results are available. If not, you will be redirected here instead.", + "probes_no_javascript_connection": "JavaScript inactive. Please enable JavaScript in order to execute the test.", + "probes_no_redirection": "Test error. Please try again later, or test another domain name.", + "probes_test_finished": "Test finished! Results available...", + "probes_test_running": "Running...", + "probes_tests_description": "The items below are being tested.", + "probes_tests_duration": "The duration of the test is between 5 and {{cache_ttl}} seconds.", + "results_dated_presentation": "Dated result presentation. Please rerun the test.", + "results_domain_appsecpriv_http_headers_label": "HTTP security headers", + "results_domain_appsecpriv_other_options_label": "Other security options", + "results_domain_ipv6_web_server_label": "Web server", + "results_domain_rpki_web_server_label": "Web server", + "results_domain_tls_http_headers_label": "HTTP headers", + "results_domain_tls_https_label": "HTTP", + "results_domain_tls_tls_label": "TLS", + "results_domain_mail_ipv6_name_servers_label": "Name servers of domain", + "results_domain_mail_rpki_name_servers_label": "Name servers of domain", + "results_domain_mail_tls_certificate_label": "Certificate", + "results_domain_mail_tls_dane_label": "DANE", + "results_empty_argument_alt_text": "None", + "results_explanation_label": "Test explanation:", + "results_further_testing_connection_label": "Further connection testing", + "results_further_testing_mail_label": "Further email testing", + "results_further_testing_web_label": "Further website testing", + "results_mail_auth_dkim_label": "DKIM", + "results_mail_auth_dmarc_label": "DMARC", + "results_mail_auth_spf_label": "SPF", + "results_mail_dnssec_domain_label": "Email address domain", + "results_mail_dnssec_mail_servers_label": "Mail server domain(s)", + "results_mail_ipv6_mail_servers_label": "Mail server(s)", + "results_mail_rpki_mail_servers_label": "Mail server(s)", + "results_mail_rpki_mx_name_servers_label": "Name servers of mail server(s)", + "results_mail_tls_starttls_label": "TLS", + "results_no_icon_detail_close": "close", + "results_no_icon_detail_open": "open", + "results_no_icon_status_error": "Error", + "results_no_icon_status_failed": "Failed", + "results_no_icon_status_info": "Information", + "results_no_icon_status_not_tested": "Not testable", + "results_no_icon_status_passed": "Passed", + "results_no_icon_status_warning": "Recommendation", + "results_panel_button_hide": "Hide details", + "results_panel_button_show": "Show details", + "results_perfect_score": "Congratulations, your domain will be added to the Hall of Fame soon!", + "results_permalink": "Permalink test result {{permadate|date:\\'(Y-m-d H:i T)\\'}}", + "results_rerun_test": "Rerun the test", + "results_retest_time": "Seconds until retest option:", + "results_score_description": "The domain {{prettyaddr}} has a test score of {{score}}%.", + "results_tech_details_label": "Technical details:", + "results_test_direct": "Directly test:", + "results_test_email_label": "Test another email", + "results_test_website_label": "Test another website", + "results_test_info": "Explanation of test report", + "results_verdict_label": "Verdict:", + "test_connipv6_failed_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", + "test_connipv6_failed_summary": "Modern addresses not reachable (IPv6)", + "test_connipv6_info_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", + "test_connipv6_info_summary": "Modern addresses not reachable (IPv6)", + "test_connipv6_label": "Modern addresses reachable (IPv6)", + "test_connipv6_passed_description": "Well done! Your internet provider has provided you with a modern internet address (IPv6). Therefore you can reach other computers with modern addresses.", + "test_connipv6_passed_summary": "Modern addresses reachable (IPv6)", + "test_connipv6_title": "Modern addresses reachable?", + "test_connipv6_warning_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", + "test_connipv6_warning_summary": "Modern addresses not reachable (IPv6)", + "test_connresolver_failed_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", + "test_connresolver_failed_summary": "Domain signatures not validated (DNSSEC)", + "test_connresolver_info_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", + "test_connresolver_info_summary": "Domain signatures not validated (DNSSEC)", + "test_connresolver_label": "Domain signature validation (DNSSEC)", + "test_connresolver_passed_description": "Well done! Domain signatures (DNSSEC) are validated for you. Therefore you are protected against false translation from signed domain names into rogue IP addresses.", + "test_connresolver_passed_summary": "Domain signatures validated (DNSSEC)", + "test_connresolver_title": "Domain signatures validated?", + "test_connresolver_warning_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", + "test_connresolver_warning_summary": "Domain signatures not validated (DNSSEC)", + "test_error_summary": "Error during test execution!", + "test_mailauth_failed_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", + "test_mailauth_failed_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_mailauth_info_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", + "test_mailauth_info_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_mailauth_label": "Authenticity marks against phishing (DMARC, DKIM and SPF)", + "test_mailauth_passed_description": "Well done! Your domain contains all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are able to reliably separate phishing and spam emails abusing your domain in their sender address, from your authentic emails. ", + "test_mailauth_passed_summary": "Authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_mailauth_title": "Authenticity marks against email phishing?", + "test_mailauth_warning_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", + "test_mailauth_warning_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_maildnssec_failed_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", + "test_maildnssec_failed_summary": "Not all domain names signed (DNSSEC)", + "test_maildnssec_info_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", + "test_maildnssec_info_summary": "Not all domain names signed (DNSSEC)", + "test_maildnssec_label": "Signed domain names (DNSSEC)", + "test_maildnssec_passed_description": "Well done! Your email address domain and your mail server domain(s) are signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are able to reliably query the IP address of your receiving mail server(s). ", + "test_maildnssec_passed_summary": "All domain names signed (DNSSEC)", + "test_maildnssec_title": "Domain names signed?", + "test_maildnssec_warning_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", + "test_maildnssec_warning_summary": "Not all domain names signed (DNSSEC)", + "test_mailipv6_failed_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_failed_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_mailipv6_info_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_info_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_mailipv6_label": "Modern address (IPv6)", + "test_mailipv6_passed_description": "Well done! Your mail server can be reached by senders using modern
addresses (IPv6), making it fully part of the modern Internet.", + "test_mailipv6_passed_summary": "Reachable via modern internet address (IPv6)", + "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_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)", + "test_mailrpki_label": "Route authorisation (RPKI)", + "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": "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)", + "test_mailtls_info_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_info_summary": "Mail server connection not or insufficiently secured (STARTTLS and DANE)", + "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: 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 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)", + "test_mailtls_null_mx_with_other_mx_description": "Warning: 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. ", + "test_mailtls_null_mx_with_other_mx_summary": "Inconsistently configured non-receiving mail domain (STARTTLS and DANE)", + "test_mailtls_null_mx_without_a_aaaa_description": "Warning: 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.", + "test_mailtls_null_mx_without_a_aaaa_summary": "Properly configured non-receiving mail domain, though with unnecessary record (STARTTLS and DANE)", + "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 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 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. 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. 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. 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. 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)", + "test_sitednssec_info_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_info_summary": "Domain name not signed (DNSSEC)", + "test_sitednssec_label": "Signed domain name (DNSSEC)", + "test_sitednssec_passed_description": "Well done! Your domain is signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are protected against manipulated translation from your domain into rogue internet addresses.", + "test_sitednssec_passed_summary": "Domain name signed (DNSSEC)", + "test_sitednssec_title": "Domain name signed?", + "test_sitednssec_warning_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_warning_summary": "Domain name not signed (DNSSEC)", + "test_siteipv6_failed_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_failed_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_siteipv6_info_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_info_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_siteipv6_label": "Modern address (IPv6)", + "test_siteipv6_passed_description": "Well done! Your website is reachable for visitors using a modern internet address (IPv6), making it fully part of the modern Internet.", + "test_siteipv6_passed_summary": "Reachable via modern internet address (IPv6)", + "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_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)", + "test_siterpki_label": "Route authorisation (RPKI)", + "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": "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)", + "test_sitetls_info_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_info_summary": "Connection not or insufficiently secured (HTTPS)", + "test_sitetls_label": "Secure connection (HTTPS)", + "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 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 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", + "widget_site_intro": "

Website test widget

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

" +} \ No newline at end of file diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json new file mode 100644 index 00000000..b0d79ad3 --- /dev/null +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json @@ -0,0 +1,848 @@ +{ + "about_contact": "

Contact

Platform Internetstandaarden
p/a ECP
Maanweg 174 (8e verdieping)
2516 AB Den Haag

KvK-nummer: 27169301

E-mail

vraag@internet.nl

PGP publieke sleutel
Vingerafdruk: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Vervaldatum: 19 maart 2025

", + "base_about": "Over Internet.nl", + "base_accessibility": "Toegankelijkheid", + "base_blogs": "Blogs", + "base_contact": "Contact", + "base_copyright": "Auteursrecht", + "base_disclosure": "Kwetsbaarheid melden", + "base_faqs": "Kennisbank", + "base_halloffame": "Hall of Fame", + "base_halloffame_champions": "Hall of Fame - Kampioenen!", + "base_halloffame_lead": "{{count}} domeinen met 2 x 100%
Laatste toevoeging: {{latest|date:\\'d-m-Y\\'}}", + "base_halloffame_link": "Naar Hall of Fame - Kampioenen!", + "base_halloffame_mail": "Hall of Fame - E-mail", + "base_halloffame_web": "Hall of Fame - Websites", + "base_home": "Home", + "base_info": "Internet.nl is een initiatief van de internetgemeenschap en de Nederlandse overheid.", + "base_news": "Nieuws", + "base_newslink": "Naar nieuwsoverzicht", + "base_privacy": "Privacyverklaring", + "base_test_connection_explain": "

Wat wordt getest?

Nadat je de verbindingstest hebt gestart, testen we of de momenteel door jou gebruikte internetverbinding ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

  • IPv6: zijn websites met moderne internetadressen voor jou bereikbaar?
  • DNSSEC: worden domeinnaam-handtekeningen voor jou gecontroleerd?

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\".

Hoe verbeteren?

Het testrapport kan je gebruiken om je internetverbinding te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je internetprovider. In de communicatie met je internetprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Test je verbinding

", + "base_test_connection_label": "Test je verbinding", + "base_test_connection_text": "Moderne adressen bereikbaar?
Domein-handtekeningen gecontroleerd?", + "base_test_connection_title": "Over de verbindingstest", + "base_test_explain": "Over de test", + "base_test_mail_explain": "

Wat wordt getest?

Nadat je een e-mailadres hebt opgegeven, testen we of de achterliggende e-mailvoorziening ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Let op: sommige standaarden zijn zelfs relevant als je je domeinnaam niet gebruikt voor het ontvangen en verzenden van e-mail.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\".

Hoe verbeteren?

Het testrapport kan je gebruiken om je e-mailvoorziening te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je e-mailprovider. In de communicatie met je e-mailprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de e-mailtest integreren in je eigen website door gebruik te maken van onze widget code.

Test je e-mail

", + "base_test_mail_input": "Jouw e-mailadres:", + "base_test_mail_label": "Test je e-mail", + "base_test_mail_text": "Modern adres? Anti-phishing? Beveiligd transport? Route-autorisatie?", + "base_test_mail_title": "Over de e-mailtest", + "base_test_prechecks_invalid_domain": "De opgegeven domeinnaam is niet geldig!
Toelichting: Een A- en/of AAAA-record is noodzakelijk voor de websitetest, en een SOA-record voor de e-mailtest.", + "base_test_start": "Start test", + "base_test_website_explain": "

Wat wordt getest?

Nadat je een domeinnaam van een website heb opgegeven, testen we of de website ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\". Als je website een score van 100% heeft, dan wordt deze opgenomen in de Hall of Fame.

Hoe verbeteren?

Het testrapport kan je gebruiken om je website te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je webhoster.In de communicatie met je webhoster kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de websitetest integreren in je eigen website door gebruik te maken van onze widget code.

Test je website

", + "base_test_website_input": "Jouw website-domeinnaam:", + "base_test_website_label": "Test je website", + "base_test_website_text": "Modern adres? Beveiligde verbinding? Beveiligingsopties? Route-autorisatie?", + "base_test_website_title": "Over de websitetest", + "base_widget_mail": "E-mailtest widget", + "base_widget_site": "Websitetest widget", + "connection_pagetitle": "Verbindingstest", + "connection_title": "Verbindingstest", + "detail_conn_dnssec_validation_exp": "We testen of de door jou gebruikte resolvers de DNSSEC-handtekeningen van onze domeinnaam valideren. Resolvers worden normaal gesproken geleverd door je internetprovider. Als alternatief kun je resolvers van een andere DNS provider instellen. Je kan zelfs je eigen lokaal ge\u00efnstalleerde resolver gebruiken. Hoewel validatie plaatsvindt op de resolver, kan nog steeds door een aanvaller gerommeld worden met de communicatie tussen de resolver en jouw apparaat (ook wel \\'last mile\\' genoemd). Het is daarom het meest veilig om zo dicht mogelijk op je apparaat te valideren (bijv. door een lokaal ge\u00efnstalleerde resolver te gebruiken), of zorg ervoor dat het kanaal tussen je resolver en je apparaat beveiligd c.q. vertrouwd is.", + "detail_conn_dnssec_validation_label": "DNSSEC-validatie", + "detail_conn_dnssec_validation_tech_table": "DNS-provider", + "detail_conn_dnssec_validation_verdict_bad": "Je bent niet beschermd door validatie van DNSSEC-handtekeningen.", + "detail_conn_dnssec_validation_verdict_good": "Je bent beschermd door validatie van DNSSEC-handtekeningen.", + "detail_conn_ipv6_connection_exp": "We testen of jouw apparaat via zijn huidige internetverbinding in staat is om direct (d.w.z. zonder DNS-vertaling) verbinding te maken met onze webserver via ons bijbehorende IPv6-adres.

Sommige browser add-ons en routers bieden functionaliteit aan voor het filteren van domeinnamen om de privacy te verbeteren of internetgebruik te beperken. Om omzeiling te voorkomen blokkeert deze functionaliteit vaak ook het direct verbinden met IP-adressen waardoor deze subtest faalt.", + "detail_conn_ipv6_connection_label": "IPv6-connectiviteit (direct)", + "detail_conn_ipv6_connection_tech_table": "Geanonimiseerd IPv6-adres|Reverse name|Internetprovider", + "detail_conn_ipv6_connection_verdict_bad": "Je bent niet in staat om computers direct op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_connection_verdict_good": "Je bent in staat om computers direct op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_dns_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv6. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv6-adres ophaalt.", + "detail_conn_ipv6_dns_conn_label": "IPv6-connectiviteit (via DNS)", + "detail_conn_ipv6_dns_conn_verdict_bad": "Je bent niet in staat om computers via DNS op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_dns_conn_verdict_good": "Je bent in staat om computers via DNS op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_ipv4_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv4. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv4-adres ophaalt.

Niveau van vereistheid: Optioneel", + "detail_conn_ipv6_ipv4_conn_label": "IPv4-connectiviteit (via DNS)", + "detail_conn_ipv6_ipv4_conn_tech_table": "Geanonimiseerd IPv4-adres|Reverse name|Internetprovider", + "detail_conn_ipv6_ipv4_conn_verdict_bad": "Je bent niet in staat om computers via DNS op hun IPv4-adres te bereiken.", + "detail_conn_ipv6_ipv4_conn_verdict_good": "Je bent in staat om computers via DNS op hun IPv4-adres te bereiken.", + "detail_conn_ipv6_privacy_exp": "We testen of je apparaat \\'IPv6 Privacy Extensions for SLAAC\\' (of een ander IPv6-configuratieproces dan SLAAC) gebruikt om het lekken van zijn mogelijk privacygevoelige MAC-adres naar computers waarmee het via IPv6 verbinding maakt te voorkomen.", + "detail_conn_ipv6_privacy_label": "Privacy Extensions voor IPv6", + "detail_conn_ipv6_privacy_verdict_bad": "Je gebruikt SLAAC zonder \\'IPv6 Privacy Extensions\\'.", + "detail_conn_ipv6_privacy_verdict_good": "Je hebt \\'IPv6 Privacy Extensions\\' geactiveerd (of je gebruikt geen SLAAC).", + "detail_conn_ipv6_resolver_conn_exp": "We testen of ten minste \u00e9\u00e9n van de door jou gebruikte DNS-resolvers in staat is om onze autoritatieve nameserver te bereiken via IPv6. Vaak levert je internetprovider de DNS-resolver(s).", + "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).

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.", + "detail_mail_auth_dkim_verdict_no_email": "Je domeinnaam ondersteunt geen DKIM-records. Echter omdat je DMARC- en SPF-records aangeven dat er geen mail vanaf je domein wordt verstuurd, is DKIM niet nodig en wordt deze subtest overgeslagen.", + "detail_mail_auth_dmarc_exp": "We testen of DMARC beschikbaar is voor jouw domein. Een ontvangendemailserver kan de DMARC-policy gebruiken om te bepalen hoe om te gaan meteen e-mail met jouw domein als verzender waarvan de authenticatie met zowelDKIM als SPF faalt, en de ontvangende mailserver kan je e-mailadres uit het DMARC-recordgebruiken om je feedbackrapporten over het authenticatieresultaat te sturen. Het hebben van meer dan \u00e9\u00e9n DMARC-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt. Let op: DMARC vereist dathet SPF-domein (envelope sender, d.w.z. return-path dat terugkomt inMAIL FROM) en het DKIM-domein (d=) gelijk zijn aan het verzenddomein in hetmailbericht (From:). ", + "detail_mail_auth_dmarc_label": "DMARC aanwezigheid", + "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_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. ", + "detail_mail_auth_dmarc_policy_verdict_good": "Je DMARC-policy is voldoende strikt.", + "detail_mail_auth_dmarc_policy_verdict_policy": "Je DMARC-policy is niet voldoende strikt.", + "detail_mail_auth_spf_exp": "We testen of je domeinnaam een SPF-record heeft. Een ontvangende mailserver kan de IP-adressen in je SPF-record gebruiken om de verzendende mailserver van een ontvangen e-mail met jouw domein als afzender te authenticeren. Het bijbehorende beleid kan worden gebruikt om passende actie te ondernemen als de authenticatie mislukt. Meer dan \u00e9\u00e9n SPF-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt.

Voor een \"good practice voor domeinnamen zonder mail\" zie de uitleg van de \"DMARC-policy\" subtest.", + "detail_mail_auth_spf_label": "SPF aanwezigheid", + "detail_mail_auth_spf_tech_table": "SPF-record", + "detail_mail_auth_spf_verdict_bad": "Je domeinnaam heeft geen geldig SPF-record.", + "detail_mail_auth_spf_verdict_good": "Je domein heeft een SPF-record.", + "detail_mail_auth_spf_policy_exp": "We controleren of de syntax van je SPF-record geldig is en of deze een voldoende strikte policy, d.w.z. ~all (softfail) of -all (hardfail), bevat om misbruik van je domein door phishers en spammers tegen te gaan. Om misbruik van je domein tegen te gaan is een liberale policy, d.w.z. +all (pass) of ?all (neutral), onvoldoende. Als all ontbreekt en er is geen redirect aanwezig in je SPF-record, dan is de default policy ?all.

We volgen ook include en redirect voor geldige SPF-records. Bovendien controleren we of je SPF-record het toegestane aantal van 10 DNS-opvragingen niet overschrijdt waardoor het geen werking meer heeft. Ieder van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.

Merk op dat als het domein onder include of redirect uit macro\\'s bestaat, dan volgen we deze niet omdat we niet over de noodzakelijk informatie van een daadwerkelijke mail of mailserververbinding beschikken om de macro\\'s uit te voeren. Dit betekent dat we het gevolg van macro\\'s niet beoordelen. Bovendien tellen we de door macro\\'s veroorzaakte DNS-opvragingen niet mee om te bepalen of het toegestane aantal DNS-opvragingen is overschreden.

Voor verzendende domeinen heeft het gebruik van ~all (softfail) in plaats van -all (fail) meestal de voorkeur. De reden hiervoor is dat wanneer de SPF-authenticatie faalt met een SPF fail, een ontvangende mailserver de verbinding al kan blokkeren zonder de DKIM-handtekening en het DMARC-beleid te evalueren. Dit kan leiden tot ten onrechte geblokkeerde mails (bijvoorbeeld wanneer mails door de ontvangende mailserver automatisch worden doorgestuurd naar een andere ontvangende mailserver). Merk op dat een getriggerde SPF softfail er nog steeds voor zorgt dat een strikte DMARC policy je domein beschermt als ook de DKIM-authenticatie faalt.

Voor domeinen zonder mail zie de good practice op uitleg van de \"DMARC-policy\" subtest.", + "detail_mail_auth_spf_policy_label": "SPF policy", + "detail_mail_auth_spf_policy_tech_table": "Domein|SPF-record", + "detail_mail_auth_spf_policy_verdict_all": "Je SPF-policy is niet voldoende strikt.", + "detail_mail_auth_spf_policy_verdict_bad": "Je SPF-policy is syntactisch niet correct.", + "detail_mail_auth_spf_policy_verdict_good": "Je SPF-policy is voldoende strikt.", + "detail_mail_auth_spf_policy_verdict_include": "Je SPF-policy is niet voldoende strikt. Het \\'include\\'-mechanisme in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.", + "detail_mail_auth_spf_policy_verdict_max_lookups": "Je SPF-policy is niet effectief omdat deze meer dan de toegestane 10 DNS-opvragingen vereist. Elk van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.", + "detail_mail_auth_spf_policy_verdict_redirect": "Je SPF-policy is niet voldoende strikt. De \\'redirect modifier\\' in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.", + "detail_mail_dnssec_exists_exp": "We testen of de domeinnaam in je e-mailadres, meer specifiek het SOA-record, ondertekend is met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze jouw mailserverdomeinen (MX) kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar een mailserverdomein dat onder controle is van de aanvaller.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", + "detail_mail_dnssec_exists_label": "DNSSEC aanwezigheid", + "detail_mail_dnssec_exists_tech_table": "E-mailadresdomein|Registrar", + "detail_mail_dnssec_exists_verdict_bad": "Je e-mailadresdomein is onveilig oftewel \\'insecure\\', omdat het niet ondertekend is met DNSSEC.", + "detail_mail_dnssec_exists_verdict_good": "Je e-mailadresdomein is met DNSSEC ondertekend.", + "detail_mail_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", + "detail_mail_dnssec_exists_verdict_servfail": "De nameservers van je e-mailadresdomein zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", + "detail_mail_dnssec_mx_exists_exp": "We testen of de domeinnamen van je mailservers (MX), meer specifiek hun SOA-records, ondertekend zijn met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze de IP-adressen en DANE-records van jouw mailservers kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar IP-adressen die onder controle staan van de aanvaller \u00f3f de beveiligde mailserver-verbinding afluistert.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

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

De geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", + "detail_mail_dnssec_mx_exists_label": "DNSSEC aanwezigheid", + "detail_mail_dnssec_mx_exists_tech_table": "Domein van mailserver (MX)|DNSSEC aanwezig", + "detail_mail_dnssec_mx_exists_verdict_bad": "Tenminste \u00e9\u00e9n 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, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f 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": "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\u00ebn 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.", + "detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", + "detail_mail_dnssec_mx_exists_verdict_servfail": "De nameservers van tenminste \u00e9\u00e9n van je mailserverdomeinen zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je mailprovider) om dit spoedig op te lossen.", + "detail_mail_dnssec_mx_valid_exp": "We testen of de domeinen van je ontvangende mailservers (MX), meer specifiek hun SOA-records, zijn ondertekend met een geldige DNSSEC-handtekening die ze veilig oftewel \\'secure\\' maakt.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot vari\u00ebrende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", + "detail_mail_dnssec_mx_valid_label": "DNSSEC geldigheid", + "detail_mail_dnssec_mx_valid_tech_table": "Domein van mailserver (MX)|Status", + "detail_mail_dnssec_mx_valid_verdict_bad": "Tenminste \u00e9\u00e9n van de ondertekende domeinen van je mailservers is onbetrouwbaar oftewel \\'bogus\\', omdat zijn DNSSEC-handtekening niet geldig is. \u00d3f iemand manipuleerde de antwoorden van de nameservers, \u00f3f je mailserverdomein heeft serieuze DNSSEC-configuratiefouten. Dit laatste maakt je ontvangende mailserver onbereikbaar voor alle verzendende mailservers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met de nameserver-beheerder (vaak je mailprovider).", + "detail_mail_dnssec_mx_valid_verdict_good": "Al de ondertekende domeinnamen van je mailservers zijn veilig oftewel \\'secure\\', omdat hun DNSSEC-handtekeningen geldig zijn.", + "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "Tenminste \u00e9\u00e9n van de domeinen van je mailservers is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", + "detail_mail_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot vari\u00ebrende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", + "detail_mail_dnssec_valid_label": "DNSSEC geldigheid", + "detail_mail_dnssec_valid_tech_table": "E-mailadresdomein|Status", + "detail_mail_dnssec_valid_verdict_bad": "Je e-mailadresdomein is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. \u00d3f iemand manipuleerde het antwoord van jouw nameserver, \u00f3f je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", + "detail_mail_dnssec_valid_verdict_good": "Je e-mailadresdomein is veilig oftewel \\'secure\\', omdat zijn DNSSEC-handtekening geldig is.", + "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Je e-mailadresdomein is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", + "detail_mail_ipv6_mx_aaaa_exp": "We testen of er tenminste \u00e9\u00e9n AAAA-record met IPv6-adres voor iedere ontvangende mailserver (MX) is. In het geval er geen mailserver is gedefinieerd, geven we een notificatie en we voeren andere subtesten van de mailtest die nog steeds relevant zijn gewoon uit.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.", + "detail_mail_ipv6_mx_aaaa_label": "IPv6-adressen voor mailserver(s)", + "detail_mail_ipv6_mx_aaaa_tech_table": "Mailserver (MX)|IPv6-adres|IPv4-adres", + "detail_mail_ipv6_mx_aaaa_verdict_bad": "Tenminste \u00e9\u00e9n 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, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f 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 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\u00ebn 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": "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\u00ebn 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 \u00e9\u00e9n 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.", + "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 \u00e9\u00e9n 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.", + "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 \u00e9\u00e9n 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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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 \u00e9\u00e9n 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 \u00e9\u00e9n 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) \u00f3f 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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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 \u00e9\u00e9n 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 \u00e9\u00e9n 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) \u00f3f 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", + "detail_mail_tls_cert_hostmatch_tech_table": "Mailserver (MX)|Niet-overeenkomende domeinen op certificaat", + "detail_mail_tls_cert_hostmatch_verdict_bad": "De domeinnaam van tenminste \u00e9\u00e9n van je mailservers komt niet overeen met de domeinnaam op het mailservercertificaat.", + "detail_mail_tls_cert_hostmatch_verdict_good": "De domeinnamen van al je mailservers komen overeen met de domeinnamen op je mailservercertificaten.", + "detail_mail_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan \u00e9\u00e9n algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 \u2013 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", + "detail_mail_tls_cert_pubkey_label": "Publieke sleutel van certificaat", + "detail_mail_tls_cert_pubkey_tech_table": "Mailserver (MX)|Getroffen handtekening-parameters|Status", + "detail_mail_tls_cert_pubkey_verdict_bad": "De digitale handtekening van tenminste \u00e9\u00e9n van je mailserver-certificaten gebruikt onvoldoende veilige parameters.", + "detail_mail_tls_cert_pubkey_verdict_good": "De digitale handtekeningen van al je mailserver-certificaten gebruiken veilige parameters.", + "detail_mail_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van tenminste \u00e9\u00e9n van je mailserver-certificaten gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van ieder van je mailserver-certificaten is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", + "detail_mail_tls_cert_signature_label": "Handtekening van certificaat", + "detail_mail_tls_cert_signature_tech_table": "Mailserver (MX)|Getroffen hashing-algoritme|Status", + "detail_mail_tls_cert_signature_verdict_bad": "Tenminste \u00e9\u00e9n van je mailserver-certificaten is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", + "detail_mail_tls_cert_signature_verdict_good": "Al je mailserver-certificaten zijn ondertekend met een veilig algoritme voor hashing.", + "detail_mail_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je mailserver-certificaten kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit \u00e9n je ontvangende mailserver alle noodzakelijke tussenliggende certificaten presenteert.

Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.

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

Niveau van vereistheid: Optioneel", + "detail_mail_tls_cert_trust_label": "Vertrouwensketen van certificaat", + "detail_mail_tls_cert_trust_tech_table": "Mailserver (MX)|Onvertrouwde certificaatketen", + "detail_mail_tls_cert_trust_verdict_bad": "De vertrouwensketen van tenminste \u00e9\u00e9n 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 \u00e9n 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-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 \u00e9\u00e9n van je mailservers dwingt niet zijn eigen cipher-voorkeur af (\\'I\\').", + "detail_mail_tls_cipher_order_verdict_good": "Al je mailservers dwingen hun eigen cipher-voorkeur af (\\'I\\'), en bieden ciphers aan conform de voorgeschreven volgorde (\\'II\\').", + "detail_mail_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je mailserver alleen \\'Goede\\' ciphers ondersteunt.", + "detail_mail_tls_cipher_order_verdict_seclevel_bad": "Tenminste \u00e9\u00e9n van je mailservers prefereert niet \\'Goede\\' boven \\'Voldoende\\' en dan pas \\'Uit te faseren\\' ciphers (\\'II\\').", + "detail_mail_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Tenminste een van je mailservers biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\\'II-B\\').", + "detail_mail_tls_ciphers_exp": "

We testen of je ontvangende mailservers (MX) alleen veilige, d.w.z. \\'Goede\\' en/of \\'Voldoende\\', ciphers (ook algoritmeselecties genoemd) ondersteunen. Om te voorkomen dat we tegen \\'rate limits\\' van ontvangende mailservers aanlopen, bevat het testresultaat alleen de eerstgevonden getroffen algoritmeselectie.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing.

  • Vanaf TLS 1.3 omvat de term \\'cipher suite\\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \\'cipher suite\\' ambigu maakt, gebruikt NCSC de term \\'algoritmeselectie\\' om alle vier de functies te omvatten.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselectie. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \\'Goede\\', \\'Voldoende\\' en \\'Uit te faseren\\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\\'. Achter iedere algoritmeselectie staat de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \\'Uit te faseren\\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_mail_tls_ciphers_label": "Ciphers (Algoritmeselecties)", + "detail_mail_tls_ciphers_tech_table": "Mailserver (MX)|Eerst gevonden onveilige cipher|Status", + "detail_mail_tls_ciphers_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer onvoldoende veilige ciphers.", + "detail_mail_tls_ciphers_verdict_good": "Al je mailservers ondersteunen alleen veilige ciphers.", + "detail_mail_tls_ciphers_verdict_phase_out": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer ciphers die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_compression_exp": "

We testen of je ontvangende mailservers (MX) TLS-compressie ondersteunen.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te be\u00efnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau
  • Onvoldoende: TLS-compressie
", + "detail_mail_tls_compression_label": "TLS-compressie", + "detail_mail_tls_compression_tech_table": "Mailserver (MX)|TLS-compressie", + "detail_mail_tls_compression_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt TLS-compressie, wat niet veilig is.", + "detail_mail_tls_compression_verdict_good": "Al je mailservers ondersteunen geen TLS-compressie.", + "detail_mail_tls_dane_exists_exp": "We testen of de nameservers van ieder van je ontvangende mailservers (MX) een of meer TLSA-records voor DANE bevatten.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het mailserver-domein.

Merk op dat de test TLSA-records van de types PKIX-TA(0) or PKIX-EE(1) negeert, omdat deze niet gebruikt dienen te worden voor ontvangende mailservers.

De test slaagt daarnaast niet als er geen DNSSEC-bewijs van \\'Denial of Existence\\' voor TLSA-records is. Als een ondertekend TLSA-record bestaat maar tegelijkertijd is er een \\'insecure\\' NXDOMAIN voor hetzelfde domein (door verkeerd werkende DNSSEC-ondertekeningssoftware), dan zal de test ook niet slagen. De laatste twee foutscenario\\'s kunnen leiden tot afleveringsproblemen van aan jou gerichte e-mails door DANE-validerende mailverzenders.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, Appendix A, onder \\'Certificate pinning en DANE\\'.", + "detail_mail_tls_dane_exists_label": "DANE aanwezigheid", + "detail_mail_tls_dane_exists_tech_table": "Mailserver (MX)|DANE TLSA-record aanwezig", + "detail_mail_tls_dane_exists_verdict_bad": "Tenminste \u00e9\u00e9n van je mailserverdomeinen bevat geen TLSA-record voor DANE.", + "detail_mail_tls_dane_exists_verdict_bogus": "Tenminste \u00e9\u00e9n 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 \u00e9\u00e9n 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, \u00e9\u00e9n voor het huidige en \u00e9\u00e9n 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 (\u00e9\u00e9n gebaseerd op RSA en \u00e9\u00e9n gebaseerd op ECDSA), een afzonderlijk DANE TLSA rollover schema wordt aanbevolen voor ieder certificaat. De subtest controleert niet op dit scenario. Als er slechts \u00e9\u00e9n 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.", + "detail_mail_tls_dane_rollover_verdict_good": "Al je mailserver-domeinen hebben een actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.", + "detail_mail_tls_dane_valid_exp": "We testen of de DANE-fingerprints die je mailserverdomeinen presenteren geldig zijn voor je mailservercertificaten.

Met DANE kan je informatie over jouw mailservercertificaten publiceren in een speciaal DNS-record, een TLSA-record. Verzendende mailservers kunnen de certificaten nu niet alleen via de certificaatautoriteit, maar ook via de TLSA-records controleren op authenticiteit. Een verzendende mail server kan het TLSA-record ook als signaal gebruiken om alleen via STARTTLS (en niet onversleuteld) te verbinden. Als de DANE-fingerprint van een ontvangende mailserver wordt gecontroleerd door de verzendende mailserver, dan kan een actieve aanvaller die in staat is het berichtenverkeer te manipuleren de STARTTLS-encryptie niet verwijderen.", + "detail_mail_tls_dane_valid_label": "DANE geldigheid", + "detail_mail_tls_dane_valid_tech_table": "Mailserver (MX)|DANE TLSA-record geldig", + "detail_mail_tls_dane_valid_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers heeft geen geldige DANE-fingerprints. \u00d3f iemand manipuleerde het antwoord van je mailserver, \u00f3f 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 \u00e9\u00e9n 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_label": "Sleuteluitwisselingsparameters", + "detail_mail_tls_fs_params_tech_table": "Mailserver (MX)|Getroffen parameters|Veiligheidsniveau", + "detail_mail_tls_fs_params_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_mail_tls_fs_params_verdict_good": "Je mailserver ondersteunt voldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_mail_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je mailservers niet Diffie-Hellman-sleuteluitwisseling ondersteunen. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", + "detail_mail_tls_fs_params_verdict_phase_out": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_kex_hash_func_exp": "

We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver cre\u00ebert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", + "detail_mail_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", + "detail_mail_tls_kex_hash_func_tech_table": "Mailserver (MX)|SHA-2-ondersteuning voor handtekeningen", + "detail_mail_tls_kex_hash_func_verdict_good": "Al je mailservers ondersteunen veilige hashfuncties voor sleuteluitwisseling.", + "detail_mail_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie tenminste \u00e9\u00e9n van je mailservers gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", + "detail_mail_tls_kex_hash_func_verdict_phase_out": "Ten minste \u00e9\u00e9n van je mailservers ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", + "detail_mail_tls_ocsp_stapling_exp": "OUTDATED TEXT; TEST NOT USED
TODO", + "detail_mail_tls_ocsp_stapling_label": "OUTDATED TEXT; TEST NOT USED
TODO", + "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mailserver (MX)|TODO", + "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\u00ebren met jouw ontvangende mailservers (MX).

In het algemeen is het niet nodig om clients de mogelijkheid te bieden om een renegotiation te initi\u00ebren (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 \u00e9\u00e9n van je mailservers staat client-initiated renegotiation toe, wat een negatieve invloed kan hebben op de beschikbaarheid van je mailserver.", + "detail_mail_tls_renegotiation_client_verdict_good": "Al je mailservers staan geen client-initiated renegotiation toe.", + "detail_mail_tls_renegotiation_secure_exp": "

We testen of je mailservers (MX) secure renegotiation ondersteunen.

In de oudere versies van TLS (v\u00f3\u00f3r TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", + "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_mail_tls_renegotiation_secure_tech_table": "Mailserver (MX)|Secure renegotiation", + "detail_mail_tls_renegotiation_secure_verdict_bad": "Tenminste \u00e9\u00e9n 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\u00ebn 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 \u00e9\u00e9n 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, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f 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 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\u00ebn 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 \u00e9\u00e9n van je mailservers is onbereikbaar.", + "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\u00ebn 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 \u00e9\u00e9n 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", + "detail_mail_tls_version_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer onvoldoende veilige TLS-versies.", + "detail_mail_tls_version_verdict_good": "Al je mailservers ondersteunen alleen veilige TLS-versies.", + "detail_mail_tls_version_verdict_phase_out": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_zero_rtt_exp": "

We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie ge\u00efnitieerd. De omvang van de ondersteuning voor early data zoals aangegeven door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando v\u00f3\u00f3r de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", + "detail_mail_tls_zero_rtt_label": "0-RTT", + "detail_mail_tls_zero_rtt_tech_table": "Mailserver (MX)|0-RTT", + "detail_mail_tls_zero_rtt_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt 0-RTT, wat niet veilig is.", + "detail_mail_tls_zero_rtt_verdict_good": "Geen van je mailservers ondersteunen 0-RTT.", + "detail_mail_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je mailservers TLS 1.3 niet ondersteunen.", + "detail_tech_data_bogus": "bogus", + "detail_tech_data_good": "goed", + "detail_tech_data_http_csp_has_bare_https": "Aanbeveling: \\'https:\\' schema zonder specifiek hoofddomein moet niet worden gebruikt (#9).", + "detail_tech_data_http_csp_has_data": "Aanbeveling: \\'data:\\' schema moet niet worden gebruikt waar dat niet is toegestaan (#7).", + "detail_tech_data_http_csp_has_host_without_scheme": "Aanbeveling: Een domein zonder schema moet niet worden gebruikt (#8). ", + "detail_tech_data_http_csp_has_http": "Aanbeveling: \\'http:\\' schema moet niet worden gebruikt (#8).", + "detail_tech_data_http_csp_has_invalid_host": "Aanbeveling: Een wildcard (d.w.z. \\'*\\') of \\'127.0.0.1\\' moeten niet worden gebruikt (#9 en #10).", + "detail_tech_data_http_csp_has_unsafe_eval": "Aanbeveling: \\'unsafe-eval\\' moet niet worden gebruikt (#6).", + "detail_tech_data_http_csp_has_unsafe_hashes": "Aanbeveling: \\'unsafe-hashes\\' moet niet worden gebruikt (#6).", + "detail_tech_data_http_csp_has_unsafe_inline": "Aanbeveling: \\'unsafe-inline\\' moet niet worden gebruikt (#6).", + "detail_tech_data_http_csp_missing_invalid_base_uri": "Aanbeveling: \\'base-uri\\' met voldoende veilige waarde moet zijn gedefinieerd (#2).", + "detail_tech_data_http_csp_missing_invalid_default_src": "Aanbeveling: \\'default-src\\' met voldoende veilige waarde moet zijn gedefinieerd (#1).", + "detail_tech_data_http_csp_missing_invalid_form_action": "Aanbeveling: \\'form-action\\' met voldoende veilige waarde moet zijn gedefinieerd (#5).", + "detail_tech_data_http_csp_missing_invalid_frame_ancestors": "Aanbeveling: \\'frame-ancestors\\' met voldoende veilige waarde moet zijn gedefinieerd (#4).", + "detail_tech_data_http_csp_missing_invalid_frame_src": "Aanbeveling: \\'frame-src\\' (of \\'child-src\\' of \\'default-src\\' als fallback) met voldoende veilige waarde moet zijn gedefinieerd (#3).", + "detail_tech_data_http_csp_no_policy_found": "Geen CSP gevonden.", + "detail_tech_data_http_csp_policy_found": "Opgehaalde CSP-waarde: {policy}", + "detail_tech_data_http_referrer_policy_bad_invalid": "Slecht: policy-waarde is niet geldig.", + "detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade": "Slecht: \\'no-referrer-when-downgrade\\' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_bad_origin": "Slecht: \\'origin\\' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin": "Slecht: \\'origin-when-cross-origin\\' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_bad_unsafe_url": "Slecht: \\'unsafe-url\\' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_no_policy": "Geen Referrer-Policy gevonden.", + "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 \u00e9\u00e9n 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 \u00e9\u00e9n keer voorkomen.", + "detail_tech_data_http_securitytxt_multi_lang": "Fout: Het veld \\'Preferred-Languages\\' moet niet meer dan \u00e9\u00e9n keer voorkomen.", + "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Aanbeveling: Meerdere \\'CSAF\\'-velden zouden moeten worden teruggebracht tot \u00e9\u00e9n \\'CSAF\\'-veld.", + "detail_tech_data_http_securitytxt_no_canonical": "Aanbeveling: Het veld \\'Canonical\\' zou aanwezig moeten zijn in een ondertekend bestand.", + "detail_tech_data_http_securitytxt_no_canonical_match": "Fout: De web URI van security.txt (d.w.z. bij redirecting ten minste de laatste URI van de redirect-keten) moet worden vermeld in een \\'Canonical\\'-veld als dat aanwezig is.", + "detail_tech_data_http_securitytxt_no_contact": "Fout: Het veld \\'Contact\\' moet minstens \u00e9\u00e9n keer voorkomen.", + "detail_tech_data_http_securitytxt_no_content_type": "Fout: HTTP Content-Type header moet worden verstuurd.", + "detail_tech_data_http_securitytxt_no_csaf_file": "Fout: Ieder optioneel \\'CSAF\\'-veld moet verwijzen naar een bestand met de naam \\'provider-metadata.json\\'.", + "detail_tech_data_http_securitytxt_no_encryption": "Aanbeveling: Het veld \\'Encryption\\' zou aanwezig moeten zijn wanneer het veld \\'Contact\\' een e-mailadres bevat.", + "detail_tech_data_http_securitytxt_no_expire": "Fout: Het veld \\'Expires\\' moet aanwezig zijn.", + "detail_tech_data_http_securitytxt_no_https": "Fout: De web URI moet beginnen met \\'https://\\' (regel {line_no}).", + "detail_tech_data_http_securitytxt_no_line_separators": "Fout: Elke regel moet eindigen met \u00f3f een carriage return en line feed characters \u00f3f alleen een line feed character.", + "detail_tech_data_http_securitytxt_no_security_txt_404": "Fout: security.txt kon niet gevonden worden.", + "detail_tech_data_http_securitytxt_no_security_txt_other": "Fout: security.txt kon niet gevonden worden (onverwachte HTTP response code {status_code}).", + "detail_tech_data_http_securitytxt_no_space": "Fout: Veld-scheidingsteken (dubbele punt) moet worden gevolgd door een spatie (regel {line_no}).", + "detail_tech_data_http_securitytxt_no_uri": "Fout: Veldwaarde moet een URI zijn (bijv. beginnend met \\'mailto:\\') (regel {line_no}).", + "detail_tech_data_http_securitytxt_not_signed": "Aanbeveling: security.txt zou digitaal ondertekend moeten zijn.", + "detail_tech_data_http_securitytxt_pgp_data_error": "Fout: Ondertekende security.txt moet een correct \\'ASCII-armored PGP block\\' bevatten.", + "detail_tech_data_http_securitytxt_pgp_error": "Fout: Het decoderen of parsen van de ondertekende security.txt moet slagen.", + "detail_tech_data_http_securitytxt_prec_ws": "Fout: Er mag geen spatie staan voor het veld-scheidingsteken (dubbele punt) (regel {line_no}).", + "detail_tech_data_http_securitytxt_requested_from": "security.txt opgevraagd van {hostname}.", + "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 gecodeerd zijn met UTF-8 in Net-Unicode vorm.", + "detail_tech_data_insecure": "insecure", + "detail_tech_data_insufficient": "onvoldoende", + "detail_tech_data_no": "nee", + "detail_tech_data_not_applicable": "niet van toepassing", + "detail_tech_data_not_reachable": "niet bereikbaar", + "detail_tech_data_not_testable": "niet testbaar", + "detail_tech_data_not_tested": "niet getest", + "detail_tech_data_phase_out": "uit te faseren", + "detail_tech_data_secure": "secure", + "detail_tech_data_sufficient": "voldoende", + "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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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\u00ebn 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, \u00f3f 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.

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.

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.

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.", + "detail_web_appsecpriv_http_x_frame_verdict_good": "Je webserver biedt veilig ingestelde X-Frame-Options aan.", + "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We testen of je webserver een HTTP header voor X-XSS-Protection aanbiedt die een voldoende veilige waarde heeft (dat wil zeggen 1 of 1; mode=block). Deze HTTP header kan worden gebruikt om het beschermingsfilter van browsers tegen reflectieve cross-site scripting (XSS) aanvallen te activeren.

Geldige waardes voor de X-XSS-Protection header zijn:

  • 0 deactiveert het XSS-filter. Deze waarde dient NIET te worden gebruikt.
  • 1 activeert het XSS-filter. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het script opschonen en de onveilige delen verwijderen. Deze waarde is normaal gesproken de standaard-waarde (\\'default\\') in browsers als een website geen X-XSS-Protection header aanbiedt.
  • 1; mode=block activeert het XSS-filter \u00e9n de blokkeermodus. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het antwoord blokkeren en de webpagina niet laden. Dit is de aanbevolen waarde.

Mits goed geconfigureerd kan Content-Security-Policy (CSP) vergelijkbare bescherming en meer bieden aan gebruikers van moderne webbrowsers. X-XSS-Protection biedt in dat geval nog altijd bescherming aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-XSS-Protection waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Niveau van vereistheid: Aanbevolen", + "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", + "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres|X-XSS-Protection waarde", + "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt geen veilig ingestelde X-XSS-Protection aan.", + "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt veilig ingestelde X-XSS-Protection aan.", + "detail_web_dnssec_exists_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, ondertekend is met DNSSEC.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", + "detail_web_dnssec_exists_label": "DNSSEC aanwezigheid", + "detail_web_dnssec_exists_tech_table": "Domein|Registrar", + "detail_web_dnssec_exists_verdict_bad": "Je domein is onveilig oftewel \\'insecure\\', omdat het niet ondertekend is met DNSSEC.", + "detail_web_dnssec_exists_verdict_good": "Je domein is met DNSSEC ondertekend.", + "detail_web_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", + "detail_web_dnssec_exists_verdict_servfail": "De nameservers van je domeinnaam zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", + "detail_web_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot vari\u00ebrende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zij", + "detail_web_dnssec_valid_label": "DNSSEC geldigheid", + "detail_web_dnssec_valid_tech_table": "Domein|Status", + "detail_web_dnssec_valid_verdict_bad": "Je domeinnaam is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. \u00d3f iemand manipuleerde het antwoord van jouw nameserver, \u00f3f je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", + "detail_web_dnssec_valid_verdict_good": "Je domeinnaam is veilig oftewel \\'secure\\', omdat zijn DNSSEC-handtekening geldig is.", + "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Je domeinnaam is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", + "detail_web_ipv6_web_aaaa_exp": "We testen of er tenminste \u00e9\u00e9n AAAA-record met IPv6-adres voor je webserver is.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.", + "detail_web_ipv6_web_aaaa_label": "IPv6-adressen voor webserver", + "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 \u00e9\u00e9n van je webservers heeft een IPv6-adres.", + "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 \u2013 299) en \\'redirection messages\\' (300 \u2013 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 \u00e9\u00e9n IPv6-adres en \u00e9\u00e9n 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 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 \u00e9\u00e9n 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.", + "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 \u00e9\u00e9n 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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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 \u00e9\u00e9n 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 \u00e9\u00e9n 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) \u00f3f 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", + "detail_web_tls_cert_hostmatch_tech_table": "Webserver-IP-adres|Niet-overeenkomende domeinen op certificaat", + "detail_web_tls_cert_hostmatch_verdict_bad": "De domeinnaam van je website komt niet overeen met de domeinnaam op je websitecertificaat.", + "detail_web_tls_cert_hostmatch_verdict_good": "De domeinnaam van je website komt overeen met de domeinnaam op je websitecertificaat.", + "detail_web_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan \u00e9\u00e9n algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 \u2013 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", + "detail_web_tls_cert_pubkey_label": "Publieke sleutel van certificaat", + "detail_web_tls_cert_pubkey_tech_table": "Webserver-IP-adres|Getroffen handtekening-parameters|Status", + "detail_web_tls_cert_pubkey_verdict_bad": "De digitale handtekening van je websitecertificaat gebruikt onvoldoende veilige parameters.", + "detail_web_tls_cert_pubkey_verdict_good": "De digitale handtekening van je websitecertificaat gebruikt veilige parameters.", + "detail_web_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van je websitecertificaat gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van het websitecertificaat is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", + "detail_web_tls_cert_signature_label": "Handtekening van certificaat", + "detail_web_tls_cert_signature_tech_table": "Webserver-IP-adres|Getroffen hashing-algoritme|Status", + "detail_web_tls_cert_signature_verdict_bad": "Je websitecertificaat is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", + "detail_web_tls_cert_signature_verdict_good": "Je websitecertificaat is ondertekend met een voldoende algoritme voor hashing.", + "detail_web_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit \u00e9n je webserver alle noodzakelijke tussenliggende certificaten presenteert.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B3-4.", + "detail_web_tls_cert_trust_label": "Vertrouwensketen van certificaat", + "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-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\\').", + "detail_web_tls_cipher_order_verdict_good": "Je webserver dwingt zijn eigen cipher-voorkeur af (\\'I\\'), en biedt ciphers aan conform de voorgeschreven volgorde (\\'II\\').", + "detail_web_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver alleen \\'Goede\\' ciphers ondersteunt.", + "detail_web_tls_cipher_order_verdict_seclevel_bad": "Je webserver prefereert niet \\'Goede\\' boven \\'Voldoende\\' en dan pas \\'Uit te faseren\\' ciphers (\\'II\\').", + "detail_web_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Je webserver biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\\'II-B\\').", + "detail_web_tls_ciphers_exp": "

We testen of je webserver alleen veilige, d.w.z. \\'Goede\\' en/of \\'Voldoende\\', ciphers (ook algoritmeselecties genoemd) ondersteunt.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing. Een webserver kan meer dan \u00e9\u00e9n algoritmeselectie ondersteunen.

  • Vanaf TLS 1.3 omvat de term \\'cipher suite\\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \\'cipher suite\\' ambigu maakt, gebruikt NCSC de term \\'algoritmeselectie\\' om alle vier de functies aan te duiden.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselecties. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \\'Goede\\', \\'Voldoende\\' en \\'Uit te faseren\\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\\'. Achter iedere algoritmeselectie noemen we de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \\'Uit te faseren\\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_web_tls_ciphers_label": "Ciphers (Algoritmeselecties)", + "detail_web_tls_ciphers_tech_table": "Webserver-IP-adres|Getroffen ciphers|Status", + "detail_web_tls_ciphers_verdict_bad": "Je webserver ondersteunt een of meer onvoldoende veilige ciphers.", + "detail_web_tls_ciphers_verdict_good": "Je webserver ondersteunt alleen veilige ciphers.", + "detail_web_tls_ciphers_verdict_phase_out": "Je webserver ondersteunt een of meer ciphers die de status uit te faseren hebben omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_compression_exp": "

We testen of je webserver TLS-compressie ondersteunt.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te be\u00efnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", + "detail_web_tls_compression_label": "TLS-compressie", + "detail_web_tls_compression_tech_table": "Webserver-IP-adres|TLS-compressie", + "detail_web_tls_compression_verdict_bad": "Je webserver ondersteunt TLS-compressie, wat niet veilig is.", + "detail_web_tls_compression_verdict_good": "Je webserver ondersteunt geen TLS-compressie.", + "detail_web_tls_dane_exists_exp": "We testen of de nameserver van je websitedomein een correct ondertekend TLSA-record voor DANE bevat.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het websitedomein, of als er DANE-gerelateerde DNSSEC-issues zijn (bijv. geen bewijs voor \\'Denial of Existence\\').

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, Appendix A, onder \\'Certificate pinning en DANE\\'.

Niveau van vereistheid: Optioneel", + "detail_web_tls_dane_exists_label": "DANE aanwezigheid", + "detail_web_tls_dane_exists_tech_table": "Webserver-IP-adres|DANE TLSA-record aanwezig", + "detail_web_tls_dane_exists_verdict_bad": "Je websitedomein bevat geen TLSA-record voor DANE.", + "detail_web_tls_dane_exists_verdict_bogus": "Je websitedomein bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Vraag je nameserver-beheerder om deze fout op te lossen.", + "detail_web_tls_dane_exists_verdict_good": "Je websitedomein bevat een TLSA-record voor DANE.", + "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", + "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", + "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", + "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", + "detail_web_tls_dane_valid_exp": "We testen of de DANE-fingerprint die je domein presenteert geldig is voor je websitecertificaat.

Met DANE kan je informatie over jouw websitecertificaat publiceren in een speciaal DNS-record, een TLSA-record. Clients, zoals webbrowsers, kunnen het certificaat nu niet alleen via de certificaatautoriteit, maar ook via het TLSA-record controleren op authenticiteit. Een client kan het TLSA-record ook als signaal gebruiken om alleen via HTTPS (en niet via HTTP) te verbinden. DNSSEC is een noodzakelijke randvoorwaarde voor DANE. Helaas ondersteunen nog niet veel webbrowsers DANE-validatie.

Niveau van vereistheid: Aanbevolen (alleen als subtest voor \\'DANE aanwezigheid\\' is geslaagd)", + "detail_web_tls_dane_valid_label": "DANE geldigheid", + "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. \u00d3f iemand manipuleerde het antwoord van jouw nameserver, \u00f3f 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_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.", + "detail_web_tls_fs_params_verdict_good": "Je webserver ondersteunt veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_web_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je webserver niet Diffie-Hellman-sleuteluitwisseling ondersteunt. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", + "detail_web_tls_fs_params_verdict_phase_out": "Je webserver ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_http_compression_exp": "

We testen of je webserver HTTP-compressie ondersteunt.

Bij het HTTP-protocol wordt compressie vaak gebruikt om de beschikbare bandbreedte effici\u00ebnter te gebruiken. HTTP-compressie maakt de beveiligde verbinding met je webserver echter kwetsbaar voor de BREACH-aanval. Weeg de voors en tegens van HTTP-compressie zorgvuldig tegen elkaar af. Wanneer u kiest voor het gebruik van HTTP-compressie, ga dan na of het mogelijk is om hieruit voortvloeiende potenti\u00eble applicatie-aanvallen te beperken. Een voorbeeld van een dergelijke maatregel is het beperken van de mate waarin een aanvaller de respons van de server kan be\u00efnvloeden.

Dit testonderdeel controleert of de webserver op rootdirectory-niveau HTTP-compressie ondersteunt, maar controleert geen andere websitebronnen zoals plaatje en scripts.

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

Niveau van vereistheid: Optioneel

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", + "detail_web_tls_http_compression_label": "HTTP-compressie", + "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.

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.", + "detail_web_tls_https_exists_verdict_good": "Je website biedt HTTPS aan.", + "detail_web_tls_https_exists_verdict_other": "Je webserver is niet bereikbaar.", + "detail_web_tls_https_forced_exp": "We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), \u00f3f dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf \\'upgraden\\' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

  • http://example.nl \u21d2 https://example.nl \u21d2 https://www.example.nl
  • http://www.example.nl \u21d2 https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie \\'Webapplicatie-richtlijnen, Verdieping\\' van NCSC, richtlijn U/WA.05.", + "detail_web_tls_https_forced_label": "HTTPS-doorverwijzing", + "detail_web_tls_https_forced_tech_table": "Webserver-IP-adres|HTTPS-doorverwijzing", + "detail_web_tls_https_forced_verdict_bad": "Je webserver ondersteunt zowel HTTP als HTTPS, maar verwijst bezoekers niet automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", + "detail_web_tls_https_forced_verdict_good": "Je webserver verwijst bezoekers automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", + "detail_web_tls_https_forced_verdict_no_https": "Deze test is niet uitgevoerd, omdat je webserver geen HTTPS biedt of alleen HTTPS met een te verouderde, onveilige TLS-configuratie.", + "detail_web_tls_https_forced_verdict_other": "Je webserver biedt alleen ondersteuning voor HTTPS en niet voor HTTP.", + "detail_web_tls_https_hsts_exp": "We testen of je webserver HSTS ondersteunt.

Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.

HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt man-in-the-middle-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van tenminste 1 jaar (max-age=31536000) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen.

De test controleert niet of preload wordt gebruikt en of het domein is opgenomen in de HSTS Preload Lijst.

Aanbevelingen voor implementatie

HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze niet bereikbaar zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen.

Daarom adviseren we u om de onderstaande implementatiestappen te volgen:

  1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);

  2. Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina\\'s. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.

  3. Begin met 5 minuten (max-age=300);

  4. Verhoog dit naar 1 week (max-age=604800);
  5. Verhoog dit naar 1 maand (max-age=2592000);

  6. Verhoog het naar 1 jaar (max-age=31536000) of meer.

  7. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik includeSubDomains alleen als je er volledig zeker van bent dat alle (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.

  8. Gebruik preload alleen als je heel zeker weet dat je je domein wil laten opnemen in de HSTS Preload Lijst. HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien.

Zie \\'Webapplicatie-richtlijnen, Verdieping\\' van NCSC, richtlijn U/WA.05.", + "detail_web_tls_https_hsts_label": "HSTS", + "detail_web_tls_https_hsts_tech_table": "Webserver-IP-adres|HSTS-policy", + "detail_web_tls_https_hsts_verdict_bad": "Je webserver biedt geen HSTS-policy aan.", + "detail_web_tls_https_hsts_verdict_good": "Je webserver biedt een HSTS-policy aan.", + "detail_web_tls_https_hsts_verdict_other": "Je webserver biedt een HSTS-policy aan met een geldigheidsduur voor caching (max-age) die niet voldoende lang (d.w.z. korter dan 1 jaar) is.", + "detail_web_tls_kex_hash_func_exp": "

We testen of je webserver ondersteuning biedt voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver cre\u00ebert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", + "detail_web_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", + "detail_web_tls_kex_hash_func_tech_table": "Webserver-IP-adress|SHA-2-ondersteuning voor handtekeningen", + "detail_web_tls_kex_hash_func_verdict_good": "Je webserver ondersteunt een veilige hashfunctie voor sleuteluitwisseling.", + "detail_web_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie je webserver gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", + "detail_web_tls_kex_hash_func_verdict_phase_out": "Je webserver ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", + "detail_web_tls_ocsp_stapling_exp": "

We testen of je webserver de TLS Certificate Status extension of te wel OCSP stapling ondersteunt.

De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.

Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifi\u00ebren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.

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

Niveau van vereistheid: Optioneel

OCSP stapling

  • Goed: Aan
  • Voldoende: Uit
", + "detail_web_tls_ocsp_stapling_label": "OCSP stapling", + "detail_web_tls_ocsp_stapling_tech_table": "Webserver-IP-adres|OCSP stapling", + "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\u00ebren met jouw webserver.

In het algemeen is het niet nodig om clients de mogelijkheid te bieden om een renegotiation te initi\u00ebren (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.", + "detail_web_tls_renegotiation_client_verdict_good": "Je webserver staat geen client-initiated renegotiation toe.", + "detail_web_tls_renegotiation_secure_exp": "

We testen of je webserver secure renegotiation ondersteunt.

In de oudere versies van TLS (v\u00f3\u00f3r TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", + "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table": "Webserver-IP-adres|Secure renegotiation", + "detail_web_tls_renegotiation_secure_verdict_bad": "Je webserver ondersteunt insecure renegotiation, wat uiteraard niet veilig is.", + "detail_web_tls_renegotiation_secure_verdict_good": "Je webserver ondersteunt secure renegotiation.", + "detail_web_tls_version_exp": "

We testen of je webserver alleen veilige TLS-versies ondersteunt.

Een webserver kan meer dan \u00e9\u00e9n TLS-versie ondersteunen.

Merk op dat browsermakers hebben aangekondigd dat ze zullen stoppen met de ondersteuning van TLS 1.1 en 1.0. Daardoor zullen websites die geen TLS 1.2 en/of 1.3 ondersteunen onbereikbaar worden.

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_web_tls_version_label": "TLS-versie", + "detail_web_tls_version_tech_table": "Webserver-IP-adres|TLS-versie|Status", + "detail_web_tls_version_verdict_bad": "Je webserver ondersteunt onvoldoende veilige TLS-versies.", + "detail_web_tls_version_verdict_good": "Je webserver ondersteunt alleen veilige TLS-versies.", + "detail_web_tls_version_verdict_phase_out": "Je webserver ondersteunt TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_zero_rtt_exp": "

We testen of je webserver Zero Round Trip Time Resumption (0-RTT) ondersteunt.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina / opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor early data zoals aangegeven door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging v\u00f3\u00f3r de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-HTTP 425 Too Early, dan wordt aangenomen dat de webserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", + "detail_web_tls_zero_rtt_label": "0-RTT", + "detail_web_tls_zero_rtt_tech_table": "Webserver-IP-adres|0-RTT", + "detail_web_tls_zero_rtt_verdict_bad": "Je webserver ondersteunt 0-RTT, wat niet veilig is.", + "detail_web_tls_zero_rtt_verdict_good": "Je webserver ondersteunt geen 0-RTT.", + "detail_web_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver TLS 1.3 niet ondersteunt. ", + "detail_web_mail_ipv6_ns_aaaa_exp": "We testen of je domeinnaam tenminste twee nameservers met een IPv6-adres heeft.

Dit sluit aan bij de \"Technische eisen voor registratie en gebruik van .nl-domeinnamen\" d.d. 13 november 2017 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze test, aangezien zij geen IPv6-connectiviteit bieden.", + "detail_web_mail_ipv6_ns_aaaa_label": "IPv6-adressen voor nameservers", + "detail_web_mail_ipv6_ns_aaaa_tech_table": "Nameserver|IPv6-adres|IPv4-adres", + "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "Geen van de nameservers van je domeinnaam heeft een IPv6-adres.", + "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Twee of meer nameservers van je domeinnaam hebben een IPv6-adres.", + "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Slechts \u00e9\u00e9n nameserver van je domeinnaam heeft een IPv6-adres.", + "detail_web_mail_ipv6_ns_reach_exp": "We testen of alle nameservers, die een AAAA-record met IPv6-adres hebben, bereikbaar zijn via IPv6.", + "detail_web_mail_ipv6_ns_reach_label": "IPv6-bereikbaarheid van nameservers", + "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.", + "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 \u00e9\u00e9n 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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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 \u00e9\u00e9n 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 \u00e9\u00e9n 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) \u00f3f 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 \u21d2 nulscore", + "faqs_report_subtest_error": "Testfout: uitvoeringsfout tijdens testen \u21d2 nulscore", + "faqs_report_subtest_good": "Goed: geslaagd voor VEREISTE, AANBEVOLEN of OPTIONELE subtest \u21d2 eerste: volledige score / laatste twee: geen impact op score", + "faqs_report_subtest_info": "Ter informatie: gezakt voor OPTIONELE subtest \u21d2 geen impact op score", + "faqs_report_subtest_not_tested": "Niet getest, want al gezakt voor gerelateerde bovenliggende subtest \u21d2 nulscore", + "faqs_report_subtest_title": "Iconen per subtest", + "faqs_report_subtest_warning": "Waarschuwing: gezakt voor AANBEVOLEN subtest \u21d2 geen impact op score", + "faqs_report_test_bad": "Slecht: gezakt voor tenminste \u00e9\u00e9n VEREISTE subtest \u21d2 geen volledige score voor testcategorie", + "faqs_report_test_error": "Testfout: uitvoeringsfout voor tenminste \u00e9\u00e9n subtest \u21d2 geen resultaat voor testcategorie", + "faqs_report_test_good": "Goed: geslaagd voor alle subtesten \u21d2 volledige score voor testcategorie ", + "faqs_report_test_info": "Ter informatie: gezakt voor tenminste \u00e9\u00e9n OPTIONELE subtest \u21d2 volledige score voor testcategorie", + "faqs_report_test_title": "Iconen per testcategorie", + "faqs_report_test_warning": "Waarschuwing: gezakt voor tenminste \u00e9\u00e9n AANBEVOLEN subtest \u21d2 volledige score voor testcategorie ", + "faqs_report_title": "Toelichting op testrapport", + "faqs_rpki_title": "Autorisatie voor routering (RPKI)", + "faqs_starttls_title": "Beveiligd e-mailtransport (STARTTLS en DANE)", + "faqs_title": "Kennisbank", + "halloffame_champions_menu": "Kampioenen!", + "halloffame_champions_subtitle": "100% in website- \u00e9n e-mailtest", + "halloffame_champions_text": "De {{count}} onderstaande domeinnamen scoren 100% in zowel de websitetest als de e-mailtest. Leden van deze Hall of Fame mogen beide 100%-badges gebruiken.", + "halloffame_champions_title": "Hall of Fame - Kampioenen!", + "halloffame_mail_badge": "Badge met tekst: 100%-score in e-mailtest", + "halloffame_mail_menu": "E-mail", + "halloffame_mail_subtitle": "100% in e-mailtest", + "halloffame_mail_text": "De {{count}} onderstaande domeinnamen scoren 100% in de e-mailtest. Leden van deze Hall of Fame mogen de 100%-badge voor mail gebruiken.", + "halloffame_mail_title": "Hall of Fame - E-mail", + "halloffame_web_badge": "Badge met tekst: 100%-score in websitetest", + "halloffame_web_menu": "Websites", + "halloffame_web_subtitle": "100% in websitetest", + "halloffame_web_text": "De {{count}} onderstaande domeinnamen scoren 100% in de websitetest. Leden van deze Hall of Fame mogen de 100%-badge voor websites gebruiken.", + "halloffame_web_title": "Hall of Fame - Websites", + "home_pagetitle": "Test voor moderne Internetstandaarden zoals IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE.", + "home_stats_connection": "unieke verbindingen", + "home_stats_connection_items": "", + "home_stats_header": "Tests in cijfers", + "home_stats_mail": "unieke mail-domeinen", + "home_stats_mail_items": "", + "home_stats_notpassed": "0-99%:", + "home_stats_passed": "100%:", + "home_stats_website": "unieke web-domeinen", + "home_stats_website_items": "", + "home_teaser": "Moderne Internetstandaarden zorgen voor meer betrouwbaarheid en verdere groei van het Internet.
Gebruik jij ze al?", + "mail_pagetitle": "E-mailtest:", + "mail_title": "E-mailtest: {{prettyaddr}}", + "mail_tweetmessage": "De%20mailserver%20op%20{{report.domain}}%20scoort%20{{score}}%25%20in%20de%20e-mailtest%20van%20%40Internet_nl%3A", + "page_gotocontents": "Ga naar tekst-inhoud", + "page_gotofooter": "Ga naar de footer", + "page_gotomainmenu": "Ga naar het hoofd-menu", + "page_metadescription": "Test voor moderne Internetstandaarden IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI en security.txt", + "page_metakeywords": "IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, testtool, testen, check, controle, internet, internetstandaarden, open standaarden, moderne standaarden, beveiliging, security, internetbeveiliging, mail, e-mailbeveiliging, website, websitebeveiliging, internetverbinding, beveiligde verbinding, e-mailauthenticatie, encryptie, versleuteling, ciphers, cipher suites, PKI, SSL certificaat, TLS certificaat, websitecertificaat, Platform Internetstandaarden", + "page_sitedescription": "Is jouw internet up-to-date?", + "page_sitetitle": "Internet.nl", + "page404_title": "Pagina niet gevonden!", + "probes_auto_redirect": "Als de test gereed is, word je automatisch doorgestuurd naar de resultaatpagina.", + "probes_no_javascript": "Controleer of de testresultaten beschikbaar zijn. Zo niet, dan word je automatisch teruggeleid naar deze pagina.", + "probes_no_javascript_connection": "JavaScript inactief. Activeer JavaScript om de test toch uit te kunnen voeren.", + "probes_no_redirection": "Testfout. Probeer het later opnieuw, of test een andere domeinnaam.", + "probes_test_finished": "Test klaar! Resultaten beschikbaar...", + "probes_test_running": "Bezig...", + "probes_tests_description": "De onderstaande onderdelen worden getest.", + "probes_tests_duration": "Het testen duurt tussen de 5 en {{cache_ttl}} seconden.", + "results_dated_presentation": "Oude resultaatpresentatie. Doe de test opnieuw.", + "results_domain_appsecpriv_http_headers_label": "HTTP security headers", + "results_domain_appsecpriv_other_options_label": "Andere beveiligingsopties", + "results_domain_ipv6_web_server_label": "Webserver", + "results_domain_rpki_web_server_label": "Webserver", + "results_domain_tls_http_headers_label": "HTTP headers", + "results_domain_tls_https_label": "HTTP", + "results_domain_tls_tls_label": "TLS", + "results_domain_mail_ipv6_name_servers_label": "Nameservers van domein", + "results_domain_mail_rpki_name_servers_label": "Nameservers van domein", + "results_domain_mail_tls_certificate_label": "Certificaat", + "results_domain_mail_tls_dane_label": "DANE", + "results_empty_argument_alt_text": "Geen", + "results_explanation_label": "Testuitleg:", + "results_further_testing_connection_label": "Aanvullende verbindingstesten", + "results_further_testing_mail_label": "Aanvullende e-mailtesten", + "results_further_testing_web_label": "Aanvullende websitetesten", + "results_mail_auth_dkim_label": "DKIM", + "results_mail_auth_dmarc_label": "DMARC", + "results_mail_auth_spf_label": "SPF", + "results_mail_dnssec_domain_label": "E-mailadresdomein", + "results_mail_dnssec_mail_servers_label": "Mailserverdomein(en)", + "results_mail_ipv6_mail_servers_label": "Mailserver(s)", + "results_mail_rpki_mail_servers_label": "Mailserver(s)", + "results_mail_rpki_mx_name_servers_label": "Nameservers van mailserver(s)", + "results_mail_tls_starttls_label": "TLS", + "results_no_icon_detail_close": "sluit", + "results_no_icon_detail_open": "open", + "results_no_icon_status_error": "Error", + "results_no_icon_status_failed": "Gezakt", + "results_no_icon_status_info": "Informatie", + "results_no_icon_status_not_tested": "Niet-testbaar", + "results_no_icon_status_passed": "Geslaagd", + "results_no_icon_status_warning": "Suggestie", + "results_panel_button_hide": "Verberg details", + "results_panel_button_show": "Toon details", + "results_perfect_score": "Gefeliciteerd, je domeinnaam wordt spoedig in de Hall of Fame opgenomen!", + "results_permalink": "Permalink testresultaat {{permadate|date:\\'(Y-m-d H:i T)\\'}}", + "results_rerun_test": "Herhaal de test", + "results_retest_time": "Seconden tot hertest-mogelijkheid:", + "results_score_description": "Het domein {{prettyaddr}} heeft een testscore van {{score}}%.", + "results_tech_details_label": "Technische details:", + "results_test_direct": "Test direct:", + "results_test_email_label": "Test andere e-mail", + "results_test_website_label": "Test andere website", + "results_test_info": "Toelichting op testrapport", + "results_verdict_label": "Uitslag:", + "test_connipv6_failed_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", + "test_connipv6_failed_summary": "Moderne adressen niet bereikbaar (IPv6)", + "test_connipv6_info_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", + "test_connipv6_info_summary": "Moderne adressen niet bereikbaar (IPv6)", + "test_connipv6_label": "Moderne adressen bereikbaar (IPv6)", + "test_connipv6_passed_description": "Goed gedaan! Je internetprovider heeft je een modern internetadres (IPv6) gegeven. Daardoor kan je andere computers met moderne adressen bereiken.", + "test_connipv6_passed_summary": "Moderne adressen bereikbaar (IPv6)", + "test_connipv6_title": "Moderne adressen bereikbaar?", + "test_connipv6_warning_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", + "test_connipv6_warning_summary": "Moderne adressen niet bereikbaar (IPv6)", + "test_connresolver_failed_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", + "test_connresolver_failed_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", + "test_connresolver_info_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", + "test_connresolver_info_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", + "test_connresolver_label": "Controle van domein-handtekeningen (DNSSEC)", + "test_connresolver_passed_description": "Goed gedaan! Domein-handtekeningen (DNSSEC) worden voor jou gecontroleerd. Daardoor ben je beschermd tegen vervalste vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen.", + "test_connresolver_passed_summary": "Domein-handtekeningen gecontroleerd (DNSSEC)", + "test_connresolver_title": "Domein-handtekeningen gecontroleerd?", + "test_connresolver_warning_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", + "test_connresolver_warning_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", + "test_error_summary": "Fout tijdens uitvoering van test!", + "test_mailauth_failed_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", + "test_mailauth_failed_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_mailauth_info_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", + "test_mailauth_info_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_mailauth_label": "Echtheidswaarmerken tegen phishing (DMARC, DKIM en SPF)", + "test_mailauth_passed_description": "Goed gedaan! Je domein bevat alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails.", + "test_mailauth_passed_summary": "Echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_mailauth_title": "Echtheidswaarmerken tegen e-mailphishing?", + "test_mailauth_warning_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", + "test_mailauth_warning_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_maildnssec_failed_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", + "test_maildnssec_failed_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", + "test_maildnssec_info_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", + "test_maildnssec_info_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", + "test_maildnssec_label": "Ondertekende domeinnamen (DNSSEC)", + "test_maildnssec_passed_description": "Goed gedaan! Je e-mailadresdomein en je mailserverdomein(en) zijn ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen daardoor betrouwbaar het IP-adres van je ontvangende mailserver(s) opvragen.", + "test_maildnssec_passed_summary": "Alle domeinnamen ondertekend (DNSSEC)", + "test_maildnssec_title": "Domeinnamen ondertekend?", + "test_maildnssec_warning_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", + "test_maildnssec_warning_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", + "test_mailipv6_failed_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_failed_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_mailipv6_info_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_info_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_mailipv6_label": "Modern adres (IPv6)", + "test_mailipv6_passed_description": "Goed gedaan! Je mailserver is bereikbaar voor verzenders met moderne adressen (IPv6). Daardoor is je mailserver volledig onderdeel van het moderne Internet.", + "test_mailipv6_passed_summary": "Bereikbaar via modern internetadres (IPv6)", + "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_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 \u00e9\u00e9n 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) \u00f3f 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)", + "test_mailrpki_label": "Route-autorisatie (RPKI)", + "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": "Helaas! Ten minste \u00e9\u00e9n 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)", + "test_mailtls_info_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_info_summary": "Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)", + "test_mailtls_invalid_null_mx_description": "Waarschuwing: Je domeinnaam adverteert een \"Null MX\" record dat aangeeft dat deze geen e-mail accepteert. Echter, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f 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: 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\u00ebn 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 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\u00ebn 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\u00ebn voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorie\u00ebn voor IPv6 en DNSSEC.", + "test_mailtls_null_mx_summary": "Goed geconfigureerd niet-ontvangend mail domein (STARTTLS en DANE)", + "test_mailtls_null_mx_with_other_mx_description": "Waarschuwing: 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.", + "test_mailtls_null_mx_with_other_mx_summary": "Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)", + "test_mailtls_null_mx_without_a_aaaa_description": "Waarschuwing: 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.", + "test_mailtls_null_mx_without_a_aaaa_summary": "Goed geconfigureerd niet-ontvangend mail domein, maar met overbodig record (STARTTLS en DANE)", + "test_mailtls_passed_description": "Goed gedaan! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) een beveiligde verbinding opzetten. STARTTLS voorkomt dat passieve aanvallers e-mails onderweg naar jou kunnen lezen. DANE beschermt tegen actieve aanvallers, die door manipulatie van het mailverkeer de STARTTLS-encryptie kunnen verwijderen.", + "test_mailtls_passed_summary": "Mailserver-verbinding voldoende beveiligd (STARTTLS en DANE)", + "test_mailtls_title": "Beveiligde mailserver-verbinding?", + "test_mailtls_unreachable_description": "Testfout: tenminste \u00e9\u00e9n van jouw ontvangende mailservers was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw mailserver(s).", + "test_mailtls_unreachable_summary": "Onbereikbare ontvangende mailserver (STARTTLS en DANE)", + "test_mailtls_untestable_description": "Testfout: tenminste \u00e9\u00e9n van jouw ontvangende mailservers was niet testbaar voor ons. Daardoor was het niet mogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door onder meer SMTP errors en geactiveerde ratelimiting-maatregelen die verbindingen tegenhouden.", + "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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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)", + "test_sitednssec_info_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_info_summary": "Domeinnaam niet ondertekend (DNSSEC)", + "test_sitednssec_label": "Ondertekende domeinnaam (DNSSEC)", + "test_sitednssec_passed_description": "Goed gedaan! Je domeinnaam is ondertekend met een geldige handtekening (DNSSEC). Daardoor zijn bezoekers die controle van domein-handtekeningen geactiveerd hebben, beschermd tegen gemanipuleerde vertaling van jouw domeinnaam naar kwaadaardige internetadressen.", + "test_sitednssec_passed_summary": "Domeinnaam ondertekend (DNSSEC)", + "test_sitednssec_title": "Domeinnaam ondertekend?", + "test_sitednssec_warning_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_warning_summary": "Domeinnaam niet ondertekend (DNSSEC)", + "test_siteipv6_failed_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_failed_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_siteipv6_info_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_info_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_siteipv6_label": "Modern adres (IPv6)", + "test_siteipv6_passed_description": "Goed gedaan! Je website is bereikbaar voor bezoekers die een moderne internetadres (IPv6) gebruiken, en daardoor volledig onderdeel van het moderne internet.", + "test_siteipv6_passed_summary": "Bereikbaar via moderne internetadres (IPv6)", + "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_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 \u00e9\u00e9n 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) \u00f3f 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)", + "test_siterpki_label": "Route-autorisatie (RPKI)", + "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": "Helaas! Ten minste \u00e9\u00e9n 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)", + "test_sitetls_info_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_info_summary": "Verbinding niet of onvoldoende beveiligd (HTTPS)", + "test_sitetls_label": "Beveiligde verbinding (HTTPS)", + "test_sitetls_passed_description": "Goed gedaan! De verbinding met je website is voldoende beveiligd (HTTPS). Gegevens die onderweg zijn tussen je website en haar bezoekers, zijn daardoor beschermd tegen afluisteren en manipulatie.", + "test_sitetls_passed_summary": "Verbinding voldoende beveiligd (HTTPS)", + "test_sitetls_title": "Beveiligde verbinding?", + "test_sitetls_unreachable_description": "Je webserver was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor HTTPS (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw webserver.", + "test_sitetls_unreachable_summary": "Onbereikbare webserver (HTTPS)", + "test_sitetls_warning_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_warning_summary": "Verbinding niet of onvoldoende beveiligd (HTTPS)", + "widget_content_notes": "

Opmerkingen

  • Logo: We raden aan om ons logo op je eigen webserver op te slaan en te gebruiken. Op die manier is er geen contact met onze webserver als je website wordt bezocht.
  • Content-Security-Policy (CSP): Indien je op je website gebruikmaakt van CSP, dan zou je internet.nl moeten toevoegen aan de regels voor form-action en eventueel ook voor img-src als je linkt naar het logo op onze webserver.
", + "widget_mail_html_block": "Test je e-mail", + "widget_mail_intro": "

E-mailtest widget

Wil je dat bezoekers van jouw website direct een e-mailtest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

", + "widget_site_html_block": "Test je website", + "widget_site_intro": "

Websitetest widget

Wil je dat bezoekers van jouw website direct een websitetest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

" +} \ No newline at end of file From 7b8157cbcb277fb0607dc96e34c68be87d18c718 Mon Sep 17 00:00:00 2001 From: stitch1 Date: Wed, 19 Feb 2025 11:09:36 +0100 Subject: [PATCH 6/9] also include tech table translations with english keys --- .../logic/internet_nl_translations.py | 40 +- .../js/translations/internet_nl.en.json | 207 ++++++++- .../js/translations/internet_nl.nl.json | 431 ++++++++++++------ 3 files changed, 526 insertions(+), 152 deletions(-) diff --git a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py index 48923d54..f80bb915 100644 --- a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py +++ b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py @@ -5,6 +5,7 @@ import tempfile from pathlib import Path from typing import Any, Dict, List, Union +from functools import lru_cache import markdown import polib @@ -67,14 +68,18 @@ def convert_internet_nl_content_to_vue(): json_content = convert_json_format(locale, structured_content) combined_vue_i18n_content += vue_i18n_content store_vue_i18n_file(f"internet_nl.{locale}.js", vue_i18n_content) - store_vue_i18n_file(f"internet_nl.{locale}.json", json.dumps(json_content, indent=2)) + # ensure ascii escaped some of the nice unicode characters and emojis. + store_vue_i18n_file(f"internet_nl.{locale}.json", json.dumps(json_content, indent=2, ensure_ascii=False)) # the locales are easiest stored together. This makes language switching a lot easier. store_vue_i18n_file("internet_nl.js", combined_vue_i18n_content) +@lru_cache(maxsize=None) def get_locale_content(locale: str) -> bytes: """ + Use LRU cache as this script is not run for long times and basically returns the same stuff per run. + A simple download and return response function. Input files: @@ -140,10 +145,41 @@ def convert_json_format(locale: str, po_content: Any) -> dict: if entry.msgid.endswith("content"): continue - content[_js_safe_msgid(entry.msgid)] = _js_safe_msgstr(entry.msgstr) + message_id = _js_safe_msgid(entry.msgid) + content[message_id] = _js_safe_msgstr(entry.msgstr) + + # todo: split tech table key into multiple keys so translations can be performed + # tech table is pipe seperated implicit translated, like this: + # "detail_mail_ipv6_mx_aaaa_tech_table": "Mail server (MX)|IPv6 address|IPv4 address", + # so we will make a translation like this: + # "detail_mail_ipv6_mx_aaaa_tech_table_mail_server_mx": "Mail server (MX)", + # "detail_mail_ipv6_mx_aaaa_tech_table_ipv6_address": "IPv6 address", + # "detail_mail_ipv6_mx_aaaa_tech_table_ipv4_address": "IPv4 address" + # MAAR je moet de keys van de ENGELSE vertaling gebruiken :) + if message_id.endswith("_tech_table"): + submessage_titles = dirty_workaround_to_still_get_tech_table_titles_in_english(message_id) + submessages = entry.msgstr.split("|") + print(f"titles: {submessage_titles}, values: {submessages}") + for submessage_title, submessage in zip(submessage_titles, submessages): + content[f"{message_id}_{_js_safe_msgid(submessage_title)}"] = _js_safe_msgstr(submessage) return content +def dirty_workaround_to_still_get_tech_table_titles_in_english(message_id: str): + # this prevents some parameterized calls and even more spagetti. This is the 'lunch' version. + # given that all translations will be json in the future, this approach is somewhat 'ok' + # always has to be english. + raw_content: bytes = get_locale_content('en') + # with lru cache it's fast enough :) + structured_content = load_as_po_file(raw_content) + + for entry in structured_content: + # print(entry.msgid) + if _js_safe_msgid(entry.msgid) == message_id: + return entry.msgstr.split("|") + + return [] + def convert_vue_i18n_format(locale: str, po_content: Any) -> str: """ diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json index 37b1cc8e..1b5b627d 100644 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json @@ -42,11 +42,15 @@ "detail_conn_dnssec_validation_exp": "We check if the resolvers that you use validate the DNSSEC signatures of our domain name. Resolvers are usually provided by your internet provider. Alternatively you can configure resolvers from another DNS provider. You can even use your own locally installed resolver. Although validation is done in the resolver, the communication from the resolver back to your device (referred to as \\'last mile\\') could still be tampered with by an attacker. Thus the most secure way is to validate close to the end user device (e.g. by using a locally installed resolver), or make sure that the channel between your resolver and your end user device is secured/trusted.", "detail_conn_dnssec_validation_label": "DNSSEC validation", "detail_conn_dnssec_validation_tech_table": "DNS provider", + "detail_conn_dnssec_validation_tech_table_dns_provider": "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 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_tech_table_anonymized_ipv6_address": "Anonymized IPv6 address", + "detail_conn_ipv6_connection_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_connection_tech_table_internet_provider": "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 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.", @@ -56,6 +60,9 @@ "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_tech_table_anonymized_ipv4_address": "Anonymized IPv4 address", + "detail_conn_ipv6_ipv4_conn_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_ipv4_conn_tech_table_internet_provider": "Internet provider", "detail_conn_ipv6_ipv4_conn_verdict_bad": "You are not able to reach computers via DNS on their IPv4 address.", "detail_conn_ipv6_ipv4_conn_verdict_good": "You are able to reach computers via DNS on their IPv4 address.", "detail_conn_ipv6_privacy_exp": "We check if your device uses IPv6 Privacy Extensions for SLAAC (or another IPv6 configuration process than SLAAC) in order to prevent leakage of its potentially privacy sensitive MAC address to computers it connects with over IPV6.", @@ -74,6 +81,8 @@ "detail_mail_auth_dmarc_exp": "We check if DMARC is available for your domain. A receiving mail server mayuse your DMARC policy to evaluate how to handle a mail with your domain assender that could not be authenticated with both DKIM and SPF, and it mayuse your mail address from the DMARC record to provide feedback reports onthe authentication to you. Having more than one DMARC record in the same domainis not valid and will lead to a test failure.Note: DMARC requires the SPFdomain (envelope sender, i.e. return-path that shows up in MAIL FROM) andthe DKIM domain (d=) to align with the mail body domain (From:).", "detail_mail_auth_dmarc_label": "DMARC existence", "detail_mail_auth_dmarc_tech_table": "DMARC record|Found on", + "detail_mail_auth_dmarc_tech_table_dmarc_record": "DMARC record", + "detail_mail_auth_dmarc_tech_table_found_on": "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;\"
", @@ -85,11 +94,14 @@ "detail_mail_auth_spf_exp": "We check if your domain has an SPF record. A receiving mail server can use the IP addresses in your SPF record to authenticate the sending mail server of a received email with your domain as sender. The accompanying policy can be used to take appropriate action if authentication fails. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", "detail_mail_auth_spf_label": "SPF existence", "detail_mail_auth_spf_tech_table": "SPF record", + "detail_mail_auth_spf_tech_table_spf_record": "SPF record", "detail_mail_auth_spf_verdict_bad": "Your domain does not have a valid SPF record.", "detail_mail_auth_spf_verdict_good": "Your domain has an SPF record.", "detail_mail_auth_spf_policy_exp": "We check if the syntax of your SPF record is correct and if it contains a sufficiently strict policy i.e. ~all (softfail) or -all (fail) in order to prevent abuse by phishers and spammers. To be effective against abuse of your domain, a liberal policy i.e. +all (pass) or ?all (neutral) is insufficient. If all is missing and a redirect modifier is not present in your SPF record, the default is ?all.

We also follow include and redirect for valid SPF records. In addition, we check that your SPF record does not exceed the allowed number of 10 DNS lookups making it ineffective. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. While the SPF terms all, ip4, ip6 and exp do not count as DNS lookups.

Note that if the include or redirect domain consists of macros, we will not follow them as we do not have the necessary information from an actual mail or mail server connection to expand those macros. This means that we do not evaluate the outcome of macros. Moreover, we do not count DNS lookups caused by macros to determine whether the allowed number of DNS lookups has been exceeded.

For sending domains, using ~all (softfail) instead of -all (fail) is usually preferred. This is because when SPF authentication fails with an SPF fail, a receiving mail server may already block the connection without evaluating the DKIM signature and DMARC policy. This can lead to falsely blocked mails (e.g. when mails are automatically forwarded by the receiving mail server to another receiving mail server). Note that a triggered SPF softfail still ensures that a strict DMARC policy protects your domain if DKIM authentication also fails.

For no-mail domains see the good practice on explanation of the \"DMARC policy\" subtest.", "detail_mail_auth_spf_policy_label": "SPF policy", "detail_mail_auth_spf_policy_tech_table": "Domain|SPF record", + "detail_mail_auth_spf_policy_tech_table_domain": "Domain", + "detail_mail_auth_spf_policy_tech_table_spf_record": "SPF record", "detail_mail_auth_spf_policy_verdict_all": "Your SPF policy is not sufficiently strict.", "detail_mail_auth_spf_policy_verdict_bad": "Your SPF policy is not syntactically correct.", "detail_mail_auth_spf_policy_verdict_good": "Your SPF policy is sufficiently strict.", @@ -99,6 +111,8 @@ "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_tech_table_email_address_domain": "Email address domain", + "detail_mail_dnssec_exists_tech_table_registrar": "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.", @@ -106,6 +120,8 @@ "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_tech_table_domain_of_mail_server_mx": "Domain of mail server (MX)", + "detail_mail_dnssec_mx_exists_tech_table_dnssec_existent": "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.", @@ -119,18 +135,25 @@ "detail_mail_dnssec_mx_valid_exp": "We check if the domains of your receiving mail servers (MX), more specifically their SOA records, are signed with a valid signature making them \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", "detail_mail_dnssec_mx_valid_label": "DNSSEC validity", "detail_mail_dnssec_mx_valid_tech_table": "Domain of mail server (MX)|Status", + "detail_mail_dnssec_mx_valid_tech_table_domain_of_mail_server_mx": "Domain of mail server (MX)", + "detail_mail_dnssec_mx_valid_tech_table_status": "Status", "detail_mail_dnssec_mx_valid_verdict_bad": "At least one of your signed mail server domains is \\'bogus\\', because its DNSSEC signature is not valid. Either someone manipulated the responses from its name servers, or your mail server domain has serious DNSSEC configuration errors. The latter makes your receiving mail server unreachable for any sending mail server that validates DNSSEC signatures. You should contact the name server operator (often your mail provider) as soon as possible.", "detail_mail_dnssec_mx_valid_verdict_good": "All your signed mail server domains are secure, because their DNSSEC signatures are valid.", "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "At least one of your mail server domains is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", "detail_mail_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", "detail_mail_dnssec_valid_label": "DNSSEC validity", "detail_mail_dnssec_valid_tech_table": "Email address domain|Status", + "detail_mail_dnssec_valid_tech_table_email_address_domain": "Email address domain", + "detail_mail_dnssec_valid_tech_table_status": "Status", "detail_mail_dnssec_valid_verdict_bad": "Your email address domain is \\'bogus\\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", "detail_mail_dnssec_valid_verdict_good": "Your email address domain is secure, because its DNSSEC signature is valid.", "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Your email address domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", "detail_mail_ipv6_mx_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for every receiving mail server (MX). In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.", "detail_mail_ipv6_mx_aaaa_label": "IPv6 addresses for mail server(s)", "detail_mail_ipv6_mx_aaaa_tech_table": "Mail server (MX)|IPv6 address|IPv4 address", + "detail_mail_ipv6_mx_aaaa_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv6_address": "IPv6 address", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv4_address": "IPv4 address", "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.", @@ -142,30 +165,46 @@ "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_ipv6_mx_reach_tech_table_unreachable_ipv6_address": "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.", "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_tech_table_mail_server": "Mail server", + "detail_mail_rpki_exists_tech_table_ip_address": "IP address", + "detail_mail_rpki_exists_tech_table_rpki_route_origin_authorization": "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.", "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_tech_table_name_server_of_mx": "Name server of MX", + "detail_mail_rpki_mx_ns_exists_tech_table_ip_address": "IP address", + "detail_mail_rpki_mx_ns_exists_tech_table_rpki_route_origin_authorization": "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.

1\u2024 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\u2024 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\u2024 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_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_tech_table_name_server_of_mx": "Name server of MX", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_mx_ns_valid_tech_table_rpki_origin_validation_state": "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 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.

1\u2024 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\u2024 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\u2024 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_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_tech_table_mail_server": "Mail server", + "detail_mail_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_valid_tech_table_rpki_origin_validation_state": "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 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.", @@ -173,27 +212,40 @@ "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", "detail_mail_tls_cert_hostmatch_tech_table": "Mail server (MX)|Unmatched domains on certificate", + "detail_mail_tls_cert_hostmatch_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Unmatched domains on certificate", "detail_mail_tls_cert_hostmatch_verdict_bad": "The domain name of at least one of your mail servers does not match the domain name on the mail server certificate.", "detail_mail_tls_cert_hostmatch_verdict_good": "The domain names of all your mail servers match the domain names on your mail server certificates.", - "detail_mail_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 \u2013 3071 bit
  • Insufficient: Less than 2048 bit
", + "detail_mail_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
", "detail_mail_tls_cert_pubkey_label": "Public key of certificate", "detail_mail_tls_cert_pubkey_tech_table": "Mail server (MX)|Affected signature parameters|Status", + "detail_mail_tls_cert_pubkey_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_pubkey_tech_table_affected_signature_parameters": "Affected signature parameters", + "detail_mail_tls_cert_pubkey_tech_table_status": "Status", "detail_mail_tls_cert_pubkey_verdict_bad": "The digital signature of at least one of your mail server certificates uses insufficiently secure parameters.", "detail_mail_tls_cert_pubkey_verdict_good": "The digital signatures of all your mail server certificates use secure parameters.", "detail_mail_tls_cert_pubkey_verdict_phase_out": "The digital signature of at least one of your mail server certificates uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", "detail_mail_tls_cert_signature_exp": "

We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", "detail_mail_tls_cert_signature_label": "Signature of certificate", "detail_mail_tls_cert_signature_tech_table": "Mail server (MX)|Affected hash algorithm|Status", + "detail_mail_tls_cert_signature_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_signature_tech_table_affected_hash_algorithm": "Affected hash algorithm", + "detail_mail_tls_cert_signature_tech_table_status": "Status", "detail_mail_tls_cert_signature_verdict_bad": "At least one of your mail server certificates is signed using a hash algorithm that is insufficiently secure.", "detail_mail_tls_cert_signature_verdict_good": "All your mail server certificates are signed using a secure hash algorithm.", "detail_mail_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your mail server certificates.

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

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

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

Requirement level: Optional", "detail_mail_tls_cert_trust_label": "Trust chain of certificate", "detail_mail_tls_cert_trust_tech_table": "Mail server (MX)|Untrusted certificate chain", + "detail_mail_tls_cert_trust_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_trust_tech_table_untrusted_certificate_chain": "Untrusted certificate chain", "detail_mail_tls_cert_trust_verdict_bad": "The trust chain of at least one of your mail server certificates is not complete and/or not signed by a trusted root certificate authority.", "detail_mail_tls_cert_trust_verdict_good": "The trust chain of all your mail server certificates is complete and signed by a trusted root certificate authority.", "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "First found affected cipher pair", + "detail_mail_tls_cipher_order_tech_table_violated_rule_ii_b": "Violated rule # (\\'II-B\\')", "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.", @@ -202,33 +254,47 @@ "detail_mail_tls_ciphers_exp": "

We check if your receiving mail servers (MX) only support secure, i.e. \\'Good\\' and/or \\'Sufficient\\', ciphers (also known as algorithm selections).

To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \\'cipher suite\\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \\'cipher suite\\' ambiguous, NCSC-NL uses the term \\'algorithm selection\\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \\'Good\\', \\'Sufficient\\' and \\'Phase out\\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \\'IT Security Guidelines for Transport Layer Security (TLS)\\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \\'Phase out\\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", "detail_mail_tls_ciphers_label": "Ciphers (Algorithm selections)", "detail_mail_tls_ciphers_tech_table": "Mail server (MX)|First found affected cipher|Status", + "detail_mail_tls_ciphers_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_ciphers_tech_table_first_found_affected_cipher": "First found affected cipher", + "detail_mail_tls_ciphers_tech_table_status": "Status", "detail_mail_tls_ciphers_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure ciphers.", "detail_mail_tls_ciphers_verdict_good": "All your mail servers support secure ciphers only.", "detail_mail_tls_ciphers_verdict_phase_out": "At least one of your mail servers supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", "detail_mail_tls_compression_exp": "

We check if your receiving mail servers (MX) support TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression
  • Insufficient: TLS compression
", "detail_mail_tls_compression_label": "TLS compression", "detail_mail_tls_compression_tech_table": "Mail server (MX)|TLS compression", + "detail_mail_tls_compression_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_compression_tech_table_tls_compression": "TLS compression", "detail_mail_tls_compression_verdict_bad": "At least on of your mail servers supports TLS compression, which is not secure.", "detail_mail_tls_compression_verdict_good": "All your mail servers do not support TLS compression.", "detail_mail_tls_dane_exists_exp": "We check if the name servers of each of your receiving mail servers (MX) provide a TLSA record for DANE.

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

Note that the test ignores TLSA records of the types PKIX-TA(0) or PKIX-EE(1) as these should not be used for receiving mail servers.

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

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, Appendix A, under \\'Certificate pinning and DANE\\' (in English).", "detail_mail_tls_dane_exists_label": "DANE existence", "detail_mail_tls_dane_exists_tech_table": "Mail server (MX)|DANE TLSA record existent", + "detail_mail_tls_dane_exists_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA record existent", "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.

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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_dane_rollover_tech_table_dane_rollover_scheme": "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.", "detail_mail_tls_dane_rollover_verdict_good": "All your mail server domains have an active DANE scheme for a reliable rollover of certificate keys.", "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_dane_valid_tech_table_dane_tlsa_record_valid": "DANE TLSA record valid", "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_fs_params_tech_table_affected_parameters": "Affected parameters", + "detail_mail_tls_fs_params_tech_table_security_level": "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.", "detail_mail_tls_fs_params_verdict_good": "All your mail servers support secure parameters for Diffie-Hellman key exchange.", "detail_mail_tls_fs_params_verdict_na": "This subtest is not applicable as your mail servers do not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.", @@ -236,28 +302,38 @@ "detail_mail_tls_kex_hash_func_exp": "

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

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "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_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", "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mail server (MX)|OCSP stapling", + "detail_mail_tls_ocsp_stapling_tech_table_outdated_text_test_not_used_mail_server_mx": "OUTDATED TEXT; TEST NOT USED
Mail server (MX)", + "detail_mail_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", "detail_mail_tls_ocsp_stapling_verdict_bad": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers supports OCSP stapling but responds with invalid data", "detail_mail_tls_ocsp_stapling_verdict_good": "OUTDATED TEXT; TEST NOT USED
Your mail servers support OCSP stapling.", "detail_mail_tls_ocsp_stapling_verdict_ok": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers does not support OCSP stapling.", "detail_mail_tls_renegotiation_client_exp": "

We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX).

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", "detail_mail_tls_renegotiation_client_label": "Client-initiated renegotiation", "detail_mail_tls_renegotiation_client_tech_table": "Mail server (MX)|Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "Client-initiated renegotiation", "detail_mail_tls_renegotiation_client_verdict_bad": "At least one of your mail servers allows for client-initiated renegotiation, which could have negative impact on the availability of your mail server.", "detail_mail_tls_renegotiation_client_verdict_good": "All your mail servers do not allow for client-initiated renegotiation.", "detail_mail_tls_renegotiation_secure_exp": "

We check if your mail servers (MX) support secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", "detail_mail_tls_renegotiation_secure_tech_table": "Mail server (MX)|Secure renegotiation", + "detail_mail_tls_renegotiation_secure_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", "detail_mail_tls_renegotiation_secure_verdict_bad": "At least one of your mail servers supports insecure renegotiation, which is obviously not secure.", "detail_mail_tls_renegotiation_secure_verdict_good": "All your mail servers support secure renegotiation.", "detail_mail_tls_starttls_exists_exp": "We check if your receiving mail servers (MX) support STARTTLS. If so, we also check in the subtests of this test category whether STARTTLS is configured sufficiently secure.

Because of performance reasons at most ten mail servers over either IPv6 or IPv4 are tested for STARTTLS and DANE.

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

Non-receiving domain:

  1. Null MX: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use \"Null MX\" (RFC 7505). Note that a \"Null MX record\" should not be combined with a normal MX record that is pointing to a mail host.

  2. No MX: In case your domain does not have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even not an \"Null MX\" record).

  3. If we detect any of the above two cases, the subtests in the STARTTLS and DANE category are not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. Other subtests of the email test (e.g. for DMARC) are still applicable.

  4. Note that having a \"Null MX\" record or no MX record could also impact sending mail, because receiving servers may reject email that has an invalid return address.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", "detail_mail_tls_starttls_exists_label": "STARTTLS available", "detail_mail_tls_starttls_exists_tech_table": "Mail server (MX)|STARTTLS", + "detail_mail_tls_starttls_exists_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_starttls_exists_tech_table_starttls": "STARTTLS", "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.", @@ -270,12 +346,17 @@ "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", + "detail_mail_tls_version_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_version_tech_table_tls_versions": "TLS versions", + "detail_mail_tls_version_tech_table_status": "Status", "detail_mail_tls_version_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure TLS versions.", "detail_mail_tls_version_verdict_good": "All your mail servers support secure TLS versions only.", "detail_mail_tls_version_verdict_phase_out": "At least one of your mail servers supports one or more TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", "detail_mail_tls_zero_rtt_exp": "

We check if your mail servers (MX) support Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your mail servers do not support TLS 1.3, the test is not applicable.For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLSsession is initiated. The amount ofearly datasupport indicated by themail server is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theEHLO command before the TLS handshake but after the STARTTLS command(i.e. no round trips (0-RTT) needed before application data to the server).If the TLS handshake is completed and the mail server responds,then the mail server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", "detail_mail_tls_zero_rtt_label": "0-RTT", "detail_mail_tls_zero_rtt_tech_table": "Mail server (MX)|0-RTT", + "detail_mail_tls_zero_rtt_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_zero_rtt_tech_table_0_rtt": "0-RTT", "detail_mail_tls_zero_rtt_verdict_bad": "At least one of your mail servers supports 0-RTT, which is not secure.", "detail_mail_tls_zero_rtt_verdict_good": "None of your mail servers support 0-RTT.", "detail_mail_tls_zero_rtt_verdict_na": "This subtest is not applicable as your mail servers do not support TLS 1.3.", @@ -360,38 +441,52 @@ "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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_csp_tech_table_findings": "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 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_referrer_policy_tech_table_findings": "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 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_securitytxt_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_x_content_type_tech_table_x_content_type_options_value": "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).

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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_x_frame_tech_table_x_frame_options_value": "X-Frame-Options value", "detail_web_appsecpriv_http_x_frame_verdict_bad": "Your web server does not offer securely configured X-Frame-Options.", "detail_web_appsecpriv_http_x_frame_verdict_good": "Your web server offers securely configured X-Frame-Options.", "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We check if your web server provides an HTTP header for X-XSS-Protection that has a sufficiently secure value (i.e. 1 or 1; mode=block). This HTTP header can be used to activate the protection filter of browsers against reflective cross-site scripting (XSS) attacks. Valid values for the X-XSS-Protection header are:

  • 0 disables the XSS filter. This value should NOT be used.
  • 1 enables the XSS filter. If a cross-site scripting attack is detected, the browser will sanitize the script and remove the unsafe parts. This value is usually the default in browsers when a website does not offer an X-XSS-Protection header.
  • 1; mode=block enables the XSS filter. If a cross-site scripting attack is detected, the browser will block the response and prevent rendering the page. This is the recommended value.

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

Requirement level: Recommended", "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|X-XSS-Protection value", + "detail_web_appsecpriv_http_x_xss_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", + "detail_web_appsecpriv_http_x_xss_tech_table_x_xss_protection_value": "X-XSS-Protection value", "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your web server does not offer securely configured X-XSS-Protection.", "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your web server offers securely configured X-XSS-Protection.", "detail_web_dnssec_exists_exp": "We check if your domain, more specifically its SOA record, is DNSSEC signed.

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_web_dnssec_exists_label": "DNSSEC existence", "detail_web_dnssec_exists_tech_table": "Domain|Registrar", + "detail_web_dnssec_exists_tech_table_domain": "Domain", + "detail_web_dnssec_exists_tech_table_registrar": "Registrar", "detail_web_dnssec_exists_verdict_bad": "Your domain is insecure, because it is not DNSSEC signed.", "detail_web_dnssec_exists_verdict_good": "Your domain is DNSSEC signed.", "detail_web_dnssec_exists_verdict_resolver_error": "Unfortunately an error occurred in Internet.nl\\'s resolver. Please contact us.", @@ -399,15 +494,20 @@ "detail_web_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", "detail_web_dnssec_valid_label": "DNSSEC validity", "detail_web_dnssec_valid_tech_table": "Domain|Status", + "detail_web_dnssec_valid_tech_table_domain": "Domain", + "detail_web_dnssec_valid_tech_table_status": "Status", "detail_web_dnssec_valid_verdict_bad": "Your domain is \\'bogus\\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", "detail_web_dnssec_valid_verdict_good": "Your domain is secure, because its DNSSEC signature is valid.", "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Your domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", "detail_web_ipv6_web_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for your web server.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.", "detail_web_ipv6_web_aaaa_label": "IPv6 addresses for web server", "detail_web_ipv6_web_aaaa_tech_table": "Web server|IPv6 address|IPv4 address", + "detail_web_ipv6_web_aaaa_tech_table_web_server": "Web server", + "detail_web_ipv6_web_aaaa_tech_table_ipv6_address": "IPv6 address", + "detail_web_ipv6_web_aaaa_tech_table_ipv4_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 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 \u2013 299) and redirection messages (300 \u2013 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_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 via IPv4 are not the same via IPv6.", "detail_web_ipv6_web_ipv46_verdict_good": "Your website via IPv6 looks identical via IPv4.", @@ -416,17 +516,26 @@ "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_tech_table_web_server": "Web server", + "detail_web_ipv6_web_reach_tech_table_unreachable_ipv6_address": "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.", "detail_web_rpki_exists_label": "Route Origin Authorisation existence", "detail_web_rpki_exists_tech_table": "Web server|IP address|RPKI Route Origin Authorization", + "detail_web_rpki_exists_tech_table_web_server": "Web server", + "detail_web_rpki_exists_tech_table_ip_address": "IP address", + "detail_web_rpki_exists_tech_table_rpki_route_origin_authorization": "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.

1\u2024 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\u2024 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\u2024 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_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_tech_table_web_server": "Web server", + "detail_web_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_rpki_valid_tech_table_rpki_origin_validation_state": "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 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.", @@ -434,27 +543,40 @@ "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", "detail_web_tls_cert_hostmatch_tech_table": "Web server IP address|Unmatched domains on certificate", + "detail_web_tls_cert_hostmatch_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Unmatched domains on certificate", "detail_web_tls_cert_hostmatch_verdict_bad": "The domain name of your website does not match the domain name on your website certificate.", "detail_web_tls_cert_hostmatch_verdict_good": "The domain name of your website matches the domain name on your website certificate.", - "detail_web_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 \u2013 3071 bit
  • Insufficient: Less than 2048 bit
", + "detail_web_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
", "detail_web_tls_cert_pubkey_label": "Public key of certificate", "detail_web_tls_cert_pubkey_tech_table": "Web server IP address|Affected signature parameters|Status", + "detail_web_tls_cert_pubkey_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_pubkey_tech_table_affected_signature_parameters": "Affected signature parameters", + "detail_web_tls_cert_pubkey_tech_table_status": "Status", "detail_web_tls_cert_pubkey_verdict_bad": "The digital signature of your website certificate uses insufficiently secure parameters.", "detail_web_tls_cert_pubkey_verdict_good": "The digital signature of your website certificate uses secure parameters.", "detail_web_tls_cert_pubkey_verdict_phase_out": "The digital signature of your website certificate uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", "detail_web_tls_cert_signature_exp": "

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", "detail_web_tls_cert_signature_label": "Signature of certificate", "detail_web_tls_cert_signature_tech_table": "Web server IP address|Affected hash algorithm|Status", + "detail_web_tls_cert_signature_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_signature_tech_table_affected_hash_algorithm": "Affected hash algorithm", + "detail_web_tls_cert_signature_tech_table_status": "Status", "detail_web_tls_cert_signature_verdict_bad": "Your website certificate is signed using a hash algorithm that is insufficiently secure.", "detail_web_tls_cert_signature_verdict_good": "Your website certificate is signed using a secure hash algorithm.", "detail_web_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your website certificate.

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

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B3-4 (in English).", "detail_web_tls_cert_trust_label": "Trust chain of certificate", "detail_web_tls_cert_trust_tech_table": "Web server IP address|Untrusted certificate chain", + "detail_web_tls_cert_trust_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_trust_tech_table_untrusted_certificate_chain": "Untrusted certificate chain", "detail_web_tls_cert_trust_verdict_bad": "The trust chain of your website certificate is not complete and/or not signed by a trusted root certificate authority.", "detail_web_tls_cert_trust_verdict_good": "The trust chain of your website certificate is complete and signed by a trusted root certificate authority.", "detail_web_tls_cipher_order_exp": "We check if your web server enforces its own cipher preference (\\'I\\'), and offers ciphers in accordance with the prescribed ordering (\\'II\\').

When your web server supports \\'Good\\' ciphers only, this subtest is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The web server enforces its own cipher preference while negotiating with a web browser, and does not accept any preference of the web browser;

II. Prescribed ordering: Ciphers are offered by the web server 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_web_tls_cipher_order_label": "Cipher order", "detail_web_tls_cipher_order_tech_table": "Web server IP address|First found affected cipher pair|Violated rule # (\\'II-B\\')", + "detail_web_tls_cipher_order_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "First found affected cipher pair", + "detail_web_tls_cipher_order_tech_table_violated_rule_ii_b": "Violated rule # (\\'II-B\\')", "detail_web_tls_cipher_order_verdict_bad": "Your web server does not enforce its own cipher preference (\\'I\\').", "detail_web_tls_cipher_order_verdict_good": "Your web server enforces its own cipher preference (\\'I\\'), and offers ciphers in accordance with the prescribed ordering (\\'II\\').", "detail_web_tls_cipher_order_verdict_na": "This subtest is not applicable as your web server supports \\'Good\\' ciphers only.", @@ -463,33 +585,47 @@ "detail_web_tls_ciphers_exp": "

We check if your web server only supports secure, i.e. \\'Good\\' and/or \\'Sufficient\\', ciphers (also known as algorithm selections).

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \\'cipher suite\\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \\'cipher suite\\' ambiguous, NCSC-NL uses the term \\'algorithm selection\\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \\'Good\\', \\'Sufficient\\' and \\'Phase out\\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \\'IT Security Guidelines for Transport Layer Security (TLS)\\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \\'Phase out\\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", "detail_web_tls_ciphers_label": "Ciphers (Algorithm selections)", "detail_web_tls_ciphers_tech_table": "Web server IP address|Affected ciphers|Status", + "detail_web_tls_ciphers_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_ciphers_tech_table_affected_ciphers": "Affected ciphers", + "detail_web_tls_ciphers_tech_table_status": "Status", "detail_web_tls_ciphers_verdict_bad": "Your web server supports one or more insufficiently secure ciphers.", "detail_web_tls_ciphers_verdict_good": "Your web server supports secure ciphers only.", "detail_web_tls_ciphers_verdict_phase_out": "Your web server supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", "detail_web_tls_compression_exp": "

We check if your web server supports TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
", "detail_web_tls_compression_label": "TLS compression", "detail_web_tls_compression_tech_table": "Web server IP address|TLS compression", + "detail_web_tls_compression_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_compression_tech_table_tls_compression": "TLS compression", "detail_web_tls_compression_verdict_bad": "Your web server supports TLS compression, which is not secure.", "detail_web_tls_compression_verdict_good": "Your web server does not support TLS compression.", "detail_web_tls_dane_exists_exp": "We check if the name servers of your website domain contain a correctly signed TLSA record for DANE.

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the website domain, or if there are DANE related DNSSEC issues (e.g. no proof of \\'Denial of Existence\\').

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

Requirement level: Optional", "detail_web_tls_dane_exists_label": "DANE existence", "detail_web_tls_dane_exists_tech_table": "Web server IP address|DANE TLSA record existent", + "detail_web_tls_dane_exists_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA record existent", "detail_web_tls_dane_exists_verdict_bad": "Your website domain does not contain a TLSA record for DANE.", "detail_web_tls_dane_exists_verdict_bogus": "Your website domain does not provide DNSSEC proof that DANE TLSA records do not exist. You should ask your name server operator to fix this issue.", "detail_web_tls_dane_exists_verdict_good": "Your website domain contains a TLSA record for DANE.", "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", + "detail_web_tls_dane_rollover_tech_table_dane_rollover_scheme": "DANE rollover scheme", "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", "detail_web_tls_dane_valid_exp": "We check if the DANE fingerprint presented by your domain is valid for your web certificate.

DANE allows you to publish information about your website certificate in a special DNS record, called TLSA record. Clients, like web browsers, can check the authenticity of your certificate not only through the certificate authority but also through the TLSA record. A client can also use the TLSA record as a signal to only use HTTPS (and not HTTP). DNSSEC is preconditional for DANE. Unfortunately not much web browsers are supporting DANE validation yet.

Requirement level: Recommended (only if subtest for \\'DANE existence\\' is passed)", "detail_web_tls_dane_valid_label": "DANE validity", "detail_web_tls_dane_valid_tech_table": "Web server IP address|DANE TLSA record valid", + "detail_web_tls_dane_valid_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Key exchange parameters", "detail_web_tls_fs_params_tech_table": "Web server IP address|Affected parameters|Status", + "detail_web_tls_fs_params_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_fs_params_tech_table_affected_parameters": "Affected parameters", + "detail_web_tls_fs_params_tech_table_status": "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 web server does not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.", @@ -497,17 +633,23 @@ "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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_http_compression_tech_table_http_compression": "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 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_https_exists_tech_table_https_existent": "HTTPS existent", "detail_web_tls_https_exists_verdict_bad": "Your website does not offer HTTPS.", "detail_web_tls_https_exists_verdict_good": "Your website offers HTTPS.", "detail_web_tls_https_exists_verdict_other": "Your web server is unreachable.", - "detail_web_tls_https_forced_exp": "We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

  • http://example.nl \u21d2 https://example.nl \u21d2 https://www.example.nl
  • http://www.example.nl \u21d2 https://www.example.nl

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See \\'Web application guidelines, detailed version\\' from NCSC-NL, guideline U/WA.05 (in Dutch).", + "detail_web_tls_https_forced_exp": "We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See \\'Web application guidelines, detailed version\\' from NCSC-NL, guideline U/WA.05 (in Dutch).", "detail_web_tls_https_forced_label": "HTTPS redirect", "detail_web_tls_https_forced_tech_table": "Web server IP address|HTTPS redirect", + "detail_web_tls_https_forced_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_https_forced_tech_table_https_redirect": "HTTPS redirect", "detail_web_tls_https_forced_verdict_bad": "Your web server does offer support for both HTTP and HTTPS, but does not automatically redirect visitors from HTTP to HTTPS on the same domain.", "detail_web_tls_https_forced_verdict_good": "Your web server automatically redirects visitors from HTTP to HTTPS on the same domain.", "detail_web_tls_https_forced_verdict_no_https": "This test could not be performed, because your web server offers either no HTTPS or HTTPS with a very outdated, insecure TLS configuration.", @@ -515,63 +657,90 @@ "detail_web_tls_https_hsts_exp": "We check if your web server supports HSTS.

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period of at least 1 year (max-age=31536000) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired.

The test does not check whether preload is used and whether the domain is included in the HSTS Preload List.

Deployment recommendation

HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will not be reachable by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy.

Therefore we advise you to follow the implementation steps below:

  1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);

  2. Increase the HSTS cache validity period in the stages below. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.

  3. Start with 5 minutes (max-age=300);

  4. Increase it to 1 week (max-age=604800);
  5. Increase it to 1 month (max-age=2592000);

  6. Increase it to 1 year (max-age=31536000) or more.

  7. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use includeSubDomains if you are fully sure that all the (nested) subdomains of your domain properly support HTTPS now and in the future.

  8. Use preload only if you are very sure that you want your domain to be included in the HSTS Preload List. HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.

See \\'Web application guidelines, detailed version\\' from NCSC-NL, guideline U/WA.05 (in Dutch).", "detail_web_tls_https_hsts_label": "HSTS", "detail_web_tls_https_hsts_tech_table": "Web server IP address|HSTS policy", + "detail_web_tls_https_hsts_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_https_hsts_tech_table_hsts_policy": "HSTS policy", "detail_web_tls_https_hsts_verdict_bad": "Your web server does not offer an HSTS policy.", "detail_web_tls_https_hsts_verdict_good": "Your web server offers an HSTS policy.", "detail_web_tls_https_hsts_verdict_other": "Your web server offers an HSTS policy with a cache validity period (max-age) that is not sufficiently long (i.e. less than 1 year).", "detail_web_tls_kex_hash_func_exp": "

We check if your web server supports secure hash functions to create the digital signature during key exchange.

The web server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The web server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", "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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "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 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", "detail_web_tls_ocsp_stapling_tech_table": "Web server IP address|OCSP stapling", + "detail_web_tls_ocsp_stapling_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", "detail_web_tls_ocsp_stapling_verdict_bad": "Your web server supports OCSP stapling but the data in the response is not valid.", "detail_web_tls_ocsp_stapling_verdict_good": "Your web server supports OCSP stapling and the data in the response is valid.", "detail_web_tls_ocsp_stapling_verdict_ok": "Your web server does not support OCSP stapling.", "detail_web_tls_renegotiation_client_exp": "

We check if a client (usually a web browser) can initiate a renegotiation with your web server.

Allowing clients to initiate renegotiation is generally not necessary and opens a web server to DoS attacks inside a TLS connection. An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", "detail_web_tls_renegotiation_client_label": "Client-initiated renegotiation", "detail_web_tls_renegotiation_client_tech_table": "Web server IP address|Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "Client-initiated renegotiation", "detail_web_tls_renegotiation_client_verdict_bad": "Your web server allows for client-initiated renegotiation, which could have negative impact on the availability of your website.", "detail_web_tls_renegotiation_client_verdict_good": "Your web server does not allow for client-initiated renegotiation.", "detail_web_tls_renegotiation_secure_exp": "

We check if your web server supports secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", "detail_web_tls_renegotiation_secure_tech_table": "Web server IP address|Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", "detail_web_tls_renegotiation_secure_verdict_bad": "Your web server supports insecure renegotiation, which is obviously not secure.", "detail_web_tls_renegotiation_secure_verdict_good": "Your web server supports secure renegotiation.", "detail_web_tls_version_exp": "

We check if your web server supports secure TLS versions only.

A web server may support more than one TLS version.

Note that browser makers have announced that they will stop supporting TLS 1.1 and 1.0. This will cause websites that do not support TLS 1.2 and/or 1.3 to be unreachable.

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_web_tls_version_label": "TLS version", "detail_web_tls_version_tech_table": "Web server IP address|TLS version|Status", + "detail_web_tls_version_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_version_tech_table_tls_version": "TLS version", + "detail_web_tls_version_tech_table_status": "Status", "detail_web_tls_version_verdict_bad": "Your web server supports insufficiently secure TLS versions.", "detail_web_tls_version_verdict_good": "Your web server supports secure TLS versions only.", "detail_web_tls_version_verdict_phase_out": "Your web server supports TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", "detail_web_tls_zero_rtt_exp": "

We check if your web server supports Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the firsthandshake message. 0-RTT does not provide protection against replay attacks atthe TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable.For web servers that support TLS 1.3, the index / page of the website isfetched using TLS 1.3 and the amount ofearly datasupport indicated by theserver is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theHTTP request before the TLS handshake (i.e. no round trips (0-RTT) neededbefore application data to the server). If the TLS handshake is completed andthe web server responds with anynon-HTTP 425 Too Earlyresponse, then the web server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", "detail_web_tls_zero_rtt_label": "0-RTT", "detail_web_tls_zero_rtt_tech_table": "Web server IP address|0-RTT", + "detail_web_tls_zero_rtt_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_zero_rtt_tech_table_0_rtt": "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 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", + "detail_web_mail_ipv6_ns_aaaa_tech_table_name_server": "Name server", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv6_address": "IPv6 address", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv4_address": "IPv4 address", "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "None of the name servers of your domain has an IPv6 address.", "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Two or more name servers of your domain have an IPv6 address.", "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Only one name server of your domain has an IPv6 address.", "detail_web_mail_ipv6_ns_reach_exp": "We check if all name servers, that have an AAAA record with IPv6 address, are reachable over IPv6.", "detail_web_mail_ipv6_ns_reach_label": "IPv6 reachability of name servers", "detail_web_mail_ipv6_ns_reach_tech_table": "Name server|Unreachable IPv6 address", + "detail_web_mail_ipv6_ns_reach_tech_table_name_server": "Name server", + "detail_web_mail_ipv6_ns_reach_tech_table_unreachable_ipv6_address": "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.", "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_tech_table_name_server": "Name server", + "detail_web_mail_rpki_ns_exists_tech_table_ip_address": "IP address", + "detail_web_mail_rpki_ns_exists_tech_table_rpki_route_origin_authorization": "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.

1\u2024 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\u2024 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\u2024 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_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_tech_table_name_server": "Name server", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_mail_rpki_ns_valid_tech_table_rpki_origin_validation_state": "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 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.", @@ -589,19 +758,19 @@ "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 \u21d2 null score", - "faqs_report_subtest_error": "Test error: error encountered during testing \u21d2 null score", - "faqs_report_subtest_good": "Good: pass on REQUIRED, RECOMMENDED or OPTIONAL subtest \u21d2 first: full score / latter two: no score impact", - "faqs_report_subtest_info": "Informational: fail on OPTIONAL subtest \u21d2 no score impact", - "faqs_report_subtest_not_tested": "Not tested, because already failed related parent subtest \u21d2 null score", + "faqs_report_subtest_bad": "Bad: fail on REQUIRED subtest ⇒ null score", + "faqs_report_subtest_error": "Test error: error encountered during testing ⇒ null score", + "faqs_report_subtest_good": "Good: pass on REQUIRED, RECOMMENDED or OPTIONAL subtest ⇒ first: full score / latter two: no score impact", + "faqs_report_subtest_info": "Informational: fail on OPTIONAL subtest ⇒ no score impact", + "faqs_report_subtest_not_tested": "Not tested, because already failed related parent subtest ⇒ null score", "faqs_report_subtest_title": "Icons per subtest", - "faqs_report_subtest_warning": "Warning: fail on RECOMMENDED subtest \u21d2 no score impact", - "faqs_report_test_bad": "Bad: failed at least one REQUIRED subtest \u21d2 no full score in test category", - "faqs_report_test_error": "Test error: execution error for at least one subtest \u21d2 no result in test category", - "faqs_report_test_good": "Good: passed all subtests \u21d2 full score in test category", - "faqs_report_test_info": "Informational: failed at least one OPTIONAL subtest \u21d2 full score in test category ", + "faqs_report_subtest_warning": "Warning: fail on RECOMMENDED subtest ⇒ no score impact", + "faqs_report_test_bad": "Bad: failed at least one REQUIRED subtest ⇒ no full score in test category", + "faqs_report_test_error": "Test error: execution error for at least one subtest ⇒ no result in test category", + "faqs_report_test_good": "Good: passed all subtests ⇒ full score in test category", + "faqs_report_test_info": "Informational: failed at least one OPTIONAL subtest ⇒ full score in test category ", "faqs_report_test_title": "Icons per test category", - "faqs_report_test_warning": "Warning: failed at least one RECOMMENDED subtest \u21d2 full score in test category ", + "faqs_report_test_warning": "Warning: failed at least one RECOMMENDED subtest ⇒ full score in test category ", "faqs_report_title": "Explanation of test report", "faqs_rpki_title": "Authorisation for routing (RPKI)", "faqs_starttls_title": "Secure email transport (STARTTLS and DANE)", diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json index b0d79ad3..d3084fe9 100644 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json @@ -39,14 +39,18 @@ "base_widget_site": "Websitetest widget", "connection_pagetitle": "Verbindingstest", "connection_title": "Verbindingstest", - "detail_conn_dnssec_validation_exp": "We testen of de door jou gebruikte resolvers de DNSSEC-handtekeningen van onze domeinnaam valideren. Resolvers worden normaal gesproken geleverd door je internetprovider. Als alternatief kun je resolvers van een andere DNS provider instellen. Je kan zelfs je eigen lokaal ge\u00efnstalleerde resolver gebruiken. Hoewel validatie plaatsvindt op de resolver, kan nog steeds door een aanvaller gerommeld worden met de communicatie tussen de resolver en jouw apparaat (ook wel \\'last mile\\' genoemd). Het is daarom het meest veilig om zo dicht mogelijk op je apparaat te valideren (bijv. door een lokaal ge\u00efnstalleerde resolver te gebruiken), of zorg ervoor dat het kanaal tussen je resolver en je apparaat beveiligd c.q. vertrouwd is.", + "detail_conn_dnssec_validation_exp": "We testen of de door jou gebruikte resolvers de DNSSEC-handtekeningen van onze domeinnaam valideren. Resolvers worden normaal gesproken geleverd door je internetprovider. Als alternatief kun je resolvers van een andere DNS provider instellen. Je kan zelfs je eigen lokaal geïnstalleerde resolver gebruiken. Hoewel validatie plaatsvindt op de resolver, kan nog steeds door een aanvaller gerommeld worden met de communicatie tussen de resolver en jouw apparaat (ook wel \\'last mile\\' genoemd). Het is daarom het meest veilig om zo dicht mogelijk op je apparaat te valideren (bijv. door een lokaal geïnstalleerde resolver te gebruiken), of zorg ervoor dat het kanaal tussen je resolver en je apparaat beveiligd c.q. vertrouwd is.", "detail_conn_dnssec_validation_label": "DNSSEC-validatie", "detail_conn_dnssec_validation_tech_table": "DNS-provider", + "detail_conn_dnssec_validation_tech_table_dns_provider": "DNS-provider", "detail_conn_dnssec_validation_verdict_bad": "Je bent niet beschermd door validatie van DNSSEC-handtekeningen.", "detail_conn_dnssec_validation_verdict_good": "Je bent beschermd door validatie van DNSSEC-handtekeningen.", "detail_conn_ipv6_connection_exp": "We testen of jouw apparaat via zijn huidige internetverbinding in staat is om direct (d.w.z. zonder DNS-vertaling) verbinding te maken met onze webserver via ons bijbehorende IPv6-adres.

Sommige browser add-ons en routers bieden functionaliteit aan voor het filteren van domeinnamen om de privacy te verbeteren of internetgebruik te beperken. Om omzeiling te voorkomen blokkeert deze functionaliteit vaak ook het direct verbinden met IP-adressen waardoor deze subtest faalt.", "detail_conn_ipv6_connection_label": "IPv6-connectiviteit (direct)", "detail_conn_ipv6_connection_tech_table": "Geanonimiseerd IPv6-adres|Reverse name|Internetprovider", + "detail_conn_ipv6_connection_tech_table_anonymized_ipv6_address": "Geanonimiseerd IPv6-adres", + "detail_conn_ipv6_connection_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_connection_tech_table_internet_provider": "Internetprovider", "detail_conn_ipv6_connection_verdict_bad": "Je bent niet in staat om computers direct op hun IPv6-adres te bereiken.", "detail_conn_ipv6_connection_verdict_good": "Je bent in staat om computers direct op hun IPv6-adres te bereiken.", "detail_conn_ipv6_dns_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv6. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv6-adres ophaalt.", @@ -56,13 +60,16 @@ "detail_conn_ipv6_ipv4_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv4. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv4-adres ophaalt.

Niveau van vereistheid: Optioneel", "detail_conn_ipv6_ipv4_conn_label": "IPv4-connectiviteit (via DNS)", "detail_conn_ipv6_ipv4_conn_tech_table": "Geanonimiseerd IPv4-adres|Reverse name|Internetprovider", + "detail_conn_ipv6_ipv4_conn_tech_table_anonymized_ipv4_address": "Geanonimiseerd IPv4-adres", + "detail_conn_ipv6_ipv4_conn_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_ipv4_conn_tech_table_internet_provider": "Internetprovider", "detail_conn_ipv6_ipv4_conn_verdict_bad": "Je bent niet in staat om computers via DNS op hun IPv4-adres te bereiken.", "detail_conn_ipv6_ipv4_conn_verdict_good": "Je bent in staat om computers via DNS op hun IPv4-adres te bereiken.", "detail_conn_ipv6_privacy_exp": "We testen of je apparaat \\'IPv6 Privacy Extensions for SLAAC\\' (of een ander IPv6-configuratieproces dan SLAAC) gebruikt om het lekken van zijn mogelijk privacygevoelige MAC-adres naar computers waarmee het via IPv6 verbinding maakt te voorkomen.", "detail_conn_ipv6_privacy_label": "Privacy Extensions voor IPv6", "detail_conn_ipv6_privacy_verdict_bad": "Je gebruikt SLAAC zonder \\'IPv6 Privacy Extensions\\'.", "detail_conn_ipv6_privacy_verdict_good": "Je hebt \\'IPv6 Privacy Extensions\\' geactiveerd (of je gebruikt geen SLAAC).", - "detail_conn_ipv6_resolver_conn_exp": "We testen of ten minste \u00e9\u00e9n van de door jou gebruikte DNS-resolvers in staat is om onze autoritatieve nameserver te bereiken via IPv6. Vaak levert je internetprovider de DNS-resolver(s).", + "detail_conn_ipv6_resolver_conn_exp": "We testen of ten minste één van de door jou gebruikte DNS-resolvers in staat is om onze autoritatieve nameserver te bereiken via IPv6. Vaak levert je internetprovider de DNS-resolver(s).", "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.", @@ -71,9 +78,11 @@ "detail_mail_auth_dkim_verdict_bad": "Je domeinnaam ondersteunt geen DKIM-records.", "detail_mail_auth_dkim_verdict_good": "Je domeinnaam ondersteunt DKIM-records.", "detail_mail_auth_dkim_verdict_no_email": "Je domeinnaam ondersteunt geen DKIM-records. Echter omdat je DMARC- en SPF-records aangeven dat er geen mail vanaf je domein wordt verstuurd, is DKIM niet nodig en wordt deze subtest overgeslagen.", - "detail_mail_auth_dmarc_exp": "We testen of DMARC beschikbaar is voor jouw domein. Een ontvangendemailserver kan de DMARC-policy gebruiken om te bepalen hoe om te gaan meteen e-mail met jouw domein als verzender waarvan de authenticatie met zowelDKIM als SPF faalt, en de ontvangende mailserver kan je e-mailadres uit het DMARC-recordgebruiken om je feedbackrapporten over het authenticatieresultaat te sturen. Het hebben van meer dan \u00e9\u00e9n DMARC-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt. Let op: DMARC vereist dathet SPF-domein (envelope sender, d.w.z. return-path dat terugkomt inMAIL FROM) en het DKIM-domein (d=) gelijk zijn aan het verzenddomein in hetmailbericht (From:). ", + "detail_mail_auth_dmarc_exp": "We testen of DMARC beschikbaar is voor jouw domein. Een ontvangendemailserver kan de DMARC-policy gebruiken om te bepalen hoe om te gaan meteen e-mail met jouw domein als verzender waarvan de authenticatie met zowelDKIM als SPF faalt, en de ontvangende mailserver kan je e-mailadres uit het DMARC-recordgebruiken om je feedbackrapporten over het authenticatieresultaat te sturen. Het hebben van meer dan één DMARC-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt. Let op: DMARC vereist dathet SPF-domein (envelope sender, d.w.z. return-path dat terugkomt inMAIL FROM) en het DKIM-domein (d=) gelijk zijn aan het verzenddomein in hetmailbericht (From:). ", "detail_mail_auth_dmarc_label": "DMARC aanwezigheid", "detail_mail_auth_dmarc_tech_table": "DMARC-record|Gevonden op", + "detail_mail_auth_dmarc_tech_table_dmarc_record": "DMARC-record", + "detail_mail_auth_dmarc_tech_table_found_on": "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;\"
", @@ -82,14 +91,17 @@ "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. ", "detail_mail_auth_dmarc_policy_verdict_good": "Je DMARC-policy is voldoende strikt.", "detail_mail_auth_dmarc_policy_verdict_policy": "Je DMARC-policy is niet voldoende strikt.", - "detail_mail_auth_spf_exp": "We testen of je domeinnaam een SPF-record heeft. Een ontvangende mailserver kan de IP-adressen in je SPF-record gebruiken om de verzendende mailserver van een ontvangen e-mail met jouw domein als afzender te authenticeren. Het bijbehorende beleid kan worden gebruikt om passende actie te ondernemen als de authenticatie mislukt. Meer dan \u00e9\u00e9n SPF-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt.

Voor een \"good practice voor domeinnamen zonder mail\" zie de uitleg van de \"DMARC-policy\" subtest.", + "detail_mail_auth_spf_exp": "We testen of je domeinnaam een SPF-record heeft. Een ontvangende mailserver kan de IP-adressen in je SPF-record gebruiken om de verzendende mailserver van een ontvangen e-mail met jouw domein als afzender te authenticeren. Het bijbehorende beleid kan worden gebruikt om passende actie te ondernemen als de authenticatie mislukt. Meer dan één SPF-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt.

Voor een \"good practice voor domeinnamen zonder mail\" zie de uitleg van de \"DMARC-policy\" subtest.", "detail_mail_auth_spf_label": "SPF aanwezigheid", "detail_mail_auth_spf_tech_table": "SPF-record", + "detail_mail_auth_spf_tech_table_spf_record": "SPF-record", "detail_mail_auth_spf_verdict_bad": "Je domeinnaam heeft geen geldig SPF-record.", "detail_mail_auth_spf_verdict_good": "Je domein heeft een SPF-record.", "detail_mail_auth_spf_policy_exp": "We controleren of de syntax van je SPF-record geldig is en of deze een voldoende strikte policy, d.w.z. ~all (softfail) of -all (hardfail), bevat om misbruik van je domein door phishers en spammers tegen te gaan. Om misbruik van je domein tegen te gaan is een liberale policy, d.w.z. +all (pass) of ?all (neutral), onvoldoende. Als all ontbreekt en er is geen redirect aanwezig in je SPF-record, dan is de default policy ?all.

We volgen ook include en redirect voor geldige SPF-records. Bovendien controleren we of je SPF-record het toegestane aantal van 10 DNS-opvragingen niet overschrijdt waardoor het geen werking meer heeft. Ieder van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.

Merk op dat als het domein onder include of redirect uit macro\\'s bestaat, dan volgen we deze niet omdat we niet over de noodzakelijk informatie van een daadwerkelijke mail of mailserververbinding beschikken om de macro\\'s uit te voeren. Dit betekent dat we het gevolg van macro\\'s niet beoordelen. Bovendien tellen we de door macro\\'s veroorzaakte DNS-opvragingen niet mee om te bepalen of het toegestane aantal DNS-opvragingen is overschreden.

Voor verzendende domeinen heeft het gebruik van ~all (softfail) in plaats van -all (fail) meestal de voorkeur. De reden hiervoor is dat wanneer de SPF-authenticatie faalt met een SPF fail, een ontvangende mailserver de verbinding al kan blokkeren zonder de DKIM-handtekening en het DMARC-beleid te evalueren. Dit kan leiden tot ten onrechte geblokkeerde mails (bijvoorbeeld wanneer mails door de ontvangende mailserver automatisch worden doorgestuurd naar een andere ontvangende mailserver). Merk op dat een getriggerde SPF softfail er nog steeds voor zorgt dat een strikte DMARC policy je domein beschermt als ook de DKIM-authenticatie faalt.

Voor domeinen zonder mail zie de good practice op uitleg van de \"DMARC-policy\" subtest.", "detail_mail_auth_spf_policy_label": "SPF policy", "detail_mail_auth_spf_policy_tech_table": "Domein|SPF-record", + "detail_mail_auth_spf_policy_tech_table_domain": "Domein", + "detail_mail_auth_spf_policy_tech_table_spf_record": "SPF-record", "detail_mail_auth_spf_policy_verdict_all": "Je SPF-policy is niet voldoende strikt.", "detail_mail_auth_spf_policy_verdict_bad": "Je SPF-policy is syntactisch niet correct.", "detail_mail_auth_spf_policy_verdict_good": "Je SPF-policy is voldoende strikt.", @@ -99,184 +111,253 @@ "detail_mail_dnssec_exists_exp": "We testen of de domeinnaam in je e-mailadres, meer specifiek het SOA-record, ondertekend is met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze jouw mailserverdomeinen (MX) kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar een mailserverdomein dat onder controle is van de aanvaller.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", "detail_mail_dnssec_exists_label": "DNSSEC aanwezigheid", "detail_mail_dnssec_exists_tech_table": "E-mailadresdomein|Registrar", + "detail_mail_dnssec_exists_tech_table_email_address_domain": "E-mailadresdomein", + "detail_mail_dnssec_exists_tech_table_registrar": "Registrar", "detail_mail_dnssec_exists_verdict_bad": "Je e-mailadresdomein is onveilig oftewel \\'insecure\\', omdat het niet ondertekend is met DNSSEC.", "detail_mail_dnssec_exists_verdict_good": "Je e-mailadresdomein is met DNSSEC ondertekend.", "detail_mail_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", "detail_mail_dnssec_exists_verdict_servfail": "De nameservers van je e-mailadresdomein zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", - "detail_mail_dnssec_mx_exists_exp": "We testen of de domeinnamen van je mailservers (MX), meer specifiek hun SOA-records, ondertekend zijn met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze de IP-adressen en DANE-records van jouw mailservers kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar IP-adressen die onder controle staan van de aanvaller \u00f3f de beveiligde mailserver-verbinding afluistert.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

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

De geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", + "detail_mail_dnssec_mx_exists_exp": "We testen of de domeinnamen van je mailservers (MX), meer specifiek hun SOA-records, ondertekend zijn met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze de IP-adressen en DANE-records van jouw mailservers kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar IP-adressen die onder controle staan van de aanvaller óf de beveiligde mailserver-verbinding afluistert.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

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

De geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", "detail_mail_dnssec_mx_exists_label": "DNSSEC aanwezigheid", "detail_mail_dnssec_mx_exists_tech_table": "Domein van mailserver (MX)|DNSSEC aanwezig", - "detail_mail_dnssec_mx_exists_verdict_bad": "Tenminste \u00e9\u00e9n van jouw mailserverdomeinen is onveilig oftewel \\'insecure\\', omdat deze niet ondertekend is met DNSSEC.", + "detail_mail_dnssec_mx_exists_tech_table_domain_of_mail_server_mx": "Domein van mailserver (MX)", + "detail_mail_dnssec_mx_exists_tech_table_dnssec_existent": "DNSSEC aanwezig", + "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, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f 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": "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\u00ebn IPv6 en DNSSEC niet van toepassing.", + "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": "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.", "detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", - "detail_mail_dnssec_mx_exists_verdict_servfail": "De nameservers van tenminste \u00e9\u00e9n van je mailserverdomeinen zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je mailprovider) om dit spoedig op te lossen.", - "detail_mail_dnssec_mx_valid_exp": "We testen of de domeinen van je ontvangende mailservers (MX), meer specifiek hun SOA-records, zijn ondertekend met een geldige DNSSEC-handtekening die ze veilig oftewel \\'secure\\' maakt.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot vari\u00ebrende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", + "detail_mail_dnssec_mx_exists_verdict_servfail": "De nameservers van tenminste één van je mailserverdomeinen zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je mailprovider) om dit spoedig op te lossen.", + "detail_mail_dnssec_mx_valid_exp": "We testen of de domeinen van je ontvangende mailservers (MX), meer specifiek hun SOA-records, zijn ondertekend met een geldige DNSSEC-handtekening die ze veilig oftewel \\'secure\\' maakt.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", "detail_mail_dnssec_mx_valid_label": "DNSSEC geldigheid", "detail_mail_dnssec_mx_valid_tech_table": "Domein van mailserver (MX)|Status", - "detail_mail_dnssec_mx_valid_verdict_bad": "Tenminste \u00e9\u00e9n van de ondertekende domeinen van je mailservers is onbetrouwbaar oftewel \\'bogus\\', omdat zijn DNSSEC-handtekening niet geldig is. \u00d3f iemand manipuleerde de antwoorden van de nameservers, \u00f3f je mailserverdomein heeft serieuze DNSSEC-configuratiefouten. Dit laatste maakt je ontvangende mailserver onbereikbaar voor alle verzendende mailservers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met de nameserver-beheerder (vaak je mailprovider).", + "detail_mail_dnssec_mx_valid_tech_table_domain_of_mail_server_mx": "Domein van mailserver (MX)", + "detail_mail_dnssec_mx_valid_tech_table_status": "Status", + "detail_mail_dnssec_mx_valid_verdict_bad": "Tenminste één van de ondertekende domeinen van je mailservers is onbetrouwbaar oftewel \\'bogus\\', omdat zijn DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde de antwoorden van de nameservers, óf je mailserverdomein heeft serieuze DNSSEC-configuratiefouten. Dit laatste maakt je ontvangende mailserver onbereikbaar voor alle verzendende mailservers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met de nameserver-beheerder (vaak je mailprovider).", "detail_mail_dnssec_mx_valid_verdict_good": "Al de ondertekende domeinnamen van je mailservers zijn veilig oftewel \\'secure\\', omdat hun DNSSEC-handtekeningen geldig zijn.", - "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "Tenminste \u00e9\u00e9n van de domeinen van je mailservers is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", - "detail_mail_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot vari\u00ebrende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", + "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "Tenminste één van de domeinen van je mailservers is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", + "detail_mail_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", "detail_mail_dnssec_valid_label": "DNSSEC geldigheid", "detail_mail_dnssec_valid_tech_table": "E-mailadresdomein|Status", - "detail_mail_dnssec_valid_verdict_bad": "Je e-mailadresdomein is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. \u00d3f iemand manipuleerde het antwoord van jouw nameserver, \u00f3f je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", + "detail_mail_dnssec_valid_tech_table_email_address_domain": "E-mailadresdomein", + "detail_mail_dnssec_valid_tech_table_status": "Status", + "detail_mail_dnssec_valid_verdict_bad": "Je e-mailadresdomein is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", "detail_mail_dnssec_valid_verdict_good": "Je e-mailadresdomein is veilig oftewel \\'secure\\', omdat zijn DNSSEC-handtekening geldig is.", "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Je e-mailadresdomein is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", - "detail_mail_ipv6_mx_aaaa_exp": "We testen of er tenminste \u00e9\u00e9n AAAA-record met IPv6-adres voor iedere ontvangende mailserver (MX) is. In het geval er geen mailserver is gedefinieerd, geven we een notificatie en we voeren andere subtesten van de mailtest die nog steeds relevant zijn gewoon uit.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.", + "detail_mail_ipv6_mx_aaaa_exp": "We testen of er tenminste één AAAA-record met IPv6-adres voor iedere ontvangende mailserver (MX) is. In het geval er geen mailserver is gedefinieerd, geven we een notificatie en we voeren andere subtesten van de mailtest die nog steeds relevant zijn gewoon uit.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.", "detail_mail_ipv6_mx_aaaa_label": "IPv6-adressen voor mailserver(s)", "detail_mail_ipv6_mx_aaaa_tech_table": "Mailserver (MX)|IPv6-adres|IPv4-adres", - "detail_mail_ipv6_mx_aaaa_verdict_bad": "Tenminste \u00e9\u00e9n ontvangende mailserver op jouw domeinnaam heeft geen IPv6-adres.", + "detail_mail_ipv6_mx_aaaa_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv6_address": "IPv6-adres", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv4_address": "IPv4-adres", + "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, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f 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 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\u00ebn IPv6 en DNSSEC niet van toepassing.", + "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 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": "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\u00ebn IPv6 en DNSSEC niet van toepassing.", + "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 \u00e9\u00e9n van je ontvangende mailservers met een IPv6-adres is niet bereikbaar via IPv6.", + "detail_mail_ipv6_mx_reach_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_ipv6_mx_reach_tech_table_unreachable_ipv6_address": "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.", "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 \u00e9\u00e9n van de IP-adressen van je ontvangende mailserver(s) is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.", + "detail_mail_rpki_exists_tech_table_mail_server": "Mailserver", + "detail_mail_rpki_exists_tech_table_ip_address": "IP-adres", + "detail_mail_rpki_exists_tech_table_rpki_route_origin_authorization": "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.", "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 \u00e9\u00e9n 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_tech_table_name_server_of_mx": "Nameserver van MX", + "detail_mail_rpki_mx_ns_exists_tech_table_ip_address": "IP-adres", + "detail_mail_rpki_mx_ns_exists_tech_table_rpki_route_origin_authorization": "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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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_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 \u00e9\u00e9n 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_tech_table_name_server_of_mx": "Nameserver van MX", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_mx_ns_valid_tech_table_rpki_origin_validation_state": "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 \u00e9\u00e9n 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) \u00f3f 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_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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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_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 \u00e9\u00e9n 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_tech_table_mail_server": "Mailserver", + "detail_mail_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_valid_tech_table_rpki_origin_validation_state": "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 \u00e9\u00e9n 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) \u00f3f 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_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", "detail_mail_tls_cert_hostmatch_tech_table": "Mailserver (MX)|Niet-overeenkomende domeinen op certificaat", - "detail_mail_tls_cert_hostmatch_verdict_bad": "De domeinnaam van tenminste \u00e9\u00e9n van je mailservers komt niet overeen met de domeinnaam op het mailservercertificaat.", + "detail_mail_tls_cert_hostmatch_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Niet-overeenkomende domeinen op certificaat", + "detail_mail_tls_cert_hostmatch_verdict_bad": "De domeinnaam van tenminste één van je mailservers komt niet overeen met de domeinnaam op het mailservercertificaat.", "detail_mail_tls_cert_hostmatch_verdict_good": "De domeinnamen van al je mailservers komen overeen met de domeinnamen op je mailservercertificaten.", - "detail_mail_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan \u00e9\u00e9n algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 \u2013 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", + "detail_mail_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", "detail_mail_tls_cert_pubkey_label": "Publieke sleutel van certificaat", "detail_mail_tls_cert_pubkey_tech_table": "Mailserver (MX)|Getroffen handtekening-parameters|Status", - "detail_mail_tls_cert_pubkey_verdict_bad": "De digitale handtekening van tenminste \u00e9\u00e9n van je mailserver-certificaten gebruikt onvoldoende veilige parameters.", + "detail_mail_tls_cert_pubkey_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_pubkey_tech_table_affected_signature_parameters": "Getroffen handtekening-parameters", + "detail_mail_tls_cert_pubkey_tech_table_status": "Status", + "detail_mail_tls_cert_pubkey_verdict_bad": "De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt onvoldoende veilige parameters.", "detail_mail_tls_cert_pubkey_verdict_good": "De digitale handtekeningen van al je mailserver-certificaten gebruiken veilige parameters.", - "detail_mail_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van tenminste \u00e9\u00e9n van je mailserver-certificaten gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", "detail_mail_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van ieder van je mailserver-certificaten is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", "detail_mail_tls_cert_signature_label": "Handtekening van certificaat", "detail_mail_tls_cert_signature_tech_table": "Mailserver (MX)|Getroffen hashing-algoritme|Status", - "detail_mail_tls_cert_signature_verdict_bad": "Tenminste \u00e9\u00e9n van je mailserver-certificaten is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", + "detail_mail_tls_cert_signature_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_signature_tech_table_affected_hash_algorithm": "Getroffen hashing-algoritme", + "detail_mail_tls_cert_signature_tech_table_status": "Status", + "detail_mail_tls_cert_signature_verdict_bad": "Tenminste één van je mailserver-certificaten is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", "detail_mail_tls_cert_signature_verdict_good": "Al je mailserver-certificaten zijn ondertekend met een veilig algoritme voor hashing.", - "detail_mail_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je mailserver-certificaten kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit \u00e9n je ontvangende mailserver alle noodzakelijke tussenliggende certificaten presenteert.

Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.

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

Niveau van vereistheid: Optioneel", + "detail_mail_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je mailserver-certificaten kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je ontvangende mailserver alle noodzakelijke tussenliggende certificaten presenteert.

Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.

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

Niveau van vereistheid: Optioneel", "detail_mail_tls_cert_trust_label": "Vertrouwensketen van certificaat", "detail_mail_tls_cert_trust_tech_table": "Mailserver (MX)|Onvertrouwde certificaatketen", - "detail_mail_tls_cert_trust_verdict_bad": "De vertrouwensketen van tenminste \u00e9\u00e9n 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 \u00e9n ondertekend door een vertrouwde certificaatautoriteit.", + "detail_mail_tls_cert_trust_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_trust_tech_table_untrusted_certificate_chain": "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-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 \u00e9\u00e9n van je mailservers dwingt niet zijn eigen cipher-voorkeur af (\\'I\\').", + "detail_mail_tls_cipher_order_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "Eerst gevonden getroffen cipher-paren", + "detail_mail_tls_cipher_order_tech_table_violated_rule_ii_b": "Overtreden regel # (\\'II-B\\')", + "detail_mail_tls_cipher_order_verdict_bad": "Tenminste één van je mailservers dwingt niet zijn eigen cipher-voorkeur af (\\'I\\').", "detail_mail_tls_cipher_order_verdict_good": "Al je mailservers dwingen hun eigen cipher-voorkeur af (\\'I\\'), en bieden ciphers aan conform de voorgeschreven volgorde (\\'II\\').", "detail_mail_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je mailserver alleen \\'Goede\\' ciphers ondersteunt.", - "detail_mail_tls_cipher_order_verdict_seclevel_bad": "Tenminste \u00e9\u00e9n van je mailservers prefereert niet \\'Goede\\' boven \\'Voldoende\\' en dan pas \\'Uit te faseren\\' ciphers (\\'II\\').", + "detail_mail_tls_cipher_order_verdict_seclevel_bad": "Tenminste één van je mailservers prefereert niet \\'Goede\\' boven \\'Voldoende\\' en dan pas \\'Uit te faseren\\' ciphers (\\'II\\').", "detail_mail_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Tenminste een van je mailservers biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\\'II-B\\').", "detail_mail_tls_ciphers_exp": "

We testen of je ontvangende mailservers (MX) alleen veilige, d.w.z. \\'Goede\\' en/of \\'Voldoende\\', ciphers (ook algoritmeselecties genoemd) ondersteunen. Om te voorkomen dat we tegen \\'rate limits\\' van ontvangende mailservers aanlopen, bevat het testresultaat alleen de eerstgevonden getroffen algoritmeselectie.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing.

  • Vanaf TLS 1.3 omvat de term \\'cipher suite\\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \\'cipher suite\\' ambigu maakt, gebruikt NCSC de term \\'algoritmeselectie\\' om alle vier de functies te omvatten.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselectie. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \\'Goede\\', \\'Voldoende\\' en \\'Uit te faseren\\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\\'. Achter iedere algoritmeselectie staat de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \\'Uit te faseren\\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", "detail_mail_tls_ciphers_label": "Ciphers (Algoritmeselecties)", "detail_mail_tls_ciphers_tech_table": "Mailserver (MX)|Eerst gevonden onveilige cipher|Status", - "detail_mail_tls_ciphers_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer onvoldoende veilige ciphers.", + "detail_mail_tls_ciphers_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_ciphers_tech_table_first_found_affected_cipher": "Eerst gevonden onveilige cipher", + "detail_mail_tls_ciphers_tech_table_status": "Status", + "detail_mail_tls_ciphers_verdict_bad": "Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige ciphers.", "detail_mail_tls_ciphers_verdict_good": "Al je mailservers ondersteunen alleen veilige ciphers.", - "detail_mail_tls_ciphers_verdict_phase_out": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer ciphers die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_mail_tls_compression_exp": "

We testen of je ontvangende mailservers (MX) TLS-compressie ondersteunen.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te be\u00efnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau
  • Onvoldoende: TLS-compressie
", + "detail_mail_tls_ciphers_verdict_phase_out": "Tenminste één van je mailservers ondersteunt een of meer ciphers die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_compression_exp": "

We testen of je ontvangende mailservers (MX) TLS-compressie ondersteunen.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau
  • Onvoldoende: TLS-compressie
", "detail_mail_tls_compression_label": "TLS-compressie", "detail_mail_tls_compression_tech_table": "Mailserver (MX)|TLS-compressie", - "detail_mail_tls_compression_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt TLS-compressie, wat niet veilig is.", + "detail_mail_tls_compression_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_compression_tech_table_tls_compression": "TLS-compressie", + "detail_mail_tls_compression_verdict_bad": "Tenminste één van je mailservers ondersteunt TLS-compressie, wat niet veilig is.", "detail_mail_tls_compression_verdict_good": "Al je mailservers ondersteunen geen TLS-compressie.", "detail_mail_tls_dane_exists_exp": "We testen of de nameservers van ieder van je ontvangende mailservers (MX) een of meer TLSA-records voor DANE bevatten.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het mailserver-domein.

Merk op dat de test TLSA-records van de types PKIX-TA(0) or PKIX-EE(1) negeert, omdat deze niet gebruikt dienen te worden voor ontvangende mailservers.

De test slaagt daarnaast niet als er geen DNSSEC-bewijs van \\'Denial of Existence\\' voor TLSA-records is. Als een ondertekend TLSA-record bestaat maar tegelijkertijd is er een \\'insecure\\' NXDOMAIN voor hetzelfde domein (door verkeerd werkende DNSSEC-ondertekeningssoftware), dan zal de test ook niet slagen. De laatste twee foutscenario\\'s kunnen leiden tot afleveringsproblemen van aan jou gerichte e-mails door DANE-validerende mailverzenders.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, Appendix A, onder \\'Certificate pinning en DANE\\'.", "detail_mail_tls_dane_exists_label": "DANE aanwezigheid", "detail_mail_tls_dane_exists_tech_table": "Mailserver (MX)|DANE TLSA-record aanwezig", - "detail_mail_tls_dane_exists_verdict_bad": "Tenminste \u00e9\u00e9n van je mailserverdomeinen bevat geen TLSA-record voor DANE.", - "detail_mail_tls_dane_exists_verdict_bogus": "Tenminste \u00e9\u00e9n 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_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA-record aanwezig", + "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 \u00e9\u00e9n 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, \u00e9\u00e9n voor het huidige en \u00e9\u00e9n 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 (\u00e9\u00e9n gebaseerd op RSA en \u00e9\u00e9n gebaseerd op ECDSA), een afzonderlijk DANE TLSA rollover schema wordt aanbevolen voor ieder certificaat. De subtest controleert niet op dit scenario. Als er slechts \u00e9\u00e9n 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_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_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_dane_rollover_tech_table_dane_rollover_scheme": "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.", "detail_mail_tls_dane_rollover_verdict_good": "Al je mailserver-domeinen hebben een actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.", "detail_mail_tls_dane_valid_exp": "We testen of de DANE-fingerprints die je mailserverdomeinen presenteren geldig zijn voor je mailservercertificaten.

Met DANE kan je informatie over jouw mailservercertificaten publiceren in een speciaal DNS-record, een TLSA-record. Verzendende mailservers kunnen de certificaten nu niet alleen via de certificaatautoriteit, maar ook via de TLSA-records controleren op authenticiteit. Een verzendende mail server kan het TLSA-record ook als signaal gebruiken om alleen via STARTTLS (en niet onversleuteld) te verbinden. Als de DANE-fingerprint van een ontvangende mailserver wordt gecontroleerd door de verzendende mailserver, dan kan een actieve aanvaller die in staat is het berichtenverkeer te manipuleren de STARTTLS-encryptie niet verwijderen.", "detail_mail_tls_dane_valid_label": "DANE geldigheid", "detail_mail_tls_dane_valid_tech_table": "Mailserver (MX)|DANE TLSA-record geldig", - "detail_mail_tls_dane_valid_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers heeft geen geldige DANE-fingerprints. \u00d3f iemand manipuleerde het antwoord van je mailserver, \u00f3f 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 \u00e9\u00e9n geldige DANE-fingerprint. Daardoor kunnen verzendende mailservers die DANE-verificatie ondersteunen, een geauthenticeerde versleutelde transportverbinding met je ontvangende mailserver(s) opzetten.", + "detail_mail_tls_dane_valid_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Sleuteluitwisselingsparameters", "detail_mail_tls_fs_params_tech_table": "Mailserver (MX)|Getroffen parameters|Veiligheidsniveau", - "detail_mail_tls_fs_params_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_mail_tls_fs_params_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_fs_params_tech_table_affected_parameters": "Getroffen parameters", + "detail_mail_tls_fs_params_tech_table_security_level": "Veiligheidsniveau", + "detail_mail_tls_fs_params_verdict_bad": "Tenminste één van je mailservers ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", "detail_mail_tls_fs_params_verdict_good": "Je mailserver ondersteunt voldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", "detail_mail_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je mailservers niet Diffie-Hellman-sleuteluitwisseling ondersteunen. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", - "detail_mail_tls_fs_params_verdict_phase_out": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_mail_tls_kex_hash_func_exp": "

We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver cre\u00ebert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", + "detail_mail_tls_fs_params_verdict_phase_out": "Tenminste één van je mailservers ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_kex_hash_func_exp": "

We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", "detail_mail_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", "detail_mail_tls_kex_hash_func_tech_table": "Mailserver (MX)|SHA-2-ondersteuning voor handtekeningen", + "detail_mail_tls_kex_hash_func_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "SHA-2-ondersteuning voor handtekeningen", "detail_mail_tls_kex_hash_func_verdict_good": "Al je mailservers ondersteunen veilige hashfuncties voor sleuteluitwisseling.", - "detail_mail_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie tenminste \u00e9\u00e9n van je mailservers gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", - "detail_mail_tls_kex_hash_func_verdict_phase_out": "Ten minste \u00e9\u00e9n van je mailservers ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", + "detail_mail_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie tenminste één van je mailservers gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", + "detail_mail_tls_kex_hash_func_verdict_phase_out": "Ten minste één van je mailservers ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", "detail_mail_tls_ocsp_stapling_exp": "OUTDATED TEXT; TEST NOT USED
TODO", "detail_mail_tls_ocsp_stapling_label": "OUTDATED TEXT; TEST NOT USED
TODO", "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mailserver (MX)|TODO", + "detail_mail_tls_ocsp_stapling_tech_table_outdated_text_test_not_used_mail_server_mx": "OUTDATED TEXT; TEST NOT USED
Mailserver (MX)", + "detail_mail_tls_ocsp_stapling_tech_table_ocsp_stapling": "TODO", "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\u00ebren met jouw ontvangende mailservers (MX).

In het algemeen is het niet nodig om clients de mogelijkheid te bieden om een renegotiation te initi\u00ebren (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 \u00e9\u00e9n van je mailservers staat client-initiated renegotiation toe, wat een negatieve invloed kan hebben op de beschikbaarheid van je mailserver.", + "detail_mail_tls_renegotiation_client_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "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.", "detail_mail_tls_renegotiation_client_verdict_good": "Al je mailservers staan geen client-initiated renegotiation toe.", - "detail_mail_tls_renegotiation_secure_exp": "

We testen of je mailservers (MX) secure renegotiation ondersteunen.

In de oudere versies van TLS (v\u00f3\u00f3r TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", + "detail_mail_tls_renegotiation_secure_exp": "

We testen of je mailservers (MX) secure renegotiation ondersteunen.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", "detail_mail_tls_renegotiation_secure_tech_table": "Mailserver (MX)|Secure renegotiation", - "detail_mail_tls_renegotiation_secure_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt insecure renegotiation, wat uiteraard niet veilig is.", + "detail_mail_tls_renegotiation_secure_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_renegotiation_secure_tech_table_secure_renegotiation": "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\u00ebn 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 \u00e9\u00e9n van je mailservers biedt geen STARTTLS aan.", + "detail_mail_tls_starttls_exists_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_starttls_exists_tech_table_starttls": "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, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f 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 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\u00ebn IPv6 en DNSSEC niet van toepassing.", + "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 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 \u00e9\u00e9n van je mailservers is onbereikbaar.", - "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\u00ebn 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 \u00e9\u00e9n 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_starttls_exists_verdict_other": "Tenminste één van je mailservers is onbereikbaar.", + "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", - "detail_mail_tls_version_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer onvoldoende veilige TLS-versies.", + "detail_mail_tls_version_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_version_tech_table_tls_versions": "TLS-versies", + "detail_mail_tls_version_tech_table_status": "Status", + "detail_mail_tls_version_verdict_bad": "Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige TLS-versies.", "detail_mail_tls_version_verdict_good": "Al je mailservers ondersteunen alleen veilige TLS-versies.", - "detail_mail_tls_version_verdict_phase_out": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt een of meer TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_mail_tls_zero_rtt_exp": "

We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie ge\u00efnitieerd. De omvang van de ondersteuning voor early data zoals aangegeven door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando v\u00f3\u00f3r de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", + "detail_mail_tls_version_verdict_phase_out": "Tenminste één van je mailservers ondersteunt een of meer TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_zero_rtt_exp": "

We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie geïnitieerd. De omvang van de ondersteuning voor early data zoals aangegeven door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando vóór de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", "detail_mail_tls_zero_rtt_label": "0-RTT", "detail_mail_tls_zero_rtt_tech_table": "Mailserver (MX)|0-RTT", - "detail_mail_tls_zero_rtt_verdict_bad": "Tenminste \u00e9\u00e9n van je mailservers ondersteunt 0-RTT, wat niet veilig is.", + "detail_mail_tls_zero_rtt_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_zero_rtt_tech_table_0_rtt": "0-RTT", + "detail_mail_tls_zero_rtt_verdict_bad": "Tenminste één van je mailservers ondersteunt 0-RTT, wat niet veilig is.", "detail_mail_tls_zero_rtt_verdict_good": "Geen van je mailservers ondersteunen 0-RTT.", "detail_mail_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je mailservers TLS 1.3 niet ondersteunen.", "detail_tech_data_bogus": "bogus", @@ -313,24 +394,24 @@ "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 \u00e9\u00e9n 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 \u00e9\u00e9n keer voorkomen.", - "detail_tech_data_http_securitytxt_multi_lang": "Fout: Het veld \\'Preferred-Languages\\' moet niet meer dan \u00e9\u00e9n keer voorkomen.", - "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Aanbeveling: Meerdere \\'CSAF\\'-velden zouden moeten worden teruggebracht tot \u00e9\u00e9n \\'CSAF\\'-veld.", + "detail_tech_data_http_securitytxt_multi_expire": "Fout: Het veld \\'Expires\\' moet niet meer dan één keer voorkomen.", + "detail_tech_data_http_securitytxt_multi_lang": "Fout: Het veld \\'Preferred-Languages\\' moet niet meer dan één keer voorkomen.", + "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Aanbeveling: Meerdere \\'CSAF\\'-velden zouden moeten worden teruggebracht tot één \\'CSAF\\'-veld.", "detail_tech_data_http_securitytxt_no_canonical": "Aanbeveling: Het veld \\'Canonical\\' zou aanwezig moeten zijn in een ondertekend bestand.", "detail_tech_data_http_securitytxt_no_canonical_match": "Fout: De web URI van security.txt (d.w.z. bij redirecting ten minste de laatste URI van de redirect-keten) moet worden vermeld in een \\'Canonical\\'-veld als dat aanwezig is.", - "detail_tech_data_http_securitytxt_no_contact": "Fout: Het veld \\'Contact\\' moet minstens \u00e9\u00e9n keer voorkomen.", + "detail_tech_data_http_securitytxt_no_contact": "Fout: Het veld \\'Contact\\' moet minstens één keer voorkomen.", "detail_tech_data_http_securitytxt_no_content_type": "Fout: HTTP Content-Type header moet worden verstuurd.", "detail_tech_data_http_securitytxt_no_csaf_file": "Fout: Ieder optioneel \\'CSAF\\'-veld moet verwijzen naar een bestand met de naam \\'provider-metadata.json\\'.", "detail_tech_data_http_securitytxt_no_encryption": "Aanbeveling: Het veld \\'Encryption\\' zou aanwezig moeten zijn wanneer het veld \\'Contact\\' een e-mailadres bevat.", "detail_tech_data_http_securitytxt_no_expire": "Fout: Het veld \\'Expires\\' moet aanwezig zijn.", "detail_tech_data_http_securitytxt_no_https": "Fout: De web URI moet beginnen met \\'https://\\' (regel {line_no}).", - "detail_tech_data_http_securitytxt_no_line_separators": "Fout: Elke regel moet eindigen met \u00f3f een carriage return en line feed characters \u00f3f alleen een line feed character.", + "detail_tech_data_http_securitytxt_no_line_separators": "Fout: Elke regel moet eindigen met óf een carriage return en line feed characters óf alleen een line feed character.", "detail_tech_data_http_securitytxt_no_security_txt_404": "Fout: security.txt kon niet gevonden worden.", "detail_tech_data_http_securitytxt_no_security_txt_other": "Fout: security.txt kon niet gevonden worden (onverwachte HTTP response code {status_code}).", "detail_tech_data_http_securitytxt_no_space": "Fout: Veld-scheidingsteken (dubbele punt) moet worden gevolgd door een spatie (regel {line_no}).", @@ -357,57 +438,76 @@ "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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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 \u00f3f \\'none\\', \u00f3f \\'self\\' en/of \u00e9\u00e9n 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_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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_csp_tech_table_findings": "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\u00ebn 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_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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_referrer_policy_tech_table_findings": "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, \u00f3f 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_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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_securitytxt_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_x_content_type_tech_table_x_content_type_options_value": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_x_frame_tech_table_x_frame_options_value": "X-Frame-Options waarde", "detail_web_appsecpriv_http_x_frame_verdict_bad": "Je webserver biedt geen veilig ingestelde X-Frame-Options aan.", "detail_web_appsecpriv_http_x_frame_verdict_good": "Je webserver biedt veilig ingestelde X-Frame-Options aan.", - "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We testen of je webserver een HTTP header voor X-XSS-Protection aanbiedt die een voldoende veilige waarde heeft (dat wil zeggen 1 of 1; mode=block). Deze HTTP header kan worden gebruikt om het beschermingsfilter van browsers tegen reflectieve cross-site scripting (XSS) aanvallen te activeren.

Geldige waardes voor de X-XSS-Protection header zijn:

  • 0 deactiveert het XSS-filter. Deze waarde dient NIET te worden gebruikt.
  • 1 activeert het XSS-filter. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het script opschonen en de onveilige delen verwijderen. Deze waarde is normaal gesproken de standaard-waarde (\\'default\\') in browsers als een website geen X-XSS-Protection header aanbiedt.
  • 1; mode=block activeert het XSS-filter \u00e9n de blokkeermodus. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het antwoord blokkeren en de webpagina niet laden. Dit is de aanbevolen waarde.

Mits goed geconfigureerd kan Content-Security-Policy (CSP) vergelijkbare bescherming en meer bieden aan gebruikers van moderne webbrowsers. X-XSS-Protection biedt in dat geval nog altijd bescherming aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-XSS-Protection waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Niveau van vereistheid: Aanbevolen", + "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We testen of je webserver een HTTP header voor X-XSS-Protection aanbiedt die een voldoende veilige waarde heeft (dat wil zeggen 1 of 1; mode=block). Deze HTTP header kan worden gebruikt om het beschermingsfilter van browsers tegen reflectieve cross-site scripting (XSS) aanvallen te activeren.

Geldige waardes voor de X-XSS-Protection header zijn:

  • 0 deactiveert het XSS-filter. Deze waarde dient NIET te worden gebruikt.
  • 1 activeert het XSS-filter. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het script opschonen en de onveilige delen verwijderen. Deze waarde is normaal gesproken de standaard-waarde (\\'default\\') in browsers als een website geen X-XSS-Protection header aanbiedt.
  • 1; mode=block activeert het XSS-filter én de blokkeermodus. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het antwoord blokkeren en de webpagina niet laden. Dit is de aanbevolen waarde.

Mits goed geconfigureerd kan Content-Security-Policy (CSP) vergelijkbare bescherming en meer bieden aan gebruikers van moderne webbrowsers. X-XSS-Protection biedt in dat geval nog altijd bescherming aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-XSS-Protection waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Niveau van vereistheid: Aanbevolen", "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres|X-XSS-Protection waarde", + "detail_web_appsecpriv_http_x_xss_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres", + "detail_web_appsecpriv_http_x_xss_tech_table_x_xss_protection_value": "X-XSS-Protection waarde", "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt geen veilig ingestelde X-XSS-Protection aan.", "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt veilig ingestelde X-XSS-Protection aan.", "detail_web_dnssec_exists_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, ondertekend is met DNSSEC.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", "detail_web_dnssec_exists_label": "DNSSEC aanwezigheid", "detail_web_dnssec_exists_tech_table": "Domein|Registrar", + "detail_web_dnssec_exists_tech_table_domain": "Domein", + "detail_web_dnssec_exists_tech_table_registrar": "Registrar", "detail_web_dnssec_exists_verdict_bad": "Je domein is onveilig oftewel \\'insecure\\', omdat het niet ondertekend is met DNSSEC.", "detail_web_dnssec_exists_verdict_good": "Je domein is met DNSSEC ondertekend.", "detail_web_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", "detail_web_dnssec_exists_verdict_servfail": "De nameservers van je domeinnaam zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", - "detail_web_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot vari\u00ebrende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zij", + "detail_web_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zij", "detail_web_dnssec_valid_label": "DNSSEC geldigheid", "detail_web_dnssec_valid_tech_table": "Domein|Status", - "detail_web_dnssec_valid_verdict_bad": "Je domeinnaam is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. \u00d3f iemand manipuleerde het antwoord van jouw nameserver, \u00f3f je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", + "detail_web_dnssec_valid_tech_table_domain": "Domein", + "detail_web_dnssec_valid_tech_table_status": "Status", + "detail_web_dnssec_valid_verdict_bad": "Je domeinnaam is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", "detail_web_dnssec_valid_verdict_good": "Je domeinnaam is veilig oftewel \\'secure\\', omdat zijn DNSSEC-handtekening geldig is.", "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Je domeinnaam is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", - "detail_web_ipv6_web_aaaa_exp": "We testen of er tenminste \u00e9\u00e9n AAAA-record met IPv6-adres voor je webserver is.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.", + "detail_web_ipv6_web_aaaa_exp": "We testen of er tenminste één AAAA-record met IPv6-adres voor je webserver is.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.", "detail_web_ipv6_web_aaaa_label": "IPv6-adressen voor webserver", "detail_web_ipv6_web_aaaa_tech_table": "Webserver|IPv6-adres|IPv4-adres", + "detail_web_ipv6_web_aaaa_tech_table_web_server": "Webserver", + "detail_web_ipv6_web_aaaa_tech_table_ipv6_address": "IPv6-adres", + "detail_web_ipv6_web_aaaa_tech_table_ipv4_address": "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 \u00e9\u00e9n van je webservers heeft een IPv6-adres.", - "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 \u2013 299) en \\'redirection messages\\' (300 \u2013 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 \u00e9\u00e9n IPv6-adres en \u00e9\u00e9n 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_aaaa_verdict_good": "Tenminste één van je webservers heeft een IPv6-adres.", + "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 via IPv4 zijn niet hetzelfde via IPv6.", "detail_web_ipv6_web_ipv46_verdict_good": "Je website via IPv6 lijkt identiek via IPv4.", @@ -416,98 +516,140 @@ "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 \u00e9\u00e9n van jouw webservers met een IPv6-adres, is niet bereikbaar via IPv6.", + "detail_web_ipv6_web_reach_tech_table_web_server": "Webserver", + "detail_web_ipv6_web_reach_tech_table_unreachable_ipv6_address": "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.", "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 \u00e9\u00e9n van de IP-adressen van je webserver is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.", + "detail_web_rpki_exists_tech_table_web_server": "Webserver", + "detail_web_rpki_exists_tech_table_ip_address": "IP-adres", + "detail_web_rpki_exists_tech_table_rpki_route_origin_authorization": "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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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_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 \u00e9\u00e9n 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_tech_table_web_server": "Webserver", + "detail_web_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_rpki_valid_tech_table_rpki_origin_validation_state": "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 \u00e9\u00e9n 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) \u00f3f 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_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", "detail_web_tls_cert_hostmatch_tech_table": "Webserver-IP-adres|Niet-overeenkomende domeinen op certificaat", + "detail_web_tls_cert_hostmatch_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Niet-overeenkomende domeinen op certificaat", "detail_web_tls_cert_hostmatch_verdict_bad": "De domeinnaam van je website komt niet overeen met de domeinnaam op je websitecertificaat.", "detail_web_tls_cert_hostmatch_verdict_good": "De domeinnaam van je website komt overeen met de domeinnaam op je websitecertificaat.", - "detail_web_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan \u00e9\u00e9n algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 \u2013 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", + "detail_web_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", "detail_web_tls_cert_pubkey_label": "Publieke sleutel van certificaat", "detail_web_tls_cert_pubkey_tech_table": "Webserver-IP-adres|Getroffen handtekening-parameters|Status", + "detail_web_tls_cert_pubkey_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_pubkey_tech_table_affected_signature_parameters": "Getroffen handtekening-parameters", + "detail_web_tls_cert_pubkey_tech_table_status": "Status", "detail_web_tls_cert_pubkey_verdict_bad": "De digitale handtekening van je websitecertificaat gebruikt onvoldoende veilige parameters.", "detail_web_tls_cert_pubkey_verdict_good": "De digitale handtekening van je websitecertificaat gebruikt veilige parameters.", "detail_web_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van je websitecertificaat gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", "detail_web_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van het websitecertificaat is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", "detail_web_tls_cert_signature_label": "Handtekening van certificaat", "detail_web_tls_cert_signature_tech_table": "Webserver-IP-adres|Getroffen hashing-algoritme|Status", + "detail_web_tls_cert_signature_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_signature_tech_table_affected_hash_algorithm": "Getroffen hashing-algoritme", + "detail_web_tls_cert_signature_tech_table_status": "Status", "detail_web_tls_cert_signature_verdict_bad": "Je websitecertificaat is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", "detail_web_tls_cert_signature_verdict_good": "Je websitecertificaat is ondertekend met een voldoende algoritme voor hashing.", - "detail_web_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit \u00e9n je webserver alle noodzakelijke tussenliggende certificaten presenteert.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B3-4.", + "detail_web_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je webserver alle noodzakelijke tussenliggende certificaten presenteert.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B3-4.", "detail_web_tls_cert_trust_label": "Vertrouwensketen van certificaat", "detail_web_tls_cert_trust_tech_table": "Webserver-IP-adres|Onvertrouwde certificaatketen", + "detail_web_tls_cert_trust_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_trust_tech_table_untrusted_certificate_chain": "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-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_tech_table_web_server_ip_address": "Webserver IP-adres", + "detail_web_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "Eerst gevonden getroffen cipher-paren", + "detail_web_tls_cipher_order_tech_table_violated_rule_ii_b": "Overtreden regel # (\\'II-B\\')", "detail_web_tls_cipher_order_verdict_bad": "Je webserver dwingt niet zijn eigen cipher-voorkeur af (\\'I\\').", "detail_web_tls_cipher_order_verdict_good": "Je webserver dwingt zijn eigen cipher-voorkeur af (\\'I\\'), en biedt ciphers aan conform de voorgeschreven volgorde (\\'II\\').", "detail_web_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver alleen \\'Goede\\' ciphers ondersteunt.", "detail_web_tls_cipher_order_verdict_seclevel_bad": "Je webserver prefereert niet \\'Goede\\' boven \\'Voldoende\\' en dan pas \\'Uit te faseren\\' ciphers (\\'II\\').", "detail_web_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Je webserver biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\\'II-B\\').", - "detail_web_tls_ciphers_exp": "

We testen of je webserver alleen veilige, d.w.z. \\'Goede\\' en/of \\'Voldoende\\', ciphers (ook algoritmeselecties genoemd) ondersteunt.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing. Een webserver kan meer dan \u00e9\u00e9n algoritmeselectie ondersteunen.

  • Vanaf TLS 1.3 omvat de term \\'cipher suite\\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \\'cipher suite\\' ambigu maakt, gebruikt NCSC de term \\'algoritmeselectie\\' om alle vier de functies aan te duiden.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselecties. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \\'Goede\\', \\'Voldoende\\' en \\'Uit te faseren\\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\\'. Achter iedere algoritmeselectie noemen we de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \\'Uit te faseren\\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_web_tls_ciphers_exp": "

We testen of je webserver alleen veilige, d.w.z. \\'Goede\\' en/of \\'Voldoende\\', ciphers (ook algoritmeselecties genoemd) ondersteunt.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing. Een webserver kan meer dan één algoritmeselectie ondersteunen.

  • Vanaf TLS 1.3 omvat de term \\'cipher suite\\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \\'cipher suite\\' ambigu maakt, gebruikt NCSC de term \\'algoritmeselectie\\' om alle vier de functies aan te duiden.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselecties. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \\'Goede\\', \\'Voldoende\\' en \\'Uit te faseren\\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\\'. Achter iedere algoritmeselectie noemen we de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \\'Uit te faseren\\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", "detail_web_tls_ciphers_label": "Ciphers (Algoritmeselecties)", "detail_web_tls_ciphers_tech_table": "Webserver-IP-adres|Getroffen ciphers|Status", + "detail_web_tls_ciphers_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_ciphers_tech_table_affected_ciphers": "Getroffen ciphers", + "detail_web_tls_ciphers_tech_table_status": "Status", "detail_web_tls_ciphers_verdict_bad": "Je webserver ondersteunt een of meer onvoldoende veilige ciphers.", "detail_web_tls_ciphers_verdict_good": "Je webserver ondersteunt alleen veilige ciphers.", "detail_web_tls_ciphers_verdict_phase_out": "Je webserver ondersteunt een of meer ciphers die de status uit te faseren hebben omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_web_tls_compression_exp": "

We testen of je webserver TLS-compressie ondersteunt.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te be\u00efnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", + "detail_web_tls_compression_exp": "

We testen of je webserver TLS-compressie ondersteunt.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", "detail_web_tls_compression_label": "TLS-compressie", "detail_web_tls_compression_tech_table": "Webserver-IP-adres|TLS-compressie", + "detail_web_tls_compression_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_compression_tech_table_tls_compression": "TLS-compressie", "detail_web_tls_compression_verdict_bad": "Je webserver ondersteunt TLS-compressie, wat niet veilig is.", "detail_web_tls_compression_verdict_good": "Je webserver ondersteunt geen TLS-compressie.", "detail_web_tls_dane_exists_exp": "We testen of de nameserver van je websitedomein een correct ondertekend TLSA-record voor DANE bevat.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het websitedomein, of als er DANE-gerelateerde DNSSEC-issues zijn (bijv. geen bewijs voor \\'Denial of Existence\\').

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, Appendix A, onder \\'Certificate pinning en DANE\\'.

Niveau van vereistheid: Optioneel", "detail_web_tls_dane_exists_label": "DANE aanwezigheid", "detail_web_tls_dane_exists_tech_table": "Webserver-IP-adres|DANE TLSA-record aanwezig", + "detail_web_tls_dane_exists_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA-record aanwezig", "detail_web_tls_dane_exists_verdict_bad": "Je websitedomein bevat geen TLSA-record voor DANE.", "detail_web_tls_dane_exists_verdict_bogus": "Je websitedomein bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Vraag je nameserver-beheerder om deze fout op te lossen.", "detail_web_tls_dane_exists_verdict_good": "Je websitedomein bevat een TLSA-record voor DANE.", "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", + "detail_web_tls_dane_rollover_tech_table_dane_rollover_scheme": "DANE rollover scheme", "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", "detail_web_tls_dane_valid_exp": "We testen of de DANE-fingerprint die je domein presenteert geldig is voor je websitecertificaat.

Met DANE kan je informatie over jouw websitecertificaat publiceren in een speciaal DNS-record, een TLSA-record. Clients, zoals webbrowsers, kunnen het certificaat nu niet alleen via de certificaatautoriteit, maar ook via het TLSA-record controleren op authenticiteit. Een client kan het TLSA-record ook als signaal gebruiken om alleen via HTTPS (en niet via HTTP) te verbinden. DNSSEC is een noodzakelijke randvoorwaarde voor DANE. Helaas ondersteunen nog niet veel webbrowsers DANE-validatie.

Niveau van vereistheid: Aanbevolen (alleen als subtest voor \\'DANE aanwezigheid\\' is geslaagd)", "detail_web_tls_dane_valid_label": "DANE geldigheid", "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. \u00d3f iemand manipuleerde het antwoord van jouw nameserver, \u00f3f 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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Sleuteluitwisselingsparameters", "detail_web_tls_fs_params_tech_table": "Webserver-IP-adres|Getroffen parameters|Status", + "detail_web_tls_fs_params_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_fs_params_tech_table_affected_parameters": "Getroffen parameters", + "detail_web_tls_fs_params_tech_table_status": "Status", "detail_web_tls_fs_params_verdict_bad": "Je webserver ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", "detail_web_tls_fs_params_verdict_good": "Je webserver ondersteunt veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", "detail_web_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je webserver niet Diffie-Hellman-sleuteluitwisseling ondersteunt. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", "detail_web_tls_fs_params_verdict_phase_out": "Je webserver ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_web_tls_http_compression_exp": "

We testen of je webserver HTTP-compressie ondersteunt.

Bij het HTTP-protocol wordt compressie vaak gebruikt om de beschikbare bandbreedte effici\u00ebnter te gebruiken. HTTP-compressie maakt de beveiligde verbinding met je webserver echter kwetsbaar voor de BREACH-aanval. Weeg de voors en tegens van HTTP-compressie zorgvuldig tegen elkaar af. Wanneer u kiest voor het gebruik van HTTP-compressie, ga dan na of het mogelijk is om hieruit voortvloeiende potenti\u00eble applicatie-aanvallen te beperken. Een voorbeeld van een dergelijke maatregel is het beperken van de mate waarin een aanvaller de respons van de server kan be\u00efnvloeden.

Dit testonderdeel controleert of de webserver op rootdirectory-niveau HTTP-compressie ondersteunt, maar controleert geen andere websitebronnen zoals plaatje en scripts.

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

Niveau van vereistheid: Optioneel

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", + "detail_web_tls_http_compression_exp": "

We testen of je webserver HTTP-compressie ondersteunt.

Bij het HTTP-protocol wordt compressie vaak gebruikt om de beschikbare bandbreedte efficiënter te gebruiken. HTTP-compressie maakt de beveiligde verbinding met je webserver echter kwetsbaar voor de BREACH-aanval. Weeg de voors en tegens van HTTP-compressie zorgvuldig tegen elkaar af. Wanneer u kiest voor het gebruik van HTTP-compressie, ga dan na of het mogelijk is om hieruit voortvloeiende potentiële applicatie-aanvallen te beperken. Een voorbeeld van een dergelijke maatregel is het beperken van de mate waarin een aanvaller de respons van de server kan beïnvloeden.

Dit testonderdeel controleert of de webserver op rootdirectory-niveau HTTP-compressie ondersteunt, maar controleert geen andere websitebronnen zoals plaatje en scripts.

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

Niveau van vereistheid: Optioneel

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", "detail_web_tls_http_compression_label": "HTTP-compressie", "detail_web_tls_http_compression_tech_table": "Webserver-IP-adres|HTTP-compressie", + "detail_web_tls_http_compression_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_http_compression_tech_table_http_compression": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_https_exists_tech_table_https_existent": "HTTPS aanwezig", "detail_web_tls_https_exists_verdict_bad": "Je website biedt geen HTTPS aan.", "detail_web_tls_https_exists_verdict_good": "Je website biedt HTTPS aan.", "detail_web_tls_https_exists_verdict_other": "Je webserver is niet bereikbaar.", - "detail_web_tls_https_forced_exp": "We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), \u00f3f dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf \\'upgraden\\' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

  • http://example.nl \u21d2 https://example.nl \u21d2 https://www.example.nl
  • http://www.example.nl \u21d2 https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie \\'Webapplicatie-richtlijnen, Verdieping\\' van NCSC, richtlijn U/WA.05.", + "detail_web_tls_https_forced_exp": "We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf \\'upgraden\\' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie \\'Webapplicatie-richtlijnen, Verdieping\\' van NCSC, richtlijn U/WA.05.", "detail_web_tls_https_forced_label": "HTTPS-doorverwijzing", "detail_web_tls_https_forced_tech_table": "Webserver-IP-adres|HTTPS-doorverwijzing", + "detail_web_tls_https_forced_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_https_forced_tech_table_https_redirect": "HTTPS-doorverwijzing", "detail_web_tls_https_forced_verdict_bad": "Je webserver ondersteunt zowel HTTP als HTTPS, maar verwijst bezoekers niet automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", "detail_web_tls_https_forced_verdict_good": "Je webserver verwijst bezoekers automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", "detail_web_tls_https_forced_verdict_no_https": "Deze test is niet uitgevoerd, omdat je webserver geen HTTPS biedt of alleen HTTPS met een te verouderde, onveilige TLS-configuratie.", @@ -515,66 +657,93 @@ "detail_web_tls_https_hsts_exp": "We testen of je webserver HSTS ondersteunt.

Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.

HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt man-in-the-middle-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van tenminste 1 jaar (max-age=31536000) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen.

De test controleert niet of preload wordt gebruikt en of het domein is opgenomen in de HSTS Preload Lijst.

Aanbevelingen voor implementatie

HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze niet bereikbaar zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen.

Daarom adviseren we u om de onderstaande implementatiestappen te volgen:

  1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);

  2. Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina\\'s. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.

  3. Begin met 5 minuten (max-age=300);

  4. Verhoog dit naar 1 week (max-age=604800);
  5. Verhoog dit naar 1 maand (max-age=2592000);

  6. Verhoog het naar 1 jaar (max-age=31536000) of meer.

  7. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik includeSubDomains alleen als je er volledig zeker van bent dat alle (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.

  8. Gebruik preload alleen als je heel zeker weet dat je je domein wil laten opnemen in de HSTS Preload Lijst. HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien.

Zie \\'Webapplicatie-richtlijnen, Verdieping\\' van NCSC, richtlijn U/WA.05.", "detail_web_tls_https_hsts_label": "HSTS", "detail_web_tls_https_hsts_tech_table": "Webserver-IP-adres|HSTS-policy", + "detail_web_tls_https_hsts_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_https_hsts_tech_table_hsts_policy": "HSTS-policy", "detail_web_tls_https_hsts_verdict_bad": "Je webserver biedt geen HSTS-policy aan.", "detail_web_tls_https_hsts_verdict_good": "Je webserver biedt een HSTS-policy aan.", "detail_web_tls_https_hsts_verdict_other": "Je webserver biedt een HSTS-policy aan met een geldigheidsduur voor caching (max-age) die niet voldoende lang (d.w.z. korter dan 1 jaar) is.", - "detail_web_tls_kex_hash_func_exp": "

We testen of je webserver ondersteuning biedt voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver cre\u00ebert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", + "detail_web_tls_kex_hash_func_exp": "

We testen of je webserver ondersteuning biedt voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", "detail_web_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", "detail_web_tls_kex_hash_func_tech_table": "Webserver-IP-adress|SHA-2-ondersteuning voor handtekeningen", + "detail_web_tls_kex_hash_func_tech_table_web_server_ip_address": "Webserver-IP-adress", + "detail_web_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "SHA-2-ondersteuning voor handtekeningen", "detail_web_tls_kex_hash_func_verdict_good": "Je webserver ondersteunt een veilige hashfunctie voor sleuteluitwisseling.", "detail_web_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie je webserver gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", "detail_web_tls_kex_hash_func_verdict_phase_out": "Je webserver ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", - "detail_web_tls_ocsp_stapling_exp": "

We testen of je webserver de TLS Certificate Status extension of te wel OCSP stapling ondersteunt.

De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.

Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifi\u00ebren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.

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

Niveau van vereistheid: Optioneel

OCSP stapling

  • Goed: Aan
  • Voldoende: Uit
", + "detail_web_tls_ocsp_stapling_exp": "

We testen of je webserver de TLS Certificate Status extension of te wel OCSP stapling ondersteunt.

De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.

Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifiëren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.

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

Niveau van vereistheid: Optioneel

OCSP stapling

  • Goed: Aan
  • Voldoende: Uit
", "detail_web_tls_ocsp_stapling_label": "OCSP stapling", "detail_web_tls_ocsp_stapling_tech_table": "Webserver-IP-adres|OCSP stapling", + "detail_web_tls_ocsp_stapling_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", "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\u00ebren met jouw webserver.

In het algemeen is het niet nodig om clients de mogelijkheid te bieden om een renegotiation te initi\u00ebren (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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "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.", "detail_web_tls_renegotiation_client_verdict_good": "Je webserver staat geen client-initiated renegotiation toe.", - "detail_web_tls_renegotiation_secure_exp": "

We testen of je webserver secure renegotiation ondersteunt.

In de oudere versies van TLS (v\u00f3\u00f3r TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", + "detail_web_tls_renegotiation_secure_exp": "

We testen of je webserver secure renegotiation ondersteunt.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", "detail_web_tls_renegotiation_secure_tech_table": "Webserver-IP-adres|Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", "detail_web_tls_renegotiation_secure_verdict_bad": "Je webserver ondersteunt insecure renegotiation, wat uiteraard niet veilig is.", "detail_web_tls_renegotiation_secure_verdict_good": "Je webserver ondersteunt secure renegotiation.", - "detail_web_tls_version_exp": "

We testen of je webserver alleen veilige TLS-versies ondersteunt.

Een webserver kan meer dan \u00e9\u00e9n TLS-versie ondersteunen.

Merk op dat browsermakers hebben aangekondigd dat ze zullen stoppen met de ondersteuning van TLS 1.1 en 1.0. Daardoor zullen websites die geen TLS 1.2 en/of 1.3 ondersteunen onbereikbaar worden.

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_web_tls_version_exp": "

We testen of je webserver alleen veilige TLS-versies ondersteunt.

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

Merk op dat browsermakers hebben aangekondigd dat ze zullen stoppen met de ondersteuning van TLS 1.1 en 1.0. Daardoor zullen websites die geen TLS 1.2 en/of 1.3 ondersteunen onbereikbaar worden.

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_web_tls_version_label": "TLS-versie", "detail_web_tls_version_tech_table": "Webserver-IP-adres|TLS-versie|Status", + "detail_web_tls_version_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_version_tech_table_tls_version": "TLS-versie", + "detail_web_tls_version_tech_table_status": "Status", "detail_web_tls_version_verdict_bad": "Je webserver ondersteunt onvoldoende veilige TLS-versies.", "detail_web_tls_version_verdict_good": "Je webserver ondersteunt alleen veilige TLS-versies.", "detail_web_tls_version_verdict_phase_out": "Je webserver ondersteunt TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_web_tls_zero_rtt_exp": "

We testen of je webserver Zero Round Trip Time Resumption (0-RTT) ondersteunt.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina / opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor early data zoals aangegeven door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging v\u00f3\u00f3r de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-HTTP 425 Too Early, dan wordt aangenomen dat de webserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", + "detail_web_tls_zero_rtt_exp": "

We testen of je webserver Zero Round Trip Time Resumption (0-RTT) ondersteunt.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina / opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor early data zoals aangegeven door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging vóór de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-HTTP 425 Too Early, dan wordt aangenomen dat de webserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", "detail_web_tls_zero_rtt_label": "0-RTT", "detail_web_tls_zero_rtt_tech_table": "Webserver-IP-adres|0-RTT", + "detail_web_tls_zero_rtt_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_zero_rtt_tech_table_0_rtt": "0-RTT", "detail_web_tls_zero_rtt_verdict_bad": "Je webserver ondersteunt 0-RTT, wat niet veilig is.", "detail_web_tls_zero_rtt_verdict_good": "Je webserver ondersteunt geen 0-RTT.", "detail_web_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver TLS 1.3 niet ondersteunt. ", "detail_web_mail_ipv6_ns_aaaa_exp": "We testen of je domeinnaam tenminste twee nameservers met een IPv6-adres heeft.

Dit sluit aan bij de \"Technische eisen voor registratie en gebruik van .nl-domeinnamen\" d.d. 13 november 2017 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze test, aangezien zij geen IPv6-connectiviteit bieden.", "detail_web_mail_ipv6_ns_aaaa_label": "IPv6-adressen voor nameservers", "detail_web_mail_ipv6_ns_aaaa_tech_table": "Nameserver|IPv6-adres|IPv4-adres", + "detail_web_mail_ipv6_ns_aaaa_tech_table_name_server": "Nameserver", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv6_address": "IPv6-adres", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv4_address": "IPv4-adres", "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "Geen van de nameservers van je domeinnaam heeft een IPv6-adres.", "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Twee of meer nameservers van je domeinnaam hebben een IPv6-adres.", - "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Slechts \u00e9\u00e9n nameserver van je domeinnaam heeft een IPv6-adres.", + "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Slechts één nameserver van je domeinnaam heeft een IPv6-adres.", "detail_web_mail_ipv6_ns_reach_exp": "We testen of alle nameservers, die een AAAA-record met IPv6-adres hebben, bereikbaar zijn via IPv6.", "detail_web_mail_ipv6_ns_reach_label": "IPv6-bereikbaarheid van nameservers", "detail_web_mail_ipv6_ns_reach_tech_table": "Nameserver|Onbereikbaar IPv6-adres", + "detail_web_mail_ipv6_ns_reach_tech_table_name_server": "Nameserver", + "detail_web_mail_ipv6_ns_reach_tech_table_unreachable_ipv6_address": "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.", "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 \u00e9\u00e9n van de IP-adressen van je nameservers is geen RPKI Route Origin Authorisation (ROA) gepubliceerd.", + "detail_web_mail_rpki_ns_exists_tech_table_name_server": "Nameserver", + "detail_web_mail_rpki_ns_exists_tech_table_ip_address": "IP-adres", + "detail_web_mail_rpki_ns_exists_tech_table_rpki_route_origin_authorization": "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.

1\u2024 Valid: De route-aankondiging van het desbetreffende IP-adres wordt gematcht door tenminste \u00e9\u00e9n 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\u2024 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\u2024 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) \u00f3f 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_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 \u00e9\u00e9n 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_tech_table_name_server": "Nameserver", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_mail_rpki_ns_valid_tech_table_rpki_origin_validation_state": "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 \u00e9\u00e9n 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) \u00f3f 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_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}} ", @@ -589,25 +758,25 @@ "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 \u21d2 nulscore", - "faqs_report_subtest_error": "Testfout: uitvoeringsfout tijdens testen \u21d2 nulscore", - "faqs_report_subtest_good": "Goed: geslaagd voor VEREISTE, AANBEVOLEN of OPTIONELE subtest \u21d2 eerste: volledige score / laatste twee: geen impact op score", - "faqs_report_subtest_info": "Ter informatie: gezakt voor OPTIONELE subtest \u21d2 geen impact op score", - "faqs_report_subtest_not_tested": "Niet getest, want al gezakt voor gerelateerde bovenliggende subtest \u21d2 nulscore", + "faqs_report_subtest_bad": "Slecht: gezakt voor VEREISTE subtest ⇒ nulscore", + "faqs_report_subtest_error": "Testfout: uitvoeringsfout tijdens testen ⇒ nulscore", + "faqs_report_subtest_good": "Goed: geslaagd voor VEREISTE, AANBEVOLEN of OPTIONELE subtest ⇒ eerste: volledige score / laatste twee: geen impact op score", + "faqs_report_subtest_info": "Ter informatie: gezakt voor OPTIONELE subtest ⇒ geen impact op score", + "faqs_report_subtest_not_tested": "Niet getest, want al gezakt voor gerelateerde bovenliggende subtest ⇒ nulscore", "faqs_report_subtest_title": "Iconen per subtest", - "faqs_report_subtest_warning": "Waarschuwing: gezakt voor AANBEVOLEN subtest \u21d2 geen impact op score", - "faqs_report_test_bad": "Slecht: gezakt voor tenminste \u00e9\u00e9n VEREISTE subtest \u21d2 geen volledige score voor testcategorie", - "faqs_report_test_error": "Testfout: uitvoeringsfout voor tenminste \u00e9\u00e9n subtest \u21d2 geen resultaat voor testcategorie", - "faqs_report_test_good": "Goed: geslaagd voor alle subtesten \u21d2 volledige score voor testcategorie ", - "faqs_report_test_info": "Ter informatie: gezakt voor tenminste \u00e9\u00e9n OPTIONELE subtest \u21d2 volledige score voor testcategorie", + "faqs_report_subtest_warning": "Waarschuwing: gezakt voor AANBEVOLEN subtest ⇒ geen impact op score", + "faqs_report_test_bad": "Slecht: gezakt voor tenminste één VEREISTE subtest ⇒ geen volledige score voor testcategorie", + "faqs_report_test_error": "Testfout: uitvoeringsfout voor tenminste één subtest ⇒ geen resultaat voor testcategorie", + "faqs_report_test_good": "Goed: geslaagd voor alle subtesten ⇒ volledige score voor testcategorie ", + "faqs_report_test_info": "Ter informatie: gezakt voor tenminste één OPTIONELE subtest ⇒ volledige score voor testcategorie", "faqs_report_test_title": "Iconen per testcategorie", - "faqs_report_test_warning": "Waarschuwing: gezakt voor tenminste \u00e9\u00e9n AANBEVOLEN subtest \u21d2 volledige score voor testcategorie ", + "faqs_report_test_warning": "Waarschuwing: gezakt voor tenminste één AANBEVOLEN subtest ⇒ volledige score voor testcategorie ", "faqs_report_title": "Toelichting op testrapport", "faqs_rpki_title": "Autorisatie voor routering (RPKI)", "faqs_starttls_title": "Beveiligd e-mailtransport (STARTTLS en DANE)", "faqs_title": "Kennisbank", "halloffame_champions_menu": "Kampioenen!", - "halloffame_champions_subtitle": "100% in website- \u00e9n e-mailtest", + "halloffame_champions_subtitle": "100% in website- én e-mailtest", "halloffame_champions_text": "De {{count}} onderstaande domeinnamen scoren 100% in zowel de websitetest als de e-mailtest. Leden van deze Hall of Fame mogen beide 100%-badges gebruiken.", "halloffame_champions_title": "Hall of Fame - Kampioenen!", "halloffame_mail_badge": "Badge met tekst: 100%-score in e-mailtest", @@ -750,7 +919,7 @@ "test_mailipv6_warning_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", "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 \u00e9\u00e9n 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) \u00f3f 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_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)", @@ -758,20 +927,20 @@ "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": "Helaas! Ten minste \u00e9\u00e9n 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)", "test_mailtls_info_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_info_summary": "Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)", - "test_mailtls_invalid_null_mx_description": "Waarschuwing: Je domeinnaam adverteert een \"Null MX\" record dat aangeeft dat deze geen e-mail accepteert. Echter, \u00f3f je domeinnaam heeft geen A/AAAA records, waardoor het \"Null MX\" record onnodig is. \u00d3f op je domeinnaam is een ontvangende mailserver ingesteld door een ander MX record, waardoor de \"Null MX\" tegenstrijdig is.", + "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: 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\u00ebn IPv6 en DNSSEC niet van toepassing.", + "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 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\u00ebn IPv6 en DNSSEC niet van toepassing.", + "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\u00ebn voor STARTTLS en DANE niet van toepassing. Dit geldt ook voor de mailserver-specifieke subtesten in de categorie\u00ebn voor IPv6 en DNSSEC.", + "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)", "test_mailtls_null_mx_with_other_mx_description": "Waarschuwing: 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.", "test_mailtls_null_mx_with_other_mx_summary": "Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)", @@ -780,21 +949,21 @@ "test_mailtls_passed_description": "Goed gedaan! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) een beveiligde verbinding opzetten. STARTTLS voorkomt dat passieve aanvallers e-mails onderweg naar jou kunnen lezen. DANE beschermt tegen actieve aanvallers, die door manipulatie van het mailverkeer de STARTTLS-encryptie kunnen verwijderen.", "test_mailtls_passed_summary": "Mailserver-verbinding voldoende beveiligd (STARTTLS en DANE)", "test_mailtls_title": "Beveiligde mailserver-verbinding?", - "test_mailtls_unreachable_description": "Testfout: tenminste \u00e9\u00e9n van jouw ontvangende mailservers was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw mailserver(s).", + "test_mailtls_unreachable_description": "Testfout: tenminste één van jouw ontvangende mailservers was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw mailserver(s).", "test_mailtls_unreachable_summary": "Onbereikbare ontvangende mailserver (STARTTLS en DANE)", - "test_mailtls_untestable_description": "Testfout: tenminste \u00e9\u00e9n van jouw ontvangende mailservers was niet testbaar voor ons. Daardoor was het niet mogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door onder meer SMTP errors en geactiveerde ratelimiting-maatregelen die verbindingen tegenhouden.", + "test_mailtls_untestable_description": "Testfout: tenminste één van jouw ontvangende mailservers was niet testbaar voor ons. Daardoor was het niet mogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door onder meer SMTP errors en geactiveerde ratelimiting-maatregelen die verbindingen tegenhouden.", "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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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_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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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_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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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_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. Security headers zijn ook relevant voor domeinen met HTTP response codes zoals \\'301 Redirect\\' en \\'404 Not Found\\', omdat ze hun eigen browsercontext cre\u00ebren (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_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)", @@ -818,7 +987,7 @@ "test_siteipv6_warning_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", "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 \u00e9\u00e9n 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) \u00f3f 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_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)", @@ -826,7 +995,7 @@ "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": "Helaas! Ten minste \u00e9\u00e9n 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)", From dfeafae027733658bc63104da2ee264faddf9d6b Mon Sep 17 00:00:00 2001 From: stitch1 Date: Wed, 19 Feb 2025 13:20:20 +0100 Subject: [PATCH 7/9] also include tech table translations with english keys --- .../logic/internet_nl_translations.py | 2 +- .../js/translations/internet_nl.en.json | 1017 ----------------- .../js/translations/internet_nl.nl.json | 1017 ----------------- 3 files changed, 1 insertion(+), 2035 deletions(-) delete mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json delete mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json diff --git a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py index f80bb915..8447837f 100644 --- a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py +++ b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py @@ -279,7 +279,7 @@ def _js_safe_msgid(text): def _js_safe_msgstr(msgstr): # a poor mans escape for single quotes. - msgstr = msgstr.replace("'", "\\'") + # msgstr = msgstr.replace("'", "\\'") html = markdown.markdown(msgstr) one_line_html = html.replace("\n", "") diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json deleted file mode 100644 index 1b5b627d..00000000 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json +++ /dev/null @@ -1,1017 +0,0 @@ -{ - "about_contact": "

Contact

Internet Standards Platform
c/o ECP
Maanweg 174 (8th floor)
2516 AB The Hague
The Netherlands

CoC number: 27169301

Email

question@internet.nl

PGP public key
Fingerprint: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Expiration date: 19th of March 2025

", - "base_about": "About Internet.nl", - "base_accessibility": "Accessibility", - "base_blogs": "Blogs", - "base_contact": "Contact", - "base_copyright": "Copyright", - "base_disclosure": "Report vulnerability", - "base_faqs": "Knowledge base", - "base_halloffame": "Hall of Fame", - "base_halloffame_champions": "Hall of Fame - Champions!", - "base_halloffame_lead": "{{count}} domains with 2 x 100%
Latest entry: {{latest|date:\\'d-m-Y\\'}}", - "base_halloffame_link": "To Hall of Fame - Champions!", - "base_halloffame_mail": "Hall of Fame - Email", - "base_halloffame_web": "Hall of Fame - Websites", - "base_home": "Home", - "base_info": "Internet.nl is an initiative of the Internet community and the Dutch government.", - "base_news": "News", - "base_newslink": "To the news overview", - "base_privacy": "Privacy statement", - "base_test_connection_explain": "

What is tested?

After you start the connection test, we will check if your currently used internet connection offers support for the modern Internet Standards below.

  • IPv6: are websites with modern internet addresses reachable for you?
  • DNSSEC: are domain signatures validated for you?

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your internet connection. Usually contacting your internet provider on this will be the best next step. In the communication with your internet provider you can use the permalink (i.e. the URL) of the test report.

Test your connection

", - "base_test_connection_label": "Test your connection", - "base_test_connection_text": "Modern addresses reachable?
Domain signatures validated?", - "base_test_connection_title": "About the connection test", - "base_test_explain": "About the test", - "base_test_mail_explain": "

What is tested?

After you enter a domain name of an email service, we will test if the email service offers support for the modern Internet Standards below.

Note: some standards are even relevant if there are no mail servers configured for your domain.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your mail service. Usually contacting your mail hoster on this will be the best next step. In the communication with your mail hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the email test into your own website using our widget code.

Test your email

", - "base_test_mail_input": "Your email address:", - "base_test_mail_label": "Test your email", - "base_test_mail_text": "Modern address? Anti-phishing? Secure transport? Route authorisation?", - "base_test_mail_title": "About the email test", - "base_test_prechecks_invalid_domain": "The given domain is invalid!
Explanation: An A and/or AAAA record is necessary for the website test, and a SOA record for the email test.", - "base_test_start": "Start test", - "base_test_website_explain": "

What is tested?

After you enter a domain name of a website, we will test if the website offers support for the modern Internet Standards below.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your website. Usually contacting your web hoster on this will be the best next step. In the communication with your web hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the website test into your own website using our widget code.

Test your website

", - "base_test_website_input": "Your website domain name:", - "base_test_website_label": "Test your website", - "base_test_website_text": "Modern address? Signed domain? Secure connection? Route authorisation?", - "base_test_website_title": "About the website test", - "base_widget_mail": "Email test widget", - "base_widget_site": "Website test widget", - "connection_pagetitle": "Connection test", - "connection_title": "Connection test", - "detail_conn_dnssec_validation_exp": "We check if the resolvers that you use validate the DNSSEC signatures of our domain name. Resolvers are usually provided by your internet provider. Alternatively you can configure resolvers from another DNS provider. You can even use your own locally installed resolver. Although validation is done in the resolver, the communication from the resolver back to your device (referred to as \\'last mile\\') could still be tampered with by an attacker. Thus the most secure way is to validate close to the end user device (e.g. by using a locally installed resolver), or make sure that the channel between your resolver and your end user device is secured/trusted.", - "detail_conn_dnssec_validation_label": "DNSSEC validation", - "detail_conn_dnssec_validation_tech_table": "DNS provider", - "detail_conn_dnssec_validation_tech_table_dns_provider": "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 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_tech_table_anonymized_ipv6_address": "Anonymized IPv6 address", - "detail_conn_ipv6_connection_tech_table_reverse_name": "Reverse name", - "detail_conn_ipv6_connection_tech_table_internet_provider": "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 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 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_tech_table_anonymized_ipv4_address": "Anonymized IPv4 address", - "detail_conn_ipv6_ipv4_conn_tech_table_reverse_name": "Reverse name", - "detail_conn_ipv6_ipv4_conn_tech_table_internet_provider": "Internet provider", - "detail_conn_ipv6_ipv4_conn_verdict_bad": "You are not able to reach computers via DNS on their IPv4 address.", - "detail_conn_ipv6_ipv4_conn_verdict_good": "You are able to reach computers via DNS on their IPv4 address.", - "detail_conn_ipv6_privacy_exp": "We check if your device uses IPv6 Privacy Extensions for SLAAC (or another IPv6 configuration process than SLAAC) in order to prevent leakage of its potentially privacy sensitive MAC address to computers it connects with over IPV6.", - "detail_conn_ipv6_privacy_label": "Privacy Extensions for IPv6", - "detail_conn_ipv6_privacy_verdict_bad": "You are using SLAAC without \\'IPv6 Privacy Extensions\\'.", - "detail_conn_ipv6_privacy_verdict_good": "You have enabled \\'IPv6 Privacy Extensions\\' (or you are not using SLAAC).", - "detail_conn_ipv6_resolver_conn_exp": "We check if at least one of the DNS resolvers that you are using is able to reach our authoritative name servers over IPv6. Usually your internet provider provides the DNS resolver(s).", - "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).

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.", - "detail_mail_auth_dkim_verdict_no_email": "Your domain does not support DKIM records. However because your DMARC and SPF records hint that no mail is sent from your domain, DKIM is not necessary and this subtest is skipped.", - "detail_mail_auth_dmarc_exp": "We check if DMARC is available for your domain. A receiving mail server mayuse your DMARC policy to evaluate how to handle a mail with your domain assender that could not be authenticated with both DKIM and SPF, and it mayuse your mail address from the DMARC record to provide feedback reports onthe authentication to you. Having more than one DMARC record in the same domainis not valid and will lead to a test failure.Note: DMARC requires the SPFdomain (envelope sender, i.e. return-path that shows up in MAIL FROM) andthe DKIM domain (d=) to align with the mail body domain (From:).", - "detail_mail_auth_dmarc_label": "DMARC existence", - "detail_mail_auth_dmarc_tech_table": "DMARC record|Found on", - "detail_mail_auth_dmarc_tech_table_dmarc_record": "DMARC record", - "detail_mail_auth_dmarc_tech_table_found_on": "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_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. ", - "detail_mail_auth_dmarc_policy_verdict_good": "Your DMARC policy is sufficiently strict.", - "detail_mail_auth_dmarc_policy_verdict_policy": "Your DMARC policy is not sufficiently strict.", - "detail_mail_auth_spf_exp": "We check if your domain has an SPF record. A receiving mail server can use the IP addresses in your SPF record to authenticate the sending mail server of a received email with your domain as sender. The accompanying policy can be used to take appropriate action if authentication fails. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", - "detail_mail_auth_spf_label": "SPF existence", - "detail_mail_auth_spf_tech_table": "SPF record", - "detail_mail_auth_spf_tech_table_spf_record": "SPF record", - "detail_mail_auth_spf_verdict_bad": "Your domain does not have a valid SPF record.", - "detail_mail_auth_spf_verdict_good": "Your domain has an SPF record.", - "detail_mail_auth_spf_policy_exp": "We check if the syntax of your SPF record is correct and if it contains a sufficiently strict policy i.e. ~all (softfail) or -all (fail) in order to prevent abuse by phishers and spammers. To be effective against abuse of your domain, a liberal policy i.e. +all (pass) or ?all (neutral) is insufficient. If all is missing and a redirect modifier is not present in your SPF record, the default is ?all.

We also follow include and redirect for valid SPF records. In addition, we check that your SPF record does not exceed the allowed number of 10 DNS lookups making it ineffective. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. While the SPF terms all, ip4, ip6 and exp do not count as DNS lookups.

Note that if the include or redirect domain consists of macros, we will not follow them as we do not have the necessary information from an actual mail or mail server connection to expand those macros. This means that we do not evaluate the outcome of macros. Moreover, we do not count DNS lookups caused by macros to determine whether the allowed number of DNS lookups has been exceeded.

For sending domains, using ~all (softfail) instead of -all (fail) is usually preferred. This is because when SPF authentication fails with an SPF fail, a receiving mail server may already block the connection without evaluating the DKIM signature and DMARC policy. This can lead to falsely blocked mails (e.g. when mails are automatically forwarded by the receiving mail server to another receiving mail server). Note that a triggered SPF softfail still ensures that a strict DMARC policy protects your domain if DKIM authentication also fails.

For no-mail domains see the good practice on explanation of the \"DMARC policy\" subtest.", - "detail_mail_auth_spf_policy_label": "SPF policy", - "detail_mail_auth_spf_policy_tech_table": "Domain|SPF record", - "detail_mail_auth_spf_policy_tech_table_domain": "Domain", - "detail_mail_auth_spf_policy_tech_table_spf_record": "SPF record", - "detail_mail_auth_spf_policy_verdict_all": "Your SPF policy is not sufficiently strict.", - "detail_mail_auth_spf_policy_verdict_bad": "Your SPF policy is not syntactically correct.", - "detail_mail_auth_spf_policy_verdict_good": "Your SPF policy is sufficiently strict.", - "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 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_tech_table_email_address_domain": "Email address domain", - "detail_mail_dnssec_exists_tech_table_registrar": "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 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_tech_table_domain_of_mail_server_mx": "Domain of mail server (MX)", - "detail_mail_dnssec_mx_exists_tech_table_dnssec_existent": "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": "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.", - "detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error": "Unfortunately an error occurred in Internet.nl\\'s resolver. Please contact us.", - "detail_mail_dnssec_mx_exists_verdict_servfail": "The name servers of at least one of your mail server domains are broken. They returned an error (SERVFAIL) to our queries for a DNSSEC signature. Please contact your name server operator (often your mail provider) to fix this soon.", - "detail_mail_dnssec_mx_valid_exp": "We check if the domains of your receiving mail servers (MX), more specifically their SOA records, are signed with a valid signature making them \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", - "detail_mail_dnssec_mx_valid_label": "DNSSEC validity", - "detail_mail_dnssec_mx_valid_tech_table": "Domain of mail server (MX)|Status", - "detail_mail_dnssec_mx_valid_tech_table_domain_of_mail_server_mx": "Domain of mail server (MX)", - "detail_mail_dnssec_mx_valid_tech_table_status": "Status", - "detail_mail_dnssec_mx_valid_verdict_bad": "At least one of your signed mail server domains is \\'bogus\\', because its DNSSEC signature is not valid. Either someone manipulated the responses from its name servers, or your mail server domain has serious DNSSEC configuration errors. The latter makes your receiving mail server unreachable for any sending mail server that validates DNSSEC signatures. You should contact the name server operator (often your mail provider) as soon as possible.", - "detail_mail_dnssec_mx_valid_verdict_good": "All your signed mail server domains are secure, because their DNSSEC signatures are valid.", - "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "At least one of your mail server domains is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", - "detail_mail_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", - "detail_mail_dnssec_valid_label": "DNSSEC validity", - "detail_mail_dnssec_valid_tech_table": "Email address domain|Status", - "detail_mail_dnssec_valid_tech_table_email_address_domain": "Email address domain", - "detail_mail_dnssec_valid_tech_table_status": "Status", - "detail_mail_dnssec_valid_verdict_bad": "Your email address domain is \\'bogus\\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", - "detail_mail_dnssec_valid_verdict_good": "Your email address domain is secure, because its DNSSEC signature is valid.", - "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Your email address domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", - "detail_mail_ipv6_mx_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for every receiving mail server (MX). In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.", - "detail_mail_ipv6_mx_aaaa_label": "IPv6 addresses for mail server(s)", - "detail_mail_ipv6_mx_aaaa_tech_table": "Mail server (MX)|IPv6 address|IPv4 address", - "detail_mail_ipv6_mx_aaaa_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_ipv6_mx_aaaa_tech_table_ipv6_address": "IPv6 address", - "detail_mail_ipv6_mx_aaaa_tech_table_ipv4_address": "IPv4 address", - "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 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": "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_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_ipv6_mx_reach_tech_table_unreachable_ipv6_address": "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.", - "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_tech_table_mail_server": "Mail server", - "detail_mail_rpki_exists_tech_table_ip_address": "IP address", - "detail_mail_rpki_exists_tech_table_rpki_route_origin_authorization": "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.", - "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_tech_table_name_server_of_mx": "Name server of MX", - "detail_mail_rpki_mx_ns_exists_tech_table_ip_address": "IP address", - "detail_mail_rpki_mx_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server_of_mx": "Name server of MX", - "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_mail_rpki_mx_ns_valid_tech_table_rpki_origin_validation_state": "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 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.

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_tech_table_mail_server": "Mail server", - "detail_mail_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_mail_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_mail_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", - "detail_mail_tls_cert_hostmatch_tech_table": "Mail server (MX)|Unmatched domains on certificate", - "detail_mail_tls_cert_hostmatch_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Unmatched domains on certificate", - "detail_mail_tls_cert_hostmatch_verdict_bad": "The domain name of at least one of your mail servers does not match the domain name on the mail server certificate.", - "detail_mail_tls_cert_hostmatch_verdict_good": "The domain names of all your mail servers match the domain names on your mail server certificates.", - "detail_mail_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
", - "detail_mail_tls_cert_pubkey_label": "Public key of certificate", - "detail_mail_tls_cert_pubkey_tech_table": "Mail server (MX)|Affected signature parameters|Status", - "detail_mail_tls_cert_pubkey_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_cert_pubkey_tech_table_affected_signature_parameters": "Affected signature parameters", - "detail_mail_tls_cert_pubkey_tech_table_status": "Status", - "detail_mail_tls_cert_pubkey_verdict_bad": "The digital signature of at least one of your mail server certificates uses insufficiently secure parameters.", - "detail_mail_tls_cert_pubkey_verdict_good": "The digital signatures of all your mail server certificates use secure parameters.", - "detail_mail_tls_cert_pubkey_verdict_phase_out": "The digital signature of at least one of your mail server certificates uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", - "detail_mail_tls_cert_signature_exp": "

We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", - "detail_mail_tls_cert_signature_label": "Signature of certificate", - "detail_mail_tls_cert_signature_tech_table": "Mail server (MX)|Affected hash algorithm|Status", - "detail_mail_tls_cert_signature_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_cert_signature_tech_table_affected_hash_algorithm": "Affected hash algorithm", - "detail_mail_tls_cert_signature_tech_table_status": "Status", - "detail_mail_tls_cert_signature_verdict_bad": "At least one of your mail server certificates is signed using a hash algorithm that is insufficiently secure.", - "detail_mail_tls_cert_signature_verdict_good": "All your mail server certificates are signed using a secure hash algorithm.", - "detail_mail_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your mail server certificates.

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

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

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

Requirement level: Optional", - "detail_mail_tls_cert_trust_label": "Trust chain of certificate", - "detail_mail_tls_cert_trust_tech_table": "Mail server (MX)|Untrusted certificate chain", - "detail_mail_tls_cert_trust_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_cert_trust_tech_table_untrusted_certificate_chain": "Untrusted certificate chain", - "detail_mail_tls_cert_trust_verdict_bad": "The trust chain of at least one of your mail server certificates is not complete and/or not signed by a trusted root certificate authority.", - "detail_mail_tls_cert_trust_verdict_good": "The trust chain of all your mail server certificates is complete and signed by a trusted root certificate authority.", - "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_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "First found affected cipher pair", - "detail_mail_tls_cipher_order_tech_table_violated_rule_ii_b": "Violated rule # (\\'II-B\\')", - "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\\').", - "detail_mail_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

At least one of your mail servers does not offer ciphers in accordance with the prescribed ordering within a particular security level (\\'II-B\\').", - "detail_mail_tls_ciphers_exp": "

We check if your receiving mail servers (MX) only support secure, i.e. \\'Good\\' and/or \\'Sufficient\\', ciphers (also known as algorithm selections).

To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \\'cipher suite\\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \\'cipher suite\\' ambiguous, NCSC-NL uses the term \\'algorithm selection\\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \\'Good\\', \\'Sufficient\\' and \\'Phase out\\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \\'IT Security Guidelines for Transport Layer Security (TLS)\\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \\'Phase out\\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", - "detail_mail_tls_ciphers_label": "Ciphers (Algorithm selections)", - "detail_mail_tls_ciphers_tech_table": "Mail server (MX)|First found affected cipher|Status", - "detail_mail_tls_ciphers_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_ciphers_tech_table_first_found_affected_cipher": "First found affected cipher", - "detail_mail_tls_ciphers_tech_table_status": "Status", - "detail_mail_tls_ciphers_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure ciphers.", - "detail_mail_tls_ciphers_verdict_good": "All your mail servers support secure ciphers only.", - "detail_mail_tls_ciphers_verdict_phase_out": "At least one of your mail servers supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", - "detail_mail_tls_compression_exp": "

We check if your receiving mail servers (MX) support TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression
  • Insufficient: TLS compression
", - "detail_mail_tls_compression_label": "TLS compression", - "detail_mail_tls_compression_tech_table": "Mail server (MX)|TLS compression", - "detail_mail_tls_compression_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_compression_tech_table_tls_compression": "TLS compression", - "detail_mail_tls_compression_verdict_bad": "At least on of your mail servers supports TLS compression, which is not secure.", - "detail_mail_tls_compression_verdict_good": "All your mail servers do not support TLS compression.", - "detail_mail_tls_dane_exists_exp": "We check if the name servers of each of your receiving mail servers (MX) provide a TLSA record for DANE.

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

Note that the test ignores TLSA records of the types PKIX-TA(0) or PKIX-EE(1) as these should not be used for receiving mail servers.

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

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, Appendix A, under \\'Certificate pinning and DANE\\' (in English).", - "detail_mail_tls_dane_exists_label": "DANE existence", - "detail_mail_tls_dane_exists_tech_table": "Mail server (MX)|DANE TLSA record existent", - "detail_mail_tls_dane_exists_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA record existent", - "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.

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_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_dane_rollover_tech_table_dane_rollover_scheme": "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.", - "detail_mail_tls_dane_rollover_verdict_good": "All your mail server domains have an active DANE scheme for a reliable rollover of certificate keys.", - "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_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_dane_valid_tech_table_dane_tlsa_record_valid": "DANE TLSA record valid", - "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_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_fs_params_tech_table_affected_parameters": "Affected parameters", - "detail_mail_tls_fs_params_tech_table_security_level": "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.", - "detail_mail_tls_fs_params_verdict_good": "All your mail servers support secure parameters for Diffie-Hellman key exchange.", - "detail_mail_tls_fs_params_verdict_na": "This subtest is not applicable as your mail servers do not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.", - "detail_mail_tls_fs_params_verdict_phase_out": "At least one of your mail servers supports parameters for Diffie-Hellman key exchange that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", - "detail_mail_tls_kex_hash_func_exp": "

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

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", - "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_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "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_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", - "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mail server (MX)|OCSP stapling", - "detail_mail_tls_ocsp_stapling_tech_table_outdated_text_test_not_used_mail_server_mx": "OUTDATED TEXT; TEST NOT USED
Mail server (MX)", - "detail_mail_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", - "detail_mail_tls_ocsp_stapling_verdict_bad": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers supports OCSP stapling but responds with invalid data", - "detail_mail_tls_ocsp_stapling_verdict_good": "OUTDATED TEXT; TEST NOT USED
Your mail servers support OCSP stapling.", - "detail_mail_tls_ocsp_stapling_verdict_ok": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers does not support OCSP stapling.", - "detail_mail_tls_renegotiation_client_exp": "

We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX).

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", - "detail_mail_tls_renegotiation_client_label": "Client-initiated renegotiation", - "detail_mail_tls_renegotiation_client_tech_table": "Mail server (MX)|Client-initiated renegotiation", - "detail_mail_tls_renegotiation_client_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "Client-initiated renegotiation", - "detail_mail_tls_renegotiation_client_verdict_bad": "At least one of your mail servers allows for client-initiated renegotiation, which could have negative impact on the availability of your mail server.", - "detail_mail_tls_renegotiation_client_verdict_good": "All your mail servers do not allow for client-initiated renegotiation.", - "detail_mail_tls_renegotiation_secure_exp": "

We check if your mail servers (MX) support secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", - "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", - "detail_mail_tls_renegotiation_secure_tech_table": "Mail server (MX)|Secure renegotiation", - "detail_mail_tls_renegotiation_secure_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", - "detail_mail_tls_renegotiation_secure_verdict_bad": "At least one of your mail servers supports insecure renegotiation, which is obviously not secure.", - "detail_mail_tls_renegotiation_secure_verdict_good": "All your mail servers support secure renegotiation.", - "detail_mail_tls_starttls_exists_exp": "We check if your receiving mail servers (MX) support STARTTLS. If so, we also check in the subtests of this test category whether STARTTLS is configured sufficiently secure.

Because of performance reasons at most ten mail servers over either IPv6 or IPv4 are tested for STARTTLS and DANE.

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

Non-receiving domain:

  1. Null MX: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use \"Null MX\" (RFC 7505). Note that a \"Null MX record\" should not be combined with a normal MX record that is pointing to a mail host.

  2. No MX: In case your domain does not have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even not an \"Null MX\" record).

  3. If we detect any of the above two cases, the subtests in the STARTTLS and DANE category are not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. Other subtests of the email test (e.g. for DMARC) are still applicable.

  4. Note that having a \"Null MX\" record or no MX record could also impact sending mail, because receiving servers may reject email that has an invalid return address.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", - "detail_mail_tls_starttls_exists_label": "STARTTLS available", - "detail_mail_tls_starttls_exists_tech_table": "Mail server (MX)|STARTTLS", - "detail_mail_tls_starttls_exists_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_starttls_exists_tech_table_starttls": "STARTTLS", - "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 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": "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", - "detail_mail_tls_version_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_version_tech_table_tls_versions": "TLS versions", - "detail_mail_tls_version_tech_table_status": "Status", - "detail_mail_tls_version_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure TLS versions.", - "detail_mail_tls_version_verdict_good": "All your mail servers support secure TLS versions only.", - "detail_mail_tls_version_verdict_phase_out": "At least one of your mail servers supports one or more TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", - "detail_mail_tls_zero_rtt_exp": "

We check if your mail servers (MX) support Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your mail servers do not support TLS 1.3, the test is not applicable.For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLSsession is initiated. The amount ofearly datasupport indicated by themail server is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theEHLO command before the TLS handshake but after the STARTTLS command(i.e. no round trips (0-RTT) needed before application data to the server).If the TLS handshake is completed and the mail server responds,then the mail server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", - "detail_mail_tls_zero_rtt_label": "0-RTT", - "detail_mail_tls_zero_rtt_tech_table": "Mail server (MX)|0-RTT", - "detail_mail_tls_zero_rtt_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_zero_rtt_tech_table_0_rtt": "0-RTT", - "detail_mail_tls_zero_rtt_verdict_bad": "At least one of your mail servers supports 0-RTT, which is not secure.", - "detail_mail_tls_zero_rtt_verdict_good": "None of your mail servers support 0-RTT.", - "detail_mail_tls_zero_rtt_verdict_na": "This subtest is not applicable as your mail servers do not support TLS 1.3.", - "detail_tech_data_bogus": "bogus", - "detail_tech_data_good": "good", - "detail_tech_data_http_csp_has_bare_https": "Recommendation: \\'https:\\' scheme without a specific main domain should not be used (#9).", - "detail_tech_data_http_csp_has_data": "Recommendation: \\'data:\\' scheme should not be used where that is not permitted (#7).", - "detail_tech_data_http_csp_has_host_without_scheme": "Recommendation: A domain without a scheme should not be used (#8).", - "detail_tech_data_http_csp_has_http": "Recommendation: \\'http:\\' scheme should not be used (#8).", - "detail_tech_data_http_csp_has_invalid_host": "Recommendation: A wildcard (i.e. \\'*\\') or \\'127.0.0.1\\' should not be used (#9 and #10).", - "detail_tech_data_http_csp_has_unsafe_eval": "Recommendation: \\'unsafe-eval\\' should not be used (#6).", - "detail_tech_data_http_csp_has_unsafe_hashes": "Recommendation: \\'unsafe-hashes\\' should not be used (#6).", - "detail_tech_data_http_csp_has_unsafe_inline": "Recommendation: \\'unsafe-inline\\' should not be used (#6).", - "detail_tech_data_http_csp_missing_invalid_base_uri": "Recommendation: \\'base-uri\\' with sufficiently secure value should be defined (#2).", - "detail_tech_data_http_csp_missing_invalid_default_src": "Recommendation: \\'default-src\\' with sufficiently secure value should be defined (#1).", - "detail_tech_data_http_csp_missing_invalid_form_action": "Recommendation: \\'form-action\\' with sufficiently secure value should be defined (#5).", - "detail_tech_data_http_csp_missing_invalid_frame_ancestors": "Recommendation: \\'frame-ancestors\\' with sufficiently secure value should be defined (#4).", - "detail_tech_data_http_csp_missing_invalid_frame_src": "Recommendation: \\'frame-src\\' (or child-src\\' or \\'default-src\\' as fallback) with sufficiently secure value should be defined (#3).", - "detail_tech_data_http_csp_no_policy_found": "No CSP found.", - "detail_tech_data_http_csp_policy_found": "Retrieved CSP value: {policy}", - "detail_tech_data_http_referrer_policy_bad_invalid": "Bad: policy value is not valid.", - "detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade": "Bad: \\'no-referrer-when-downgrade\\' must not be used.", - "detail_tech_data_http_referrer_policy_bad_origin": "Bad: \\'origin\\' must not be used.", - "detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin": "Bad: \\'origin-when-cross-origin\\' must not be used.", - "detail_tech_data_http_referrer_policy_bad_unsafe_url": "Bad: \\'unsafe-url\\' must not be used.", - "detail_tech_data_http_referrer_policy_no_policy": "No Referrer-Policy found.", - "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_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.", - "detail_tech_data_http_securitytxt_multi_lang": "Error: \\'Preferred-Languages\\' field must not appear more than once.", - "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Recommendation: Multiple \\'CSAF\\' fields should be brought back to one \\'CSAF\\' field.", - "detail_tech_data_http_securitytxt_no_canonical": "Recommendation: \\'Canonical\\' field should be present in a signed file.", - "detail_tech_data_http_securitytxt_no_canonical_match": "Error: The web URI of security.txt (i.e. when redirecting at least the last URI of the redirect chain) must be listed in a \\'Canonical\\' field if present.", - "detail_tech_data_http_securitytxt_no_contact": "Error: \\'Contact\\' field must appear at least once.", - "detail_tech_data_http_securitytxt_no_content_type": "Error: HTTP Content-Type header must be sent.", - "detail_tech_data_http_securitytxt_no_csaf_file": "Error: Every optional \\'CSAF\\' field must point to a file named \\'provider-metadata.json\\'.", - "detail_tech_data_http_securitytxt_no_encryption": "Recommendation: \\'Encryption\\' field should be present when \\'Contact\\' field contains an email address.", - "detail_tech_data_http_securitytxt_no_expire": "Error: \\'Expires\\' field must be present.", - "detail_tech_data_http_securitytxt_no_https": "Error: Web URI must begin with \\'https://\\' (line {line_no}).", - "detail_tech_data_http_securitytxt_no_line_separators": "Error: Every line must end with either a carriage return and line feed characters or just a line feed character.", - "detail_tech_data_http_securitytxt_no_security_txt_404": "Error: security.txt could not be located.", - "detail_tech_data_http_securitytxt_no_security_txt_other": "Error: security.txt could not be located (unexpected HTTP response code {status_code}).", - "detail_tech_data_http_securitytxt_no_space": "Error: Field separator (colon) must be followed by a space (line {line_no}).", - "detail_tech_data_http_securitytxt_no_uri": "Error: Field value must be a URI (e.g. beginning with \\'mailto:\\') (line {line_no}).", - "detail_tech_data_http_securitytxt_not_signed": "Recommendation: security.txt should be digitally signed.", - "detail_tech_data_http_securitytxt_pgp_data_error": "Error: Signed security.txt must contain a correct ASCII-armored PGP block.", - "detail_tech_data_http_securitytxt_pgp_error": "Error: Decoding or parsing of the signed security.txt must succeed.", - "detail_tech_data_http_securitytxt_prec_ws": "Error: There must be no whitespace before the field separator (colon) (line {line_no}).", - "detail_tech_data_http_securitytxt_requested_from": "security.txt requested from {hostname}.", - "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 encoded using UTF-8 in Net-Unicode form.", - "detail_tech_data_insecure": "insecure", - "detail_tech_data_insufficient": "insufficient", - "detail_tech_data_no": "no", - "detail_tech_data_not_applicable": "not applicable", - "detail_tech_data_not_reachable": "not reachable", - "detail_tech_data_not_testable": "not testable", - "detail_tech_data_not_tested": "not tested", - "detail_tech_data_phase_out": "phase out", - "detail_tech_data_secure": "secure", - "detail_tech_data_sufficient": "sufficient", - "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). 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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_appsecpriv_http_csp_tech_table_findings": "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 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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_appsecpriv_http_referrer_policy_tech_table_findings": "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 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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_appsecpriv_http_securitytxt_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_appsecpriv_http_x_content_type_tech_table_x_content_type_options_value": "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).

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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_appsecpriv_http_x_frame_tech_table_x_frame_options_value": "X-Frame-Options value", - "detail_web_appsecpriv_http_x_frame_verdict_bad": "Your web server does not offer securely configured X-Frame-Options.", - "detail_web_appsecpriv_http_x_frame_verdict_good": "Your web server offers securely configured X-Frame-Options.", - "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We check if your web server provides an HTTP header for X-XSS-Protection that has a sufficiently secure value (i.e. 1 or 1; mode=block). This HTTP header can be used to activate the protection filter of browsers against reflective cross-site scripting (XSS) attacks. Valid values for the X-XSS-Protection header are:

  • 0 disables the XSS filter. This value should NOT be used.
  • 1 enables the XSS filter. If a cross-site scripting attack is detected, the browser will sanitize the script and remove the unsafe parts. This value is usually the default in browsers when a website does not offer an X-XSS-Protection header.
  • 1; mode=block enables the XSS filter. If a cross-site scripting attack is detected, the browser will block the response and prevent rendering the page. This is the recommended value.

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

Requirement level: Recommended", - "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", - "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|X-XSS-Protection value", - "detail_web_appsecpriv_http_x_xss_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", - "detail_web_appsecpriv_http_x_xss_tech_table_x_xss_protection_value": "X-XSS-Protection value", - "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your web server does not offer securely configured X-XSS-Protection.", - "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your web server offers securely configured X-XSS-Protection.", - "detail_web_dnssec_exists_exp": "We check if your domain, more specifically its SOA record, is DNSSEC signed.

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_web_dnssec_exists_label": "DNSSEC existence", - "detail_web_dnssec_exists_tech_table": "Domain|Registrar", - "detail_web_dnssec_exists_tech_table_domain": "Domain", - "detail_web_dnssec_exists_tech_table_registrar": "Registrar", - "detail_web_dnssec_exists_verdict_bad": "Your domain is insecure, because it is not DNSSEC signed.", - "detail_web_dnssec_exists_verdict_good": "Your domain is DNSSEC signed.", - "detail_web_dnssec_exists_verdict_resolver_error": "Unfortunately an error occurred in Internet.nl\\'s resolver. Please contact us.", - "detail_web_dnssec_exists_verdict_servfail": "The name servers of your 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_web_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it \\'secure\\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \\'secure\\' one time and \\'bogus\\' the next.", - "detail_web_dnssec_valid_label": "DNSSEC validity", - "detail_web_dnssec_valid_tech_table": "Domain|Status", - "detail_web_dnssec_valid_tech_table_domain": "Domain", - "detail_web_dnssec_valid_tech_table_status": "Status", - "detail_web_dnssec_valid_verdict_bad": "Your domain is \\'bogus\\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", - "detail_web_dnssec_valid_verdict_good": "Your domain is secure, because its DNSSEC signature is valid.", - "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Your domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", - "detail_web_ipv6_web_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for your web server.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.", - "detail_web_ipv6_web_aaaa_label": "IPv6 addresses for web server", - "detail_web_ipv6_web_aaaa_tech_table": "Web server|IPv6 address|IPv4 address", - "detail_web_ipv6_web_aaaa_tech_table_web_server": "Web server", - "detail_web_ipv6_web_aaaa_tech_table_ipv6_address": "IPv6 address", - "detail_web_ipv6_web_aaaa_tech_table_ipv4_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 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 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_tech_table_web_server": "Web server", - "detail_web_ipv6_web_reach_tech_table_unreachable_ipv6_address": "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.", - "detail_web_rpki_exists_label": "Route Origin Authorisation existence", - "detail_web_rpki_exists_tech_table": "Web server|IP address|RPKI Route Origin Authorization", - "detail_web_rpki_exists_tech_table_web_server": "Web server", - "detail_web_rpki_exists_tech_table_ip_address": "IP address", - "detail_web_rpki_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_web_server": "Web server", - "detail_web_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_web_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_web_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", - "detail_web_tls_cert_hostmatch_tech_table": "Web server IP address|Unmatched domains on certificate", - "detail_web_tls_cert_hostmatch_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Unmatched domains on certificate", - "detail_web_tls_cert_hostmatch_verdict_bad": "The domain name of your website does not match the domain name on your website certificate.", - "detail_web_tls_cert_hostmatch_verdict_good": "The domain name of your website matches the domain name on your website certificate.", - "detail_web_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
", - "detail_web_tls_cert_pubkey_label": "Public key of certificate", - "detail_web_tls_cert_pubkey_tech_table": "Web server IP address|Affected signature parameters|Status", - "detail_web_tls_cert_pubkey_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_cert_pubkey_tech_table_affected_signature_parameters": "Affected signature parameters", - "detail_web_tls_cert_pubkey_tech_table_status": "Status", - "detail_web_tls_cert_pubkey_verdict_bad": "The digital signature of your website certificate uses insufficiently secure parameters.", - "detail_web_tls_cert_pubkey_verdict_good": "The digital signature of your website certificate uses secure parameters.", - "detail_web_tls_cert_pubkey_verdict_phase_out": "The digital signature of your website certificate uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", - "detail_web_tls_cert_signature_exp": "

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", - "detail_web_tls_cert_signature_label": "Signature of certificate", - "detail_web_tls_cert_signature_tech_table": "Web server IP address|Affected hash algorithm|Status", - "detail_web_tls_cert_signature_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_cert_signature_tech_table_affected_hash_algorithm": "Affected hash algorithm", - "detail_web_tls_cert_signature_tech_table_status": "Status", - "detail_web_tls_cert_signature_verdict_bad": "Your website certificate is signed using a hash algorithm that is insufficiently secure.", - "detail_web_tls_cert_signature_verdict_good": "Your website certificate is signed using a secure hash algorithm.", - "detail_web_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your website certificate.

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

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B3-4 (in English).", - "detail_web_tls_cert_trust_label": "Trust chain of certificate", - "detail_web_tls_cert_trust_tech_table": "Web server IP address|Untrusted certificate chain", - "detail_web_tls_cert_trust_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_cert_trust_tech_table_untrusted_certificate_chain": "Untrusted certificate chain", - "detail_web_tls_cert_trust_verdict_bad": "The trust chain of your website certificate is not complete and/or not signed by a trusted root certificate authority.", - "detail_web_tls_cert_trust_verdict_good": "The trust chain of your website certificate is complete and signed by a trusted root certificate authority.", - "detail_web_tls_cipher_order_exp": "We check if your web server enforces its own cipher preference (\\'I\\'), and offers ciphers in accordance with the prescribed ordering (\\'II\\').

When your web server supports \\'Good\\' ciphers only, this subtest is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The web server enforces its own cipher preference while negotiating with a web browser, and does not accept any preference of the web browser;

II. Prescribed ordering: Ciphers are offered by the web server 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_web_tls_cipher_order_label": "Cipher order", - "detail_web_tls_cipher_order_tech_table": "Web server IP address|First found affected cipher pair|Violated rule # (\\'II-B\\')", - "detail_web_tls_cipher_order_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "First found affected cipher pair", - "detail_web_tls_cipher_order_tech_table_violated_rule_ii_b": "Violated rule # (\\'II-B\\')", - "detail_web_tls_cipher_order_verdict_bad": "Your web server does not enforce its own cipher preference (\\'I\\').", - "detail_web_tls_cipher_order_verdict_good": "Your web server enforces its own cipher preference (\\'I\\'), and offers ciphers in accordance with the prescribed ordering (\\'II\\').", - "detail_web_tls_cipher_order_verdict_na": "This subtest is not applicable as your web server supports \\'Good\\' ciphers only.", - "detail_web_tls_cipher_order_verdict_seclevel_bad": "Your web server does not prefer \\'Good\\' over \\'Sufficient\\' over \\'Phase out\\' ciphers (\\'II\\').", - "detail_web_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Your web server does not offer ciphers in accordance with the prescribed ordering within a particular security level (\\'II-B\\').", - "detail_web_tls_ciphers_exp": "

We check if your web server only supports secure, i.e. \\'Good\\' and/or \\'Sufficient\\', ciphers (also known as algorithm selections).

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \\'cipher suite\\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \\'cipher suite\\' ambiguous, NCSC-NL uses the term \\'algorithm selection\\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \\'IT Security Guidelines for Transport Layer Security (TLS) v2.1\\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \\'Good\\', \\'Sufficient\\' and \\'Phase out\\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \\'IT Security Guidelines for Transport Layer Security (TLS)\\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \\'Phase out\\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", - "detail_web_tls_ciphers_label": "Ciphers (Algorithm selections)", - "detail_web_tls_ciphers_tech_table": "Web server IP address|Affected ciphers|Status", - "detail_web_tls_ciphers_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_ciphers_tech_table_affected_ciphers": "Affected ciphers", - "detail_web_tls_ciphers_tech_table_status": "Status", - "detail_web_tls_ciphers_verdict_bad": "Your web server supports one or more insufficiently secure ciphers.", - "detail_web_tls_ciphers_verdict_good": "Your web server supports secure ciphers only.", - "detail_web_tls_ciphers_verdict_phase_out": "Your web server supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", - "detail_web_tls_compression_exp": "

We check if your web server supports TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
", - "detail_web_tls_compression_label": "TLS compression", - "detail_web_tls_compression_tech_table": "Web server IP address|TLS compression", - "detail_web_tls_compression_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_compression_tech_table_tls_compression": "TLS compression", - "detail_web_tls_compression_verdict_bad": "Your web server supports TLS compression, which is not secure.", - "detail_web_tls_compression_verdict_good": "Your web server does not support TLS compression.", - "detail_web_tls_dane_exists_exp": "We check if the name servers of your website domain contain a correctly signed TLSA record for DANE.

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the website domain, or if there are DANE related DNSSEC issues (e.g. no proof of \\'Denial of Existence\\').

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

Requirement level: Optional", - "detail_web_tls_dane_exists_label": "DANE existence", - "detail_web_tls_dane_exists_tech_table": "Web server IP address|DANE TLSA record existent", - "detail_web_tls_dane_exists_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA record existent", - "detail_web_tls_dane_exists_verdict_bad": "Your website domain does not contain a TLSA record for DANE.", - "detail_web_tls_dane_exists_verdict_bogus": "Your website domain does not provide DNSSEC proof that DANE TLSA records do not exist. You should ask your name server operator to fix this issue.", - "detail_web_tls_dane_exists_verdict_good": "Your website domain contains a TLSA record for DANE.", - "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", - "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", - "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", - "detail_web_tls_dane_rollover_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", - "detail_web_tls_dane_rollover_tech_table_dane_rollover_scheme": "DANE rollover scheme", - "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", - "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", - "detail_web_tls_dane_valid_exp": "We check if the DANE fingerprint presented by your domain is valid for your web certificate.

DANE allows you to publish information about your website certificate in a special DNS record, called TLSA record. Clients, like web browsers, can check the authenticity of your certificate not only through the certificate authority but also through the TLSA record. A client can also use the TLSA record as a signal to only use HTTPS (and not HTTP). DNSSEC is preconditional for DANE. Unfortunately not much web browsers are supporting DANE validation yet.

Requirement level: Recommended (only if subtest for \\'DANE existence\\' is passed)", - "detail_web_tls_dane_valid_label": "DANE validity", - "detail_web_tls_dane_valid_tech_table": "Web server IP address|DANE TLSA record valid", - "detail_web_tls_dane_valid_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Key exchange parameters", - "detail_web_tls_fs_params_tech_table": "Web server IP address|Affected parameters|Status", - "detail_web_tls_fs_params_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_fs_params_tech_table_affected_parameters": "Affected parameters", - "detail_web_tls_fs_params_tech_table_status": "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 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 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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_http_compression_tech_table_http_compression": "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 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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_https_exists_tech_table_https_existent": "HTTPS existent", - "detail_web_tls_https_exists_verdict_bad": "Your website does not offer HTTPS.", - "detail_web_tls_https_exists_verdict_good": "Your website offers HTTPS.", - "detail_web_tls_https_exists_verdict_other": "Your web server is unreachable.", - "detail_web_tls_https_forced_exp": "We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See \\'Web application guidelines, detailed version\\' from NCSC-NL, guideline U/WA.05 (in Dutch).", - "detail_web_tls_https_forced_label": "HTTPS redirect", - "detail_web_tls_https_forced_tech_table": "Web server IP address|HTTPS redirect", - "detail_web_tls_https_forced_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_https_forced_tech_table_https_redirect": "HTTPS redirect", - "detail_web_tls_https_forced_verdict_bad": "Your web server does offer support for both HTTP and HTTPS, but does not automatically redirect visitors from HTTP to HTTPS on the same domain.", - "detail_web_tls_https_forced_verdict_good": "Your web server automatically redirects visitors from HTTP to HTTPS on the same domain.", - "detail_web_tls_https_forced_verdict_no_https": "This test could not be performed, because your web server offers either no HTTPS or HTTPS with a very outdated, insecure TLS configuration.", - "detail_web_tls_https_forced_verdict_other": "Your web server only offers support for HTTPS and not for HTTP.", - "detail_web_tls_https_hsts_exp": "We check if your web server supports HSTS.

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period of at least 1 year (max-age=31536000) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired.

The test does not check whether preload is used and whether the domain is included in the HSTS Preload List.

Deployment recommendation

HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will not be reachable by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy.

Therefore we advise you to follow the implementation steps below:

  1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);

  2. Increase the HSTS cache validity period in the stages below. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.

  3. Start with 5 minutes (max-age=300);

  4. Increase it to 1 week (max-age=604800);
  5. Increase it to 1 month (max-age=2592000);

  6. Increase it to 1 year (max-age=31536000) or more.

  7. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use includeSubDomains if you are fully sure that all the (nested) subdomains of your domain properly support HTTPS now and in the future.

  8. Use preload only if you are very sure that you want your domain to be included in the HSTS Preload List. HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.

See \\'Web application guidelines, detailed version\\' from NCSC-NL, guideline U/WA.05 (in Dutch).", - "detail_web_tls_https_hsts_label": "HSTS", - "detail_web_tls_https_hsts_tech_table": "Web server IP address|HSTS policy", - "detail_web_tls_https_hsts_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_https_hsts_tech_table_hsts_policy": "HSTS policy", - "detail_web_tls_https_hsts_verdict_bad": "Your web server does not offer an HSTS policy.", - "detail_web_tls_https_hsts_verdict_good": "Your web server offers an HSTS policy.", - "detail_web_tls_https_hsts_verdict_other": "Your web server offers an HSTS policy with a cache validity period (max-age) that is not sufficiently long (i.e. less than 1 year).", - "detail_web_tls_kex_hash_func_exp": "

We check if your web server supports secure hash functions to create the digital signature during key exchange.

The web server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The web server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", - "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_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "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 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", - "detail_web_tls_ocsp_stapling_tech_table": "Web server IP address|OCSP stapling", - "detail_web_tls_ocsp_stapling_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", - "detail_web_tls_ocsp_stapling_verdict_bad": "Your web server supports OCSP stapling but the data in the response is not valid.", - "detail_web_tls_ocsp_stapling_verdict_good": "Your web server supports OCSP stapling and the data in the response is valid.", - "detail_web_tls_ocsp_stapling_verdict_ok": "Your web server does not support OCSP stapling.", - "detail_web_tls_renegotiation_client_exp": "

We check if a client (usually a web browser) can initiate a renegotiation with your web server.

Allowing clients to initiate renegotiation is generally not necessary and opens a web server to DoS attacks inside a TLS connection. An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", - "detail_web_tls_renegotiation_client_label": "Client-initiated renegotiation", - "detail_web_tls_renegotiation_client_tech_table": "Web server IP address|Client-initiated renegotiation", - "detail_web_tls_renegotiation_client_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "Client-initiated renegotiation", - "detail_web_tls_renegotiation_client_verdict_bad": "Your web server allows for client-initiated renegotiation, which could have negative impact on the availability of your website.", - "detail_web_tls_renegotiation_client_verdict_good": "Your web server does not allow for client-initiated renegotiation.", - "detail_web_tls_renegotiation_secure_exp": "

We check if your web server supports secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", - "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", - "detail_web_tls_renegotiation_secure_tech_table": "Web server IP address|Secure renegotiation", - "detail_web_tls_renegotiation_secure_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", - "detail_web_tls_renegotiation_secure_verdict_bad": "Your web server supports insecure renegotiation, which is obviously not secure.", - "detail_web_tls_renegotiation_secure_verdict_good": "Your web server supports secure renegotiation.", - "detail_web_tls_version_exp": "

We check if your web server supports secure TLS versions only.

A web server may support more than one TLS version.

Note that browser makers have announced that they will stop supporting TLS 1.1 and 1.0. This will cause websites that do not support TLS 1.2 and/or 1.3 to be unreachable.

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_web_tls_version_label": "TLS version", - "detail_web_tls_version_tech_table": "Web server IP address|TLS version|Status", - "detail_web_tls_version_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_version_tech_table_tls_version": "TLS version", - "detail_web_tls_version_tech_table_status": "Status", - "detail_web_tls_version_verdict_bad": "Your web server supports insufficiently secure TLS versions.", - "detail_web_tls_version_verdict_good": "Your web server supports secure TLS versions only.", - "detail_web_tls_version_verdict_phase_out": "Your web server supports TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", - "detail_web_tls_zero_rtt_exp": "

We check if your web server supports Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the firsthandshake message. 0-RTT does not provide protection against replay attacks atthe TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable.For web servers that support TLS 1.3, the index / page of the website isfetched using TLS 1.3 and the amount ofearly datasupport indicated by theserver is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theHTTP request before the TLS handshake (i.e. no round trips (0-RTT) neededbefore application data to the server). If the TLS handshake is completed andthe web server responds with anynon-HTTP 425 Too Earlyresponse, then the web server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", - "detail_web_tls_zero_rtt_label": "0-RTT", - "detail_web_tls_zero_rtt_tech_table": "Web server IP address|0-RTT", - "detail_web_tls_zero_rtt_tech_table_web_server_ip_address": "Web server IP address", - "detail_web_tls_zero_rtt_tech_table_0_rtt": "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 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", - "detail_web_mail_ipv6_ns_aaaa_tech_table_name_server": "Name server", - "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv6_address": "IPv6 address", - "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv4_address": "IPv4 address", - "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "None of the name servers of your domain has an IPv6 address.", - "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Two or more name servers of your domain have an IPv6 address.", - "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Only one name server of your domain has an IPv6 address.", - "detail_web_mail_ipv6_ns_reach_exp": "We check if all name servers, that have an AAAA record with IPv6 address, are reachable over IPv6.", - "detail_web_mail_ipv6_ns_reach_label": "IPv6 reachability of name servers", - "detail_web_mail_ipv6_ns_reach_tech_table": "Name server|Unreachable IPv6 address", - "detail_web_mail_ipv6_ns_reach_tech_table_name_server": "Name server", - "detail_web_mail_ipv6_ns_reach_tech_table_unreachable_ipv6_address": "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.", - "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_tech_table_name_server": "Name server", - "detail_web_mail_rpki_ns_exists_tech_table_ip_address": "IP address", - "detail_web_mail_rpki_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server": "Name server", - "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_web_mail_rpki_ns_valid_tech_table_rpki_origin_validation_state": "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 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", - "faqs_report_subtest_good": "Good: pass on REQUIRED, RECOMMENDED or OPTIONAL subtest ⇒ first: full score / latter two: no score impact", - "faqs_report_subtest_info": "Informational: fail on OPTIONAL subtest ⇒ no score impact", - "faqs_report_subtest_not_tested": "Not tested, because already failed related parent subtest ⇒ null score", - "faqs_report_subtest_title": "Icons per subtest", - "faqs_report_subtest_warning": "Warning: fail on RECOMMENDED subtest ⇒ no score impact", - "faqs_report_test_bad": "Bad: failed at least one REQUIRED subtest ⇒ no full score in test category", - "faqs_report_test_error": "Test error: execution error for at least one subtest ⇒ no result in test category", - "faqs_report_test_good": "Good: passed all subtests ⇒ full score in test category", - "faqs_report_test_info": "Informational: failed at least one OPTIONAL subtest ⇒ full score in test category ", - "faqs_report_test_title": "Icons per test category", - "faqs_report_test_warning": "Warning: failed at least one RECOMMENDED subtest ⇒ full score in test category ", - "faqs_report_title": "Explanation of test report", - "faqs_rpki_title": "Authorisation for routing (RPKI)", - "faqs_starttls_title": "Secure email transport (STARTTLS and DANE)", - "faqs_title": "Knowledge base", - "halloffame_champions_menu": "Champions!", - "halloffame_champions_subtitle": "100% in website and email test", - "halloffame_champions_text": "The {{count}} domains below score 100% in both the website test and the email test. Inductees of this Hall of Fame are allowed to use both 100% badges.", - "halloffame_champions_title": "Hall of Fame - Champions!", - "halloffame_mail_badge": "Badge with text: 100% score in email test", - "halloffame_mail_menu": "Email", - "halloffame_mail_subtitle": "100% in email test", - "halloffame_mail_text": "The {{count}} domains below score 100% in the email test. Inductees of this Hall of Fame are allowed to use the 100% mail badge.", - "halloffame_mail_title": "Hall of Fame - Email", - "halloffame_web_badge": "Badge with text: 100% score in website test", - "halloffame_web_menu": "Websites", - "halloffame_web_subtitle": "100% in website test", - "halloffame_web_text": "The {{count}} domains below score 100% in the website test. Inductees of this Hall of Fame are allowed to use the 100% website badge.", - "halloffame_web_title": "Hall of Fame - Websites", - "home_pagetitle": "Test for modern Internet Standards like IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE.", - "home_stats_connection": "unique connections", - "home_stats_connection_items": "", - "home_stats_header": "Tests in numbers", - "home_stats_mail": "unique mail domains", - "home_stats_mail_items": "", - "home_stats_notpassed": "0-99%:", - "home_stats_passed": "100%:", - "home_stats_website": "unique web domains", - "home_stats_website_items": "", - "home_teaser": "Modern Internet Standards provide for more reliability and further growth of the Internet.
Are you using them?", - "mail_pagetitle": "Email test:", - "mail_title": "Email test: {{prettyaddr}}", - "mail_tweetmessage": "The%20mail%20server%20at%20{{report.domain}}%20scores%20{{score}}%25%20in%20the%20email%20test%20of%20%40Internet_nl%3A", - "page_gotocontents": "Go to the content", - "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 certificate, Internet Standards Platform", - "page_sitedescription": "Is your Internet up-to-date?", - "page_sitetitle": "Internet.nl", - "page404_title": "Page not found!", - "probes_auto_redirect": "You will be automatically redirected to the results page when all tests are finished.", - "probes_no_javascript": "Check if the test results are available. If not, you will be redirected here instead.", - "probes_no_javascript_connection": "JavaScript inactive. Please enable JavaScript in order to execute the test.", - "probes_no_redirection": "Test error. Please try again later, or test another domain name.", - "probes_test_finished": "Test finished! Results available...", - "probes_test_running": "Running...", - "probes_tests_description": "The items below are being tested.", - "probes_tests_duration": "The duration of the test is between 5 and {{cache_ttl}} seconds.", - "results_dated_presentation": "Dated result presentation. Please rerun the test.", - "results_domain_appsecpriv_http_headers_label": "HTTP security headers", - "results_domain_appsecpriv_other_options_label": "Other security options", - "results_domain_ipv6_web_server_label": "Web server", - "results_domain_rpki_web_server_label": "Web server", - "results_domain_tls_http_headers_label": "HTTP headers", - "results_domain_tls_https_label": "HTTP", - "results_domain_tls_tls_label": "TLS", - "results_domain_mail_ipv6_name_servers_label": "Name servers of domain", - "results_domain_mail_rpki_name_servers_label": "Name servers of domain", - "results_domain_mail_tls_certificate_label": "Certificate", - "results_domain_mail_tls_dane_label": "DANE", - "results_empty_argument_alt_text": "None", - "results_explanation_label": "Test explanation:", - "results_further_testing_connection_label": "Further connection testing", - "results_further_testing_mail_label": "Further email testing", - "results_further_testing_web_label": "Further website testing", - "results_mail_auth_dkim_label": "DKIM", - "results_mail_auth_dmarc_label": "DMARC", - "results_mail_auth_spf_label": "SPF", - "results_mail_dnssec_domain_label": "Email address domain", - "results_mail_dnssec_mail_servers_label": "Mail server domain(s)", - "results_mail_ipv6_mail_servers_label": "Mail server(s)", - "results_mail_rpki_mail_servers_label": "Mail server(s)", - "results_mail_rpki_mx_name_servers_label": "Name servers of mail server(s)", - "results_mail_tls_starttls_label": "TLS", - "results_no_icon_detail_close": "close", - "results_no_icon_detail_open": "open", - "results_no_icon_status_error": "Error", - "results_no_icon_status_failed": "Failed", - "results_no_icon_status_info": "Information", - "results_no_icon_status_not_tested": "Not testable", - "results_no_icon_status_passed": "Passed", - "results_no_icon_status_warning": "Recommendation", - "results_panel_button_hide": "Hide details", - "results_panel_button_show": "Show details", - "results_perfect_score": "Congratulations, your domain will be added to the Hall of Fame soon!", - "results_permalink": "Permalink test result {{permadate|date:\\'(Y-m-d H:i T)\\'}}", - "results_rerun_test": "Rerun the test", - "results_retest_time": "Seconds until retest option:", - "results_score_description": "The domain {{prettyaddr}} has a test score of {{score}}%.", - "results_tech_details_label": "Technical details:", - "results_test_direct": "Directly test:", - "results_test_email_label": "Test another email", - "results_test_website_label": "Test another website", - "results_test_info": "Explanation of test report", - "results_verdict_label": "Verdict:", - "test_connipv6_failed_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", - "test_connipv6_failed_summary": "Modern addresses not reachable (IPv6)", - "test_connipv6_info_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", - "test_connipv6_info_summary": "Modern addresses not reachable (IPv6)", - "test_connipv6_label": "Modern addresses reachable (IPv6)", - "test_connipv6_passed_description": "Well done! Your internet provider has provided you with a modern internet address (IPv6). Therefore you can reach other computers with modern addresses.", - "test_connipv6_passed_summary": "Modern addresses reachable (IPv6)", - "test_connipv6_title": "Modern addresses reachable?", - "test_connipv6_warning_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", - "test_connipv6_warning_summary": "Modern addresses not reachable (IPv6)", - "test_connresolver_failed_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", - "test_connresolver_failed_summary": "Domain signatures not validated (DNSSEC)", - "test_connresolver_info_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", - "test_connresolver_info_summary": "Domain signatures not validated (DNSSEC)", - "test_connresolver_label": "Domain signature validation (DNSSEC)", - "test_connresolver_passed_description": "Well done! Domain signatures (DNSSEC) are validated for you. Therefore you are protected against false translation from signed domain names into rogue IP addresses.", - "test_connresolver_passed_summary": "Domain signatures validated (DNSSEC)", - "test_connresolver_title": "Domain signatures validated?", - "test_connresolver_warning_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", - "test_connresolver_warning_summary": "Domain signatures not validated (DNSSEC)", - "test_error_summary": "Error during test execution!", - "test_mailauth_failed_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", - "test_mailauth_failed_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", - "test_mailauth_info_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", - "test_mailauth_info_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", - "test_mailauth_label": "Authenticity marks against phishing (DMARC, DKIM and SPF)", - "test_mailauth_passed_description": "Well done! Your domain contains all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are able to reliably separate phishing and spam emails abusing your domain in their sender address, from your authentic emails. ", - "test_mailauth_passed_summary": "Authenticity marks against email phishing (DMARC, DKIM and SPF)", - "test_mailauth_title": "Authenticity marks against email phishing?", - "test_mailauth_warning_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", - "test_mailauth_warning_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", - "test_maildnssec_failed_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", - "test_maildnssec_failed_summary": "Not all domain names signed (DNSSEC)", - "test_maildnssec_info_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", - "test_maildnssec_info_summary": "Not all domain names signed (DNSSEC)", - "test_maildnssec_label": "Signed domain names (DNSSEC)", - "test_maildnssec_passed_description": "Well done! Your email address domain and your mail server domain(s) are signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are able to reliably query the IP address of your receiving mail server(s). ", - "test_maildnssec_passed_summary": "All domain names signed (DNSSEC)", - "test_maildnssec_title": "Domain names signed?", - "test_maildnssec_warning_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", - "test_maildnssec_warning_summary": "Not all domain names signed (DNSSEC)", - "test_mailipv6_failed_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_failed_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", - "test_mailipv6_info_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_info_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", - "test_mailipv6_label": "Modern address (IPv6)", - "test_mailipv6_passed_description": "Well done! Your mail server can be reached by senders using modern
addresses (IPv6), making it fully part of the modern Internet.", - "test_mailipv6_passed_summary": "Reachable via modern internet address (IPv6)", - "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_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)", - "test_mailrpki_label": "Route authorisation (RPKI)", - "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": "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)", - "test_mailtls_info_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_info_summary": "Mail server connection not or insufficiently secured (STARTTLS and DANE)", - "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: 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 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)", - "test_mailtls_null_mx_with_other_mx_description": "Warning: 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. ", - "test_mailtls_null_mx_with_other_mx_summary": "Inconsistently configured non-receiving mail domain (STARTTLS and DANE)", - "test_mailtls_null_mx_without_a_aaaa_description": "Warning: 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.", - "test_mailtls_null_mx_without_a_aaaa_summary": "Properly configured non-receiving mail domain, though with unnecessary record (STARTTLS and DANE)", - "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 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 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. 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. 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. 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. 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)", - "test_sitednssec_info_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_info_summary": "Domain name not signed (DNSSEC)", - "test_sitednssec_label": "Signed domain name (DNSSEC)", - "test_sitednssec_passed_description": "Well done! Your domain is signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are protected against manipulated translation from your domain into rogue internet addresses.", - "test_sitednssec_passed_summary": "Domain name signed (DNSSEC)", - "test_sitednssec_title": "Domain name signed?", - "test_sitednssec_warning_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_warning_summary": "Domain name not signed (DNSSEC)", - "test_siteipv6_failed_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_failed_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", - "test_siteipv6_info_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_info_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", - "test_siteipv6_label": "Modern address (IPv6)", - "test_siteipv6_passed_description": "Well done! Your website is reachable for visitors using a modern internet address (IPv6), making it fully part of the modern Internet.", - "test_siteipv6_passed_summary": "Reachable via modern internet address (IPv6)", - "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_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)", - "test_siterpki_label": "Route authorisation (RPKI)", - "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": "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)", - "test_sitetls_info_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_info_summary": "Connection not or insufficiently secured (HTTPS)", - "test_sitetls_label": "Secure connection (HTTPS)", - "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 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 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", - "widget_site_intro": "

Website test widget

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

" -} \ No newline at end of file diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json deleted file mode 100644 index d3084fe9..00000000 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json +++ /dev/null @@ -1,1017 +0,0 @@ -{ - "about_contact": "

Contact

Platform Internetstandaarden
p/a ECP
Maanweg 174 (8e verdieping)
2516 AB Den Haag

KvK-nummer: 27169301

E-mail

vraag@internet.nl

PGP publieke sleutel
Vingerafdruk: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Vervaldatum: 19 maart 2025

", - "base_about": "Over Internet.nl", - "base_accessibility": "Toegankelijkheid", - "base_blogs": "Blogs", - "base_contact": "Contact", - "base_copyright": "Auteursrecht", - "base_disclosure": "Kwetsbaarheid melden", - "base_faqs": "Kennisbank", - "base_halloffame": "Hall of Fame", - "base_halloffame_champions": "Hall of Fame - Kampioenen!", - "base_halloffame_lead": "{{count}} domeinen met 2 x 100%
Laatste toevoeging: {{latest|date:\\'d-m-Y\\'}}", - "base_halloffame_link": "Naar Hall of Fame - Kampioenen!", - "base_halloffame_mail": "Hall of Fame - E-mail", - "base_halloffame_web": "Hall of Fame - Websites", - "base_home": "Home", - "base_info": "Internet.nl is een initiatief van de internetgemeenschap en de Nederlandse overheid.", - "base_news": "Nieuws", - "base_newslink": "Naar nieuwsoverzicht", - "base_privacy": "Privacyverklaring", - "base_test_connection_explain": "

Wat wordt getest?

Nadat je de verbindingstest hebt gestart, testen we of de momenteel door jou gebruikte internetverbinding ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

  • IPv6: zijn websites met moderne internetadressen voor jou bereikbaar?
  • DNSSEC: worden domeinnaam-handtekeningen voor jou gecontroleerd?

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\".

Hoe verbeteren?

Het testrapport kan je gebruiken om je internetverbinding te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je internetprovider. In de communicatie met je internetprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Test je verbinding

", - "base_test_connection_label": "Test je verbinding", - "base_test_connection_text": "Moderne adressen bereikbaar?
Domein-handtekeningen gecontroleerd?", - "base_test_connection_title": "Over de verbindingstest", - "base_test_explain": "Over de test", - "base_test_mail_explain": "

Wat wordt getest?

Nadat je een e-mailadres hebt opgegeven, testen we of de achterliggende e-mailvoorziening ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Let op: sommige standaarden zijn zelfs relevant als je je domeinnaam niet gebruikt voor het ontvangen en verzenden van e-mail.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\".

Hoe verbeteren?

Het testrapport kan je gebruiken om je e-mailvoorziening te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je e-mailprovider. In de communicatie met je e-mailprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de e-mailtest integreren in je eigen website door gebruik te maken van onze widget code.

Test je e-mail

", - "base_test_mail_input": "Jouw e-mailadres:", - "base_test_mail_label": "Test je e-mail", - "base_test_mail_text": "Modern adres? Anti-phishing? Beveiligd transport? Route-autorisatie?", - "base_test_mail_title": "Over de e-mailtest", - "base_test_prechecks_invalid_domain": "De opgegeven domeinnaam is niet geldig!
Toelichting: Een A- en/of AAAA-record is noodzakelijk voor de websitetest, en een SOA-record voor de e-mailtest.", - "base_test_start": "Start test", - "base_test_website_explain": "

Wat wordt getest?

Nadat je een domeinnaam van een website heb opgegeven, testen we of de website ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\". Als je website een score van 100% heeft, dan wordt deze opgenomen in de Hall of Fame.

Hoe verbeteren?

Het testrapport kan je gebruiken om je website te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je webhoster.In de communicatie met je webhoster kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de websitetest integreren in je eigen website door gebruik te maken van onze widget code.

Test je website

", - "base_test_website_input": "Jouw website-domeinnaam:", - "base_test_website_label": "Test je website", - "base_test_website_text": "Modern adres? Beveiligde verbinding? Beveiligingsopties? Route-autorisatie?", - "base_test_website_title": "Over de websitetest", - "base_widget_mail": "E-mailtest widget", - "base_widget_site": "Websitetest widget", - "connection_pagetitle": "Verbindingstest", - "connection_title": "Verbindingstest", - "detail_conn_dnssec_validation_exp": "We testen of de door jou gebruikte resolvers de DNSSEC-handtekeningen van onze domeinnaam valideren. Resolvers worden normaal gesproken geleverd door je internetprovider. Als alternatief kun je resolvers van een andere DNS provider instellen. Je kan zelfs je eigen lokaal geïnstalleerde resolver gebruiken. Hoewel validatie plaatsvindt op de resolver, kan nog steeds door een aanvaller gerommeld worden met de communicatie tussen de resolver en jouw apparaat (ook wel \\'last mile\\' genoemd). Het is daarom het meest veilig om zo dicht mogelijk op je apparaat te valideren (bijv. door een lokaal geïnstalleerde resolver te gebruiken), of zorg ervoor dat het kanaal tussen je resolver en je apparaat beveiligd c.q. vertrouwd is.", - "detail_conn_dnssec_validation_label": "DNSSEC-validatie", - "detail_conn_dnssec_validation_tech_table": "DNS-provider", - "detail_conn_dnssec_validation_tech_table_dns_provider": "DNS-provider", - "detail_conn_dnssec_validation_verdict_bad": "Je bent niet beschermd door validatie van DNSSEC-handtekeningen.", - "detail_conn_dnssec_validation_verdict_good": "Je bent beschermd door validatie van DNSSEC-handtekeningen.", - "detail_conn_ipv6_connection_exp": "We testen of jouw apparaat via zijn huidige internetverbinding in staat is om direct (d.w.z. zonder DNS-vertaling) verbinding te maken met onze webserver via ons bijbehorende IPv6-adres.

Sommige browser add-ons en routers bieden functionaliteit aan voor het filteren van domeinnamen om de privacy te verbeteren of internetgebruik te beperken. Om omzeiling te voorkomen blokkeert deze functionaliteit vaak ook het direct verbinden met IP-adressen waardoor deze subtest faalt.", - "detail_conn_ipv6_connection_label": "IPv6-connectiviteit (direct)", - "detail_conn_ipv6_connection_tech_table": "Geanonimiseerd IPv6-adres|Reverse name|Internetprovider", - "detail_conn_ipv6_connection_tech_table_anonymized_ipv6_address": "Geanonimiseerd IPv6-adres", - "detail_conn_ipv6_connection_tech_table_reverse_name": "Reverse name", - "detail_conn_ipv6_connection_tech_table_internet_provider": "Internetprovider", - "detail_conn_ipv6_connection_verdict_bad": "Je bent niet in staat om computers direct op hun IPv6-adres te bereiken.", - "detail_conn_ipv6_connection_verdict_good": "Je bent in staat om computers direct op hun IPv6-adres te bereiken.", - "detail_conn_ipv6_dns_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv6. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv6-adres ophaalt.", - "detail_conn_ipv6_dns_conn_label": "IPv6-connectiviteit (via DNS)", - "detail_conn_ipv6_dns_conn_verdict_bad": "Je bent niet in staat om computers via DNS op hun IPv6-adres te bereiken.", - "detail_conn_ipv6_dns_conn_verdict_good": "Je bent in staat om computers via DNS op hun IPv6-adres te bereiken.", - "detail_conn_ipv6_ipv4_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv4. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv4-adres ophaalt.

Niveau van vereistheid: Optioneel", - "detail_conn_ipv6_ipv4_conn_label": "IPv4-connectiviteit (via DNS)", - "detail_conn_ipv6_ipv4_conn_tech_table": "Geanonimiseerd IPv4-adres|Reverse name|Internetprovider", - "detail_conn_ipv6_ipv4_conn_tech_table_anonymized_ipv4_address": "Geanonimiseerd IPv4-adres", - "detail_conn_ipv6_ipv4_conn_tech_table_reverse_name": "Reverse name", - "detail_conn_ipv6_ipv4_conn_tech_table_internet_provider": "Internetprovider", - "detail_conn_ipv6_ipv4_conn_verdict_bad": "Je bent niet in staat om computers via DNS op hun IPv4-adres te bereiken.", - "detail_conn_ipv6_ipv4_conn_verdict_good": "Je bent in staat om computers via DNS op hun IPv4-adres te bereiken.", - "detail_conn_ipv6_privacy_exp": "We testen of je apparaat \\'IPv6 Privacy Extensions for SLAAC\\' (of een ander IPv6-configuratieproces dan SLAAC) gebruikt om het lekken van zijn mogelijk privacygevoelige MAC-adres naar computers waarmee het via IPv6 verbinding maakt te voorkomen.", - "detail_conn_ipv6_privacy_label": "Privacy Extensions voor IPv6", - "detail_conn_ipv6_privacy_verdict_bad": "Je gebruikt SLAAC zonder \\'IPv6 Privacy Extensions\\'.", - "detail_conn_ipv6_privacy_verdict_good": "Je hebt \\'IPv6 Privacy Extensions\\' geactiveerd (of je gebruikt geen SLAAC).", - "detail_conn_ipv6_resolver_conn_exp": "We testen of ten minste één van de door jou gebruikte DNS-resolvers in staat is om onze autoritatieve nameserver te bereiken via IPv6. Vaak levert je internetprovider de DNS-resolver(s).", - "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).

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.", - "detail_mail_auth_dkim_verdict_no_email": "Je domeinnaam ondersteunt geen DKIM-records. Echter omdat je DMARC- en SPF-records aangeven dat er geen mail vanaf je domein wordt verstuurd, is DKIM niet nodig en wordt deze subtest overgeslagen.", - "detail_mail_auth_dmarc_exp": "We testen of DMARC beschikbaar is voor jouw domein. Een ontvangendemailserver kan de DMARC-policy gebruiken om te bepalen hoe om te gaan meteen e-mail met jouw domein als verzender waarvan de authenticatie met zowelDKIM als SPF faalt, en de ontvangende mailserver kan je e-mailadres uit het DMARC-recordgebruiken om je feedbackrapporten over het authenticatieresultaat te sturen. Het hebben van meer dan één DMARC-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt. Let op: DMARC vereist dathet SPF-domein (envelope sender, d.w.z. return-path dat terugkomt inMAIL FROM) en het DKIM-domein (d=) gelijk zijn aan het verzenddomein in hetmailbericht (From:). ", - "detail_mail_auth_dmarc_label": "DMARC aanwezigheid", - "detail_mail_auth_dmarc_tech_table": "DMARC-record|Gevonden op", - "detail_mail_auth_dmarc_tech_table_dmarc_record": "DMARC-record", - "detail_mail_auth_dmarc_tech_table_found_on": "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_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. ", - "detail_mail_auth_dmarc_policy_verdict_good": "Je DMARC-policy is voldoende strikt.", - "detail_mail_auth_dmarc_policy_verdict_policy": "Je DMARC-policy is niet voldoende strikt.", - "detail_mail_auth_spf_exp": "We testen of je domeinnaam een SPF-record heeft. Een ontvangende mailserver kan de IP-adressen in je SPF-record gebruiken om de verzendende mailserver van een ontvangen e-mail met jouw domein als afzender te authenticeren. Het bijbehorende beleid kan worden gebruikt om passende actie te ondernemen als de authenticatie mislukt. Meer dan één SPF-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt.

Voor een \"good practice voor domeinnamen zonder mail\" zie de uitleg van de \"DMARC-policy\" subtest.", - "detail_mail_auth_spf_label": "SPF aanwezigheid", - "detail_mail_auth_spf_tech_table": "SPF-record", - "detail_mail_auth_spf_tech_table_spf_record": "SPF-record", - "detail_mail_auth_spf_verdict_bad": "Je domeinnaam heeft geen geldig SPF-record.", - "detail_mail_auth_spf_verdict_good": "Je domein heeft een SPF-record.", - "detail_mail_auth_spf_policy_exp": "We controleren of de syntax van je SPF-record geldig is en of deze een voldoende strikte policy, d.w.z. ~all (softfail) of -all (hardfail), bevat om misbruik van je domein door phishers en spammers tegen te gaan. Om misbruik van je domein tegen te gaan is een liberale policy, d.w.z. +all (pass) of ?all (neutral), onvoldoende. Als all ontbreekt en er is geen redirect aanwezig in je SPF-record, dan is de default policy ?all.

We volgen ook include en redirect voor geldige SPF-records. Bovendien controleren we of je SPF-record het toegestane aantal van 10 DNS-opvragingen niet overschrijdt waardoor het geen werking meer heeft. Ieder van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.

Merk op dat als het domein onder include of redirect uit macro\\'s bestaat, dan volgen we deze niet omdat we niet over de noodzakelijk informatie van een daadwerkelijke mail of mailserververbinding beschikken om de macro\\'s uit te voeren. Dit betekent dat we het gevolg van macro\\'s niet beoordelen. Bovendien tellen we de door macro\\'s veroorzaakte DNS-opvragingen niet mee om te bepalen of het toegestane aantal DNS-opvragingen is overschreden.

Voor verzendende domeinen heeft het gebruik van ~all (softfail) in plaats van -all (fail) meestal de voorkeur. De reden hiervoor is dat wanneer de SPF-authenticatie faalt met een SPF fail, een ontvangende mailserver de verbinding al kan blokkeren zonder de DKIM-handtekening en het DMARC-beleid te evalueren. Dit kan leiden tot ten onrechte geblokkeerde mails (bijvoorbeeld wanneer mails door de ontvangende mailserver automatisch worden doorgestuurd naar een andere ontvangende mailserver). Merk op dat een getriggerde SPF softfail er nog steeds voor zorgt dat een strikte DMARC policy je domein beschermt als ook de DKIM-authenticatie faalt.

Voor domeinen zonder mail zie de good practice op uitleg van de \"DMARC-policy\" subtest.", - "detail_mail_auth_spf_policy_label": "SPF policy", - "detail_mail_auth_spf_policy_tech_table": "Domein|SPF-record", - "detail_mail_auth_spf_policy_tech_table_domain": "Domein", - "detail_mail_auth_spf_policy_tech_table_spf_record": "SPF-record", - "detail_mail_auth_spf_policy_verdict_all": "Je SPF-policy is niet voldoende strikt.", - "detail_mail_auth_spf_policy_verdict_bad": "Je SPF-policy is syntactisch niet correct.", - "detail_mail_auth_spf_policy_verdict_good": "Je SPF-policy is voldoende strikt.", - "detail_mail_auth_spf_policy_verdict_include": "Je SPF-policy is niet voldoende strikt. Het \\'include\\'-mechanisme in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.", - "detail_mail_auth_spf_policy_verdict_max_lookups": "Je SPF-policy is niet effectief omdat deze meer dan de toegestane 10 DNS-opvragingen vereist. Elk van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.", - "detail_mail_auth_spf_policy_verdict_redirect": "Je SPF-policy is niet voldoende strikt. De \\'redirect modifier\\' in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.", - "detail_mail_dnssec_exists_exp": "We testen of de domeinnaam in je e-mailadres, meer specifiek het SOA-record, ondertekend is met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze jouw mailserverdomeinen (MX) kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar een mailserverdomein dat onder controle is van de aanvaller.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", - "detail_mail_dnssec_exists_label": "DNSSEC aanwezigheid", - "detail_mail_dnssec_exists_tech_table": "E-mailadresdomein|Registrar", - "detail_mail_dnssec_exists_tech_table_email_address_domain": "E-mailadresdomein", - "detail_mail_dnssec_exists_tech_table_registrar": "Registrar", - "detail_mail_dnssec_exists_verdict_bad": "Je e-mailadresdomein is onveilig oftewel \\'insecure\\', omdat het niet ondertekend is met DNSSEC.", - "detail_mail_dnssec_exists_verdict_good": "Je e-mailadresdomein is met DNSSEC ondertekend.", - "detail_mail_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", - "detail_mail_dnssec_exists_verdict_servfail": "De nameservers van je e-mailadresdomein zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", - "detail_mail_dnssec_mx_exists_exp": "We testen of de domeinnamen van je mailservers (MX), meer specifiek hun SOA-records, ondertekend zijn met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze de IP-adressen en DANE-records van jouw mailservers kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar IP-adressen die onder controle staan van de aanvaller óf de beveiligde mailserver-verbinding afluistert.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

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

De geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", - "detail_mail_dnssec_mx_exists_label": "DNSSEC aanwezigheid", - "detail_mail_dnssec_mx_exists_tech_table": "Domein van mailserver (MX)|DNSSEC aanwezig", - "detail_mail_dnssec_mx_exists_tech_table_domain_of_mail_server_mx": "Domein van mailserver (MX)", - "detail_mail_dnssec_mx_exists_tech_table_dnssec_existent": "DNSSEC aanwezig", - "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": "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.", - "detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", - "detail_mail_dnssec_mx_exists_verdict_servfail": "De nameservers van tenminste één van je mailserverdomeinen zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je mailprovider) om dit spoedig op te lossen.", - "detail_mail_dnssec_mx_valid_exp": "We testen of de domeinen van je ontvangende mailservers (MX), meer specifiek hun SOA-records, zijn ondertekend met een geldige DNSSEC-handtekening die ze veilig oftewel \\'secure\\' maakt.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", - "detail_mail_dnssec_mx_valid_label": "DNSSEC geldigheid", - "detail_mail_dnssec_mx_valid_tech_table": "Domein van mailserver (MX)|Status", - "detail_mail_dnssec_mx_valid_tech_table_domain_of_mail_server_mx": "Domein van mailserver (MX)", - "detail_mail_dnssec_mx_valid_tech_table_status": "Status", - "detail_mail_dnssec_mx_valid_verdict_bad": "Tenminste één van de ondertekende domeinen van je mailservers is onbetrouwbaar oftewel \\'bogus\\', omdat zijn DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde de antwoorden van de nameservers, óf je mailserverdomein heeft serieuze DNSSEC-configuratiefouten. Dit laatste maakt je ontvangende mailserver onbereikbaar voor alle verzendende mailservers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met de nameserver-beheerder (vaak je mailprovider).", - "detail_mail_dnssec_mx_valid_verdict_good": "Al de ondertekende domeinnamen van je mailservers zijn veilig oftewel \\'secure\\', omdat hun DNSSEC-handtekeningen geldig zijn.", - "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "Tenminste één van de domeinen van je mailservers is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", - "detail_mail_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zijn.", - "detail_mail_dnssec_valid_label": "DNSSEC geldigheid", - "detail_mail_dnssec_valid_tech_table": "E-mailadresdomein|Status", - "detail_mail_dnssec_valid_tech_table_email_address_domain": "E-mailadresdomein", - "detail_mail_dnssec_valid_tech_table_status": "Status", - "detail_mail_dnssec_valid_verdict_bad": "Je e-mailadresdomein is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", - "detail_mail_dnssec_valid_verdict_good": "Je e-mailadresdomein is veilig oftewel \\'secure\\', omdat zijn DNSSEC-handtekening geldig is.", - "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Je e-mailadresdomein is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", - "detail_mail_ipv6_mx_aaaa_exp": "We testen of er tenminste één AAAA-record met IPv6-adres voor iedere ontvangende mailserver (MX) is. In het geval er geen mailserver is gedefinieerd, geven we een notificatie en we voeren andere subtesten van de mailtest die nog steeds relevant zijn gewoon uit.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.", - "detail_mail_ipv6_mx_aaaa_label": "IPv6-adressen voor mailserver(s)", - "detail_mail_ipv6_mx_aaaa_tech_table": "Mailserver (MX)|IPv6-adres|IPv4-adres", - "detail_mail_ipv6_mx_aaaa_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_ipv6_mx_aaaa_tech_table_ipv6_address": "IPv6-adres", - "detail_mail_ipv6_mx_aaaa_tech_table_ipv4_address": "IPv4-adres", - "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 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": "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_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_ipv6_mx_reach_tech_table_unreachable_ipv6_address": "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.", - "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_tech_table_mail_server": "Mailserver", - "detail_mail_rpki_exists_tech_table_ip_address": "IP-adres", - "detail_mail_rpki_exists_tech_table_rpki_route_origin_authorization": "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.", - "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_tech_table_name_server_of_mx": "Nameserver van MX", - "detail_mail_rpki_mx_ns_exists_tech_table_ip_address": "IP-adres", - "detail_mail_rpki_mx_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server_of_mx": "Nameserver van MX", - "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_mail_rpki_mx_ns_valid_tech_table_rpki_origin_validation_state": "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 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.

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_tech_table_mail_server": "Mailserver", - "detail_mail_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_mail_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_mail_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", - "detail_mail_tls_cert_hostmatch_tech_table": "Mailserver (MX)|Niet-overeenkomende domeinen op certificaat", - "detail_mail_tls_cert_hostmatch_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Niet-overeenkomende domeinen op certificaat", - "detail_mail_tls_cert_hostmatch_verdict_bad": "De domeinnaam van tenminste één van je mailservers komt niet overeen met de domeinnaam op het mailservercertificaat.", - "detail_mail_tls_cert_hostmatch_verdict_good": "De domeinnamen van al je mailservers komen overeen met de domeinnamen op je mailservercertificaten.", - "detail_mail_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", - "detail_mail_tls_cert_pubkey_label": "Publieke sleutel van certificaat", - "detail_mail_tls_cert_pubkey_tech_table": "Mailserver (MX)|Getroffen handtekening-parameters|Status", - "detail_mail_tls_cert_pubkey_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_cert_pubkey_tech_table_affected_signature_parameters": "Getroffen handtekening-parameters", - "detail_mail_tls_cert_pubkey_tech_table_status": "Status", - "detail_mail_tls_cert_pubkey_verdict_bad": "De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt onvoldoende veilige parameters.", - "detail_mail_tls_cert_pubkey_verdict_good": "De digitale handtekeningen van al je mailserver-certificaten gebruiken veilige parameters.", - "detail_mail_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_mail_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van ieder van je mailserver-certificaten is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", - "detail_mail_tls_cert_signature_label": "Handtekening van certificaat", - "detail_mail_tls_cert_signature_tech_table": "Mailserver (MX)|Getroffen hashing-algoritme|Status", - "detail_mail_tls_cert_signature_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_cert_signature_tech_table_affected_hash_algorithm": "Getroffen hashing-algoritme", - "detail_mail_tls_cert_signature_tech_table_status": "Status", - "detail_mail_tls_cert_signature_verdict_bad": "Tenminste één van je mailserver-certificaten is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", - "detail_mail_tls_cert_signature_verdict_good": "Al je mailserver-certificaten zijn ondertekend met een veilig algoritme voor hashing.", - "detail_mail_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je mailserver-certificaten kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je ontvangende mailserver alle noodzakelijke tussenliggende certificaten presenteert.

Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.

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

Niveau van vereistheid: Optioneel", - "detail_mail_tls_cert_trust_label": "Vertrouwensketen van certificaat", - "detail_mail_tls_cert_trust_tech_table": "Mailserver (MX)|Onvertrouwde certificaatketen", - "detail_mail_tls_cert_trust_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_cert_trust_tech_table_untrusted_certificate_chain": "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-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_tech_table_mail_server_mx": "Mail server (MX)", - "detail_mail_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "Eerst gevonden getroffen cipher-paren", - "detail_mail_tls_cipher_order_tech_table_violated_rule_ii_b": "Overtreden regel # (\\'II-B\\')", - "detail_mail_tls_cipher_order_verdict_bad": "Tenminste één van je mailservers dwingt niet zijn eigen cipher-voorkeur af (\\'I\\').", - "detail_mail_tls_cipher_order_verdict_good": "Al je mailservers dwingen hun eigen cipher-voorkeur af (\\'I\\'), en bieden ciphers aan conform de voorgeschreven volgorde (\\'II\\').", - "detail_mail_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je mailserver alleen \\'Goede\\' ciphers ondersteunt.", - "detail_mail_tls_cipher_order_verdict_seclevel_bad": "Tenminste één van je mailservers prefereert niet \\'Goede\\' boven \\'Voldoende\\' en dan pas \\'Uit te faseren\\' ciphers (\\'II\\').", - "detail_mail_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Tenminste een van je mailservers biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\\'II-B\\').", - "detail_mail_tls_ciphers_exp": "

We testen of je ontvangende mailservers (MX) alleen veilige, d.w.z. \\'Goede\\' en/of \\'Voldoende\\', ciphers (ook algoritmeselecties genoemd) ondersteunen. Om te voorkomen dat we tegen \\'rate limits\\' van ontvangende mailservers aanlopen, bevat het testresultaat alleen de eerstgevonden getroffen algoritmeselectie.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing.

  • Vanaf TLS 1.3 omvat de term \\'cipher suite\\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \\'cipher suite\\' ambigu maakt, gebruikt NCSC de term \\'algoritmeselectie\\' om alle vier de functies te omvatten.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselectie. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \\'Goede\\', \\'Voldoende\\' en \\'Uit te faseren\\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\\'. Achter iedere algoritmeselectie staat de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \\'Uit te faseren\\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", - "detail_mail_tls_ciphers_label": "Ciphers (Algoritmeselecties)", - "detail_mail_tls_ciphers_tech_table": "Mailserver (MX)|Eerst gevonden onveilige cipher|Status", - "detail_mail_tls_ciphers_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_ciphers_tech_table_first_found_affected_cipher": "Eerst gevonden onveilige cipher", - "detail_mail_tls_ciphers_tech_table_status": "Status", - "detail_mail_tls_ciphers_verdict_bad": "Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige ciphers.", - "detail_mail_tls_ciphers_verdict_good": "Al je mailservers ondersteunen alleen veilige ciphers.", - "detail_mail_tls_ciphers_verdict_phase_out": "Tenminste één van je mailservers ondersteunt een of meer ciphers die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_mail_tls_compression_exp": "

We testen of je ontvangende mailservers (MX) TLS-compressie ondersteunen.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau
  • Onvoldoende: TLS-compressie
", - "detail_mail_tls_compression_label": "TLS-compressie", - "detail_mail_tls_compression_tech_table": "Mailserver (MX)|TLS-compressie", - "detail_mail_tls_compression_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_compression_tech_table_tls_compression": "TLS-compressie", - "detail_mail_tls_compression_verdict_bad": "Tenminste één van je mailservers ondersteunt TLS-compressie, wat niet veilig is.", - "detail_mail_tls_compression_verdict_good": "Al je mailservers ondersteunen geen TLS-compressie.", - "detail_mail_tls_dane_exists_exp": "We testen of de nameservers van ieder van je ontvangende mailservers (MX) een of meer TLSA-records voor DANE bevatten.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het mailserver-domein.

Merk op dat de test TLSA-records van de types PKIX-TA(0) or PKIX-EE(1) negeert, omdat deze niet gebruikt dienen te worden voor ontvangende mailservers.

De test slaagt daarnaast niet als er geen DNSSEC-bewijs van \\'Denial of Existence\\' voor TLSA-records is. Als een ondertekend TLSA-record bestaat maar tegelijkertijd is er een \\'insecure\\' NXDOMAIN voor hetzelfde domein (door verkeerd werkende DNSSEC-ondertekeningssoftware), dan zal de test ook niet slagen. De laatste twee foutscenario\\'s kunnen leiden tot afleveringsproblemen van aan jou gerichte e-mails door DANE-validerende mailverzenders.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, Appendix A, onder \\'Certificate pinning en DANE\\'.", - "detail_mail_tls_dane_exists_label": "DANE aanwezigheid", - "detail_mail_tls_dane_exists_tech_table": "Mailserver (MX)|DANE TLSA-record aanwezig", - "detail_mail_tls_dane_exists_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA-record aanwezig", - "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.

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_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_dane_rollover_tech_table_dane_rollover_scheme": "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.", - "detail_mail_tls_dane_rollover_verdict_good": "Al je mailserver-domeinen hebben een actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.", - "detail_mail_tls_dane_valid_exp": "We testen of de DANE-fingerprints die je mailserverdomeinen presenteren geldig zijn voor je mailservercertificaten.

Met DANE kan je informatie over jouw mailservercertificaten publiceren in een speciaal DNS-record, een TLSA-record. Verzendende mailservers kunnen de certificaten nu niet alleen via de certificaatautoriteit, maar ook via de TLSA-records controleren op authenticiteit. Een verzendende mail server kan het TLSA-record ook als signaal gebruiken om alleen via STARTTLS (en niet onversleuteld) te verbinden. Als de DANE-fingerprint van een ontvangende mailserver wordt gecontroleerd door de verzendende mailserver, dan kan een actieve aanvaller die in staat is het berichtenverkeer te manipuleren de STARTTLS-encryptie niet verwijderen.", - "detail_mail_tls_dane_valid_label": "DANE geldigheid", - "detail_mail_tls_dane_valid_tech_table": "Mailserver (MX)|DANE TLSA-record geldig", - "detail_mail_tls_dane_valid_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Sleuteluitwisselingsparameters", - "detail_mail_tls_fs_params_tech_table": "Mailserver (MX)|Getroffen parameters|Veiligheidsniveau", - "detail_mail_tls_fs_params_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_fs_params_tech_table_affected_parameters": "Getroffen parameters", - "detail_mail_tls_fs_params_tech_table_security_level": "Veiligheidsniveau", - "detail_mail_tls_fs_params_verdict_bad": "Tenminste één van je mailservers ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", - "detail_mail_tls_fs_params_verdict_good": "Je mailserver ondersteunt voldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", - "detail_mail_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je mailservers niet Diffie-Hellman-sleuteluitwisseling ondersteunen. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", - "detail_mail_tls_fs_params_verdict_phase_out": "Tenminste één van je mailservers ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_mail_tls_kex_hash_func_exp": "

We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", - "detail_mail_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", - "detail_mail_tls_kex_hash_func_tech_table": "Mailserver (MX)|SHA-2-ondersteuning voor handtekeningen", - "detail_mail_tls_kex_hash_func_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "SHA-2-ondersteuning voor handtekeningen", - "detail_mail_tls_kex_hash_func_verdict_good": "Al je mailservers ondersteunen veilige hashfuncties voor sleuteluitwisseling.", - "detail_mail_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie tenminste één van je mailservers gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", - "detail_mail_tls_kex_hash_func_verdict_phase_out": "Ten minste één van je mailservers ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", - "detail_mail_tls_ocsp_stapling_exp": "OUTDATED TEXT; TEST NOT USED
TODO", - "detail_mail_tls_ocsp_stapling_label": "OUTDATED TEXT; TEST NOT USED
TODO", - "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mailserver (MX)|TODO", - "detail_mail_tls_ocsp_stapling_tech_table_outdated_text_test_not_used_mail_server_mx": "OUTDATED TEXT; TEST NOT USED
Mailserver (MX)", - "detail_mail_tls_ocsp_stapling_tech_table_ocsp_stapling": "TODO", - "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_label": "Client-initiated renegotiation", - "detail_mail_tls_renegotiation_client_tech_table": "Mailserver (MX)|Client-initiated renegotiation", - "detail_mail_tls_renegotiation_client_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "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.", - "detail_mail_tls_renegotiation_client_verdict_good": "Al je mailservers staan geen client-initiated renegotiation toe.", - "detail_mail_tls_renegotiation_secure_exp": "

We testen of je mailservers (MX) secure renegotiation ondersteunen.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", - "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", - "detail_mail_tls_renegotiation_secure_tech_table": "Mailserver (MX)|Secure renegotiation", - "detail_mail_tls_renegotiation_secure_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_renegotiation_secure_tech_table_secure_renegotiation": "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_label": "STARTTLS beschikbaar", - "detail_mail_tls_starttls_exists_tech_table": "Mailserver (MX)|STARTTLS", - "detail_mail_tls_starttls_exists_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_starttls_exists_tech_table_starttls": "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 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": "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", - "detail_mail_tls_version_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_version_tech_table_tls_versions": "TLS-versies", - "detail_mail_tls_version_tech_table_status": "Status", - "detail_mail_tls_version_verdict_bad": "Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige TLS-versies.", - "detail_mail_tls_version_verdict_good": "Al je mailservers ondersteunen alleen veilige TLS-versies.", - "detail_mail_tls_version_verdict_phase_out": "Tenminste één van je mailservers ondersteunt een of meer TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_mail_tls_zero_rtt_exp": "

We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie geïnitieerd. De omvang van de ondersteuning voor early data zoals aangegeven door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando vóór de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", - "detail_mail_tls_zero_rtt_label": "0-RTT", - "detail_mail_tls_zero_rtt_tech_table": "Mailserver (MX)|0-RTT", - "detail_mail_tls_zero_rtt_tech_table_mail_server_mx": "Mailserver (MX)", - "detail_mail_tls_zero_rtt_tech_table_0_rtt": "0-RTT", - "detail_mail_tls_zero_rtt_verdict_bad": "Tenminste één van je mailservers ondersteunt 0-RTT, wat niet veilig is.", - "detail_mail_tls_zero_rtt_verdict_good": "Geen van je mailservers ondersteunen 0-RTT.", - "detail_mail_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je mailservers TLS 1.3 niet ondersteunen.", - "detail_tech_data_bogus": "bogus", - "detail_tech_data_good": "goed", - "detail_tech_data_http_csp_has_bare_https": "Aanbeveling: \\'https:\\' schema zonder specifiek hoofddomein moet niet worden gebruikt (#9).", - "detail_tech_data_http_csp_has_data": "Aanbeveling: \\'data:\\' schema moet niet worden gebruikt waar dat niet is toegestaan (#7).", - "detail_tech_data_http_csp_has_host_without_scheme": "Aanbeveling: Een domein zonder schema moet niet worden gebruikt (#8). ", - "detail_tech_data_http_csp_has_http": "Aanbeveling: \\'http:\\' schema moet niet worden gebruikt (#8).", - "detail_tech_data_http_csp_has_invalid_host": "Aanbeveling: Een wildcard (d.w.z. \\'*\\') of \\'127.0.0.1\\' moeten niet worden gebruikt (#9 en #10).", - "detail_tech_data_http_csp_has_unsafe_eval": "Aanbeveling: \\'unsafe-eval\\' moet niet worden gebruikt (#6).", - "detail_tech_data_http_csp_has_unsafe_hashes": "Aanbeveling: \\'unsafe-hashes\\' moet niet worden gebruikt (#6).", - "detail_tech_data_http_csp_has_unsafe_inline": "Aanbeveling: \\'unsafe-inline\\' moet niet worden gebruikt (#6).", - "detail_tech_data_http_csp_missing_invalid_base_uri": "Aanbeveling: \\'base-uri\\' met voldoende veilige waarde moet zijn gedefinieerd (#2).", - "detail_tech_data_http_csp_missing_invalid_default_src": "Aanbeveling: \\'default-src\\' met voldoende veilige waarde moet zijn gedefinieerd (#1).", - "detail_tech_data_http_csp_missing_invalid_form_action": "Aanbeveling: \\'form-action\\' met voldoende veilige waarde moet zijn gedefinieerd (#5).", - "detail_tech_data_http_csp_missing_invalid_frame_ancestors": "Aanbeveling: \\'frame-ancestors\\' met voldoende veilige waarde moet zijn gedefinieerd (#4).", - "detail_tech_data_http_csp_missing_invalid_frame_src": "Aanbeveling: \\'frame-src\\' (of \\'child-src\\' of \\'default-src\\' als fallback) met voldoende veilige waarde moet zijn gedefinieerd (#3).", - "detail_tech_data_http_csp_no_policy_found": "Geen CSP gevonden.", - "detail_tech_data_http_csp_policy_found": "Opgehaalde CSP-waarde: {policy}", - "detail_tech_data_http_referrer_policy_bad_invalid": "Slecht: policy-waarde is niet geldig.", - "detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade": "Slecht: \\'no-referrer-when-downgrade\\' moet niet worden gebruikt.", - "detail_tech_data_http_referrer_policy_bad_origin": "Slecht: \\'origin\\' moet niet worden gebruikt.", - "detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin": "Slecht: \\'origin-when-cross-origin\\' moet niet worden gebruikt.", - "detail_tech_data_http_referrer_policy_bad_unsafe_url": "Slecht: \\'unsafe-url\\' moet niet worden gebruikt.", - "detail_tech_data_http_referrer_policy_no_policy": "Geen Referrer-Policy gevonden.", - "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_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.", - "detail_tech_data_http_securitytxt_multi_lang": "Fout: Het veld \\'Preferred-Languages\\' moet niet meer dan één keer voorkomen.", - "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Aanbeveling: Meerdere \\'CSAF\\'-velden zouden moeten worden teruggebracht tot één \\'CSAF\\'-veld.", - "detail_tech_data_http_securitytxt_no_canonical": "Aanbeveling: Het veld \\'Canonical\\' zou aanwezig moeten zijn in een ondertekend bestand.", - "detail_tech_data_http_securitytxt_no_canonical_match": "Fout: De web URI van security.txt (d.w.z. bij redirecting ten minste de laatste URI van de redirect-keten) moet worden vermeld in een \\'Canonical\\'-veld als dat aanwezig is.", - "detail_tech_data_http_securitytxt_no_contact": "Fout: Het veld \\'Contact\\' moet minstens één keer voorkomen.", - "detail_tech_data_http_securitytxt_no_content_type": "Fout: HTTP Content-Type header moet worden verstuurd.", - "detail_tech_data_http_securitytxt_no_csaf_file": "Fout: Ieder optioneel \\'CSAF\\'-veld moet verwijzen naar een bestand met de naam \\'provider-metadata.json\\'.", - "detail_tech_data_http_securitytxt_no_encryption": "Aanbeveling: Het veld \\'Encryption\\' zou aanwezig moeten zijn wanneer het veld \\'Contact\\' een e-mailadres bevat.", - "detail_tech_data_http_securitytxt_no_expire": "Fout: Het veld \\'Expires\\' moet aanwezig zijn.", - "detail_tech_data_http_securitytxt_no_https": "Fout: De web URI moet beginnen met \\'https://\\' (regel {line_no}).", - "detail_tech_data_http_securitytxt_no_line_separators": "Fout: Elke regel moet eindigen met óf een carriage return en line feed characters óf alleen een line feed character.", - "detail_tech_data_http_securitytxt_no_security_txt_404": "Fout: security.txt kon niet gevonden worden.", - "detail_tech_data_http_securitytxt_no_security_txt_other": "Fout: security.txt kon niet gevonden worden (onverwachte HTTP response code {status_code}).", - "detail_tech_data_http_securitytxt_no_space": "Fout: Veld-scheidingsteken (dubbele punt) moet worden gevolgd door een spatie (regel {line_no}).", - "detail_tech_data_http_securitytxt_no_uri": "Fout: Veldwaarde moet een URI zijn (bijv. beginnend met \\'mailto:\\') (regel {line_no}).", - "detail_tech_data_http_securitytxt_not_signed": "Aanbeveling: security.txt zou digitaal ondertekend moeten zijn.", - "detail_tech_data_http_securitytxt_pgp_data_error": "Fout: Ondertekende security.txt moet een correct \\'ASCII-armored PGP block\\' bevatten.", - "detail_tech_data_http_securitytxt_pgp_error": "Fout: Het decoderen of parsen van de ondertekende security.txt moet slagen.", - "detail_tech_data_http_securitytxt_prec_ws": "Fout: Er mag geen spatie staan voor het veld-scheidingsteken (dubbele punt) (regel {line_no}).", - "detail_tech_data_http_securitytxt_requested_from": "security.txt opgevraagd van {hostname}.", - "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 gecodeerd zijn met UTF-8 in Net-Unicode vorm.", - "detail_tech_data_insecure": "insecure", - "detail_tech_data_insufficient": "onvoldoende", - "detail_tech_data_no": "nee", - "detail_tech_data_not_applicable": "niet van toepassing", - "detail_tech_data_not_reachable": "niet bereikbaar", - "detail_tech_data_not_testable": "niet testbaar", - "detail_tech_data_not_tested": "niet getest", - "detail_tech_data_phase_out": "uit te faseren", - "detail_tech_data_secure": "secure", - "detail_tech_data_sufficient": "voldoende", - "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_appsecpriv_http_csp_tech_table_findings": "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\".

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_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_appsecpriv_http_referrer_policy_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_appsecpriv_http_securitytxt_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_appsecpriv_http_x_content_type_tech_table_x_content_type_options_value": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_appsecpriv_http_x_frame_tech_table_x_frame_options_value": "X-Frame-Options waarde", - "detail_web_appsecpriv_http_x_frame_verdict_bad": "Je webserver biedt geen veilig ingestelde X-Frame-Options aan.", - "detail_web_appsecpriv_http_x_frame_verdict_good": "Je webserver biedt veilig ingestelde X-Frame-Options aan.", - "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We testen of je webserver een HTTP header voor X-XSS-Protection aanbiedt die een voldoende veilige waarde heeft (dat wil zeggen 1 of 1; mode=block). Deze HTTP header kan worden gebruikt om het beschermingsfilter van browsers tegen reflectieve cross-site scripting (XSS) aanvallen te activeren.

Geldige waardes voor de X-XSS-Protection header zijn:

  • 0 deactiveert het XSS-filter. Deze waarde dient NIET te worden gebruikt.
  • 1 activeert het XSS-filter. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het script opschonen en de onveilige delen verwijderen. Deze waarde is normaal gesproken de standaard-waarde (\\'default\\') in browsers als een website geen X-XSS-Protection header aanbiedt.
  • 1; mode=block activeert het XSS-filter én de blokkeermodus. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het antwoord blokkeren en de webpagina niet laden. Dit is de aanbevolen waarde.

Mits goed geconfigureerd kan Content-Security-Policy (CSP) vergelijkbare bescherming en meer bieden aan gebruikers van moderne webbrowsers. X-XSS-Protection biedt in dat geval nog altijd bescherming aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-XSS-Protection waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Niveau van vereistheid: Aanbevolen", - "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", - "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres|X-XSS-Protection waarde", - "detail_web_appsecpriv_http_x_xss_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres", - "detail_web_appsecpriv_http_x_xss_tech_table_x_xss_protection_value": "X-XSS-Protection waarde", - "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt geen veilig ingestelde X-XSS-Protection aan.", - "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt veilig ingestelde X-XSS-Protection aan.", - "detail_web_dnssec_exists_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, ondertekend is met DNSSEC.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", - "detail_web_dnssec_exists_label": "DNSSEC aanwezigheid", - "detail_web_dnssec_exists_tech_table": "Domein|Registrar", - "detail_web_dnssec_exists_tech_table_domain": "Domein", - "detail_web_dnssec_exists_tech_table_registrar": "Registrar", - "detail_web_dnssec_exists_verdict_bad": "Je domein is onveilig oftewel \\'insecure\\', omdat het niet ondertekend is met DNSSEC.", - "detail_web_dnssec_exists_verdict_good": "Je domein is met DNSSEC ondertekend.", - "detail_web_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", - "detail_web_dnssec_exists_verdict_servfail": "De nameservers van je domeinnaam zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", - "detail_web_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \\'secure\\' en de andere keer \\'bogus\\' zij", - "detail_web_dnssec_valid_label": "DNSSEC geldigheid", - "detail_web_dnssec_valid_tech_table": "Domein|Status", - "detail_web_dnssec_valid_tech_table_domain": "Domein", - "detail_web_dnssec_valid_tech_table_status": "Status", - "detail_web_dnssec_valid_verdict_bad": "Je domeinnaam is onbetrouwbaar oftewel \\'bogus\\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", - "detail_web_dnssec_valid_verdict_good": "Je domeinnaam is veilig oftewel \\'secure\\', omdat zijn DNSSEC-handtekening geldig is.", - "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Je domeinnaam is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", - "detail_web_ipv6_web_aaaa_exp": "We testen of er tenminste één AAAA-record met IPv6-adres voor je webserver is.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.", - "detail_web_ipv6_web_aaaa_label": "IPv6-adressen voor webserver", - "detail_web_ipv6_web_aaaa_tech_table": "Webserver|IPv6-adres|IPv4-adres", - "detail_web_ipv6_web_aaaa_tech_table_web_server": "Webserver", - "detail_web_ipv6_web_aaaa_tech_table_ipv6_address": "IPv6-adres", - "detail_web_ipv6_web_aaaa_tech_table_ipv4_address": "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 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 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_tech_table_web_server": "Webserver", - "detail_web_ipv6_web_reach_tech_table_unreachable_ipv6_address": "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.", - "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_tech_table_web_server": "Webserver", - "detail_web_rpki_exists_tech_table_ip_address": "IP-adres", - "detail_web_rpki_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_web_server": "Webserver", - "detail_web_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_web_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_web_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", - "detail_web_tls_cert_hostmatch_tech_table": "Webserver-IP-adres|Niet-overeenkomende domeinen op certificaat", - "detail_web_tls_cert_hostmatch_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Niet-overeenkomende domeinen op certificaat", - "detail_web_tls_cert_hostmatch_verdict_bad": "De domeinnaam van je website komt niet overeen met de domeinnaam op je websitecertificaat.", - "detail_web_tls_cert_hostmatch_verdict_good": "De domeinnaam van je website komt overeen met de domeinnaam op je websitecertificaat.", - "detail_web_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", - "detail_web_tls_cert_pubkey_label": "Publieke sleutel van certificaat", - "detail_web_tls_cert_pubkey_tech_table": "Webserver-IP-adres|Getroffen handtekening-parameters|Status", - "detail_web_tls_cert_pubkey_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_cert_pubkey_tech_table_affected_signature_parameters": "Getroffen handtekening-parameters", - "detail_web_tls_cert_pubkey_tech_table_status": "Status", - "detail_web_tls_cert_pubkey_verdict_bad": "De digitale handtekening van je websitecertificaat gebruikt onvoldoende veilige parameters.", - "detail_web_tls_cert_pubkey_verdict_good": "De digitale handtekening van je websitecertificaat gebruikt veilige parameters.", - "detail_web_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van je websitecertificaat gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_web_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van het websitecertificaat is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", - "detail_web_tls_cert_signature_label": "Handtekening van certificaat", - "detail_web_tls_cert_signature_tech_table": "Webserver-IP-adres|Getroffen hashing-algoritme|Status", - "detail_web_tls_cert_signature_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_cert_signature_tech_table_affected_hash_algorithm": "Getroffen hashing-algoritme", - "detail_web_tls_cert_signature_tech_table_status": "Status", - "detail_web_tls_cert_signature_verdict_bad": "Je websitecertificaat is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", - "detail_web_tls_cert_signature_verdict_good": "Je websitecertificaat is ondertekend met een voldoende algoritme voor hashing.", - "detail_web_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je webserver alle noodzakelijke tussenliggende certificaten presenteert.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B3-4.", - "detail_web_tls_cert_trust_label": "Vertrouwensketen van certificaat", - "detail_web_tls_cert_trust_tech_table": "Webserver-IP-adres|Onvertrouwde certificaatketen", - "detail_web_tls_cert_trust_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_cert_trust_tech_table_untrusted_certificate_chain": "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-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_tech_table_web_server_ip_address": "Webserver IP-adres", - "detail_web_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "Eerst gevonden getroffen cipher-paren", - "detail_web_tls_cipher_order_tech_table_violated_rule_ii_b": "Overtreden regel # (\\'II-B\\')", - "detail_web_tls_cipher_order_verdict_bad": "Je webserver dwingt niet zijn eigen cipher-voorkeur af (\\'I\\').", - "detail_web_tls_cipher_order_verdict_good": "Je webserver dwingt zijn eigen cipher-voorkeur af (\\'I\\'), en biedt ciphers aan conform de voorgeschreven volgorde (\\'II\\').", - "detail_web_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver alleen \\'Goede\\' ciphers ondersteunt.", - "detail_web_tls_cipher_order_verdict_seclevel_bad": "Je webserver prefereert niet \\'Goede\\' boven \\'Voldoende\\' en dan pas \\'Uit te faseren\\' ciphers (\\'II\\').", - "detail_web_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Je webserver biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\\'II-B\\').", - "detail_web_tls_ciphers_exp": "

We testen of je webserver alleen veilige, d.w.z. \\'Goede\\' en/of \\'Voldoende\\', ciphers (ook algoritmeselecties genoemd) ondersteunt.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing. Een webserver kan meer dan één algoritmeselectie ondersteunen.

  • Vanaf TLS 1.3 omvat de term \\'cipher suite\\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \\'cipher suite\\' ambigu maakt, gebruikt NCSC de term \\'algoritmeselectie\\' om alle vier de functies aan te duiden.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselecties. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \\'Goede\\', \\'Voldoende\\' en \\'Uit te faseren\\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\\'. Achter iedere algoritmeselectie noemen we de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \\'Uit te faseren\\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", - "detail_web_tls_ciphers_label": "Ciphers (Algoritmeselecties)", - "detail_web_tls_ciphers_tech_table": "Webserver-IP-adres|Getroffen ciphers|Status", - "detail_web_tls_ciphers_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_ciphers_tech_table_affected_ciphers": "Getroffen ciphers", - "detail_web_tls_ciphers_tech_table_status": "Status", - "detail_web_tls_ciphers_verdict_bad": "Je webserver ondersteunt een of meer onvoldoende veilige ciphers.", - "detail_web_tls_ciphers_verdict_good": "Je webserver ondersteunt alleen veilige ciphers.", - "detail_web_tls_ciphers_verdict_phase_out": "Je webserver ondersteunt een of meer ciphers die de status uit te faseren hebben omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_web_tls_compression_exp": "

We testen of je webserver TLS-compressie ondersteunt.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", - "detail_web_tls_compression_label": "TLS-compressie", - "detail_web_tls_compression_tech_table": "Webserver-IP-adres|TLS-compressie", - "detail_web_tls_compression_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_compression_tech_table_tls_compression": "TLS-compressie", - "detail_web_tls_compression_verdict_bad": "Je webserver ondersteunt TLS-compressie, wat niet veilig is.", - "detail_web_tls_compression_verdict_good": "Je webserver ondersteunt geen TLS-compressie.", - "detail_web_tls_dane_exists_exp": "We testen of de nameserver van je websitedomein een correct ondertekend TLSA-record voor DANE bevat.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het websitedomein, of als er DANE-gerelateerde DNSSEC-issues zijn (bijv. geen bewijs voor \\'Denial of Existence\\').

Zie \\'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\\' van NCSC, Appendix A, onder \\'Certificate pinning en DANE\\'.

Niveau van vereistheid: Optioneel", - "detail_web_tls_dane_exists_label": "DANE aanwezigheid", - "detail_web_tls_dane_exists_tech_table": "Webserver-IP-adres|DANE TLSA-record aanwezig", - "detail_web_tls_dane_exists_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA-record aanwezig", - "detail_web_tls_dane_exists_verdict_bad": "Je websitedomein bevat geen TLSA-record voor DANE.", - "detail_web_tls_dane_exists_verdict_bogus": "Je websitedomein bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Vraag je nameserver-beheerder om deze fout op te lossen.", - "detail_web_tls_dane_exists_verdict_good": "Je websitedomein bevat een TLSA-record voor DANE.", - "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", - "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", - "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", - "detail_web_tls_dane_rollover_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", - "detail_web_tls_dane_rollover_tech_table_dane_rollover_scheme": "DANE rollover scheme", - "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", - "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", - "detail_web_tls_dane_valid_exp": "We testen of de DANE-fingerprint die je domein presenteert geldig is voor je websitecertificaat.

Met DANE kan je informatie over jouw websitecertificaat publiceren in een speciaal DNS-record, een TLSA-record. Clients, zoals webbrowsers, kunnen het certificaat nu niet alleen via de certificaatautoriteit, maar ook via het TLSA-record controleren op authenticiteit. Een client kan het TLSA-record ook als signaal gebruiken om alleen via HTTPS (en niet via HTTP) te verbinden. DNSSEC is een noodzakelijke randvoorwaarde voor DANE. Helaas ondersteunen nog niet veel webbrowsers DANE-validatie.

Niveau van vereistheid: Aanbevolen (alleen als subtest voor \\'DANE aanwezigheid\\' is geslaagd)", - "detail_web_tls_dane_valid_label": "DANE geldigheid", - "detail_web_tls_dane_valid_tech_table": "Webserver-IP-adres|DANE TLSA-record geldig", - "detail_web_tls_dane_valid_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Sleuteluitwisselingsparameters", - "detail_web_tls_fs_params_tech_table": "Webserver-IP-adres|Getroffen parameters|Status", - "detail_web_tls_fs_params_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_fs_params_tech_table_affected_parameters": "Getroffen parameters", - "detail_web_tls_fs_params_tech_table_status": "Status", - "detail_web_tls_fs_params_verdict_bad": "Je webserver ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", - "detail_web_tls_fs_params_verdict_good": "Je webserver ondersteunt veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", - "detail_web_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je webserver niet Diffie-Hellman-sleuteluitwisseling ondersteunt. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", - "detail_web_tls_fs_params_verdict_phase_out": "Je webserver ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_web_tls_http_compression_exp": "

We testen of je webserver HTTP-compressie ondersteunt.

Bij het HTTP-protocol wordt compressie vaak gebruikt om de beschikbare bandbreedte efficiënter te gebruiken. HTTP-compressie maakt de beveiligde verbinding met je webserver echter kwetsbaar voor de BREACH-aanval. Weeg de voors en tegens van HTTP-compressie zorgvuldig tegen elkaar af. Wanneer u kiest voor het gebruik van HTTP-compressie, ga dan na of het mogelijk is om hieruit voortvloeiende potentiële applicatie-aanvallen te beperken. Een voorbeeld van een dergelijke maatregel is het beperken van de mate waarin een aanvaller de respons van de server kan beïnvloeden.

Dit testonderdeel controleert of de webserver op rootdirectory-niveau HTTP-compressie ondersteunt, maar controleert geen andere websitebronnen zoals plaatje en scripts.

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

Niveau van vereistheid: Optioneel

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", - "detail_web_tls_http_compression_label": "HTTP-compressie", - "detail_web_tls_http_compression_tech_table": "Webserver-IP-adres|HTTP-compressie", - "detail_web_tls_http_compression_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_http_compression_tech_table_http_compression": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_https_exists_tech_table_https_existent": "HTTPS aanwezig", - "detail_web_tls_https_exists_verdict_bad": "Je website biedt geen HTTPS aan.", - "detail_web_tls_https_exists_verdict_good": "Je website biedt HTTPS aan.", - "detail_web_tls_https_exists_verdict_other": "Je webserver is niet bereikbaar.", - "detail_web_tls_https_forced_exp": "We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf \\'upgraden\\' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie \\'Webapplicatie-richtlijnen, Verdieping\\' van NCSC, richtlijn U/WA.05.", - "detail_web_tls_https_forced_label": "HTTPS-doorverwijzing", - "detail_web_tls_https_forced_tech_table": "Webserver-IP-adres|HTTPS-doorverwijzing", - "detail_web_tls_https_forced_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_https_forced_tech_table_https_redirect": "HTTPS-doorverwijzing", - "detail_web_tls_https_forced_verdict_bad": "Je webserver ondersteunt zowel HTTP als HTTPS, maar verwijst bezoekers niet automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", - "detail_web_tls_https_forced_verdict_good": "Je webserver verwijst bezoekers automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", - "detail_web_tls_https_forced_verdict_no_https": "Deze test is niet uitgevoerd, omdat je webserver geen HTTPS biedt of alleen HTTPS met een te verouderde, onveilige TLS-configuratie.", - "detail_web_tls_https_forced_verdict_other": "Je webserver biedt alleen ondersteuning voor HTTPS en niet voor HTTP.", - "detail_web_tls_https_hsts_exp": "We testen of je webserver HSTS ondersteunt.

Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.

HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt man-in-the-middle-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van tenminste 1 jaar (max-age=31536000) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen.

De test controleert niet of preload wordt gebruikt en of het domein is opgenomen in de HSTS Preload Lijst.

Aanbevelingen voor implementatie

HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze niet bereikbaar zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen.

Daarom adviseren we u om de onderstaande implementatiestappen te volgen:

  1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);

  2. Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina\\'s. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.

  3. Begin met 5 minuten (max-age=300);

  4. Verhoog dit naar 1 week (max-age=604800);
  5. Verhoog dit naar 1 maand (max-age=2592000);

  6. Verhoog het naar 1 jaar (max-age=31536000) of meer.

  7. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik includeSubDomains alleen als je er volledig zeker van bent dat alle (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.

  8. Gebruik preload alleen als je heel zeker weet dat je je domein wil laten opnemen in de HSTS Preload Lijst. HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien.

Zie \\'Webapplicatie-richtlijnen, Verdieping\\' van NCSC, richtlijn U/WA.05.", - "detail_web_tls_https_hsts_label": "HSTS", - "detail_web_tls_https_hsts_tech_table": "Webserver-IP-adres|HSTS-policy", - "detail_web_tls_https_hsts_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_https_hsts_tech_table_hsts_policy": "HSTS-policy", - "detail_web_tls_https_hsts_verdict_bad": "Je webserver biedt geen HSTS-policy aan.", - "detail_web_tls_https_hsts_verdict_good": "Je webserver biedt een HSTS-policy aan.", - "detail_web_tls_https_hsts_verdict_other": "Je webserver biedt een HSTS-policy aan met een geldigheidsduur voor caching (max-age) die niet voldoende lang (d.w.z. korter dan 1 jaar) is.", - "detail_web_tls_kex_hash_func_exp": "

We testen of je webserver ondersteuning biedt voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", - "detail_web_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", - "detail_web_tls_kex_hash_func_tech_table": "Webserver-IP-adress|SHA-2-ondersteuning voor handtekeningen", - "detail_web_tls_kex_hash_func_tech_table_web_server_ip_address": "Webserver-IP-adress", - "detail_web_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "SHA-2-ondersteuning voor handtekeningen", - "detail_web_tls_kex_hash_func_verdict_good": "Je webserver ondersteunt een veilige hashfunctie voor sleuteluitwisseling.", - "detail_web_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie je webserver gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", - "detail_web_tls_kex_hash_func_verdict_phase_out": "Je webserver ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", - "detail_web_tls_ocsp_stapling_exp": "

We testen of je webserver de TLS Certificate Status extension of te wel OCSP stapling ondersteunt.

De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.

Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifiëren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.

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

Niveau van vereistheid: Optioneel

OCSP stapling

  • Goed: Aan
  • Voldoende: Uit
", - "detail_web_tls_ocsp_stapling_label": "OCSP stapling", - "detail_web_tls_ocsp_stapling_tech_table": "Webserver-IP-adres|OCSP stapling", - "detail_web_tls_ocsp_stapling_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", - "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_label": "Client-initiated renegotiation", - "detail_web_tls_renegotiation_client_tech_table": "Webserver-IP-adres|Client-initiated renegotiation", - "detail_web_tls_renegotiation_client_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "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.", - "detail_web_tls_renegotiation_client_verdict_good": "Je webserver staat geen client-initiated renegotiation toe.", - "detail_web_tls_renegotiation_secure_exp": "

We testen of je webserver secure renegotiation ondersteunt.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \\'opnieuw onderhandelen\\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", - "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", - "detail_web_tls_renegotiation_secure_tech_table": "Webserver-IP-adres|Secure renegotiation", - "detail_web_tls_renegotiation_secure_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", - "detail_web_tls_renegotiation_secure_verdict_bad": "Je webserver ondersteunt insecure renegotiation, wat uiteraard niet veilig is.", - "detail_web_tls_renegotiation_secure_verdict_good": "Je webserver ondersteunt secure renegotiation.", - "detail_web_tls_version_exp": "

We testen of je webserver alleen veilige TLS-versies ondersteunt.

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

Merk op dat browsermakers hebben aangekondigd dat ze zullen stoppen met de ondersteuning van TLS 1.1 en 1.0. Daardoor zullen websites die geen TLS 1.2 en/of 1.3 ondersteunen onbereikbaar worden.

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_web_tls_version_label": "TLS-versie", - "detail_web_tls_version_tech_table": "Webserver-IP-adres|TLS-versie|Status", - "detail_web_tls_version_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_version_tech_table_tls_version": "TLS-versie", - "detail_web_tls_version_tech_table_status": "Status", - "detail_web_tls_version_verdict_bad": "Je webserver ondersteunt onvoldoende veilige TLS-versies.", - "detail_web_tls_version_verdict_good": "Je webserver ondersteunt alleen veilige TLS-versies.", - "detail_web_tls_version_verdict_phase_out": "Je webserver ondersteunt TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", - "detail_web_tls_zero_rtt_exp": "

We testen of je webserver Zero Round Trip Time Resumption (0-RTT) ondersteunt.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina / opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor early data zoals aangegeven door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging vóór de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-HTTP 425 Too Early, dan wordt aangenomen dat de webserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", - "detail_web_tls_zero_rtt_label": "0-RTT", - "detail_web_tls_zero_rtt_tech_table": "Webserver-IP-adres|0-RTT", - "detail_web_tls_zero_rtt_tech_table_web_server_ip_address": "Webserver-IP-adres", - "detail_web_tls_zero_rtt_tech_table_0_rtt": "0-RTT", - "detail_web_tls_zero_rtt_verdict_bad": "Je webserver ondersteunt 0-RTT, wat niet veilig is.", - "detail_web_tls_zero_rtt_verdict_good": "Je webserver ondersteunt geen 0-RTT.", - "detail_web_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver TLS 1.3 niet ondersteunt. ", - "detail_web_mail_ipv6_ns_aaaa_exp": "We testen of je domeinnaam tenminste twee nameservers met een IPv6-adres heeft.

Dit sluit aan bij de \"Technische eisen voor registratie en gebruik van .nl-domeinnamen\" d.d. 13 november 2017 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.

\\'IPv4-mapped IPv6 addresses\\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze test, aangezien zij geen IPv6-connectiviteit bieden.", - "detail_web_mail_ipv6_ns_aaaa_label": "IPv6-adressen voor nameservers", - "detail_web_mail_ipv6_ns_aaaa_tech_table": "Nameserver|IPv6-adres|IPv4-adres", - "detail_web_mail_ipv6_ns_aaaa_tech_table_name_server": "Nameserver", - "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv6_address": "IPv6-adres", - "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv4_address": "IPv4-adres", - "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "Geen van de nameservers van je domeinnaam heeft een IPv6-adres.", - "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Twee of meer nameservers van je domeinnaam hebben een IPv6-adres.", - "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Slechts één nameserver van je domeinnaam heeft een IPv6-adres.", - "detail_web_mail_ipv6_ns_reach_exp": "We testen of alle nameservers, die een AAAA-record met IPv6-adres hebben, bereikbaar zijn via IPv6.", - "detail_web_mail_ipv6_ns_reach_label": "IPv6-bereikbaarheid van nameservers", - "detail_web_mail_ipv6_ns_reach_tech_table": "Nameserver|Onbereikbaar IPv6-adres", - "detail_web_mail_ipv6_ns_reach_tech_table_name_server": "Nameserver", - "detail_web_mail_ipv6_ns_reach_tech_table_unreachable_ipv6_address": "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.", - "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_tech_table_name_server": "Nameserver", - "detail_web_mail_rpki_ns_exists_tech_table_ip_address": "IP-adres", - "detail_web_mail_rpki_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server": "Nameserver", - "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", - "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", - "detail_web_mail_rpki_ns_valid_tech_table_rpki_origin_validation_state": "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 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", - "faqs_report_subtest_good": "Goed: geslaagd voor VEREISTE, AANBEVOLEN of OPTIONELE subtest ⇒ eerste: volledige score / laatste twee: geen impact op score", - "faqs_report_subtest_info": "Ter informatie: gezakt voor OPTIONELE subtest ⇒ geen impact op score", - "faqs_report_subtest_not_tested": "Niet getest, want al gezakt voor gerelateerde bovenliggende subtest ⇒ nulscore", - "faqs_report_subtest_title": "Iconen per subtest", - "faqs_report_subtest_warning": "Waarschuwing: gezakt voor AANBEVOLEN subtest ⇒ geen impact op score", - "faqs_report_test_bad": "Slecht: gezakt voor tenminste één VEREISTE subtest ⇒ geen volledige score voor testcategorie", - "faqs_report_test_error": "Testfout: uitvoeringsfout voor tenminste één subtest ⇒ geen resultaat voor testcategorie", - "faqs_report_test_good": "Goed: geslaagd voor alle subtesten ⇒ volledige score voor testcategorie ", - "faqs_report_test_info": "Ter informatie: gezakt voor tenminste één OPTIONELE subtest ⇒ volledige score voor testcategorie", - "faqs_report_test_title": "Iconen per testcategorie", - "faqs_report_test_warning": "Waarschuwing: gezakt voor tenminste één AANBEVOLEN subtest ⇒ volledige score voor testcategorie ", - "faqs_report_title": "Toelichting op testrapport", - "faqs_rpki_title": "Autorisatie voor routering (RPKI)", - "faqs_starttls_title": "Beveiligd e-mailtransport (STARTTLS en DANE)", - "faqs_title": "Kennisbank", - "halloffame_champions_menu": "Kampioenen!", - "halloffame_champions_subtitle": "100% in website- én e-mailtest", - "halloffame_champions_text": "De {{count}} onderstaande domeinnamen scoren 100% in zowel de websitetest als de e-mailtest. Leden van deze Hall of Fame mogen beide 100%-badges gebruiken.", - "halloffame_champions_title": "Hall of Fame - Kampioenen!", - "halloffame_mail_badge": "Badge met tekst: 100%-score in e-mailtest", - "halloffame_mail_menu": "E-mail", - "halloffame_mail_subtitle": "100% in e-mailtest", - "halloffame_mail_text": "De {{count}} onderstaande domeinnamen scoren 100% in de e-mailtest. Leden van deze Hall of Fame mogen de 100%-badge voor mail gebruiken.", - "halloffame_mail_title": "Hall of Fame - E-mail", - "halloffame_web_badge": "Badge met tekst: 100%-score in websitetest", - "halloffame_web_menu": "Websites", - "halloffame_web_subtitle": "100% in websitetest", - "halloffame_web_text": "De {{count}} onderstaande domeinnamen scoren 100% in de websitetest. Leden van deze Hall of Fame mogen de 100%-badge voor websites gebruiken.", - "halloffame_web_title": "Hall of Fame - Websites", - "home_pagetitle": "Test voor moderne Internetstandaarden zoals IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE.", - "home_stats_connection": "unieke verbindingen", - "home_stats_connection_items": "", - "home_stats_header": "Tests in cijfers", - "home_stats_mail": "unieke mail-domeinen", - "home_stats_mail_items": "", - "home_stats_notpassed": "0-99%:", - "home_stats_passed": "100%:", - "home_stats_website": "unieke web-domeinen", - "home_stats_website_items": "", - "home_teaser": "Moderne Internetstandaarden zorgen voor meer betrouwbaarheid en verdere groei van het Internet.
Gebruik jij ze al?", - "mail_pagetitle": "E-mailtest:", - "mail_title": "E-mailtest: {{prettyaddr}}", - "mail_tweetmessage": "De%20mailserver%20op%20{{report.domain}}%20scoort%20{{score}}%25%20in%20de%20e-mailtest%20van%20%40Internet_nl%3A", - "page_gotocontents": "Ga naar tekst-inhoud", - "page_gotofooter": "Ga naar de footer", - "page_gotomainmenu": "Ga naar het hoofd-menu", - "page_metadescription": "Test voor moderne Internetstandaarden IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI en security.txt", - "page_metakeywords": "IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, testtool, testen, check, controle, internet, internetstandaarden, open standaarden, moderne standaarden, beveiliging, security, internetbeveiliging, mail, e-mailbeveiliging, website, websitebeveiliging, internetverbinding, beveiligde verbinding, e-mailauthenticatie, encryptie, versleuteling, ciphers, cipher suites, PKI, SSL certificaat, TLS certificaat, websitecertificaat, Platform Internetstandaarden", - "page_sitedescription": "Is jouw internet up-to-date?", - "page_sitetitle": "Internet.nl", - "page404_title": "Pagina niet gevonden!", - "probes_auto_redirect": "Als de test gereed is, word je automatisch doorgestuurd naar de resultaatpagina.", - "probes_no_javascript": "Controleer of de testresultaten beschikbaar zijn. Zo niet, dan word je automatisch teruggeleid naar deze pagina.", - "probes_no_javascript_connection": "JavaScript inactief. Activeer JavaScript om de test toch uit te kunnen voeren.", - "probes_no_redirection": "Testfout. Probeer het later opnieuw, of test een andere domeinnaam.", - "probes_test_finished": "Test klaar! Resultaten beschikbaar...", - "probes_test_running": "Bezig...", - "probes_tests_description": "De onderstaande onderdelen worden getest.", - "probes_tests_duration": "Het testen duurt tussen de 5 en {{cache_ttl}} seconden.", - "results_dated_presentation": "Oude resultaatpresentatie. Doe de test opnieuw.", - "results_domain_appsecpriv_http_headers_label": "HTTP security headers", - "results_domain_appsecpriv_other_options_label": "Andere beveiligingsopties", - "results_domain_ipv6_web_server_label": "Webserver", - "results_domain_rpki_web_server_label": "Webserver", - "results_domain_tls_http_headers_label": "HTTP headers", - "results_domain_tls_https_label": "HTTP", - "results_domain_tls_tls_label": "TLS", - "results_domain_mail_ipv6_name_servers_label": "Nameservers van domein", - "results_domain_mail_rpki_name_servers_label": "Nameservers van domein", - "results_domain_mail_tls_certificate_label": "Certificaat", - "results_domain_mail_tls_dane_label": "DANE", - "results_empty_argument_alt_text": "Geen", - "results_explanation_label": "Testuitleg:", - "results_further_testing_connection_label": "Aanvullende verbindingstesten", - "results_further_testing_mail_label": "Aanvullende e-mailtesten", - "results_further_testing_web_label": "Aanvullende websitetesten", - "results_mail_auth_dkim_label": "DKIM", - "results_mail_auth_dmarc_label": "DMARC", - "results_mail_auth_spf_label": "SPF", - "results_mail_dnssec_domain_label": "E-mailadresdomein", - "results_mail_dnssec_mail_servers_label": "Mailserverdomein(en)", - "results_mail_ipv6_mail_servers_label": "Mailserver(s)", - "results_mail_rpki_mail_servers_label": "Mailserver(s)", - "results_mail_rpki_mx_name_servers_label": "Nameservers van mailserver(s)", - "results_mail_tls_starttls_label": "TLS", - "results_no_icon_detail_close": "sluit", - "results_no_icon_detail_open": "open", - "results_no_icon_status_error": "Error", - "results_no_icon_status_failed": "Gezakt", - "results_no_icon_status_info": "Informatie", - "results_no_icon_status_not_tested": "Niet-testbaar", - "results_no_icon_status_passed": "Geslaagd", - "results_no_icon_status_warning": "Suggestie", - "results_panel_button_hide": "Verberg details", - "results_panel_button_show": "Toon details", - "results_perfect_score": "Gefeliciteerd, je domeinnaam wordt spoedig in de Hall of Fame opgenomen!", - "results_permalink": "Permalink testresultaat {{permadate|date:\\'(Y-m-d H:i T)\\'}}", - "results_rerun_test": "Herhaal de test", - "results_retest_time": "Seconden tot hertest-mogelijkheid:", - "results_score_description": "Het domein {{prettyaddr}} heeft een testscore van {{score}}%.", - "results_tech_details_label": "Technische details:", - "results_test_direct": "Test direct:", - "results_test_email_label": "Test andere e-mail", - "results_test_website_label": "Test andere website", - "results_test_info": "Toelichting op testrapport", - "results_verdict_label": "Uitslag:", - "test_connipv6_failed_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", - "test_connipv6_failed_summary": "Moderne adressen niet bereikbaar (IPv6)", - "test_connipv6_info_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", - "test_connipv6_info_summary": "Moderne adressen niet bereikbaar (IPv6)", - "test_connipv6_label": "Moderne adressen bereikbaar (IPv6)", - "test_connipv6_passed_description": "Goed gedaan! Je internetprovider heeft je een modern internetadres (IPv6) gegeven. Daardoor kan je andere computers met moderne adressen bereiken.", - "test_connipv6_passed_summary": "Moderne adressen bereikbaar (IPv6)", - "test_connipv6_title": "Moderne adressen bereikbaar?", - "test_connipv6_warning_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", - "test_connipv6_warning_summary": "Moderne adressen niet bereikbaar (IPv6)", - "test_connresolver_failed_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", - "test_connresolver_failed_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", - "test_connresolver_info_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", - "test_connresolver_info_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", - "test_connresolver_label": "Controle van domein-handtekeningen (DNSSEC)", - "test_connresolver_passed_description": "Goed gedaan! Domein-handtekeningen (DNSSEC) worden voor jou gecontroleerd. Daardoor ben je beschermd tegen vervalste vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen.", - "test_connresolver_passed_summary": "Domein-handtekeningen gecontroleerd (DNSSEC)", - "test_connresolver_title": "Domein-handtekeningen gecontroleerd?", - "test_connresolver_warning_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", - "test_connresolver_warning_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", - "test_error_summary": "Fout tijdens uitvoering van test!", - "test_mailauth_failed_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", - "test_mailauth_failed_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", - "test_mailauth_info_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", - "test_mailauth_info_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", - "test_mailauth_label": "Echtheidswaarmerken tegen phishing (DMARC, DKIM en SPF)", - "test_mailauth_passed_description": "Goed gedaan! Je domein bevat alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails.", - "test_mailauth_passed_summary": "Echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", - "test_mailauth_title": "Echtheidswaarmerken tegen e-mailphishing?", - "test_mailauth_warning_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", - "test_mailauth_warning_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", - "test_maildnssec_failed_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", - "test_maildnssec_failed_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", - "test_maildnssec_info_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", - "test_maildnssec_info_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", - "test_maildnssec_label": "Ondertekende domeinnamen (DNSSEC)", - "test_maildnssec_passed_description": "Goed gedaan! Je e-mailadresdomein en je mailserverdomein(en) zijn ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen daardoor betrouwbaar het IP-adres van je ontvangende mailserver(s) opvragen.", - "test_maildnssec_passed_summary": "Alle domeinnamen ondertekend (DNSSEC)", - "test_maildnssec_title": "Domeinnamen ondertekend?", - "test_maildnssec_warning_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", - "test_maildnssec_warning_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", - "test_mailipv6_failed_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_failed_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", - "test_mailipv6_info_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_info_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", - "test_mailipv6_label": "Modern adres (IPv6)", - "test_mailipv6_passed_description": "Goed gedaan! Je mailserver is bereikbaar voor verzenders met moderne adressen (IPv6). Daardoor is je mailserver volledig onderdeel van het moderne Internet.", - "test_mailipv6_passed_summary": "Bereikbaar via modern internetadres (IPv6)", - "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_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)", - "test_mailrpki_label": "Route-autorisatie (RPKI)", - "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": "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)", - "test_mailtls_info_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_info_summary": "Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)", - "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: 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 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)", - "test_mailtls_null_mx_with_other_mx_description": "Waarschuwing: 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.", - "test_mailtls_null_mx_with_other_mx_summary": "Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)", - "test_mailtls_null_mx_without_a_aaaa_description": "Waarschuwing: 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.", - "test_mailtls_null_mx_without_a_aaaa_summary": "Goed geconfigureerd niet-ontvangend mail domein, maar met overbodig record (STARTTLS en DANE)", - "test_mailtls_passed_description": "Goed gedaan! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) een beveiligde verbinding opzetten. STARTTLS voorkomt dat passieve aanvallers e-mails onderweg naar jou kunnen lezen. DANE beschermt tegen actieve aanvallers, die door manipulatie van het mailverkeer de STARTTLS-encryptie kunnen verwijderen.", - "test_mailtls_passed_summary": "Mailserver-verbinding voldoende beveiligd (STARTTLS en DANE)", - "test_mailtls_title": "Beveiligde mailserver-verbinding?", - "test_mailtls_unreachable_description": "Testfout: tenminste één van jouw ontvangende mailservers was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw mailserver(s).", - "test_mailtls_unreachable_summary": "Onbereikbare ontvangende mailserver (STARTTLS en DANE)", - "test_mailtls_untestable_description": "Testfout: tenminste één van jouw ontvangende mailservers was niet testbaar voor ons. Daardoor was het niet mogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door onder meer SMTP errors en geactiveerde ratelimiting-maatregelen die verbindingen tegenhouden.", - "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. 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. 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. 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. 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)", - "test_sitednssec_info_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_info_summary": "Domeinnaam niet ondertekend (DNSSEC)", - "test_sitednssec_label": "Ondertekende domeinnaam (DNSSEC)", - "test_sitednssec_passed_description": "Goed gedaan! Je domeinnaam is ondertekend met een geldige handtekening (DNSSEC). Daardoor zijn bezoekers die controle van domein-handtekeningen geactiveerd hebben, beschermd tegen gemanipuleerde vertaling van jouw domeinnaam naar kwaadaardige internetadressen.", - "test_sitednssec_passed_summary": "Domeinnaam ondertekend (DNSSEC)", - "test_sitednssec_title": "Domeinnaam ondertekend?", - "test_sitednssec_warning_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_warning_summary": "Domeinnaam niet ondertekend (DNSSEC)", - "test_siteipv6_failed_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_failed_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", - "test_siteipv6_info_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_info_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", - "test_siteipv6_label": "Modern adres (IPv6)", - "test_siteipv6_passed_description": "Goed gedaan! Je website is bereikbaar voor bezoekers die een moderne internetadres (IPv6) gebruiken, en daardoor volledig onderdeel van het moderne internet.", - "test_siteipv6_passed_summary": "Bereikbaar via moderne internetadres (IPv6)", - "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_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)", - "test_siterpki_label": "Route-autorisatie (RPKI)", - "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": "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)", - "test_sitetls_info_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_info_summary": "Verbinding niet of onvoldoende beveiligd (HTTPS)", - "test_sitetls_label": "Beveiligde verbinding (HTTPS)", - "test_sitetls_passed_description": "Goed gedaan! De verbinding met je website is voldoende beveiligd (HTTPS). Gegevens die onderweg zijn tussen je website en haar bezoekers, zijn daardoor beschermd tegen afluisteren en manipulatie.", - "test_sitetls_passed_summary": "Verbinding voldoende beveiligd (HTTPS)", - "test_sitetls_title": "Beveiligde verbinding?", - "test_sitetls_unreachable_description": "Je webserver was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor HTTPS (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw webserver.", - "test_sitetls_unreachable_summary": "Onbereikbare webserver (HTTPS)", - "test_sitetls_warning_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_warning_summary": "Verbinding niet of onvoldoende beveiligd (HTTPS)", - "widget_content_notes": "

Opmerkingen

  • Logo: We raden aan om ons logo op je eigen webserver op te slaan en te gebruiken. Op die manier is er geen contact met onze webserver als je website wordt bezocht.
  • Content-Security-Policy (CSP): Indien je op je website gebruikmaakt van CSP, dan zou je internet.nl moeten toevoegen aan de regels voor form-action en eventueel ook voor img-src als je linkt naar het logo op onze webserver.
", - "widget_mail_html_block": "Test je e-mail", - "widget_mail_intro": "

E-mailtest widget

Wil je dat bezoekers van jouw website direct een e-mailtest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

", - "widget_site_html_block": "Test je website", - "widget_site_intro": "

Websitetest widget

Wil je dat bezoekers van jouw website direct een websitetest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

" -} \ No newline at end of file From 2acc159824e56d5f7489c6cf3ce7871496cc4dbe Mon Sep 17 00:00:00 2001 From: stitch1 Date: Wed, 19 Feb 2025 13:41:43 +0100 Subject: [PATCH 8/9] remove vue translations, fix escaping backslash --- .../logic/internet_nl_translations.py | 108 +- .../static/js/translations/internet_nl.en.js | 852 --------- .../js/translations/internet_nl.en.json | 1017 ++++++++++ .../static/js/translations/internet_nl.js | 1703 ----------------- .../static/js/translations/internet_nl.nl.js | 852 --------- .../js/translations/internet_nl.nl.json | 1017 ++++++++++ .../tests/test_translation.py | 4 - 7 files changed, 2048 insertions(+), 3505 deletions(-) delete mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.js create mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json delete mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js delete mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.js create mode 100644 dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json diff --git a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py index 8447837f..8ba91522 100644 --- a/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py +++ b/dashboard/internet_nl_dashboard/logic/internet_nl_translations.py @@ -1,28 +1,24 @@ # SPDX-License-Identifier: Apache-2.0 +import json import logging import os -import json import tempfile -from pathlib import Path -from typing import Any, Dict, List, Union from functools import lru_cache +from pathlib import Path +from typing import Any, Dict, List import markdown import polib import requests from django.utils.text import slugify -# Todo: refactor this to languages from settings.py SUPPORTED_LOCALES: List[str] = ["nl", "en"] log = logging.getLogger(__package__) -# .parent = logic; .parent.parent = internet_nl_dashboard; DASHBOARD_APP_DIRECTORY = Path(__file__).parent.parent VUE_I18N_OUTPUT_PATH = f"{DASHBOARD_APP_DIRECTORY}/static/js/translations/" DJANGO_I18N_OUTPUT_PATH = f"{DASHBOARD_APP_DIRECTORY}/locale/" -# log.debug(f"VUE_I18N_OUTPUT_PATH: {VUE_I18N_OUTPUT_PATH}") -# log.debug(f"DJANGO_I18N_OUTPUT_PATH: {DJANGO_I18N_OUTPUT_PATH}") def convert_internet_nl_content_to_vue(): @@ -53,27 +49,14 @@ def convert_internet_nl_content_to_vue(): :return: None """ - - translated_locales: List[Dict[str, Union[str, List[Any]]]] = [] - combined_vue_i18n_content = "" - for locale in SUPPORTED_LOCALES: raw_content: bytes = get_locale_content(locale) store_as_django_locale(locale, raw_content) - structured_content = load_as_po_file(raw_content) - translated_locales.append({"locale": locale, "content": structured_content}) # support a per-language kind of file, in case we're going to do dynamic loading of languages. - vue_i18n_content: str = convert_vue_i18n_format(locale, structured_content) - json_content = convert_json_format(locale, structured_content) - combined_vue_i18n_content += vue_i18n_content - store_vue_i18n_file(f"internet_nl.{locale}.js", vue_i18n_content) - # ensure ascii escaped some of the nice unicode characters and emojis. + json_content = convert_json_format(load_as_po_file(raw_content)) store_vue_i18n_file(f"internet_nl.{locale}.json", json.dumps(json_content, indent=2, ensure_ascii=False)) - # the locales are easiest stored together. This makes language switching a lot easier. - store_vue_i18n_file("internet_nl.js", combined_vue_i18n_content) - @lru_cache(maxsize=None) def get_locale_content(locale: str) -> bytes: @@ -135,8 +118,7 @@ def load_as_po_file(raw_content: bytes) -> List[Any]: return polib.pofile(file.name) - -def convert_json_format(locale: str, po_content: Any) -> dict: +def convert_json_format(po_content: Any) -> dict: content = {} for entry in po_content: @@ -146,7 +128,7 @@ def convert_json_format(locale: str, po_content: Any) -> dict: continue message_id = _js_safe_msgid(entry.msgid) - content[message_id] = _js_safe_msgstr(entry.msgstr) + content[message_id] = _json_safe_msgstr(entry.msgstr) # todo: split tech table key into multiple keys so translations can be performed # tech table is pipe seperated implicit translated, like this: @@ -159,17 +141,17 @@ def convert_json_format(locale: str, po_content: Any) -> dict: if message_id.endswith("_tech_table"): submessage_titles = dirty_workaround_to_still_get_tech_table_titles_in_english(message_id) submessages = entry.msgstr.split("|") - print(f"titles: {submessage_titles}, values: {submessages}") for submessage_title, submessage in zip(submessage_titles, submessages): - content[f"{message_id}_{_js_safe_msgid(submessage_title)}"] = _js_safe_msgstr(submessage) + content[f"{message_id}_{_js_safe_msgid(submessage_title)}"] = _json_safe_msgstr(submessage) return content + def dirty_workaround_to_still_get_tech_table_titles_in_english(message_id: str): # this prevents some parameterized calls and even more spagetti. This is the 'lunch' version. # given that all translations will be json in the future, this approach is somewhat 'ok' # always has to be english. - raw_content: bytes = get_locale_content('en') + raw_content: bytes = get_locale_content("en") # with lru cache it's fast enough :) structured_content = load_as_po_file(raw_content) @@ -181,51 +163,6 @@ def dirty_workaround_to_still_get_tech_table_titles_in_english(message_id: str): return [] -def convert_vue_i18n_format(locale: str, po_content: Any) -> str: - """ - done: will markdown be parsed to html in this method? Or should we do that on the fly, everywhere... - It seems the logical place will be to parse it here. Otherwise the rest of the application becomes more - complex. Using markdown will have the benefit of the output being a single html string with proper - formatting. - - todo: change parameters {{ param }} to hello: '%{msg} world' - see: http://kazupon.github.io/vue-i18n/guide/formatting.html#list-formatting - The change is very large we don't need to do that, as we don't need those sentences. - - The content is added to the 'internet_nl' key, like this: - - const internet_nl_messages = { - en: { - internet_nl: { - key: 'value', - key: 'value' - - }, - }, - } - - There is a slight challenge that translations in vue are based on javascript properties, meaning, no quotes. - - :return: - """ - - content: str = _vue_format_start() - - content += _vue_format_locale_start(locale) - - for entry in po_content: - # to save a boatload of data, we're not storing the 'content' from the pages of internet.nl - # we'll just have to point to this content. - if entry.msgid.endswith("content"): - continue - - content += f" {_js_safe_msgid(entry.msgid)}: '{_js_safe_msgstr(entry.msgstr)}',\n" - content += _vue_format_locale_end() - content += _vue_format_end() - - return content - - def get_po_as_dictionary(file): structured_content = polib.pofile(file) po_file_as_dictionary = {} @@ -252,34 +189,17 @@ def get_po_as_dictionary_v2(language="en"): ) from error -def _vue_format_start() -> str: - return """const internet_nl_messages = { -""" - - -def _vue_format_locale_start(locale) -> str: - return f""" {locale}: {{ - internet_nl: {{ -""" - - -def _vue_format_locale_end() -> str: - return """ }, - }, -""" - - -def _vue_format_end() -> str: - return """};""" - - def _js_safe_msgid(text): return slugify(text).replace("-", "_") def _js_safe_msgstr(msgstr): # a poor mans escape for single quotes. - # msgstr = msgstr.replace("'", "\\'") + msgstr = msgstr.replace("'", "\\'") + return _json_safe_msgstr(msgstr) + + +def _json_safe_msgstr(msgstr): html = markdown.markdown(msgstr) one_line_html = html.replace("\n", "") 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 deleted file mode 100644 index f21fd28d..00000000 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.js +++ /dev/null @@ -1,852 +0,0 @@ -const internet_nl_messages = { - en: { - internet_nl: { - about_contact: '

Contact

Internet Standards Platform
c/o ECP
Maanweg 174 (8th floor)
2516 AB The Hague
The Netherlands

CoC number: 27169301

Email

question@internet.nl

PGP public key
Fingerprint: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Expiration date: 19th of March 2025

', - base_about: 'About Internet.nl', - base_accessibility: 'Accessibility', - base_blogs: 'Blogs', - base_contact: 'Contact', - base_copyright: 'Copyright', - base_disclosure: 'Report vulnerability', - base_faqs: 'Knowledge base', - base_halloffame: 'Hall of Fame', - base_halloffame_champions: 'Hall of Fame - Champions!', - base_halloffame_lead: '{{count}} domains with 2 x 100%
Latest entry: {{latest|date:\'d-m-Y\'}}', - base_halloffame_link: 'To Hall of Fame - Champions!', - base_halloffame_mail: 'Hall of Fame - Email', - base_halloffame_web: 'Hall of Fame - Websites', - base_home: 'Home', - base_info: 'Internet.nl is an initiative of the Internet community and the Dutch government.', - base_news: 'News', - base_newslink: 'To the news overview', - base_privacy: 'Privacy statement', - base_test_connection_explain: '

What is tested?

After you start the connection test, we will check if your currently used internet connection offers support for the modern Internet Standards below.

  • IPv6: are websites with modern internet addresses reachable for you?
  • DNSSEC: are domain signatures validated for you?

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see "Explanation of test report".

How to improve?

You can use this test report to improve your internet connection. Usually contacting your internet provider on this will be the best next step. In the communication with your internet provider you can use the permalink (i.e. the URL) of the test report.

Test your connection

', - base_test_connection_label: 'Test your connection', - base_test_connection_text: 'Modern addresses reachable?
Domain signatures validated?', - base_test_connection_title: 'About the connection test', - base_test_explain: 'About the test', - base_test_mail_explain: '

What is tested?

After you enter a domain name of an email service, we will test if the email service offers support for the modern Internet Standards below.

Note: some standards are even relevant if there are no mail servers configured for your domain.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see "Explanation of test report".

How to improve?

You can use this test report to improve your mail service. Usually contacting your mail hoster on this will be the best next step. In the communication with your mail hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the email test into your own website using our widget code.

Test your email

', - base_test_mail_input: 'Your email address:', - base_test_mail_label: 'Test your email', - base_test_mail_text: 'Modern address? Anti-phishing? Secure transport? Route authorisation?', - base_test_mail_title: 'About the email test', - base_test_prechecks_invalid_domain: 'The given domain is invalid!
Explanation: An A and/or AAAA record is necessary for the website test, and a SOA record for the email test.', - base_test_start: 'Start test', - base_test_website_explain: '

What is tested?

After you enter a domain name of a website, we will test if the website offers support for the modern Internet Standards below.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see "Explanation of test report".

How to improve?

You can use this test report to improve your website. Usually contacting your web hoster on this will be the best next step. In the communication with your web hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the website test into your own website using our widget code.

Test your website

', - base_test_website_input: 'Your website domain name:', - base_test_website_label: 'Test your website', - base_test_website_text: 'Modern address? Signed domain? Secure connection? Route authorisation?', - base_test_website_title: 'About the website test', - base_widget_mail: 'Email test widget', - base_widget_site: 'Website test widget', - connection_pagetitle: 'Connection test', - connection_title: 'Connection test', - detail_conn_dnssec_validation_exp: 'We check if the resolvers that you use validate the DNSSEC signatures of our domain name. Resolvers are usually provided by your internet provider. Alternatively you can configure resolvers from another DNS provider. You can even use your own locally installed resolver. Although validation is done in the resolver, the communication from the resolver back to your device (referred to as \'last mile\') could still be tampered with by an attacker. Thus the most secure way is to validate close to the end user device (e.g. by using a locally installed resolver), or make sure that the channel between your resolver and your end user device is secured/trusted.', - detail_conn_dnssec_validation_label: 'DNSSEC validation', - 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 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 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 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.', - detail_conn_ipv6_ipv4_conn_verdict_good: 'You are able to reach computers via DNS on their IPv4 address.', - detail_conn_ipv6_privacy_exp: 'We check if your device uses IPv6 Privacy Extensions for SLAAC (or another IPv6 configuration process than SLAAC) in order to prevent leakage of its potentially privacy sensitive MAC address to computers it connects with over IPV6.', - detail_conn_ipv6_privacy_label: 'Privacy Extensions for IPv6', - detail_conn_ipv6_privacy_verdict_bad: 'You are using SLAAC without \'IPv6 Privacy Extensions\'.', - detail_conn_ipv6_privacy_verdict_good: 'You have enabled \'IPv6 Privacy Extensions\' (or you are not using SLAAC).', - detail_conn_ipv6_resolver_conn_exp: 'We check if at least one of the DNS resolvers that you are using is able to reach our authoritative name servers over IPv6. Usually your internet provider provides the DNS resolver(s).', - 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).

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.', - detail_mail_auth_dkim_verdict_no_email: 'Your domain does not support DKIM records. However because your DMARC and SPF records hint that no mail is sent from your domain, DKIM is not necessary and this subtest is skipped.', - detail_mail_auth_dmarc_exp: 'We check if DMARC is available for your domain. A receiving mail server mayuse your DMARC policy to evaluate how to handle a mail with your domain assender that could not be authenticated with both DKIM and SPF, and it mayuse your mail address from the DMARC record to provide feedback reports onthe authentication to you. Having more than one DMARC record in the same domainis not valid and will lead to a test failure.Note: DMARC requires the SPFdomain (envelope sender, i.e. return-path that shows up in MAIL FROM) andthe DKIM domain (d=) to align with the mail body domain (From:).', - detail_mail_auth_dmarc_label: 'DMARC existence', - 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_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. ', - detail_mail_auth_dmarc_policy_verdict_good: 'Your DMARC policy is sufficiently strict.', - detail_mail_auth_dmarc_policy_verdict_policy: 'Your DMARC policy is not sufficiently strict.', - detail_mail_auth_spf_exp: 'We check if your domain has an SPF record. A receiving mail server can use the IP addresses in your SPF record to authenticate the sending mail server of a received email with your domain as sender. The accompanying policy can be used to take appropriate action if authentication fails. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.', - detail_mail_auth_spf_label: 'SPF existence', - detail_mail_auth_spf_tech_table: 'SPF record', - detail_mail_auth_spf_verdict_bad: 'Your domain does not have a valid SPF record.', - detail_mail_auth_spf_verdict_good: 'Your domain has an SPF record.', - detail_mail_auth_spf_policy_exp: 'We check if the syntax of your SPF record is correct and if it contains a sufficiently strict policy i.e. ~all (softfail) or -all (fail) in order to prevent abuse by phishers and spammers. To be effective against abuse of your domain, a liberal policy i.e. +all (pass) or ?all (neutral) is insufficient. If all is missing and a redirect modifier is not present in your SPF record, the default is ?all.

We also follow include and redirect for valid SPF records. In addition, we check that your SPF record does not exceed the allowed number of 10 DNS lookups making it ineffective. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. While the SPF terms all, ip4, ip6 and exp do not count as DNS lookups.

Note that if the include or redirect domain consists of macros, we will not follow them as we do not have the necessary information from an actual mail or mail server connection to expand those macros. This means that we do not evaluate the outcome of macros. Moreover, we do not count DNS lookups caused by macros to determine whether the allowed number of DNS lookups has been exceeded.

For sending domains, using ~all (softfail) instead of -all (fail) is usually preferred. This is because when SPF authentication fails with an SPF fail, a receiving mail server may already block the connection without evaluating the DKIM signature and DMARC policy. This can lead to falsely blocked mails (e.g. when mails are automatically forwarded by the receiving mail server to another receiving mail server). Note that a triggered SPF softfail still ensures that a strict DMARC policy protects your domain if DKIM authentication also fails.

For no-mail domains see the good practice on explanation of the "DMARC policy" subtest.', - detail_mail_auth_spf_policy_label: 'SPF policy', - detail_mail_auth_spf_policy_tech_table: 'Domain|SPF record', - detail_mail_auth_spf_policy_verdict_all: 'Your SPF policy is not sufficiently strict.', - detail_mail_auth_spf_policy_verdict_bad: 'Your SPF policy is not syntactically correct.', - detail_mail_auth_spf_policy_verdict_good: 'Your SPF policy is sufficiently strict.', - 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 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 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: '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.', - detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error: 'Unfortunately an error occurred in Internet.nl\'s resolver. Please contact us.', - detail_mail_dnssec_mx_exists_verdict_servfail: 'The name servers of at least one of your mail server domains are broken. They returned an error (SERVFAIL) to our queries for a DNSSEC signature. Please contact your name server operator (often your mail provider) to fix this soon.', - detail_mail_dnssec_mx_valid_exp: 'We check if the domains of your receiving mail servers (MX), more specifically their SOA records, are signed with a valid signature making them \'secure\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \'secure\' one time and \'bogus\' the next.', - detail_mail_dnssec_mx_valid_label: 'DNSSEC validity', - detail_mail_dnssec_mx_valid_tech_table: 'Domain of mail server (MX)|Status', - detail_mail_dnssec_mx_valid_verdict_bad: 'At least one of your signed mail server domains is \'bogus\', because its DNSSEC signature is not valid. Either someone manipulated the responses from its name servers, or your mail server domain has serious DNSSEC configuration errors. The latter makes your receiving mail server unreachable for any sending mail server that validates DNSSEC signatures. You should contact the name server operator (often your mail provider) as soon as possible.', - detail_mail_dnssec_mx_valid_verdict_good: 'All your signed mail server domains are secure, because their DNSSEC signatures are valid.', - detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo: 'At least one of your mail server domains is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.', - detail_mail_dnssec_valid_exp: 'We check if your domain, more specifically its SOA record, is signed with a valid signature making it \'secure\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \'secure\' one time and \'bogus\' the next.', - detail_mail_dnssec_valid_label: 'DNSSEC validity', - detail_mail_dnssec_valid_tech_table: 'Email address domain|Status', - detail_mail_dnssec_valid_verdict_bad: 'Your email address domain is \'bogus\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.', - detail_mail_dnssec_valid_verdict_good: 'Your email address domain is secure, because its DNSSEC signature is valid.', - detail_mail_dnssec_valid_verdict_unsupported_ds_algo: 'Your email address domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.', - detail_mail_ipv6_mx_aaaa_exp: 'We check if there is at least one AAAA record with IPv6 address for every receiving mail server (MX). In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.', - detail_mail_ipv6_mx_aaaa_label: 'IPv6 addresses for mail server(s)', - detail_mail_ipv6_mx_aaaa_tech_table: 'Mail server (MX)|IPv6 address|IPv4 address', - 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 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: '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.', - 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.', - 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.

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

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 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', - detail_mail_tls_cert_hostmatch_tech_table: 'Mail server (MX)|Unmatched domains on certificate', - detail_mail_tls_cert_hostmatch_verdict_bad: 'The domain name of at least one of your mail servers does not match the domain name on the mail server certificate.', - detail_mail_tls_cert_hostmatch_verdict_good: 'The domain names of all your mail servers match the domain names on your mail server certificates.', - detail_mail_tls_cert_pubkey_exp: '

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
', - detail_mail_tls_cert_pubkey_label: 'Public key of certificate', - detail_mail_tls_cert_pubkey_tech_table: 'Mail server (MX)|Affected signature parameters|Status', - detail_mail_tls_cert_pubkey_verdict_bad: 'The digital signature of at least one of your mail server certificates uses insufficiently secure parameters.', - detail_mail_tls_cert_pubkey_verdict_good: 'The digital signatures of all your mail server certificates use secure parameters.', - detail_mail_tls_cert_pubkey_verdict_phase_out: 'The digital signature of at least one of your mail server certificates uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.', - detail_mail_tls_cert_signature_exp: '

We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
', - detail_mail_tls_cert_signature_label: 'Signature of certificate', - detail_mail_tls_cert_signature_tech_table: 'Mail server (MX)|Affected hash algorithm|Status', - detail_mail_tls_cert_signature_verdict_bad: 'At least one of your mail server certificates is signed using a hash algorithm that is insufficiently secure.', - detail_mail_tls_cert_signature_verdict_good: 'All your mail server certificates are signed using a secure hash algorithm.', - detail_mail_tls_cert_trust_exp: 'We check if we are able to build a valid chain of trust for your mail server certificates.

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

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

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

Requirement level: Optional', - detail_mail_tls_cert_trust_label: 'Trust chain of certificate', - detail_mail_tls_cert_trust_tech_table: 'Mail server (MX)|Untrusted certificate chain', - detail_mail_tls_cert_trust_verdict_bad: 'The trust chain of at least one of your mail server certificates is not complete and/or not signed by a trusted root certificate authority.', - detail_mail_tls_cert_trust_verdict_good: 'The trust chain of all your mail server certificates is complete and signed by a trusted root certificate authority.', - 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 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\').', - detail_mail_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

At least one of your mail servers does not offer ciphers in accordance with the prescribed ordering within a particular security level (\'II-B\').', - detail_mail_tls_ciphers_exp: '

We check if your receiving mail servers (MX) only support secure, i.e. \'Good\' and/or \'Sufficient\', ciphers (also known as algorithm selections).

To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \'cipher suite\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \'cipher suite\' ambiguous, NCSC-NL uses the term \'algorithm selection\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \'Good\', \'Sufficient\' and \'Phase out\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \'IT Security Guidelines for Transport Layer Security (TLS)\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \'Phase out\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_mail_tls_ciphers_label: 'Ciphers (Algorithm selections)', - detail_mail_tls_ciphers_tech_table: 'Mail server (MX)|First found affected cipher|Status', - detail_mail_tls_ciphers_verdict_bad: 'At least one of your mail servers supports one or more insufficiently secure ciphers.', - detail_mail_tls_ciphers_verdict_good: 'All your mail servers support secure ciphers only.', - detail_mail_tls_ciphers_verdict_phase_out: 'At least one of your mail servers supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.', - detail_mail_tls_compression_exp: '

We check if your receiving mail servers (MX) support TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression
  • Insufficient: TLS compression
', - detail_mail_tls_compression_label: 'TLS compression', - detail_mail_tls_compression_tech_table: 'Mail server (MX)|TLS compression', - detail_mail_tls_compression_verdict_bad: 'At least on of your mail servers supports TLS compression, which is not secure.', - detail_mail_tls_compression_verdict_good: 'All your mail servers do not support TLS compression.', - detail_mail_tls_dane_exists_exp: 'We check if the name servers of each of your receiving mail servers (MX) provide a TLSA record for DANE.

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

Note that the test ignores TLSA records of the types PKIX-TA(0) or PKIX-EE(1) as these should not be used for receiving mail servers.

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

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, Appendix A, under \'Certificate pinning and DANE\' (in English).', - detail_mail_tls_dane_exists_label: 'DANE existence', - detail_mail_tls_dane_exists_tech_table: 'Mail server (MX)|DANE TLSA record existent', - 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.

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.', - detail_mail_tls_dane_rollover_verdict_good: 'All your mail server domains have an active DANE scheme for a reliable rollover of certificate keys.', - 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 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.', - detail_mail_tls_fs_params_verdict_good: 'All your mail servers support secure parameters for Diffie-Hellman key exchange.', - detail_mail_tls_fs_params_verdict_na: 'This subtest is not applicable as your mail servers do not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.', - detail_mail_tls_fs_params_verdict_phase_out: 'At least one of your mail servers supports parameters for Diffie-Hellman key exchange that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.', - detail_mail_tls_kex_hash_func_exp: '

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

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
', - 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_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', - detail_mail_tls_ocsp_stapling_tech_table: 'OUTDATED TEXT; TEST NOT USED
Mail server (MX)|OCSP stapling', - detail_mail_tls_ocsp_stapling_verdict_bad: 'OUTDATED TEXT; TEST NOT USED
At least one of your mail servers supports OCSP stapling but responds with invalid data', - detail_mail_tls_ocsp_stapling_verdict_good: 'OUTDATED TEXT; TEST NOT USED
Your mail servers support OCSP stapling.', - detail_mail_tls_ocsp_stapling_verdict_ok: 'OUTDATED TEXT; TEST NOT USED
At least one of your mail servers does not support OCSP stapling.', - detail_mail_tls_renegotiation_client_exp: '

We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX).

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
', - detail_mail_tls_renegotiation_client_label: 'Client-initiated renegotiation', - detail_mail_tls_renegotiation_client_tech_table: 'Mail server (MX)|Client-initiated renegotiation', - detail_mail_tls_renegotiation_client_verdict_bad: 'At least one of your mail servers allows for client-initiated renegotiation, which could have negative impact on the availability of your mail server.', - detail_mail_tls_renegotiation_client_verdict_good: 'All your mail servers do not allow for client-initiated renegotiation.', - detail_mail_tls_renegotiation_secure_exp: '

We check if your mail servers (MX) support secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
', - detail_mail_tls_renegotiation_secure_label: 'Secure renegotiation', - detail_mail_tls_renegotiation_secure_tech_table: 'Mail server (MX)|Secure renegotiation', - detail_mail_tls_renegotiation_secure_verdict_bad: 'At least one of your mail servers supports insecure renegotiation, which is obviously not secure.', - detail_mail_tls_renegotiation_secure_verdict_good: 'All your mail servers support secure renegotiation.', - detail_mail_tls_starttls_exists_exp: 'We check if your receiving mail servers (MX) support STARTTLS. If so, we also check in the subtests of this test category whether STARTTLS is configured sufficiently secure.

Because of performance reasons at most ten mail servers over either IPv6 or IPv4 are tested for STARTTLS and DANE.

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

Non-receiving domain:

  1. Null MX: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use "Null MX" (RFC 7505). Note that a "Null MX record" should not be combined with a normal MX record that is pointing to a mail host.

  2. No MX: In case your domain does not have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even not an "Null MX" record).

  3. If we detect any of the above two cases, the subtests in the STARTTLS and DANE category are not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. Other subtests of the email test (e.g. for DMARC) are still applicable.

  4. Note that having a "Null MX" record or no MX record could also impact sending mail, because receiving servers may reject email that has an invalid return address.

For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.', - detail_mail_tls_starttls_exists_label: 'STARTTLS available', - detail_mail_tls_starttls_exists_tech_table: 'Mail server (MX)|STARTTLS', - 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 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: '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', - detail_mail_tls_version_verdict_bad: 'At least one of your mail servers supports one or more insufficiently secure TLS versions.', - detail_mail_tls_version_verdict_good: 'All your mail servers support secure TLS versions only.', - detail_mail_tls_version_verdict_phase_out: 'At least one of your mail servers supports one or more TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.', - detail_mail_tls_zero_rtt_exp: '

We check if your mail servers (MX) support Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your mail servers do not support TLS 1.3, the test is not applicable.For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLSsession is initiated. The amount ofearly datasupport indicated by themail server is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theEHLO command before the TLS handshake but after the STARTTLS command(i.e. no round trips (0-RTT) needed before application data to the server).If the TLS handshake is completed and the mail server responds,then the mail server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
', - detail_mail_tls_zero_rtt_label: '0-RTT', - detail_mail_tls_zero_rtt_tech_table: 'Mail server (MX)|0-RTT', - detail_mail_tls_zero_rtt_verdict_bad: 'At least one of your mail servers supports 0-RTT, which is not secure.', - detail_mail_tls_zero_rtt_verdict_good: 'None of your mail servers support 0-RTT.', - detail_mail_tls_zero_rtt_verdict_na: 'This subtest is not applicable as your mail servers do not support TLS 1.3.', - detail_tech_data_bogus: 'bogus', - detail_tech_data_good: 'good', - detail_tech_data_http_csp_has_bare_https: 'Recommendation: \'https:\' scheme without a specific main domain should not be used (#9).', - detail_tech_data_http_csp_has_data: 'Recommendation: \'data:\' scheme should not be used where that is not permitted (#7).', - detail_tech_data_http_csp_has_host_without_scheme: 'Recommendation: A domain without a scheme should not be used (#8).', - detail_tech_data_http_csp_has_http: 'Recommendation: \'http:\' scheme should not be used (#8).', - detail_tech_data_http_csp_has_invalid_host: 'Recommendation: A wildcard (i.e. \'*\') or \'127.0.0.1\' should not be used (#9 and #10).', - detail_tech_data_http_csp_has_unsafe_eval: 'Recommendation: \'unsafe-eval\' should not be used (#6).', - detail_tech_data_http_csp_has_unsafe_hashes: 'Recommendation: \'unsafe-hashes\' should not be used (#6).', - detail_tech_data_http_csp_has_unsafe_inline: 'Recommendation: \'unsafe-inline\' should not be used (#6).', - detail_tech_data_http_csp_missing_invalid_base_uri: 'Recommendation: \'base-uri\' with sufficiently secure value should be defined (#2).', - detail_tech_data_http_csp_missing_invalid_default_src: 'Recommendation: \'default-src\' with sufficiently secure value should be defined (#1).', - detail_tech_data_http_csp_missing_invalid_form_action: 'Recommendation: \'form-action\' with sufficiently secure value should be defined (#5).', - detail_tech_data_http_csp_missing_invalid_frame_ancestors: 'Recommendation: \'frame-ancestors\' with sufficiently secure value should be defined (#4).', - detail_tech_data_http_csp_missing_invalid_frame_src: 'Recommendation: \'frame-src\' (or child-src\' or \'default-src\' as fallback) with sufficiently secure value should be defined (#3).', - detail_tech_data_http_csp_no_policy_found: 'No CSP found.', - detail_tech_data_http_csp_policy_found: 'Retrieved CSP value: {policy}', - detail_tech_data_http_referrer_policy_bad_invalid: 'Bad: policy value is not valid.', - detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade: 'Bad: \'no-referrer-when-downgrade\' must not be used.', - detail_tech_data_http_referrer_policy_bad_origin: 'Bad: \'origin\' must not be used.', - detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin: 'Bad: \'origin-when-cross-origin\' must not be used.', - detail_tech_data_http_referrer_policy_bad_unsafe_url: 'Bad: \'unsafe-url\' must not be used.', - detail_tech_data_http_referrer_policy_no_policy: 'No Referrer-Policy found.', - 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_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.', - detail_tech_data_http_securitytxt_multi_lang: 'Error: \'Preferred-Languages\' field must not appear more than once.', - detail_tech_data_http_securitytxt_multiple_csaf_fields: 'Recommendation: Multiple \'CSAF\' fields should be brought back to one \'CSAF\' field.', - detail_tech_data_http_securitytxt_no_canonical: 'Recommendation: \'Canonical\' field should be present in a signed file.', - detail_tech_data_http_securitytxt_no_canonical_match: 'Error: The web URI of security.txt (i.e. when redirecting at least the last URI of the redirect chain) must be listed in a \'Canonical\' field if present.', - detail_tech_data_http_securitytxt_no_contact: 'Error: \'Contact\' field must appear at least once.', - detail_tech_data_http_securitytxt_no_content_type: 'Error: HTTP Content-Type header must be sent.', - detail_tech_data_http_securitytxt_no_csaf_file: 'Error: Every optional \'CSAF\' field must point to a file named \'provider-metadata.json\'.', - detail_tech_data_http_securitytxt_no_encryption: 'Recommendation: \'Encryption\' field should be present when \'Contact\' field contains an email address.', - detail_tech_data_http_securitytxt_no_expire: 'Error: \'Expires\' field must be present.', - detail_tech_data_http_securitytxt_no_https: 'Error: Web URI must begin with \'https://\' (line {line_no}).', - detail_tech_data_http_securitytxt_no_line_separators: 'Error: Every line must end with either a carriage return and line feed characters or just a line feed character.', - detail_tech_data_http_securitytxt_no_security_txt_404: 'Error: security.txt could not be located.', - detail_tech_data_http_securitytxt_no_security_txt_other: 'Error: security.txt could not be located (unexpected HTTP response code {status_code}).', - detail_tech_data_http_securitytxt_no_space: 'Error: Field separator (colon) must be followed by a space (line {line_no}).', - detail_tech_data_http_securitytxt_no_uri: 'Error: Field value must be a URI (e.g. beginning with \'mailto:\') (line {line_no}).', - detail_tech_data_http_securitytxt_not_signed: 'Recommendation: security.txt should be digitally signed.', - detail_tech_data_http_securitytxt_pgp_data_error: 'Error: Signed security.txt must contain a correct ASCII-armored PGP block.', - detail_tech_data_http_securitytxt_pgp_error: 'Error: Decoding or parsing of the signed security.txt must succeed.', - detail_tech_data_http_securitytxt_prec_ws: 'Error: There must be no whitespace before the field separator (colon) (line {line_no}).', - detail_tech_data_http_securitytxt_requested_from: 'security.txt requested from {hostname}.', - 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 encoded using UTF-8 in Net-Unicode form.', - detail_tech_data_insecure: 'insecure', - detail_tech_data_insufficient: 'insufficient', - detail_tech_data_no: 'no', - detail_tech_data_not_applicable: 'not applicable', - detail_tech_data_not_reachable: 'not reachable', - detail_tech_data_not_testable: 'not testable', - detail_tech_data_not_tested: 'not tested', - detail_tech_data_phase_out: 'phase out', - detail_tech_data_secure: 'secure', - detail_tech_data_sufficient: 'sufficient', - 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). 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 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 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.

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

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.', - detail_web_appsecpriv_http_x_frame_verdict_good: 'Your web server offers securely configured X-Frame-Options.', - detail_web_appsecpriv_http_x_xss_exp: 'OUTDATED TEXT; TEST NOT USED

We check if your web server provides an HTTP header for X-XSS-Protection that has a sufficiently secure value (i.e. 1 or 1; mode=block). This HTTP header can be used to activate the protection filter of browsers against reflective cross-site scripting (XSS) attacks. Valid values for the X-XSS-Protection header are:

  • 0 disables the XSS filter. This value should NOT be used.
  • 1 enables the XSS filter. If a cross-site scripting attack is detected, the browser will sanitize the script and remove the unsafe parts. This value is usually the default in browsers when a website does not offer an X-XSS-Protection header.
  • 1; mode=block enables the XSS filter. If a cross-site scripting attack is detected, the browser will block the response and prevent rendering the page. This is the recommended value.

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

Requirement level: Recommended', - detail_web_appsecpriv_http_x_xss_label: 'OUTDATED TEXT; TEST NOT USED

X-XSS-Protection', - detail_web_appsecpriv_http_x_xss_tech_table: 'OUTDATED TEXT; TEST NOT USED

Web server IP address|X-XSS-Protection value', - detail_web_appsecpriv_http_x_xss_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Your web server does not offer securely configured X-XSS-Protection.', - detail_web_appsecpriv_http_x_xss_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Your web server offers securely configured X-XSS-Protection.', - detail_web_dnssec_exists_exp: 'We check if your domain, more specifically its SOA record, is DNSSEC signed.

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_web_dnssec_exists_label: 'DNSSEC existence', - detail_web_dnssec_exists_tech_table: 'Domain|Registrar', - detail_web_dnssec_exists_verdict_bad: 'Your domain is insecure, because it is not DNSSEC signed.', - detail_web_dnssec_exists_verdict_good: 'Your domain is DNSSEC signed.', - detail_web_dnssec_exists_verdict_resolver_error: 'Unfortunately an error occurred in Internet.nl\'s resolver. Please contact us.', - detail_web_dnssec_exists_verdict_servfail: 'The name servers of your 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_web_dnssec_valid_exp: 'We check if your domain, more specifically its SOA record, is signed with a valid signature making it \'secure\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \'secure\' one time and \'bogus\' the next.', - detail_web_dnssec_valid_label: 'DNSSEC validity', - detail_web_dnssec_valid_tech_table: 'Domain|Status', - detail_web_dnssec_valid_verdict_bad: 'Your domain is \'bogus\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.', - detail_web_dnssec_valid_verdict_good: 'Your domain is secure, because its DNSSEC signature is valid.', - detail_web_dnssec_valid_verdict_unsupported_ds_algo: 'Your domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.', - detail_web_ipv6_web_aaaa_exp: 'We check if there is at least one AAAA record with IPv6 address for your web server.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.', - detail_web_ipv6_web_aaaa_label: 'IPv6 addresses for web server', - 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 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 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.', - detail_web_rpki_exists_label: 'Route Origin Authorisation existence', - 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.

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 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', - detail_web_tls_cert_hostmatch_tech_table: 'Web server IP address|Unmatched domains on certificate', - detail_web_tls_cert_hostmatch_verdict_bad: 'The domain name of your website does not match the domain name on your website certificate.', - detail_web_tls_cert_hostmatch_verdict_good: 'The domain name of your website matches the domain name on your website certificate.', - detail_web_tls_cert_pubkey_exp: '

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
', - detail_web_tls_cert_pubkey_label: 'Public key of certificate', - detail_web_tls_cert_pubkey_tech_table: 'Web server IP address|Affected signature parameters|Status', - detail_web_tls_cert_pubkey_verdict_bad: 'The digital signature of your website certificate uses insufficiently secure parameters.', - detail_web_tls_cert_pubkey_verdict_good: 'The digital signature of your website certificate uses secure parameters.', - detail_web_tls_cert_pubkey_verdict_phase_out: 'The digital signature of your website certificate uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.', - detail_web_tls_cert_signature_exp: '

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
', - detail_web_tls_cert_signature_label: 'Signature of certificate', - detail_web_tls_cert_signature_tech_table: 'Web server IP address|Affected hash algorithm|Status', - detail_web_tls_cert_signature_verdict_bad: 'Your website certificate is signed using a hash algorithm that is insufficiently secure.', - detail_web_tls_cert_signature_verdict_good: 'Your website certificate is signed using a secure hash algorithm.', - detail_web_tls_cert_trust_exp: 'We check if we are able to build a valid chain of trust for your website certificate.

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

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B3-4 (in English).', - detail_web_tls_cert_trust_label: 'Trust chain of certificate', - detail_web_tls_cert_trust_tech_table: 'Web server IP address|Untrusted certificate chain', - detail_web_tls_cert_trust_verdict_bad: 'The trust chain of your website certificate is not complete and/or not signed by a trusted root certificate authority.', - detail_web_tls_cert_trust_verdict_good: 'The trust chain of your website certificate is complete and signed by a trusted root certificate authority.', - detail_web_tls_cipher_order_exp: 'We check if your web server enforces its own cipher preference (\'I\'), and offers ciphers in accordance with the prescribed ordering (\'II\').

When your web server supports \'Good\' ciphers only, this subtest is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The web server enforces its own cipher preference while negotiating with a web browser, and does not accept any preference of the web browser;

II. Prescribed ordering: Ciphers are offered by the web server 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_web_tls_cipher_order_label: 'Cipher order', - detail_web_tls_cipher_order_tech_table: 'Web server IP address|First found affected cipher pair|Violated rule # (\'II-B\')', - detail_web_tls_cipher_order_verdict_bad: 'Your web server does not enforce its own cipher preference (\'I\').', - detail_web_tls_cipher_order_verdict_good: 'Your web server enforces its own cipher preference (\'I\'), and offers ciphers in accordance with the prescribed ordering (\'II\').', - detail_web_tls_cipher_order_verdict_na: 'This subtest is not applicable as your web server supports \'Good\' ciphers only.', - detail_web_tls_cipher_order_verdict_seclevel_bad: 'Your web server does not prefer \'Good\' over \'Sufficient\' over \'Phase out\' ciphers (\'II\').', - detail_web_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

Your web server does not offer ciphers in accordance with the prescribed ordering within a particular security level (\'II-B\').', - detail_web_tls_ciphers_exp: '

We check if your web server only supports secure, i.e. \'Good\' and/or \'Sufficient\', ciphers (also known as algorithm selections).

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \'cipher suite\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \'cipher suite\' ambiguous, NCSC-NL uses the term \'algorithm selection\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \'Good\', \'Sufficient\' and \'Phase out\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \'IT Security Guidelines for Transport Layer Security (TLS)\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \'Phase out\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_web_tls_ciphers_label: 'Ciphers (Algorithm selections)', - detail_web_tls_ciphers_tech_table: 'Web server IP address|Affected ciphers|Status', - detail_web_tls_ciphers_verdict_bad: 'Your web server supports one or more insufficiently secure ciphers.', - detail_web_tls_ciphers_verdict_good: 'Your web server supports secure ciphers only.', - detail_web_tls_ciphers_verdict_phase_out: 'Your web server supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.', - detail_web_tls_compression_exp: '

We check if your web server supports TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
', - detail_web_tls_compression_label: 'TLS compression', - detail_web_tls_compression_tech_table: 'Web server IP address|TLS compression', - detail_web_tls_compression_verdict_bad: 'Your web server supports TLS compression, which is not secure.', - detail_web_tls_compression_verdict_good: 'Your web server does not support TLS compression.', - detail_web_tls_dane_exists_exp: 'We check if the name servers of your website domain contain a correctly signed TLSA record for DANE.

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the website domain, or if there are DANE related DNSSEC issues (e.g. no proof of \'Denial of Existence\').

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

Requirement level: Optional', - detail_web_tls_dane_exists_label: 'DANE existence', - detail_web_tls_dane_exists_tech_table: 'Web server IP address|DANE TLSA record existent', - detail_web_tls_dane_exists_verdict_bad: 'Your website domain does not contain a TLSA record for DANE.', - detail_web_tls_dane_exists_verdict_bogus: 'Your website domain does not provide DNSSEC proof that DANE TLSA records do not exist. You should ask your name server operator to fix this issue.', - detail_web_tls_dane_exists_verdict_good: 'Your website domain contains a TLSA record for DANE.', - detail_web_tls_dane_rollover_exp: '

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
', - detail_web_tls_dane_rollover_label: 'OUTDATED TEXT; TEST NOT USED

DANE rollover scheme', - detail_web_tls_dane_rollover_tech_table: 'OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme', - detail_web_tls_dane_rollover_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.', - detail_web_tls_dane_rollover_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.', - detail_web_tls_dane_valid_exp: 'We check if the DANE fingerprint presented by your domain is valid for your web certificate.

DANE allows you to publish information about your website certificate in a special DNS record, called TLSA record. Clients, like web browsers, can check the authenticity of your certificate not only through the certificate authority but also through the TLSA record. A client can also use the TLSA record as a signal to only use HTTPS (and not HTTP). DNSSEC is preconditional for DANE. Unfortunately not much web browsers are supporting DANE validation yet.

Requirement level: Recommended (only if subtest for \'DANE existence\' is passed)', - detail_web_tls_dane_valid_label: 'DANE validity', - 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_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 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 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 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.', - detail_web_tls_https_exists_verdict_good: 'Your website offers HTTPS.', - detail_web_tls_https_exists_verdict_other: 'Your web server is unreachable.', - detail_web_tls_https_forced_exp: 'We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See \'Web application guidelines, detailed version\' from NCSC-NL, guideline U/WA.05 (in Dutch).', - detail_web_tls_https_forced_label: 'HTTPS redirect', - detail_web_tls_https_forced_tech_table: 'Web server IP address|HTTPS redirect', - detail_web_tls_https_forced_verdict_bad: 'Your web server does offer support for both HTTP and HTTPS, but does not automatically redirect visitors from HTTP to HTTPS on the same domain.', - detail_web_tls_https_forced_verdict_good: 'Your web server automatically redirects visitors from HTTP to HTTPS on the same domain.', - detail_web_tls_https_forced_verdict_no_https: 'This test could not be performed, because your web server offers either no HTTPS or HTTPS with a very outdated, insecure TLS configuration.', - detail_web_tls_https_forced_verdict_other: 'Your web server only offers support for HTTPS and not for HTTP.', - detail_web_tls_https_hsts_exp: 'We check if your web server supports HSTS.

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period of at least 1 year (max-age=31536000) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired.

The test does not check whether preload is used and whether the domain is included in the HSTS Preload List.

Deployment recommendation

HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will not be reachable by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy.

Therefore we advise you to follow the implementation steps below:

  1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);

  2. Increase the HSTS cache validity period in the stages below. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.

  3. Start with 5 minutes (max-age=300);

  4. Increase it to 1 week (max-age=604800);
  5. Increase it to 1 month (max-age=2592000);

  6. Increase it to 1 year (max-age=31536000) or more.

  7. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use includeSubDomains if you are fully sure that all the (nested) subdomains of your domain properly support HTTPS now and in the future.

  8. Use preload only if you are very sure that you want your domain to be included in the HSTS Preload List. HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.

See \'Web application guidelines, detailed version\' from NCSC-NL, guideline U/WA.05 (in Dutch).', - detail_web_tls_https_hsts_label: 'HSTS', - detail_web_tls_https_hsts_tech_table: 'Web server IP address|HSTS policy', - detail_web_tls_https_hsts_verdict_bad: 'Your web server does not offer an HSTS policy.', - detail_web_tls_https_hsts_verdict_good: 'Your web server offers an HSTS policy.', - detail_web_tls_https_hsts_verdict_other: 'Your web server offers an HSTS policy with a cache validity period (max-age) that is not sufficiently long (i.e. less than 1 year).', - detail_web_tls_kex_hash_func_exp: '

We check if your web server supports secure hash functions to create the digital signature during key exchange.

The web server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The web server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
', - 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 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', - detail_web_tls_ocsp_stapling_tech_table: 'Web server IP address|OCSP stapling', - detail_web_tls_ocsp_stapling_verdict_bad: 'Your web server supports OCSP stapling but the data in the response is not valid.', - detail_web_tls_ocsp_stapling_verdict_good: 'Your web server supports OCSP stapling and the data in the response is valid.', - detail_web_tls_ocsp_stapling_verdict_ok: 'Your web server does not support OCSP stapling.', - detail_web_tls_renegotiation_client_exp: '

We check if a client (usually a web browser) can initiate a renegotiation with your web server.

Allowing clients to initiate renegotiation is generally not necessary and opens a web server to DoS attacks inside a TLS connection. An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
', - detail_web_tls_renegotiation_client_label: 'Client-initiated renegotiation', - detail_web_tls_renegotiation_client_tech_table: 'Web server IP address|Client-initiated renegotiation', - detail_web_tls_renegotiation_client_verdict_bad: 'Your web server allows for client-initiated renegotiation, which could have negative impact on the availability of your website.', - detail_web_tls_renegotiation_client_verdict_good: 'Your web server does not allow for client-initiated renegotiation.', - detail_web_tls_renegotiation_secure_exp: '

We check if your web server supports secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
', - detail_web_tls_renegotiation_secure_label: 'Secure renegotiation', - detail_web_tls_renegotiation_secure_tech_table: 'Web server IP address|Secure renegotiation', - detail_web_tls_renegotiation_secure_verdict_bad: 'Your web server supports insecure renegotiation, which is obviously not secure.', - detail_web_tls_renegotiation_secure_verdict_good: 'Your web server supports secure renegotiation.', - detail_web_tls_version_exp: '

We check if your web server supports secure TLS versions only.

A web server may support more than one TLS version.

Note that browser makers have announced that they will stop supporting TLS 1.1 and 1.0. This will cause websites that do not support TLS 1.2 and/or 1.3 to be unreachable.

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_web_tls_version_label: 'TLS version', - detail_web_tls_version_tech_table: 'Web server IP address|TLS version|Status', - detail_web_tls_version_verdict_bad: 'Your web server supports insufficiently secure TLS versions.', - detail_web_tls_version_verdict_good: 'Your web server supports secure TLS versions only.', - detail_web_tls_version_verdict_phase_out: 'Your web server supports TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.', - detail_web_tls_zero_rtt_exp: '

We check if your web server supports Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the firsthandshake message. 0-RTT does not provide protection against replay attacks atthe TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable.For web servers that support TLS 1.3, the index / page of the website isfetched using TLS 1.3 and the amount ofearly datasupport indicated by theserver is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theHTTP request before the TLS handshake (i.e. no round trips (0-RTT) neededbefore application data to the server). If the TLS handshake is completed andthe web server responds with anynon-HTTP 425 Too Earlyresponse, then the web server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
', - detail_web_tls_zero_rtt_label: '0-RTT', - 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 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', - detail_web_mail_ipv6_ns_aaaa_verdict_bad: 'None of the name servers of your domain has an IPv6 address.', - detail_web_mail_ipv6_ns_aaaa_verdict_good: 'Two or more name servers of your domain have an IPv6 address.', - detail_web_mail_ipv6_ns_aaaa_verdict_other: 'Only one name server of your domain has an IPv6 address.', - detail_web_mail_ipv6_ns_reach_exp: 'We check if all name servers, that have an AAAA record with IPv6 address, are reachable over IPv6.', - detail_web_mail_ipv6_ns_reach_label: 'IPv6 reachability of name servers', - 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.', - 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.

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 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', - faqs_report_subtest_good: 'Good: pass on REQUIRED, RECOMMENDED or OPTIONAL subtest ⇒ first: full score / latter two: no score impact', - faqs_report_subtest_info: 'Informational: fail on OPTIONAL subtest ⇒ no score impact', - faqs_report_subtest_not_tested: 'Not tested, because already failed related parent subtest ⇒ null score', - faqs_report_subtest_title: 'Icons per subtest', - faqs_report_subtest_warning: 'Warning: fail on RECOMMENDED subtest ⇒ no score impact', - faqs_report_test_bad: 'Bad: failed at least one REQUIRED subtest ⇒ no full score in test category', - faqs_report_test_error: 'Test error: execution error for at least one subtest ⇒ no result in test category', - faqs_report_test_good: 'Good: passed all subtests ⇒ full score in test category', - faqs_report_test_info: 'Informational: failed at least one OPTIONAL subtest ⇒ full score in test category ', - faqs_report_test_title: 'Icons per test category', - faqs_report_test_warning: 'Warning: failed at least one RECOMMENDED subtest ⇒ full score in test category ', - faqs_report_title: 'Explanation of test report', - faqs_rpki_title: 'Authorisation for routing (RPKI)', - faqs_starttls_title: 'Secure email transport (STARTTLS and DANE)', - faqs_title: 'Knowledge base', - halloffame_champions_menu: 'Champions!', - halloffame_champions_subtitle: '100% in website and email test', - halloffame_champions_text: 'The {{count}} domains below score 100% in both the website test and the email test. Inductees of this Hall of Fame are allowed to use both 100% badges.', - halloffame_champions_title: 'Hall of Fame - Champions!', - halloffame_mail_badge: 'Badge with text: 100% score in email test', - halloffame_mail_menu: 'Email', - halloffame_mail_subtitle: '100% in email test', - halloffame_mail_text: 'The {{count}} domains below score 100% in the email test. Inductees of this Hall of Fame are allowed to use the 100% mail badge.', - halloffame_mail_title: 'Hall of Fame - Email', - halloffame_web_badge: 'Badge with text: 100% score in website test', - halloffame_web_menu: 'Websites', - halloffame_web_subtitle: '100% in website test', - halloffame_web_text: 'The {{count}} domains below score 100% in the website test. Inductees of this Hall of Fame are allowed to use the 100% website badge.', - halloffame_web_title: 'Hall of Fame - Websites', - home_pagetitle: 'Test for modern Internet Standards like IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE.', - home_stats_connection: 'unique connections', - home_stats_connection_items: '', - home_stats_header: 'Tests in numbers', - home_stats_mail: 'unique mail domains', - home_stats_mail_items: '', - home_stats_notpassed: '0-99%:', - home_stats_passed: '100%:', - home_stats_website: 'unique web domains', - home_stats_website_items: '', - home_teaser: 'Modern Internet Standards provide for more reliability and further growth of the Internet.
Are you using them?', - mail_pagetitle: 'Email test:', - mail_title: 'Email test: {{prettyaddr}}', - mail_tweetmessage: 'The%20mail%20server%20at%20{{report.domain}}%20scores%20{{score}}%25%20in%20the%20email%20test%20of%20%40Internet_nl%3A', - page_gotocontents: 'Go to the content', - 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 certificate, Internet Standards Platform', - page_sitedescription: 'Is your Internet up-to-date?', - page_sitetitle: 'Internet.nl', - page404_title: 'Page not found!', - probes_auto_redirect: 'You will be automatically redirected to the results page when all tests are finished.', - probes_no_javascript: 'Check if the test results are available. If not, you will be redirected here instead.', - probes_no_javascript_connection: 'JavaScript inactive. Please enable JavaScript in order to execute the test.', - probes_no_redirection: 'Test error. Please try again later, or test another domain name.', - probes_test_finished: 'Test finished! Results available...', - probes_test_running: 'Running...', - probes_tests_description: 'The items below are being tested.', - probes_tests_duration: 'The duration of the test is between 5 and {{cache_ttl}} seconds.', - results_dated_presentation: 'Dated result presentation. Please rerun the test.', - results_domain_appsecpriv_http_headers_label: 'HTTP security headers', - results_domain_appsecpriv_other_options_label: 'Other security options', - results_domain_ipv6_web_server_label: 'Web server', - results_domain_rpki_web_server_label: 'Web server', - results_domain_tls_http_headers_label: 'HTTP headers', - results_domain_tls_https_label: 'HTTP', - results_domain_tls_tls_label: 'TLS', - results_domain_mail_ipv6_name_servers_label: 'Name servers of domain', - results_domain_mail_rpki_name_servers_label: 'Name servers of domain', - results_domain_mail_tls_certificate_label: 'Certificate', - results_domain_mail_tls_dane_label: 'DANE', - results_empty_argument_alt_text: 'None', - results_explanation_label: 'Test explanation:', - results_further_testing_connection_label: 'Further connection testing', - results_further_testing_mail_label: 'Further email testing', - results_further_testing_web_label: 'Further website testing', - results_mail_auth_dkim_label: 'DKIM', - results_mail_auth_dmarc_label: 'DMARC', - results_mail_auth_spf_label: 'SPF', - results_mail_dnssec_domain_label: 'Email address domain', - results_mail_dnssec_mail_servers_label: 'Mail server domain(s)', - results_mail_ipv6_mail_servers_label: 'Mail server(s)', - results_mail_rpki_mail_servers_label: 'Mail server(s)', - results_mail_rpki_mx_name_servers_label: 'Name servers of mail server(s)', - results_mail_tls_starttls_label: 'TLS', - results_no_icon_detail_close: 'close', - results_no_icon_detail_open: 'open', - results_no_icon_status_error: 'Error', - results_no_icon_status_failed: 'Failed', - results_no_icon_status_info: 'Information', - results_no_icon_status_not_tested: 'Not testable', - results_no_icon_status_passed: 'Passed', - results_no_icon_status_warning: 'Recommendation', - results_panel_button_hide: 'Hide details', - results_panel_button_show: 'Show details', - results_perfect_score: 'Congratulations, your domain will be added to the Hall of Fame soon!', - results_permalink: 'Permalink test result {{permadate|date:\'(Y-m-d H:i T)\'}}', - results_rerun_test: 'Rerun the test', - results_retest_time: 'Seconds until retest option:', - results_score_description: 'The domain {{prettyaddr}} has a test score of {{score}}%.', - results_tech_details_label: 'Technical details:', - results_test_direct: 'Directly test:', - results_test_email_label: 'Test another email', - results_test_website_label: 'Test another website', - results_test_info: 'Explanation of test report', - results_verdict_label: 'Verdict:', - test_connipv6_failed_description: 'Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.', - test_connipv6_failed_summary: 'Modern addresses not reachable (IPv6)', - test_connipv6_info_description: 'Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.', - test_connipv6_info_summary: 'Modern addresses not reachable (IPv6)', - test_connipv6_label: 'Modern addresses reachable (IPv6)', - test_connipv6_passed_description: 'Well done! Your internet provider has provided you with a modern internet address (IPv6). Therefore you can reach other computers with modern addresses.', - test_connipv6_passed_summary: 'Modern addresses reachable (IPv6)', - test_connipv6_title: 'Modern addresses reachable?', - test_connipv6_warning_description: 'Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.', - test_connipv6_warning_summary: 'Modern addresses not reachable (IPv6)', - test_connresolver_failed_description: 'Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.', - test_connresolver_failed_summary: 'Domain signatures not validated (DNSSEC)', - test_connresolver_info_description: 'Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.', - test_connresolver_info_summary: 'Domain signatures not validated (DNSSEC)', - test_connresolver_label: 'Domain signature validation (DNSSEC)', - test_connresolver_passed_description: 'Well done! Domain signatures (DNSSEC) are validated for you. Therefore you are protected against false translation from signed domain names into rogue IP addresses.', - test_connresolver_passed_summary: 'Domain signatures validated (DNSSEC)', - test_connresolver_title: 'Domain signatures validated?', - test_connresolver_warning_description: 'Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.', - test_connresolver_warning_summary: 'Domain signatures not validated (DNSSEC)', - test_error_summary: 'Error during test execution!', - test_mailauth_failed_description: 'Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.', - test_mailauth_failed_summary: 'Not all authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_mailauth_info_description: 'Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.', - test_mailauth_info_summary: 'Not all authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_mailauth_label: 'Authenticity marks against phishing (DMARC, DKIM and SPF)', - test_mailauth_passed_description: 'Well done! Your domain contains all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are able to reliably separate phishing and spam emails abusing your domain in their sender address, from your authentic emails. ', - test_mailauth_passed_summary: 'Authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_mailauth_title: 'Authenticity marks against email phishing?', - test_mailauth_warning_description: 'Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.', - test_mailauth_warning_summary: 'Not all authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_maildnssec_failed_description: 'Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.', - test_maildnssec_failed_summary: 'Not all domain names signed (DNSSEC)', - test_maildnssec_info_description: 'Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.', - test_maildnssec_info_summary: 'Not all domain names signed (DNSSEC)', - test_maildnssec_label: 'Signed domain names (DNSSEC)', - test_maildnssec_passed_description: 'Well done! Your email address domain and your mail server domain(s) are signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are able to reliably query the IP address of your receiving mail server(s). ', - test_maildnssec_passed_summary: 'All domain names signed (DNSSEC)', - test_maildnssec_title: 'Domain names signed?', - test_maildnssec_warning_description: 'Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.', - test_maildnssec_warning_summary: 'Not all domain names signed (DNSSEC)', - test_mailipv6_failed_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_failed_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_mailipv6_info_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_info_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_mailipv6_label: 'Modern address (IPv6)', - test_mailipv6_passed_description: 'Well done! Your mail server can be reached by senders using modern
addresses (IPv6), making it fully part of the modern Internet.', - test_mailipv6_passed_summary: 'Reachable via modern internet address (IPv6)', - 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_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)', - test_mailrpki_label: 'Route authorisation (RPKI)', - 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: '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)', - test_mailtls_info_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_info_summary: 'Mail server connection not or insufficiently secured (STARTTLS and DANE)', - 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: 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 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)', - test_mailtls_null_mx_with_other_mx_description: 'Warning: 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. ', - test_mailtls_null_mx_with_other_mx_summary: 'Inconsistently configured non-receiving mail domain (STARTTLS and DANE)', - test_mailtls_null_mx_without_a_aaaa_description: 'Warning: 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.', - test_mailtls_null_mx_without_a_aaaa_summary: 'Properly configured non-receiving mail domain, though with unnecessary record (STARTTLS and DANE)', - 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 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 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. 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. 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. 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. 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)', - test_sitednssec_info_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_info_summary: 'Domain name not signed (DNSSEC)', - test_sitednssec_label: 'Signed domain name (DNSSEC)', - test_sitednssec_passed_description: 'Well done! Your domain is signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are protected against manipulated translation from your domain into rogue internet addresses.', - test_sitednssec_passed_summary: 'Domain name signed (DNSSEC)', - test_sitednssec_title: 'Domain name signed?', - test_sitednssec_warning_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_warning_summary: 'Domain name not signed (DNSSEC)', - test_siteipv6_failed_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_failed_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_siteipv6_info_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_info_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_siteipv6_label: 'Modern address (IPv6)', - test_siteipv6_passed_description: 'Well done! Your website is reachable for visitors using a modern internet address (IPv6), making it fully part of the modern Internet.', - test_siteipv6_passed_summary: 'Reachable via modern internet address (IPv6)', - 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_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)', - test_siterpki_label: 'Route authorisation (RPKI)', - 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: '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)', - test_sitetls_info_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_info_summary: 'Connection not or insufficiently secured (HTTPS)', - test_sitetls_label: 'Secure connection (HTTPS)', - 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 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 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', - widget_site_intro: '

Website test widget

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

', - }, - }, -}; \ No newline at end of file diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json new file mode 100644 index 00000000..fce5e3a5 --- /dev/null +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.en.json @@ -0,0 +1,1017 @@ +{ + "about_contact": "

Contact

Internet Standards Platform
c/o ECP
Maanweg 174 (8th floor)
2516 AB The Hague
The Netherlands

CoC number: 27169301

Email

question@internet.nl

PGP public key
Fingerprint: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Expiration date: 19th of March 2025

", + "base_about": "About Internet.nl", + "base_accessibility": "Accessibility", + "base_blogs": "Blogs", + "base_contact": "Contact", + "base_copyright": "Copyright", + "base_disclosure": "Report vulnerability", + "base_faqs": "Knowledge base", + "base_halloffame": "Hall of Fame", + "base_halloffame_champions": "Hall of Fame - Champions!", + "base_halloffame_lead": "{{count}} domains with 2 x 100%
Latest entry: {{latest|date:'d-m-Y'}}", + "base_halloffame_link": "To Hall of Fame - Champions!", + "base_halloffame_mail": "Hall of Fame - Email", + "base_halloffame_web": "Hall of Fame - Websites", + "base_home": "Home", + "base_info": "Internet.nl is an initiative of the Internet community and the Dutch government.", + "base_news": "News", + "base_newslink": "To the news overview", + "base_privacy": "Privacy statement", + "base_test_connection_explain": "

What is tested?

After you start the connection test, we will check if your currently used internet connection offers support for the modern Internet Standards below.

  • IPv6: are websites with modern internet addresses reachable for you?
  • DNSSEC: are domain signatures validated for you?

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your internet connection. Usually contacting your internet provider on this will be the best next step. In the communication with your internet provider you can use the permalink (i.e. the URL) of the test report.

Test your connection

", + "base_test_connection_label": "Test your connection", + "base_test_connection_text": "Modern addresses reachable?
Domain signatures validated?", + "base_test_connection_title": "About the connection test", + "base_test_explain": "About the test", + "base_test_mail_explain": "

What is tested?

After you enter a domain name of an email service, we will test if the email service offers support for the modern Internet Standards below.

Note: some standards are even relevant if there are no mail servers configured for your domain.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your mail service. Usually contacting your mail hoster on this will be the best next step. In the communication with your mail hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the email test into your own website using our widget code.

Test your email

", + "base_test_mail_input": "Your email address:", + "base_test_mail_label": "Test your email", + "base_test_mail_text": "Modern address? Anti-phishing? Secure transport? Route authorisation?", + "base_test_mail_title": "About the email test", + "base_test_prechecks_invalid_domain": "The given domain is invalid!
Explanation: An A and/or AAAA record is necessary for the website test, and a SOA record for the email test.", + "base_test_start": "Start test", + "base_test_website_explain": "

What is tested?

After you enter a domain name of a website, we will test if the website offers support for the modern Internet Standards below.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see \"Explanation of test report\".

How to improve?

You can use this test report to improve your website. Usually contacting your web hoster on this will be the best next step. In the communication with your web hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the website test into your own website using our widget code.

Test your website

", + "base_test_website_input": "Your website domain name:", + "base_test_website_label": "Test your website", + "base_test_website_text": "Modern address? Signed domain? Secure connection? Route authorisation?", + "base_test_website_title": "About the website test", + "base_widget_mail": "Email test widget", + "base_widget_site": "Website test widget", + "connection_pagetitle": "Connection test", + "connection_title": "Connection test", + "detail_conn_dnssec_validation_exp": "We check if the resolvers that you use validate the DNSSEC signatures of our domain name. Resolvers are usually provided by your internet provider. Alternatively you can configure resolvers from another DNS provider. You can even use your own locally installed resolver. Although validation is done in the resolver, the communication from the resolver back to your device (referred to as 'last mile') could still be tampered with by an attacker. Thus the most secure way is to validate close to the end user device (e.g. by using a locally installed resolver), or make sure that the channel between your resolver and your end user device is secured/trusted.", + "detail_conn_dnssec_validation_label": "DNSSEC validation", + "detail_conn_dnssec_validation_tech_table": "DNS provider", + "detail_conn_dnssec_validation_tech_table_dns_provider": "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 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_tech_table_anonymized_ipv6_address": "Anonymized IPv6 address", + "detail_conn_ipv6_connection_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_connection_tech_table_internet_provider": "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 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 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_tech_table_anonymized_ipv4_address": "Anonymized IPv4 address", + "detail_conn_ipv6_ipv4_conn_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_ipv4_conn_tech_table_internet_provider": "Internet provider", + "detail_conn_ipv6_ipv4_conn_verdict_bad": "You are not able to reach computers via DNS on their IPv4 address.", + "detail_conn_ipv6_ipv4_conn_verdict_good": "You are able to reach computers via DNS on their IPv4 address.", + "detail_conn_ipv6_privacy_exp": "We check if your device uses IPv6 Privacy Extensions for SLAAC (or another IPv6 configuration process than SLAAC) in order to prevent leakage of its potentially privacy sensitive MAC address to computers it connects with over IPV6.", + "detail_conn_ipv6_privacy_label": "Privacy Extensions for IPv6", + "detail_conn_ipv6_privacy_verdict_bad": "You are using SLAAC without 'IPv6 Privacy Extensions'.", + "detail_conn_ipv6_privacy_verdict_good": "You have enabled 'IPv6 Privacy Extensions' (or you are not using SLAAC).", + "detail_conn_ipv6_resolver_conn_exp": "We check if at least one of the DNS resolvers that you are using is able to reach our authoritative name servers over IPv6. Usually your internet provider provides the DNS resolver(s).", + "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).

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.", + "detail_mail_auth_dkim_verdict_no_email": "Your domain does not support DKIM records. However because your DMARC and SPF records hint that no mail is sent from your domain, DKIM is not necessary and this subtest is skipped.", + "detail_mail_auth_dmarc_exp": "We check if DMARC is available for your domain. A receiving mail server mayuse your DMARC policy to evaluate how to handle a mail with your domain assender that could not be authenticated with both DKIM and SPF, and it mayuse your mail address from the DMARC record to provide feedback reports onthe authentication to you. Having more than one DMARC record in the same domainis not valid and will lead to a test failure.Note: DMARC requires the SPFdomain (envelope sender, i.e. return-path that shows up in MAIL FROM) andthe DKIM domain (d=) to align with the mail body domain (From:).", + "detail_mail_auth_dmarc_label": "DMARC existence", + "detail_mail_auth_dmarc_tech_table": "DMARC record|Found on", + "detail_mail_auth_dmarc_tech_table_dmarc_record": "DMARC record", + "detail_mail_auth_dmarc_tech_table_found_on": "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_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. ", + "detail_mail_auth_dmarc_policy_verdict_good": "Your DMARC policy is sufficiently strict.", + "detail_mail_auth_dmarc_policy_verdict_policy": "Your DMARC policy is not sufficiently strict.", + "detail_mail_auth_spf_exp": "We check if your domain has an SPF record. A receiving mail server can use the IP addresses in your SPF record to authenticate the sending mail server of a received email with your domain as sender. The accompanying policy can be used to take appropriate action if authentication fails. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", + "detail_mail_auth_spf_label": "SPF existence", + "detail_mail_auth_spf_tech_table": "SPF record", + "detail_mail_auth_spf_tech_table_spf_record": "SPF record", + "detail_mail_auth_spf_verdict_bad": "Your domain does not have a valid SPF record.", + "detail_mail_auth_spf_verdict_good": "Your domain has an SPF record.", + "detail_mail_auth_spf_policy_exp": "We check if the syntax of your SPF record is correct and if it contains a sufficiently strict policy i.e. ~all (softfail) or -all (fail) in order to prevent abuse by phishers and spammers. To be effective against abuse of your domain, a liberal policy i.e. +all (pass) or ?all (neutral) is insufficient. If all is missing and a redirect modifier is not present in your SPF record, the default is ?all.

We also follow include and redirect for valid SPF records. In addition, we check that your SPF record does not exceed the allowed number of 10 DNS lookups making it ineffective. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. While the SPF terms all, ip4, ip6 and exp do not count as DNS lookups.

Note that if the include or redirect domain consists of macros, we will not follow them as we do not have the necessary information from an actual mail or mail server connection to expand those macros. This means that we do not evaluate the outcome of macros. Moreover, we do not count DNS lookups caused by macros to determine whether the allowed number of DNS lookups has been exceeded.

For sending domains, using ~all (softfail) instead of -all (fail) is usually preferred. This is because when SPF authentication fails with an SPF fail, a receiving mail server may already block the connection without evaluating the DKIM signature and DMARC policy. This can lead to falsely blocked mails (e.g. when mails are automatically forwarded by the receiving mail server to another receiving mail server). Note that a triggered SPF softfail still ensures that a strict DMARC policy protects your domain if DKIM authentication also fails.

For no-mail domains see the good practice on explanation of the \"DMARC policy\" subtest.", + "detail_mail_auth_spf_policy_label": "SPF policy", + "detail_mail_auth_spf_policy_tech_table": "Domain|SPF record", + "detail_mail_auth_spf_policy_tech_table_domain": "Domain", + "detail_mail_auth_spf_policy_tech_table_spf_record": "SPF record", + "detail_mail_auth_spf_policy_verdict_all": "Your SPF policy is not sufficiently strict.", + "detail_mail_auth_spf_policy_verdict_bad": "Your SPF policy is not syntactically correct.", + "detail_mail_auth_spf_policy_verdict_good": "Your SPF policy is sufficiently strict.", + "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 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_tech_table_email_address_domain": "Email address domain", + "detail_mail_dnssec_exists_tech_table_registrar": "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 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_tech_table_domain_of_mail_server_mx": "Domain of mail server (MX)", + "detail_mail_dnssec_mx_exists_tech_table_dnssec_existent": "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": "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.", + "detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error": "Unfortunately an error occurred in Internet.nl's resolver. Please contact us.", + "detail_mail_dnssec_mx_exists_verdict_servfail": "The name servers of at least one of your mail server domains are broken. They returned an error (SERVFAIL) to our queries for a DNSSEC signature. Please contact your name server operator (often your mail provider) to fix this soon.", + "detail_mail_dnssec_mx_valid_exp": "We check if the domains of your receiving mail servers (MX), more specifically their SOA records, are signed with a valid signature making them 'secure'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be 'secure' one time and 'bogus' the next.", + "detail_mail_dnssec_mx_valid_label": "DNSSEC validity", + "detail_mail_dnssec_mx_valid_tech_table": "Domain of mail server (MX)|Status", + "detail_mail_dnssec_mx_valid_tech_table_domain_of_mail_server_mx": "Domain of mail server (MX)", + "detail_mail_dnssec_mx_valid_tech_table_status": "Status", + "detail_mail_dnssec_mx_valid_verdict_bad": "At least one of your signed mail server domains is 'bogus', because its DNSSEC signature is not valid. Either someone manipulated the responses from its name servers, or your mail server domain has serious DNSSEC configuration errors. The latter makes your receiving mail server unreachable for any sending mail server that validates DNSSEC signatures. You should contact the name server operator (often your mail provider) as soon as possible.", + "detail_mail_dnssec_mx_valid_verdict_good": "All your signed mail server domains are secure, because their DNSSEC signatures are valid.", + "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "At least one of your mail server domains is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", + "detail_mail_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it 'secure'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be 'secure' one time and 'bogus' the next.", + "detail_mail_dnssec_valid_label": "DNSSEC validity", + "detail_mail_dnssec_valid_tech_table": "Email address domain|Status", + "detail_mail_dnssec_valid_tech_table_email_address_domain": "Email address domain", + "detail_mail_dnssec_valid_tech_table_status": "Status", + "detail_mail_dnssec_valid_verdict_bad": "Your email address domain is 'bogus', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", + "detail_mail_dnssec_valid_verdict_good": "Your email address domain is secure, because its DNSSEC signature is valid.", + "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Your email address domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", + "detail_mail_ipv6_mx_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for every receiving mail server (MX). In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

'IPv4-mapped IPv6 addresses' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.", + "detail_mail_ipv6_mx_aaaa_label": "IPv6 addresses for mail server(s)", + "detail_mail_ipv6_mx_aaaa_tech_table": "Mail server (MX)|IPv6 address|IPv4 address", + "detail_mail_ipv6_mx_aaaa_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv6_address": "IPv6 address", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv4_address": "IPv4 address", + "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 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": "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_ipv6_mx_reach_tech_table_unreachable_ipv6_address": "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.", + "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_tech_table_mail_server": "Mail server", + "detail_mail_rpki_exists_tech_table_ip_address": "IP address", + "detail_mail_rpki_exists_tech_table_rpki_route_origin_authorization": "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.", + "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_tech_table_name_server_of_mx": "Name server of MX", + "detail_mail_rpki_mx_ns_exists_tech_table_ip_address": "IP address", + "detail_mail_rpki_mx_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server_of_mx": "Name server of MX", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_mx_ns_valid_tech_table_rpki_origin_validation_state": "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 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.

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_tech_table_mail_server": "Mail server", + "detail_mail_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", + "detail_mail_tls_cert_hostmatch_tech_table": "Mail server (MX)|Unmatched domains on certificate", + "detail_mail_tls_cert_hostmatch_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Unmatched domains on certificate", + "detail_mail_tls_cert_hostmatch_verdict_bad": "The domain name of at least one of your mail servers does not match the domain name on the mail server certificate.", + "detail_mail_tls_cert_hostmatch_verdict_good": "The domain names of all your mail servers match the domain names on your mail server certificates.", + "detail_mail_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
", + "detail_mail_tls_cert_pubkey_label": "Public key of certificate", + "detail_mail_tls_cert_pubkey_tech_table": "Mail server (MX)|Affected signature parameters|Status", + "detail_mail_tls_cert_pubkey_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_pubkey_tech_table_affected_signature_parameters": "Affected signature parameters", + "detail_mail_tls_cert_pubkey_tech_table_status": "Status", + "detail_mail_tls_cert_pubkey_verdict_bad": "The digital signature of at least one of your mail server certificates uses insufficiently secure parameters.", + "detail_mail_tls_cert_pubkey_verdict_good": "The digital signatures of all your mail server certificates use secure parameters.", + "detail_mail_tls_cert_pubkey_verdict_phase_out": "The digital signature of at least one of your mail server certificates uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", + "detail_mail_tls_cert_signature_exp": "

We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", + "detail_mail_tls_cert_signature_label": "Signature of certificate", + "detail_mail_tls_cert_signature_tech_table": "Mail server (MX)|Affected hash algorithm|Status", + "detail_mail_tls_cert_signature_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_signature_tech_table_affected_hash_algorithm": "Affected hash algorithm", + "detail_mail_tls_cert_signature_tech_table_status": "Status", + "detail_mail_tls_cert_signature_verdict_bad": "At least one of your mail server certificates is signed using a hash algorithm that is insufficiently secure.", + "detail_mail_tls_cert_signature_verdict_good": "All your mail server certificates are signed using a secure hash algorithm.", + "detail_mail_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your mail server certificates.

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

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

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

Requirement level: Optional", + "detail_mail_tls_cert_trust_label": "Trust chain of certificate", + "detail_mail_tls_cert_trust_tech_table": "Mail server (MX)|Untrusted certificate chain", + "detail_mail_tls_cert_trust_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cert_trust_tech_table_untrusted_certificate_chain": "Untrusted certificate chain", + "detail_mail_tls_cert_trust_verdict_bad": "The trust chain of at least one of your mail server certificates is not complete and/or not signed by a trusted root certificate authority.", + "detail_mail_tls_cert_trust_verdict_good": "The trust chain of all your mail server certificates is complete and signed by a trusted root certificate authority.", + "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "First found affected cipher pair", + "detail_mail_tls_cipher_order_tech_table_violated_rule_ii_b": "Violated rule # ('II-B')", + "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').", + "detail_mail_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

At least one of your mail servers does not offer ciphers in accordance with the prescribed ordering within a particular security level ('II-B').", + "detail_mail_tls_ciphers_exp": "

We check if your receiving mail servers (MX) only support secure, i.e. 'Good' and/or 'Sufficient', ciphers (also known as algorithm selections).

To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term 'cipher suite' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term 'cipher suite' ambiguous, NCSC-NL uses the term 'algorithm selection' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find 'Good', 'Sufficient' and 'Phase out' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the 'IT Security Guidelines for Transport Layer Security (TLS)'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least 'Phase out'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_mail_tls_ciphers_label": "Ciphers (Algorithm selections)", + "detail_mail_tls_ciphers_tech_table": "Mail server (MX)|First found affected cipher|Status", + "detail_mail_tls_ciphers_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_ciphers_tech_table_first_found_affected_cipher": "First found affected cipher", + "detail_mail_tls_ciphers_tech_table_status": "Status", + "detail_mail_tls_ciphers_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure ciphers.", + "detail_mail_tls_ciphers_verdict_good": "All your mail servers support secure ciphers only.", + "detail_mail_tls_ciphers_verdict_phase_out": "At least one of your mail servers supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", + "detail_mail_tls_compression_exp": "

We check if your receiving mail servers (MX) support TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression
  • Insufficient: TLS compression
", + "detail_mail_tls_compression_label": "TLS compression", + "detail_mail_tls_compression_tech_table": "Mail server (MX)|TLS compression", + "detail_mail_tls_compression_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_compression_tech_table_tls_compression": "TLS compression", + "detail_mail_tls_compression_verdict_bad": "At least on of your mail servers supports TLS compression, which is not secure.", + "detail_mail_tls_compression_verdict_good": "All your mail servers do not support TLS compression.", + "detail_mail_tls_dane_exists_exp": "We check if the name servers of each of your receiving mail servers (MX) provide a TLSA record for DANE.

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

Note that the test ignores TLSA records of the types PKIX-TA(0) or PKIX-EE(1) as these should not be used for receiving mail servers.

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

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL, Appendix A, under 'Certificate pinning and DANE' (in English).", + "detail_mail_tls_dane_exists_label": "DANE existence", + "detail_mail_tls_dane_exists_tech_table": "Mail server (MX)|DANE TLSA record existent", + "detail_mail_tls_dane_exists_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA record existent", + "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.

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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_dane_rollover_tech_table_dane_rollover_scheme": "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.", + "detail_mail_tls_dane_rollover_verdict_good": "All your mail server domains have an active DANE scheme for a reliable rollover of certificate keys.", + "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_dane_valid_tech_table_dane_tlsa_record_valid": "DANE TLSA record valid", + "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_fs_params_tech_table_affected_parameters": "Affected parameters", + "detail_mail_tls_fs_params_tech_table_security_level": "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.", + "detail_mail_tls_fs_params_verdict_good": "All your mail servers support secure parameters for Diffie-Hellman key exchange.", + "detail_mail_tls_fs_params_verdict_na": "This subtest is not applicable as your mail servers do not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.", + "detail_mail_tls_fs_params_verdict_phase_out": "At least one of your mail servers supports parameters for Diffie-Hellman key exchange that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", + "detail_mail_tls_kex_hash_func_exp": "

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

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", + "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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "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_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", + "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mail server (MX)|OCSP stapling", + "detail_mail_tls_ocsp_stapling_tech_table_outdated_text_test_not_used_mail_server_mx": "OUTDATED TEXT; TEST NOT USED
Mail server (MX)", + "detail_mail_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", + "detail_mail_tls_ocsp_stapling_verdict_bad": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers supports OCSP stapling but responds with invalid data", + "detail_mail_tls_ocsp_stapling_verdict_good": "OUTDATED TEXT; TEST NOT USED
Your mail servers support OCSP stapling.", + "detail_mail_tls_ocsp_stapling_verdict_ok": "OUTDATED TEXT; TEST NOT USED
At least one of your mail servers does not support OCSP stapling.", + "detail_mail_tls_renegotiation_client_exp": "

We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX).

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", + "detail_mail_tls_renegotiation_client_label": "Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_tech_table": "Mail server (MX)|Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_verdict_bad": "At least one of your mail servers allows for client-initiated renegotiation, which could have negative impact on the availability of your mail server.", + "detail_mail_tls_renegotiation_client_verdict_good": "All your mail servers do not allow for client-initiated renegotiation.", + "detail_mail_tls_renegotiation_secure_exp": "

We check if your mail servers (MX) support secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", + "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_mail_tls_renegotiation_secure_tech_table": "Mail server (MX)|Secure renegotiation", + "detail_mail_tls_renegotiation_secure_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", + "detail_mail_tls_renegotiation_secure_verdict_bad": "At least one of your mail servers supports insecure renegotiation, which is obviously not secure.", + "detail_mail_tls_renegotiation_secure_verdict_good": "All your mail servers support secure renegotiation.", + "detail_mail_tls_starttls_exists_exp": "We check if your receiving mail servers (MX) support STARTTLS. If so, we also check in the subtests of this test category whether STARTTLS is configured sufficiently secure.

Because of performance reasons at most ten mail servers over either IPv6 or IPv4 are tested for STARTTLS and DANE.

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

Non-receiving domain:

  1. Null MX: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use \"Null MX\" (RFC 7505). Note that a \"Null MX record\" should not be combined with a normal MX record that is pointing to a mail host.

  2. No MX: In case your domain does not have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even not an \"Null MX\" record).

  3. If we detect any of the above two cases, the subtests in the STARTTLS and DANE category are not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. Other subtests of the email test (e.g. for DMARC) are still applicable.

  4. Note that having a \"Null MX\" record or no MX record could also impact sending mail, because receiving servers may reject email that has an invalid return address.

For a \"good practice on domains without mail\" see the explanation of the \"DMARC policy\" subtest.", + "detail_mail_tls_starttls_exists_label": "STARTTLS available", + "detail_mail_tls_starttls_exists_tech_table": "Mail server (MX)|STARTTLS", + "detail_mail_tls_starttls_exists_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_starttls_exists_tech_table_starttls": "STARTTLS", + "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 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": "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", + "detail_mail_tls_version_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_version_tech_table_tls_versions": "TLS versions", + "detail_mail_tls_version_tech_table_status": "Status", + "detail_mail_tls_version_verdict_bad": "At least one of your mail servers supports one or more insufficiently secure TLS versions.", + "detail_mail_tls_version_verdict_good": "All your mail servers support secure TLS versions only.", + "detail_mail_tls_version_verdict_phase_out": "At least one of your mail servers supports one or more TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", + "detail_mail_tls_zero_rtt_exp": "

We check if your mail servers (MX) support Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your mail servers do not support TLS 1.3, the test is not applicable.For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLSsession is initiated. The amount ofearly datasupport indicated by themail server is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theEHLO command before the TLS handshake but after the STARTTLS command(i.e. no round trips (0-RTT) needed before application data to the server).If the TLS handshake is completed and the mail server responds,then the mail server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", + "detail_mail_tls_zero_rtt_label": "0-RTT", + "detail_mail_tls_zero_rtt_tech_table": "Mail server (MX)|0-RTT", + "detail_mail_tls_zero_rtt_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_zero_rtt_tech_table_0_rtt": "0-RTT", + "detail_mail_tls_zero_rtt_verdict_bad": "At least one of your mail servers supports 0-RTT, which is not secure.", + "detail_mail_tls_zero_rtt_verdict_good": "None of your mail servers support 0-RTT.", + "detail_mail_tls_zero_rtt_verdict_na": "This subtest is not applicable as your mail servers do not support TLS 1.3.", + "detail_tech_data_bogus": "bogus", + "detail_tech_data_good": "good", + "detail_tech_data_http_csp_has_bare_https": "Recommendation: 'https:' scheme without a specific main domain should not be used (#9).", + "detail_tech_data_http_csp_has_data": "Recommendation: 'data:' scheme should not be used where that is not permitted (#7).", + "detail_tech_data_http_csp_has_host_without_scheme": "Recommendation: A domain without a scheme should not be used (#8).", + "detail_tech_data_http_csp_has_http": "Recommendation: 'http:' scheme should not be used (#8).", + "detail_tech_data_http_csp_has_invalid_host": "Recommendation: A wildcard (i.e. '*') or '127.0.0.1' should not be used (#9 and #10).", + "detail_tech_data_http_csp_has_unsafe_eval": "Recommendation: 'unsafe-eval' should not be used (#6).", + "detail_tech_data_http_csp_has_unsafe_hashes": "Recommendation: 'unsafe-hashes' should not be used (#6).", + "detail_tech_data_http_csp_has_unsafe_inline": "Recommendation: 'unsafe-inline' should not be used (#6).", + "detail_tech_data_http_csp_missing_invalid_base_uri": "Recommendation: 'base-uri' with sufficiently secure value should be defined (#2).", + "detail_tech_data_http_csp_missing_invalid_default_src": "Recommendation: 'default-src' with sufficiently secure value should be defined (#1).", + "detail_tech_data_http_csp_missing_invalid_form_action": "Recommendation: 'form-action' with sufficiently secure value should be defined (#5).", + "detail_tech_data_http_csp_missing_invalid_frame_ancestors": "Recommendation: 'frame-ancestors' with sufficiently secure value should be defined (#4).", + "detail_tech_data_http_csp_missing_invalid_frame_src": "Recommendation: 'frame-src' (or child-src' or 'default-src' as fallback) with sufficiently secure value should be defined (#3).", + "detail_tech_data_http_csp_no_policy_found": "No CSP found.", + "detail_tech_data_http_csp_policy_found": "Retrieved CSP value: {policy}", + "detail_tech_data_http_referrer_policy_bad_invalid": "Bad: policy value is not valid.", + "detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade": "Bad: 'no-referrer-when-downgrade' must not be used.", + "detail_tech_data_http_referrer_policy_bad_origin": "Bad: 'origin' must not be used.", + "detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin": "Bad: 'origin-when-cross-origin' must not be used.", + "detail_tech_data_http_referrer_policy_bad_unsafe_url": "Bad: 'unsafe-url' must not be used.", + "detail_tech_data_http_referrer_policy_no_policy": "No Referrer-Policy found.", + "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_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.", + "detail_tech_data_http_securitytxt_multi_lang": "Error: 'Preferred-Languages' field must not appear more than once.", + "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Recommendation: Multiple 'CSAF' fields should be brought back to one 'CSAF' field.", + "detail_tech_data_http_securitytxt_no_canonical": "Recommendation: 'Canonical' field should be present in a signed file.", + "detail_tech_data_http_securitytxt_no_canonical_match": "Error: The web URI of security.txt (i.e. when redirecting at least the last URI of the redirect chain) must be listed in a 'Canonical' field if present.", + "detail_tech_data_http_securitytxt_no_contact": "Error: 'Contact' field must appear at least once.", + "detail_tech_data_http_securitytxt_no_content_type": "Error: HTTP Content-Type header must be sent.", + "detail_tech_data_http_securitytxt_no_csaf_file": "Error: Every optional 'CSAF' field must point to a file named 'provider-metadata.json'.", + "detail_tech_data_http_securitytxt_no_encryption": "Recommendation: 'Encryption' field should be present when 'Contact' field contains an email address.", + "detail_tech_data_http_securitytxt_no_expire": "Error: 'Expires' field must be present.", + "detail_tech_data_http_securitytxt_no_https": "Error: Web URI must begin with 'https://' (line {line_no}).", + "detail_tech_data_http_securitytxt_no_line_separators": "Error: Every line must end with either a carriage return and line feed characters or just a line feed character.", + "detail_tech_data_http_securitytxt_no_security_txt_404": "Error: security.txt could not be located.", + "detail_tech_data_http_securitytxt_no_security_txt_other": "Error: security.txt could not be located (unexpected HTTP response code {status_code}).", + "detail_tech_data_http_securitytxt_no_space": "Error: Field separator (colon) must be followed by a space (line {line_no}).", + "detail_tech_data_http_securitytxt_no_uri": "Error: Field value must be a URI (e.g. beginning with 'mailto:') (line {line_no}).", + "detail_tech_data_http_securitytxt_not_signed": "Recommendation: security.txt should be digitally signed.", + "detail_tech_data_http_securitytxt_pgp_data_error": "Error: Signed security.txt must contain a correct ASCII-armored PGP block.", + "detail_tech_data_http_securitytxt_pgp_error": "Error: Decoding or parsing of the signed security.txt must succeed.", + "detail_tech_data_http_securitytxt_prec_ws": "Error: There must be no whitespace before the field separator (colon) (line {line_no}).", + "detail_tech_data_http_securitytxt_requested_from": "security.txt requested from {hostname}.", + "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 encoded using UTF-8 in Net-Unicode form.", + "detail_tech_data_insecure": "insecure", + "detail_tech_data_insufficient": "insufficient", + "detail_tech_data_no": "no", + "detail_tech_data_not_applicable": "not applicable", + "detail_tech_data_not_reachable": "not reachable", + "detail_tech_data_not_testable": "not testable", + "detail_tech_data_not_tested": "not tested", + "detail_tech_data_phase_out": "phase out", + "detail_tech_data_secure": "secure", + "detail_tech_data_sufficient": "sufficient", + "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). 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_csp_tech_table_findings": "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 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_referrer_policy_tech_table_findings": "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 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_securitytxt_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_x_content_type_tech_table_x_content_type_options_value": "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).

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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_appsecpriv_http_x_frame_tech_table_x_frame_options_value": "X-Frame-Options value", + "detail_web_appsecpriv_http_x_frame_verdict_bad": "Your web server does not offer securely configured X-Frame-Options.", + "detail_web_appsecpriv_http_x_frame_verdict_good": "Your web server offers securely configured X-Frame-Options.", + "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We check if your web server provides an HTTP header for X-XSS-Protection that has a sufficiently secure value (i.e. 1 or 1; mode=block). This HTTP header can be used to activate the protection filter of browsers against reflective cross-site scripting (XSS) attacks. Valid values for the X-XSS-Protection header are:

  • 0 disables the XSS filter. This value should NOT be used.
  • 1 enables the XSS filter. If a cross-site scripting attack is detected, the browser will sanitize the script and remove the unsafe parts. This value is usually the default in browsers when a website does not offer an X-XSS-Protection header.
  • 1; mode=block enables the XSS filter. If a cross-site scripting attack is detected, the browser will block the response and prevent rendering the page. This is the recommended value.

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

Requirement level: Recommended", + "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", + "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|X-XSS-Protection value", + "detail_web_appsecpriv_http_x_xss_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", + "detail_web_appsecpriv_http_x_xss_tech_table_x_xss_protection_value": "X-XSS-Protection value", + "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your web server does not offer securely configured X-XSS-Protection.", + "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your web server offers securely configured X-XSS-Protection.", + "detail_web_dnssec_exists_exp": "We check if your domain, more specifically its SOA record, is DNSSEC signed.

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_web_dnssec_exists_label": "DNSSEC existence", + "detail_web_dnssec_exists_tech_table": "Domain|Registrar", + "detail_web_dnssec_exists_tech_table_domain": "Domain", + "detail_web_dnssec_exists_tech_table_registrar": "Registrar", + "detail_web_dnssec_exists_verdict_bad": "Your domain is insecure, because it is not DNSSEC signed.", + "detail_web_dnssec_exists_verdict_good": "Your domain is DNSSEC signed.", + "detail_web_dnssec_exists_verdict_resolver_error": "Unfortunately an error occurred in Internet.nl's resolver. Please contact us.", + "detail_web_dnssec_exists_verdict_servfail": "The name servers of your 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_web_dnssec_valid_exp": "We check if your domain, more specifically its SOA record, is signed with a valid signature making it 'secure'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be 'secure' one time and 'bogus' the next.", + "detail_web_dnssec_valid_label": "DNSSEC validity", + "detail_web_dnssec_valid_tech_table": "Domain|Status", + "detail_web_dnssec_valid_tech_table_domain": "Domain", + "detail_web_dnssec_valid_tech_table_status": "Status", + "detail_web_dnssec_valid_verdict_bad": "Your domain is 'bogus', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.", + "detail_web_dnssec_valid_verdict_good": "Your domain is secure, because its DNSSEC signature is valid.", + "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Your domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.", + "detail_web_ipv6_web_aaaa_exp": "We check if there is at least one AAAA record with IPv6 address for your web server.

'IPv4-mapped IPv6 addresses' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.", + "detail_web_ipv6_web_aaaa_label": "IPv6 addresses for web server", + "detail_web_ipv6_web_aaaa_tech_table": "Web server|IPv6 address|IPv4 address", + "detail_web_ipv6_web_aaaa_tech_table_web_server": "Web server", + "detail_web_ipv6_web_aaaa_tech_table_ipv6_address": "IPv6 address", + "detail_web_ipv6_web_aaaa_tech_table_ipv4_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 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 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_tech_table_web_server": "Web server", + "detail_web_ipv6_web_reach_tech_table_unreachable_ipv6_address": "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.", + "detail_web_rpki_exists_label": "Route Origin Authorisation existence", + "detail_web_rpki_exists_tech_table": "Web server|IP address|RPKI Route Origin Authorization", + "detail_web_rpki_exists_tech_table_web_server": "Web server", + "detail_web_rpki_exists_tech_table_ip_address": "IP address", + "detail_web_rpki_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_web_server": "Web server", + "detail_web_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", + "detail_web_tls_cert_hostmatch_tech_table": "Web server IP address|Unmatched domains on certificate", + "detail_web_tls_cert_hostmatch_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Unmatched domains on certificate", + "detail_web_tls_cert_hostmatch_verdict_bad": "The domain name of your website does not match the domain name on your website certificate.", + "detail_web_tls_cert_hostmatch_verdict_good": "The domain name of your website matches the domain name on your website certificate.", + "detail_web_tls_cert_pubkey_exp": "

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
", + "detail_web_tls_cert_pubkey_label": "Public key of certificate", + "detail_web_tls_cert_pubkey_tech_table": "Web server IP address|Affected signature parameters|Status", + "detail_web_tls_cert_pubkey_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_pubkey_tech_table_affected_signature_parameters": "Affected signature parameters", + "detail_web_tls_cert_pubkey_tech_table_status": "Status", + "detail_web_tls_cert_pubkey_verdict_bad": "The digital signature of your website certificate uses insufficiently secure parameters.", + "detail_web_tls_cert_pubkey_verdict_good": "The digital signature of your website certificate uses secure parameters.", + "detail_web_tls_cert_pubkey_verdict_phase_out": "The digital signature of your website certificate uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.", + "detail_web_tls_cert_signature_exp": "

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
", + "detail_web_tls_cert_signature_label": "Signature of certificate", + "detail_web_tls_cert_signature_tech_table": "Web server IP address|Affected hash algorithm|Status", + "detail_web_tls_cert_signature_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_signature_tech_table_affected_hash_algorithm": "Affected hash algorithm", + "detail_web_tls_cert_signature_tech_table_status": "Status", + "detail_web_tls_cert_signature_verdict_bad": "Your website certificate is signed using a hash algorithm that is insufficiently secure.", + "detail_web_tls_cert_signature_verdict_good": "Your website certificate is signed using a secure hash algorithm.", + "detail_web_tls_cert_trust_exp": "We check if we are able to build a valid chain of trust for your website certificate.

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

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL, guideline B3-4 (in English).", + "detail_web_tls_cert_trust_label": "Trust chain of certificate", + "detail_web_tls_cert_trust_tech_table": "Web server IP address|Untrusted certificate chain", + "detail_web_tls_cert_trust_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cert_trust_tech_table_untrusted_certificate_chain": "Untrusted certificate chain", + "detail_web_tls_cert_trust_verdict_bad": "The trust chain of your website certificate is not complete and/or not signed by a trusted root certificate authority.", + "detail_web_tls_cert_trust_verdict_good": "The trust chain of your website certificate is complete and signed by a trusted root certificate authority.", + "detail_web_tls_cipher_order_exp": "We check if your web server enforces its own cipher preference ('I'), and offers ciphers in accordance with the prescribed ordering ('II').

When your web server supports 'Good' ciphers only, this subtest is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The web server enforces its own cipher preference while negotiating with a web browser, and does not accept any preference of the web browser;

II. Prescribed ordering: Ciphers are offered by the web server 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_web_tls_cipher_order_label": "Cipher order", + "detail_web_tls_cipher_order_tech_table": "Web server IP address|First found affected cipher pair|Violated rule # ('II-B')", + "detail_web_tls_cipher_order_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "First found affected cipher pair", + "detail_web_tls_cipher_order_tech_table_violated_rule_ii_b": "Violated rule # ('II-B')", + "detail_web_tls_cipher_order_verdict_bad": "Your web server does not enforce its own cipher preference ('I').", + "detail_web_tls_cipher_order_verdict_good": "Your web server enforces its own cipher preference ('I'), and offers ciphers in accordance with the prescribed ordering ('II').", + "detail_web_tls_cipher_order_verdict_na": "This subtest is not applicable as your web server supports 'Good' ciphers only.", + "detail_web_tls_cipher_order_verdict_seclevel_bad": "Your web server does not prefer 'Good' over 'Sufficient' over 'Phase out' ciphers ('II').", + "detail_web_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Your web server does not offer ciphers in accordance with the prescribed ordering within a particular security level ('II-B').", + "detail_web_tls_ciphers_exp": "

We check if your web server only supports secure, i.e. 'Good' and/or 'Sufficient', ciphers (also known as algorithm selections).

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term 'cipher suite' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term 'cipher suite' ambiguous, NCSC-NL uses the term 'algorithm selection' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See 'IT Security Guidelines for Transport Layer Security (TLS) v2.1' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find 'Good', 'Sufficient' and 'Phase out' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the 'IT Security Guidelines for Transport Layer Security (TLS)'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least 'Phase out'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_web_tls_ciphers_label": "Ciphers (Algorithm selections)", + "detail_web_tls_ciphers_tech_table": "Web server IP address|Affected ciphers|Status", + "detail_web_tls_ciphers_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_ciphers_tech_table_affected_ciphers": "Affected ciphers", + "detail_web_tls_ciphers_tech_table_status": "Status", + "detail_web_tls_ciphers_verdict_bad": "Your web server supports one or more insufficiently secure ciphers.", + "detail_web_tls_ciphers_verdict_good": "Your web server supports secure ciphers only.", + "detail_web_tls_ciphers_verdict_phase_out": "Your web server supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.", + "detail_web_tls_compression_exp": "

We check if your web server supports TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
", + "detail_web_tls_compression_label": "TLS compression", + "detail_web_tls_compression_tech_table": "Web server IP address|TLS compression", + "detail_web_tls_compression_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_compression_tech_table_tls_compression": "TLS compression", + "detail_web_tls_compression_verdict_bad": "Your web server supports TLS compression, which is not secure.", + "detail_web_tls_compression_verdict_good": "Your web server does not support TLS compression.", + "detail_web_tls_dane_exists_exp": "We check if the name servers of your website domain contain a correctly signed TLSA record for DANE.

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the website domain, or if there are DANE related DNSSEC issues (e.g. no proof of 'Denial of Existence').

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

Requirement level: Optional", + "detail_web_tls_dane_exists_label": "DANE existence", + "detail_web_tls_dane_exists_tech_table": "Web server IP address|DANE TLSA record existent", + "detail_web_tls_dane_exists_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA record existent", + "detail_web_tls_dane_exists_verdict_bad": "Your website domain does not contain a TLSA record for DANE.", + "detail_web_tls_dane_exists_verdict_bogus": "Your website domain does not provide DNSSEC proof that DANE TLSA records do not exist. You should ask your name server operator to fix this issue.", + "detail_web_tls_dane_exists_verdict_good": "Your website domain contains a TLSA record for DANE.", + "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", + "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", + "detail_web_tls_dane_rollover_tech_table_dane_rollover_scheme": "DANE rollover scheme", + "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", + "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", + "detail_web_tls_dane_valid_exp": "We check if the DANE fingerprint presented by your domain is valid for your web certificate.

DANE allows you to publish information about your website certificate in a special DNS record, called TLSA record. Clients, like web browsers, can check the authenticity of your certificate not only through the certificate authority but also through the TLSA record. A client can also use the TLSA record as a signal to only use HTTPS (and not HTTP). DNSSEC is preconditional for DANE. Unfortunately not much web browsers are supporting DANE validation yet.

Requirement level: Recommended (only if subtest for 'DANE existence' is passed)", + "detail_web_tls_dane_valid_label": "DANE validity", + "detail_web_tls_dane_valid_tech_table": "Web server IP address|DANE TLSA record valid", + "detail_web_tls_dane_valid_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Key exchange parameters", + "detail_web_tls_fs_params_tech_table": "Web server IP address|Affected parameters|Status", + "detail_web_tls_fs_params_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_fs_params_tech_table_affected_parameters": "Affected parameters", + "detail_web_tls_fs_params_tech_table_status": "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 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 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_http_compression_tech_table_http_compression": "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 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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_https_exists_tech_table_https_existent": "HTTPS existent", + "detail_web_tls_https_exists_verdict_bad": "Your website does not offer HTTPS.", + "detail_web_tls_https_exists_verdict_good": "Your website offers HTTPS.", + "detail_web_tls_https_exists_verdict_other": "Your web server is unreachable.", + "detail_web_tls_https_forced_exp": "We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See 'Web application guidelines, detailed version' from NCSC-NL, guideline U/WA.05 (in Dutch).", + "detail_web_tls_https_forced_label": "HTTPS redirect", + "detail_web_tls_https_forced_tech_table": "Web server IP address|HTTPS redirect", + "detail_web_tls_https_forced_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_https_forced_tech_table_https_redirect": "HTTPS redirect", + "detail_web_tls_https_forced_verdict_bad": "Your web server does offer support for both HTTP and HTTPS, but does not automatically redirect visitors from HTTP to HTTPS on the same domain.", + "detail_web_tls_https_forced_verdict_good": "Your web server automatically redirects visitors from HTTP to HTTPS on the same domain.", + "detail_web_tls_https_forced_verdict_no_https": "This test could not be performed, because your web server offers either no HTTPS or HTTPS with a very outdated, insecure TLS configuration.", + "detail_web_tls_https_forced_verdict_other": "Your web server only offers support for HTTPS and not for HTTP.", + "detail_web_tls_https_hsts_exp": "We check if your web server supports HSTS.

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period of at least 1 year (max-age=31536000) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired.

The test does not check whether preload is used and whether the domain is included in the HSTS Preload List.

Deployment recommendation

HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will not be reachable by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy.

Therefore we advise you to follow the implementation steps below:

  1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);

  2. Increase the HSTS cache validity period in the stages below. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.

  3. Start with 5 minutes (max-age=300);

  4. Increase it to 1 week (max-age=604800);
  5. Increase it to 1 month (max-age=2592000);

  6. Increase it to 1 year (max-age=31536000) or more.

  7. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use includeSubDomains if you are fully sure that all the (nested) subdomains of your domain properly support HTTPS now and in the future.

  8. Use preload only if you are very sure that you want your domain to be included in the HSTS Preload List. HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.

See 'Web application guidelines, detailed version' from NCSC-NL, guideline U/WA.05 (in Dutch).", + "detail_web_tls_https_hsts_label": "HSTS", + "detail_web_tls_https_hsts_tech_table": "Web server IP address|HSTS policy", + "detail_web_tls_https_hsts_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_https_hsts_tech_table_hsts_policy": "HSTS policy", + "detail_web_tls_https_hsts_verdict_bad": "Your web server does not offer an HSTS policy.", + "detail_web_tls_https_hsts_verdict_good": "Your web server offers an HSTS policy.", + "detail_web_tls_https_hsts_verdict_other": "Your web server offers an HSTS policy with a cache validity period (max-age) that is not sufficiently long (i.e. less than 1 year).", + "detail_web_tls_kex_hash_func_exp": "

We check if your web server supports secure hash functions to create the digital signature during key exchange.

The web server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The web server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
", + "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_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "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 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", + "detail_web_tls_ocsp_stapling_tech_table": "Web server IP address|OCSP stapling", + "detail_web_tls_ocsp_stapling_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", + "detail_web_tls_ocsp_stapling_verdict_bad": "Your web server supports OCSP stapling but the data in the response is not valid.", + "detail_web_tls_ocsp_stapling_verdict_good": "Your web server supports OCSP stapling and the data in the response is valid.", + "detail_web_tls_ocsp_stapling_verdict_ok": "Your web server does not support OCSP stapling.", + "detail_web_tls_renegotiation_client_exp": "

We check if a client (usually a web browser) can initiate a renegotiation with your web server.

Allowing clients to initiate renegotiation is generally not necessary and opens a web server to DoS attacks inside a TLS connection. An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
", + "detail_web_tls_renegotiation_client_label": "Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_tech_table": "Web server IP address|Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_verdict_bad": "Your web server allows for client-initiated renegotiation, which could have negative impact on the availability of your website.", + "detail_web_tls_renegotiation_client_verdict_good": "Your web server does not allow for client-initiated renegotiation.", + "detail_web_tls_renegotiation_secure_exp": "

We check if your web server supports secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
", + "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table": "Web server IP address|Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", + "detail_web_tls_renegotiation_secure_verdict_bad": "Your web server supports insecure renegotiation, which is obviously not secure.", + "detail_web_tls_renegotiation_secure_verdict_good": "Your web server supports secure renegotiation.", + "detail_web_tls_version_exp": "

We check if your web server supports secure TLS versions only.

A web server may support more than one TLS version.

Note that browser makers have announced that they will stop supporting TLS 1.1 and 1.0. This will cause websites that do not support TLS 1.2 and/or 1.3 to be unreachable.

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_web_tls_version_label": "TLS version", + "detail_web_tls_version_tech_table": "Web server IP address|TLS version|Status", + "detail_web_tls_version_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_version_tech_table_tls_version": "TLS version", + "detail_web_tls_version_tech_table_status": "Status", + "detail_web_tls_version_verdict_bad": "Your web server supports insufficiently secure TLS versions.", + "detail_web_tls_version_verdict_good": "Your web server supports secure TLS versions only.", + "detail_web_tls_version_verdict_phase_out": "Your web server supports TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.", + "detail_web_tls_zero_rtt_exp": "

We check if your web server supports Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the firsthandshake message. 0-RTT does not provide protection against replay attacks atthe TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable.For web servers that support TLS 1.3, the index / page of the website isfetched using TLS 1.3 and the amount ofearly datasupport indicated by theserver is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theHTTP request before the TLS handshake (i.e. no round trips (0-RTT) neededbefore application data to the server). If the TLS handshake is completed andthe web server responds with anynon-HTTP 425 Too Earlyresponse, then the web server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
", + "detail_web_tls_zero_rtt_label": "0-RTT", + "detail_web_tls_zero_rtt_tech_table": "Web server IP address|0-RTT", + "detail_web_tls_zero_rtt_tech_table_web_server_ip_address": "Web server IP address", + "detail_web_tls_zero_rtt_tech_table_0_rtt": "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 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", + "detail_web_mail_ipv6_ns_aaaa_tech_table_name_server": "Name server", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv6_address": "IPv6 address", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv4_address": "IPv4 address", + "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "None of the name servers of your domain has an IPv6 address.", + "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Two or more name servers of your domain have an IPv6 address.", + "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Only one name server of your domain has an IPv6 address.", + "detail_web_mail_ipv6_ns_reach_exp": "We check if all name servers, that have an AAAA record with IPv6 address, are reachable over IPv6.", + "detail_web_mail_ipv6_ns_reach_label": "IPv6 reachability of name servers", + "detail_web_mail_ipv6_ns_reach_tech_table": "Name server|Unreachable IPv6 address", + "detail_web_mail_ipv6_ns_reach_tech_table_name_server": "Name server", + "detail_web_mail_ipv6_ns_reach_tech_table_unreachable_ipv6_address": "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.", + "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_tech_table_name_server": "Name server", + "detail_web_mail_rpki_ns_exists_tech_table_ip_address": "IP address", + "detail_web_mail_rpki_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server": "Name server", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_mail_rpki_ns_valid_tech_table_rpki_origin_validation_state": "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 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", + "faqs_report_subtest_good": "Good: pass on REQUIRED, RECOMMENDED or OPTIONAL subtest ⇒ first: full score / latter two: no score impact", + "faqs_report_subtest_info": "Informational: fail on OPTIONAL subtest ⇒ no score impact", + "faqs_report_subtest_not_tested": "Not tested, because already failed related parent subtest ⇒ null score", + "faqs_report_subtest_title": "Icons per subtest", + "faqs_report_subtest_warning": "Warning: fail on RECOMMENDED subtest ⇒ no score impact", + "faqs_report_test_bad": "Bad: failed at least one REQUIRED subtest ⇒ no full score in test category", + "faqs_report_test_error": "Test error: execution error for at least one subtest ⇒ no result in test category", + "faqs_report_test_good": "Good: passed all subtests ⇒ full score in test category", + "faqs_report_test_info": "Informational: failed at least one OPTIONAL subtest ⇒ full score in test category ", + "faqs_report_test_title": "Icons per test category", + "faqs_report_test_warning": "Warning: failed at least one RECOMMENDED subtest ⇒ full score in test category ", + "faqs_report_title": "Explanation of test report", + "faqs_rpki_title": "Authorisation for routing (RPKI)", + "faqs_starttls_title": "Secure email transport (STARTTLS and DANE)", + "faqs_title": "Knowledge base", + "halloffame_champions_menu": "Champions!", + "halloffame_champions_subtitle": "100% in website and email test", + "halloffame_champions_text": "The {{count}} domains below score 100% in both the website test and the email test. Inductees of this Hall of Fame are allowed to use both 100% badges.", + "halloffame_champions_title": "Hall of Fame - Champions!", + "halloffame_mail_badge": "Badge with text: 100% score in email test", + "halloffame_mail_menu": "Email", + "halloffame_mail_subtitle": "100% in email test", + "halloffame_mail_text": "The {{count}} domains below score 100% in the email test. Inductees of this Hall of Fame are allowed to use the 100% mail badge.", + "halloffame_mail_title": "Hall of Fame - Email", + "halloffame_web_badge": "Badge with text: 100% score in website test", + "halloffame_web_menu": "Websites", + "halloffame_web_subtitle": "100% in website test", + "halloffame_web_text": "The {{count}} domains below score 100% in the website test. Inductees of this Hall of Fame are allowed to use the 100% website badge.", + "halloffame_web_title": "Hall of Fame - Websites", + "home_pagetitle": "Test for modern Internet Standards like IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE.", + "home_stats_connection": "unique connections", + "home_stats_connection_items": "", + "home_stats_header": "Tests in numbers", + "home_stats_mail": "unique mail domains", + "home_stats_mail_items": "", + "home_stats_notpassed": "0-99%:", + "home_stats_passed": "100%:", + "home_stats_website": "unique web domains", + "home_stats_website_items": "", + "home_teaser": "Modern Internet Standards provide for more reliability and further growth of the Internet.
Are you using them?", + "mail_pagetitle": "Email test:", + "mail_title": "Email test: {{prettyaddr}}", + "mail_tweetmessage": "The%20mail%20server%20at%20{{report.domain}}%20scores%20{{score}}%25%20in%20the%20email%20test%20of%20%40Internet_nl%3A", + "page_gotocontents": "Go to the content", + "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 certificate, Internet Standards Platform", + "page_sitedescription": "Is your Internet up-to-date?", + "page_sitetitle": "Internet.nl", + "page404_title": "Page not found!", + "probes_auto_redirect": "You will be automatically redirected to the results page when all tests are finished.", + "probes_no_javascript": "Check if the test results are available. If not, you will be redirected here instead.", + "probes_no_javascript_connection": "JavaScript inactive. Please enable JavaScript in order to execute the test.", + "probes_no_redirection": "Test error. Please try again later, or test another domain name.", + "probes_test_finished": "Test finished! Results available...", + "probes_test_running": "Running...", + "probes_tests_description": "The items below are being tested.", + "probes_tests_duration": "The duration of the test is between 5 and {{cache_ttl}} seconds.", + "results_dated_presentation": "Dated result presentation. Please rerun the test.", + "results_domain_appsecpriv_http_headers_label": "HTTP security headers", + "results_domain_appsecpriv_other_options_label": "Other security options", + "results_domain_ipv6_web_server_label": "Web server", + "results_domain_rpki_web_server_label": "Web server", + "results_domain_tls_http_headers_label": "HTTP headers", + "results_domain_tls_https_label": "HTTP", + "results_domain_tls_tls_label": "TLS", + "results_domain_mail_ipv6_name_servers_label": "Name servers of domain", + "results_domain_mail_rpki_name_servers_label": "Name servers of domain", + "results_domain_mail_tls_certificate_label": "Certificate", + "results_domain_mail_tls_dane_label": "DANE", + "results_empty_argument_alt_text": "None", + "results_explanation_label": "Test explanation:", + "results_further_testing_connection_label": "Further connection testing", + "results_further_testing_mail_label": "Further email testing", + "results_further_testing_web_label": "Further website testing", + "results_mail_auth_dkim_label": "DKIM", + "results_mail_auth_dmarc_label": "DMARC", + "results_mail_auth_spf_label": "SPF", + "results_mail_dnssec_domain_label": "Email address domain", + "results_mail_dnssec_mail_servers_label": "Mail server domain(s)", + "results_mail_ipv6_mail_servers_label": "Mail server(s)", + "results_mail_rpki_mail_servers_label": "Mail server(s)", + "results_mail_rpki_mx_name_servers_label": "Name servers of mail server(s)", + "results_mail_tls_starttls_label": "TLS", + "results_no_icon_detail_close": "close", + "results_no_icon_detail_open": "open", + "results_no_icon_status_error": "Error", + "results_no_icon_status_failed": "Failed", + "results_no_icon_status_info": "Information", + "results_no_icon_status_not_tested": "Not testable", + "results_no_icon_status_passed": "Passed", + "results_no_icon_status_warning": "Recommendation", + "results_panel_button_hide": "Hide details", + "results_panel_button_show": "Show details", + "results_perfect_score": "Congratulations, your domain will be added to the Hall of Fame soon!", + "results_permalink": "Permalink test result {{permadate|date:'(Y-m-d H:i T)'}}", + "results_rerun_test": "Rerun the test", + "results_retest_time": "Seconds until retest option:", + "results_score_description": "The domain {{prettyaddr}} has a test score of {{score}}%.", + "results_tech_details_label": "Technical details:", + "results_test_direct": "Directly test:", + "results_test_email_label": "Test another email", + "results_test_website_label": "Test another website", + "results_test_info": "Explanation of test report", + "results_verdict_label": "Verdict:", + "test_connipv6_failed_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", + "test_connipv6_failed_summary": "Modern addresses not reachable (IPv6)", + "test_connipv6_info_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", + "test_connipv6_info_summary": "Modern addresses not reachable (IPv6)", + "test_connipv6_label": "Modern addresses reachable (IPv6)", + "test_connipv6_passed_description": "Well done! Your internet provider has provided you with a modern internet address (IPv6). Therefore you can reach other computers with modern addresses.", + "test_connipv6_passed_summary": "Modern addresses reachable (IPv6)", + "test_connipv6_title": "Modern addresses reachable?", + "test_connipv6_warning_description": "Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.", + "test_connipv6_warning_summary": "Modern addresses not reachable (IPv6)", + "test_connresolver_failed_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", + "test_connresolver_failed_summary": "Domain signatures not validated (DNSSEC)", + "test_connresolver_info_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", + "test_connresolver_info_summary": "Domain signatures not validated (DNSSEC)", + "test_connresolver_label": "Domain signature validation (DNSSEC)", + "test_connresolver_passed_description": "Well done! Domain signatures (DNSSEC) are validated for you. Therefore you are protected against false translation from signed domain names into rogue IP addresses.", + "test_connresolver_passed_summary": "Domain signatures validated (DNSSEC)", + "test_connresolver_title": "Domain signatures validated?", + "test_connresolver_warning_description": "Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.", + "test_connresolver_warning_summary": "Domain signatures not validated (DNSSEC)", + "test_error_summary": "Error during test execution!", + "test_mailauth_failed_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", + "test_mailauth_failed_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_mailauth_info_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", + "test_mailauth_info_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_mailauth_label": "Authenticity marks against phishing (DMARC, DKIM and SPF)", + "test_mailauth_passed_description": "Well done! Your domain contains all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are able to reliably separate phishing and spam emails abusing your domain in their sender address, from your authentic emails. ", + "test_mailauth_passed_summary": "Authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_mailauth_title": "Authenticity marks against email phishing?", + "test_mailauth_warning_description": "Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.", + "test_mailauth_warning_summary": "Not all authenticity marks against email phishing (DMARC, DKIM and SPF)", + "test_maildnssec_failed_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", + "test_maildnssec_failed_summary": "Not all domain names signed (DNSSEC)", + "test_maildnssec_info_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", + "test_maildnssec_info_summary": "Not all domain names signed (DNSSEC)", + "test_maildnssec_label": "Signed domain names (DNSSEC)", + "test_maildnssec_passed_description": "Well done! Your email address domain and your mail server domain(s) are signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are able to reliably query the IP address of your receiving mail server(s). ", + "test_maildnssec_passed_summary": "All domain names signed (DNSSEC)", + "test_maildnssec_title": "Domain names signed?", + "test_maildnssec_warning_description": "Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.", + "test_maildnssec_warning_summary": "Not all domain names signed (DNSSEC)", + "test_mailipv6_failed_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_failed_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_mailipv6_info_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_info_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_mailipv6_label": "Modern address (IPv6)", + "test_mailipv6_passed_description": "Well done! Your mail server can be reached by senders using modern
addresses (IPv6), making it fully part of the modern Internet.", + "test_mailipv6_passed_summary": "Reachable via modern internet address (IPv6)", + "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_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)", + "test_mailrpki_label": "Route authorisation (RPKI)", + "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": "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)", + "test_mailtls_info_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_info_summary": "Mail server connection not or insufficiently secured (STARTTLS and DANE)", + "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: 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 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)", + "test_mailtls_null_mx_with_other_mx_description": "Warning: 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. ", + "test_mailtls_null_mx_with_other_mx_summary": "Inconsistently configured non-receiving mail domain (STARTTLS and DANE)", + "test_mailtls_null_mx_without_a_aaaa_description": "Warning: 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.", + "test_mailtls_null_mx_without_a_aaaa_summary": "Properly configured non-receiving mail domain, though with unnecessary record (STARTTLS and DANE)", + "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 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 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. 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. 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. 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. 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)", + "test_sitednssec_info_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_info_summary": "Domain name not signed (DNSSEC)", + "test_sitednssec_label": "Signed domain name (DNSSEC)", + "test_sitednssec_passed_description": "Well done! Your domain is signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are protected against manipulated translation from your domain into rogue internet addresses.", + "test_sitednssec_passed_summary": "Domain name signed (DNSSEC)", + "test_sitednssec_title": "Domain name signed?", + "test_sitednssec_warning_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_warning_summary": "Domain name not signed (DNSSEC)", + "test_siteipv6_failed_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_failed_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_siteipv6_info_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_info_summary": "Not reachable via modern internet address, or improvement possible (IPv6)", + "test_siteipv6_label": "Modern address (IPv6)", + "test_siteipv6_passed_description": "Well done! Your website is reachable for visitors using a modern internet address (IPv6), making it fully part of the modern Internet.", + "test_siteipv6_passed_summary": "Reachable via modern internet address (IPv6)", + "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_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)", + "test_siterpki_label": "Route authorisation (RPKI)", + "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": "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)", + "test_sitetls_info_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_info_summary": "Connection not or insufficiently secured (HTTPS)", + "test_sitetls_label": "Secure connection (HTTPS)", + "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 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 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", + "widget_site_intro": "

Website test widget

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

" +} \ No newline at end of file diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js deleted file mode 100644 index 8db61d67..00000000 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.js +++ /dev/null @@ -1,1703 +0,0 @@ -const internet_nl_messages = { - nl: { - internet_nl: { - about_contact: '

Contact

Platform Internetstandaarden
p/a ECP
Maanweg 174 (8e verdieping)
2516 AB Den Haag

KvK-nummer: 27169301

E-mail

vraag@internet.nl

PGP publieke sleutel
Vingerafdruk: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Vervaldatum: 19 maart 2025

', - base_about: 'Over Internet.nl', - base_accessibility: 'Toegankelijkheid', - base_blogs: 'Blogs', - base_contact: 'Contact', - base_copyright: 'Auteursrecht', - base_disclosure: 'Kwetsbaarheid melden', - base_faqs: 'Kennisbank', - base_halloffame: 'Hall of Fame', - base_halloffame_champions: 'Hall of Fame - Kampioenen!', - base_halloffame_lead: '{{count}} domeinen met 2 x 100%
Laatste toevoeging: {{latest|date:\'d-m-Y\'}}', - base_halloffame_link: 'Naar Hall of Fame - Kampioenen!', - base_halloffame_mail: 'Hall of Fame - E-mail', - base_halloffame_web: 'Hall of Fame - Websites', - base_home: 'Home', - base_info: 'Internet.nl is een initiatief van de internetgemeenschap en de Nederlandse overheid.', - base_news: 'Nieuws', - base_newslink: 'Naar nieuwsoverzicht', - base_privacy: 'Privacyverklaring', - base_test_connection_explain: '

Wat wordt getest?

Nadat je de verbindingstest hebt gestart, testen we of de momenteel door jou gebruikte internetverbinding ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

  • IPv6: zijn websites met moderne internetadressen voor jou bereikbaar?
  • DNSSEC: worden domeinnaam-handtekeningen voor jou gecontroleerd?

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie "Toelichting op testrapport".

Hoe verbeteren?

Het testrapport kan je gebruiken om je internetverbinding te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je internetprovider. In de communicatie met je internetprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Test je verbinding

', - base_test_connection_label: 'Test je verbinding', - base_test_connection_text: 'Moderne adressen bereikbaar?
Domein-handtekeningen gecontroleerd?', - base_test_connection_title: 'Over de verbindingstest', - base_test_explain: 'Over de test', - base_test_mail_explain: '

Wat wordt getest?

Nadat je een e-mailadres hebt opgegeven, testen we of de achterliggende e-mailvoorziening ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Let op: sommige standaarden zijn zelfs relevant als je je domeinnaam niet gebruikt voor het ontvangen en verzenden van e-mail.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie "Toelichting op testrapport".

Hoe verbeteren?

Het testrapport kan je gebruiken om je e-mailvoorziening te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je e-mailprovider. In de communicatie met je e-mailprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de e-mailtest integreren in je eigen website door gebruik te maken van onze widget code.

Test je e-mail

', - base_test_mail_input: 'Jouw e-mailadres:', - base_test_mail_label: 'Test je e-mail', - base_test_mail_text: 'Modern adres? Anti-phishing? Beveiligd transport? Route-autorisatie?', - base_test_mail_title: 'Over de e-mailtest', - base_test_prechecks_invalid_domain: 'De opgegeven domeinnaam is niet geldig!
Toelichting: Een A- en/of AAAA-record is noodzakelijk voor de websitetest, en een SOA-record voor de e-mailtest.', - base_test_start: 'Start test', - base_test_website_explain: '

Wat wordt getest?

Nadat je een domeinnaam van een website heb opgegeven, testen we of de website ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie "Toelichting op testrapport". Als je website een score van 100% heeft, dan wordt deze opgenomen in de Hall of Fame.

Hoe verbeteren?

Het testrapport kan je gebruiken om je website te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je webhoster.In de communicatie met je webhoster kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de websitetest integreren in je eigen website door gebruik te maken van onze widget code.

Test je website

', - base_test_website_input: 'Jouw website-domeinnaam:', - base_test_website_label: 'Test je website', - base_test_website_text: 'Modern adres? Beveiligde verbinding? Beveiligingsopties? Route-autorisatie?', - base_test_website_title: 'Over de websitetest', - base_widget_mail: 'E-mailtest widget', - base_widget_site: 'Websitetest widget', - connection_pagetitle: 'Verbindingstest', - connection_title: 'Verbindingstest', - detail_conn_dnssec_validation_exp: 'We testen of de door jou gebruikte resolvers de DNSSEC-handtekeningen van onze domeinnaam valideren. Resolvers worden normaal gesproken geleverd door je internetprovider. Als alternatief kun je resolvers van een andere DNS provider instellen. Je kan zelfs je eigen lokaal geïnstalleerde resolver gebruiken. Hoewel validatie plaatsvindt op de resolver, kan nog steeds door een aanvaller gerommeld worden met de communicatie tussen de resolver en jouw apparaat (ook wel \'last mile\' genoemd). Het is daarom het meest veilig om zo dicht mogelijk op je apparaat te valideren (bijv. door een lokaal geïnstalleerde resolver te gebruiken), of zorg ervoor dat het kanaal tussen je resolver en je apparaat beveiligd c.q. vertrouwd is.', - detail_conn_dnssec_validation_label: 'DNSSEC-validatie', - detail_conn_dnssec_validation_tech_table: 'DNS-provider', - detail_conn_dnssec_validation_verdict_bad: 'Je bent niet beschermd door validatie van DNSSEC-handtekeningen.', - detail_conn_dnssec_validation_verdict_good: 'Je bent beschermd door validatie van DNSSEC-handtekeningen.', - detail_conn_ipv6_connection_exp: 'We testen of jouw apparaat via zijn huidige internetverbinding in staat is om direct (d.w.z. zonder DNS-vertaling) verbinding te maken met onze webserver via ons bijbehorende IPv6-adres.

Sommige browser add-ons en routers bieden functionaliteit aan voor het filteren van domeinnamen om de privacy te verbeteren of internetgebruik te beperken. Om omzeiling te voorkomen blokkeert deze functionaliteit vaak ook het direct verbinden met IP-adressen waardoor deze subtest faalt.', - detail_conn_ipv6_connection_label: 'IPv6-connectiviteit (direct)', - detail_conn_ipv6_connection_tech_table: 'Geanonimiseerd IPv6-adres|Reverse name|Internetprovider', - detail_conn_ipv6_connection_verdict_bad: 'Je bent niet in staat om computers direct op hun IPv6-adres te bereiken.', - detail_conn_ipv6_connection_verdict_good: 'Je bent in staat om computers direct op hun IPv6-adres te bereiken.', - detail_conn_ipv6_dns_conn_exp: 'We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv6. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv6-adres ophaalt.', - detail_conn_ipv6_dns_conn_label: 'IPv6-connectiviteit (via DNS)', - detail_conn_ipv6_dns_conn_verdict_bad: 'Je bent niet in staat om computers via DNS op hun IPv6-adres te bereiken.', - detail_conn_ipv6_dns_conn_verdict_good: 'Je bent in staat om computers via DNS op hun IPv6-adres te bereiken.', - detail_conn_ipv6_ipv4_conn_exp: 'We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv4. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv4-adres ophaalt.

Niveau van vereistheid: Optioneel', - detail_conn_ipv6_ipv4_conn_label: 'IPv4-connectiviteit (via DNS)', - detail_conn_ipv6_ipv4_conn_tech_table: 'Geanonimiseerd IPv4-adres|Reverse name|Internetprovider', - detail_conn_ipv6_ipv4_conn_verdict_bad: 'Je bent niet in staat om computers via DNS op hun IPv4-adres te bereiken.', - detail_conn_ipv6_ipv4_conn_verdict_good: 'Je bent in staat om computers via DNS op hun IPv4-adres te bereiken.', - detail_conn_ipv6_privacy_exp: 'We testen of je apparaat \'IPv6 Privacy Extensions for SLAAC\' (of een ander IPv6-configuratieproces dan SLAAC) gebruikt om het lekken van zijn mogelijk privacygevoelige MAC-adres naar computers waarmee het via IPv6 verbinding maakt te voorkomen.', - detail_conn_ipv6_privacy_label: 'Privacy Extensions voor IPv6', - detail_conn_ipv6_privacy_verdict_bad: 'Je gebruikt SLAAC zonder \'IPv6 Privacy Extensions\'.', - detail_conn_ipv6_privacy_verdict_good: 'Je hebt \'IPv6 Privacy Extensions\' geactiveerd (of je gebruikt geen SLAAC).', - detail_conn_ipv6_resolver_conn_exp: 'We testen of ten minste één van de door jou gebruikte DNS-resolvers in staat is om onze autoritatieve nameserver te bereiken via IPv6. Vaak levert je internetprovider de DNS-resolver(s).', - 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).

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.', - detail_mail_auth_dkim_verdict_no_email: 'Je domeinnaam ondersteunt geen DKIM-records. Echter omdat je DMARC- en SPF-records aangeven dat er geen mail vanaf je domein wordt verstuurd, is DKIM niet nodig en wordt deze subtest overgeslagen.', - detail_mail_auth_dmarc_exp: 'We testen of DMARC beschikbaar is voor jouw domein. Een ontvangendemailserver kan de DMARC-policy gebruiken om te bepalen hoe om te gaan meteen e-mail met jouw domein als verzender waarvan de authenticatie met zowelDKIM als SPF faalt, en de ontvangende mailserver kan je e-mailadres uit het DMARC-recordgebruiken om je feedbackrapporten over het authenticatieresultaat te sturen. Het hebben van meer dan één DMARC-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt. Let op: DMARC vereist dathet SPF-domein (envelope sender, d.w.z. return-path dat terugkomt inMAIL FROM) en het DKIM-domein (d=) gelijk zijn aan het verzenddomein in hetmailbericht (From:). ', - detail_mail_auth_dmarc_label: 'DMARC aanwezigheid', - 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_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. ', - detail_mail_auth_dmarc_policy_verdict_good: 'Je DMARC-policy is voldoende strikt.', - detail_mail_auth_dmarc_policy_verdict_policy: 'Je DMARC-policy is niet voldoende strikt.', - detail_mail_auth_spf_exp: 'We testen of je domeinnaam een SPF-record heeft. Een ontvangende mailserver kan de IP-adressen in je SPF-record gebruiken om de verzendende mailserver van een ontvangen e-mail met jouw domein als afzender te authenticeren. Het bijbehorende beleid kan worden gebruikt om passende actie te ondernemen als de authenticatie mislukt. Meer dan één SPF-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt.

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', - detail_mail_auth_spf_label: 'SPF aanwezigheid', - detail_mail_auth_spf_tech_table: 'SPF-record', - detail_mail_auth_spf_verdict_bad: 'Je domeinnaam heeft geen geldig SPF-record.', - detail_mail_auth_spf_verdict_good: 'Je domein heeft een SPF-record.', - detail_mail_auth_spf_policy_exp: 'We controleren of de syntax van je SPF-record geldig is en of deze een voldoende strikte policy, d.w.z. ~all (softfail) of -all (hardfail), bevat om misbruik van je domein door phishers en spammers tegen te gaan. Om misbruik van je domein tegen te gaan is een liberale policy, d.w.z. +all (pass) of ?all (neutral), onvoldoende. Als all ontbreekt en er is geen redirect aanwezig in je SPF-record, dan is de default policy ?all.

We volgen ook include en redirect voor geldige SPF-records. Bovendien controleren we of je SPF-record het toegestane aantal van 10 DNS-opvragingen niet overschrijdt waardoor het geen werking meer heeft. Ieder van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.

Merk op dat als het domein onder include of redirect uit macro\'s bestaat, dan volgen we deze niet omdat we niet over de noodzakelijk informatie van een daadwerkelijke mail of mailserververbinding beschikken om de macro\'s uit te voeren. Dit betekent dat we het gevolg van macro\'s niet beoordelen. Bovendien tellen we de door macro\'s veroorzaakte DNS-opvragingen niet mee om te bepalen of het toegestane aantal DNS-opvragingen is overschreden.

Voor verzendende domeinen heeft het gebruik van ~all (softfail) in plaats van -all (fail) meestal de voorkeur. De reden hiervoor is dat wanneer de SPF-authenticatie faalt met een SPF fail, een ontvangende mailserver de verbinding al kan blokkeren zonder de DKIM-handtekening en het DMARC-beleid te evalueren. Dit kan leiden tot ten onrechte geblokkeerde mails (bijvoorbeeld wanneer mails door de ontvangende mailserver automatisch worden doorgestuurd naar een andere ontvangende mailserver). Merk op dat een getriggerde SPF softfail er nog steeds voor zorgt dat een strikte DMARC policy je domein beschermt als ook de DKIM-authenticatie faalt.

Voor domeinen zonder mail zie de good practice op uitleg van de "DMARC-policy" subtest.', - detail_mail_auth_spf_policy_label: 'SPF policy', - detail_mail_auth_spf_policy_tech_table: 'Domein|SPF-record', - detail_mail_auth_spf_policy_verdict_all: 'Je SPF-policy is niet voldoende strikt.', - detail_mail_auth_spf_policy_verdict_bad: 'Je SPF-policy is syntactisch niet correct.', - detail_mail_auth_spf_policy_verdict_good: 'Je SPF-policy is voldoende strikt.', - detail_mail_auth_spf_policy_verdict_include: 'Je SPF-policy is niet voldoende strikt. Het \'include\'-mechanisme in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.', - detail_mail_auth_spf_policy_verdict_max_lookups: 'Je SPF-policy is niet effectief omdat deze meer dan de toegestane 10 DNS-opvragingen vereist. Elk van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.', - detail_mail_auth_spf_policy_verdict_redirect: 'Je SPF-policy is niet voldoende strikt. De \'redirect modifier\' in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.', - detail_mail_dnssec_exists_exp: 'We testen of de domeinnaam in je e-mailadres, meer specifiek het SOA-record, ondertekend is met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze jouw mailserverdomeinen (MX) kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar een mailserverdomein dat onder controle is van de aanvaller.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.', - detail_mail_dnssec_exists_label: 'DNSSEC aanwezigheid', - detail_mail_dnssec_exists_tech_table: 'E-mailadresdomein|Registrar', - detail_mail_dnssec_exists_verdict_bad: 'Je e-mailadresdomein is onveilig oftewel \'insecure\', omdat het niet ondertekend is met DNSSEC.', - detail_mail_dnssec_exists_verdict_good: 'Je e-mailadresdomein is met DNSSEC ondertekend.', - detail_mail_dnssec_exists_verdict_resolver_error: 'Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.', - detail_mail_dnssec_exists_verdict_servfail: 'De nameservers van je e-mailadresdomein zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.', - detail_mail_dnssec_mx_exists_exp: 'We testen of de domeinnamen van je mailservers (MX), meer specifiek hun SOA-records, ondertekend zijn met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze de IP-adressen en DANE-records van jouw mailservers kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar IP-adressen die onder controle staan van de aanvaller óf de beveiligde mailserver-verbinding afluistert.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

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

De geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.', - detail_mail_dnssec_mx_exists_label: 'DNSSEC aanwezigheid', - detail_mail_dnssec_mx_exists_tech_table: 'Domein van mailserver (MX)|DNSSEC aanwezig', - 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: '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.', - detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error: 'Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.', - detail_mail_dnssec_mx_exists_verdict_servfail: 'De nameservers van tenminste één van je mailserverdomeinen zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je mailprovider) om dit spoedig op te lossen.', - detail_mail_dnssec_mx_valid_exp: 'We testen of de domeinen van je ontvangende mailservers (MX), meer specifiek hun SOA-records, zijn ondertekend met een geldige DNSSEC-handtekening die ze veilig oftewel \'secure\' maakt.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \'secure\' en de andere keer \'bogus\' zijn.', - detail_mail_dnssec_mx_valid_label: 'DNSSEC geldigheid', - detail_mail_dnssec_mx_valid_tech_table: 'Domein van mailserver (MX)|Status', - detail_mail_dnssec_mx_valid_verdict_bad: 'Tenminste één van de ondertekende domeinen van je mailservers is onbetrouwbaar oftewel \'bogus\', omdat zijn DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde de antwoorden van de nameservers, óf je mailserverdomein heeft serieuze DNSSEC-configuratiefouten. Dit laatste maakt je ontvangende mailserver onbereikbaar voor alle verzendende mailservers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met de nameserver-beheerder (vaak je mailprovider).', - detail_mail_dnssec_mx_valid_verdict_good: 'Al de ondertekende domeinnamen van je mailservers zijn veilig oftewel \'secure\', omdat hun DNSSEC-handtekeningen geldig zijn.', - detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo: 'Tenminste één van de domeinen van je mailservers is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.', - detail_mail_dnssec_valid_exp: 'We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \'secure\' en de andere keer \'bogus\' zijn.', - detail_mail_dnssec_valid_label: 'DNSSEC geldigheid', - detail_mail_dnssec_valid_tech_table: 'E-mailadresdomein|Status', - detail_mail_dnssec_valid_verdict_bad: 'Je e-mailadresdomein is onbetrouwbaar oftewel \'bogus\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).', - detail_mail_dnssec_valid_verdict_good: 'Je e-mailadresdomein is veilig oftewel \'secure\', omdat zijn DNSSEC-handtekening geldig is.', - detail_mail_dnssec_valid_verdict_unsupported_ds_algo: 'Je e-mailadresdomein is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.', - detail_mail_ipv6_mx_aaaa_exp: 'We testen of er tenminste één AAAA-record met IPv6-adres voor iedere ontvangende mailserver (MX) is. In het geval er geen mailserver is gedefinieerd, geven we een notificatie en we voeren andere subtesten van de mailtest die nog steeds relevant zijn gewoon uit.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.', - detail_mail_ipv6_mx_aaaa_label: 'IPv6-adressen voor mailserver(s)', - detail_mail_ipv6_mx_aaaa_tech_table: 'Mailserver (MX)|IPv6-adres|IPv4-adres', - 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 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: '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.', - 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.', - 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.

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

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 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', - detail_mail_tls_cert_hostmatch_tech_table: 'Mailserver (MX)|Niet-overeenkomende domeinen op certificaat', - detail_mail_tls_cert_hostmatch_verdict_bad: 'De domeinnaam van tenminste één van je mailservers komt niet overeen met de domeinnaam op het mailservercertificaat.', - detail_mail_tls_cert_hostmatch_verdict_good: 'De domeinnamen van al je mailservers komen overeen met de domeinnamen op je mailservercertificaten.', - detail_mail_tls_cert_pubkey_exp: '

We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
', - detail_mail_tls_cert_pubkey_label: 'Publieke sleutel van certificaat', - detail_mail_tls_cert_pubkey_tech_table: 'Mailserver (MX)|Getroffen handtekening-parameters|Status', - detail_mail_tls_cert_pubkey_verdict_bad: 'De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt onvoldoende veilige parameters.', - detail_mail_tls_cert_pubkey_verdict_good: 'De digitale handtekeningen van al je mailserver-certificaten gebruiken veilige parameters.', - detail_mail_tls_cert_pubkey_verdict_phase_out: 'De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_cert_signature_exp: '

We testen of de ondertekende fingerprint van ieder van je mailserver-certificaten is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
', - detail_mail_tls_cert_signature_label: 'Handtekening van certificaat', - detail_mail_tls_cert_signature_tech_table: 'Mailserver (MX)|Getroffen hashing-algoritme|Status', - detail_mail_tls_cert_signature_verdict_bad: 'Tenminste één van je mailserver-certificaten is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.', - detail_mail_tls_cert_signature_verdict_good: 'Al je mailserver-certificaten zijn ondertekend met een veilig algoritme voor hashing.', - detail_mail_tls_cert_trust_exp: 'We testen of we een geldige vertrouwensketen voor je mailserver-certificaten kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je ontvangende mailserver alle noodzakelijke tussenliggende certificaten presenteert.

Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.

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

Niveau van vereistheid: Optioneel', - detail_mail_tls_cert_trust_label: 'Vertrouwensketen van certificaat', - 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-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\').', - detail_mail_tls_cipher_order_verdict_good: 'Al je mailservers dwingen hun eigen cipher-voorkeur af (\'I\'), en bieden ciphers aan conform de voorgeschreven volgorde (\'II\').', - detail_mail_tls_cipher_order_verdict_na: 'Deze subtest is niet van toepassing aangezien je mailserver alleen \'Goede\' ciphers ondersteunt.', - detail_mail_tls_cipher_order_verdict_seclevel_bad: 'Tenminste één van je mailservers prefereert niet \'Goede\' boven \'Voldoende\' en dan pas \'Uit te faseren\' ciphers (\'II\').', - detail_mail_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

Tenminste een van je mailservers biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\'II-B\').', - detail_mail_tls_ciphers_exp: '

We testen of je ontvangende mailservers (MX) alleen veilige, d.w.z. \'Goede\' en/of \'Voldoende\', ciphers (ook algoritmeselecties genoemd) ondersteunen. Om te voorkomen dat we tegen \'rate limits\' van ontvangende mailservers aanlopen, bevat het testresultaat alleen de eerstgevonden getroffen algoritmeselectie.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing.

  • Vanaf TLS 1.3 omvat de term \'cipher suite\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \'cipher suite\' ambigu maakt, gebruikt NCSC de term \'algoritmeselectie\' om alle vier de functies te omvatten.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselectie. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \'Goede\', \'Voldoende\' en \'Uit te faseren\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\'. Achter iedere algoritmeselectie staat de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \'Uit te faseren\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_mail_tls_ciphers_label: 'Ciphers (Algoritmeselecties)', - detail_mail_tls_ciphers_tech_table: 'Mailserver (MX)|Eerst gevonden onveilige cipher|Status', - detail_mail_tls_ciphers_verdict_bad: 'Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige ciphers.', - detail_mail_tls_ciphers_verdict_good: 'Al je mailservers ondersteunen alleen veilige ciphers.', - detail_mail_tls_ciphers_verdict_phase_out: 'Tenminste één van je mailservers ondersteunt een of meer ciphers die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_compression_exp: '

We testen of je ontvangende mailservers (MX) TLS-compressie ondersteunen.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau
  • Onvoldoende: TLS-compressie
', - detail_mail_tls_compression_label: 'TLS-compressie', - detail_mail_tls_compression_tech_table: 'Mailserver (MX)|TLS-compressie', - detail_mail_tls_compression_verdict_bad: 'Tenminste één van je mailservers ondersteunt TLS-compressie, wat niet veilig is.', - detail_mail_tls_compression_verdict_good: 'Al je mailservers ondersteunen geen TLS-compressie.', - detail_mail_tls_dane_exists_exp: 'We testen of de nameservers van ieder van je ontvangende mailservers (MX) een of meer TLSA-records voor DANE bevatten.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het mailserver-domein.

Merk op dat de test TLSA-records van de types PKIX-TA(0) or PKIX-EE(1) negeert, omdat deze niet gebruikt dienen te worden voor ontvangende mailservers.

De test slaagt daarnaast niet als er geen DNSSEC-bewijs van \'Denial of Existence\' voor TLSA-records is. Als een ondertekend TLSA-record bestaat maar tegelijkertijd is er een \'insecure\' NXDOMAIN voor hetzelfde domein (door verkeerd werkende DNSSEC-ondertekeningssoftware), dan zal de test ook niet slagen. De laatste twee foutscenario\'s kunnen leiden tot afleveringsproblemen van aan jou gerichte e-mails door DANE-validerende mailverzenders.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, Appendix A, onder \'Certificate pinning en DANE\'.', - detail_mail_tls_dane_exists_label: 'DANE aanwezigheid', - detail_mail_tls_dane_exists_tech_table: 'Mailserver (MX)|DANE TLSA-record aanwezig', - 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.

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.', - detail_mail_tls_dane_rollover_verdict_good: 'Al je mailserver-domeinen hebben een actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.', - detail_mail_tls_dane_valid_exp: 'We testen of de DANE-fingerprints die je mailserverdomeinen presenteren geldig zijn voor je mailservercertificaten.

Met DANE kan je informatie over jouw mailservercertificaten publiceren in een speciaal DNS-record, een TLSA-record. Verzendende mailservers kunnen de certificaten nu niet alleen via de certificaatautoriteit, maar ook via de TLSA-records controleren op authenticiteit. Een verzendende mail server kan het TLSA-record ook als signaal gebruiken om alleen via STARTTLS (en niet onversleuteld) te verbinden. Als de DANE-fingerprint van een ontvangende mailserver wordt gecontroleerd door de verzendende mailserver, dan kan een actieve aanvaller die in staat is het berichtenverkeer te manipuleren de STARTTLS-encryptie niet verwijderen.', - detail_mail_tls_dane_valid_label: 'DANE geldigheid', - 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_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.', - detail_mail_tls_fs_params_verdict_good: 'Je mailserver ondersteunt voldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', - detail_mail_tls_fs_params_verdict_na: 'Deze subtest is niet van toepassing, omdat je mailservers niet Diffie-Hellman-sleuteluitwisseling ondersteunen. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.', - detail_mail_tls_fs_params_verdict_phase_out: 'Tenminste één van je mailservers ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_kex_hash_func_exp: '

We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
', - detail_mail_tls_kex_hash_func_label: 'Hashfunctie voor sleuteluitwisseling', - detail_mail_tls_kex_hash_func_tech_table: 'Mailserver (MX)|SHA-2-ondersteuning voor handtekeningen', - detail_mail_tls_kex_hash_func_verdict_good: 'Al je mailservers ondersteunen veilige hashfuncties voor sleuteluitwisseling.', - detail_mail_tls_kex_hash_func_verdict_other: 'Het was niet mogelijk om vast te stellen welke hashfunctie tenminste één van je mailservers gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).', - detail_mail_tls_kex_hash_func_verdict_phase_out: 'Ten minste één van je mailservers ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ', - detail_mail_tls_ocsp_stapling_exp: 'OUTDATED TEXT; TEST NOT USED
TODO', - detail_mail_tls_ocsp_stapling_label: 'OUTDATED TEXT; TEST NOT USED
TODO', - detail_mail_tls_ocsp_stapling_tech_table: 'OUTDATED TEXT; TEST NOT USED
Mailserver (MX)|TODO', - 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_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.', - detail_mail_tls_renegotiation_client_verdict_good: 'Al je mailservers staan geen client-initiated renegotiation toe.', - detail_mail_tls_renegotiation_secure_exp: '

We testen of je mailservers (MX) secure renegotiation ondersteunen.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \'opnieuw onderhandelen\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
', - detail_mail_tls_renegotiation_secure_label: 'Secure renegotiation', - 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_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 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: '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', - detail_mail_tls_version_verdict_bad: 'Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige TLS-versies.', - detail_mail_tls_version_verdict_good: 'Al je mailservers ondersteunen alleen veilige TLS-versies.', - detail_mail_tls_version_verdict_phase_out: 'Tenminste één van je mailservers ondersteunt een of meer TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_zero_rtt_exp: '

We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie geïnitieerd. De omvang van de ondersteuning voor early data zoals aangegeven door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando vóór de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
', - detail_mail_tls_zero_rtt_label: '0-RTT', - detail_mail_tls_zero_rtt_tech_table: 'Mailserver (MX)|0-RTT', - detail_mail_tls_zero_rtt_verdict_bad: 'Tenminste één van je mailservers ondersteunt 0-RTT, wat niet veilig is.', - detail_mail_tls_zero_rtt_verdict_good: 'Geen van je mailservers ondersteunen 0-RTT.', - detail_mail_tls_zero_rtt_verdict_na: 'Deze subtest is niet van toepassing aangezien je mailservers TLS 1.3 niet ondersteunen.', - detail_tech_data_bogus: 'bogus', - detail_tech_data_good: 'goed', - detail_tech_data_http_csp_has_bare_https: 'Aanbeveling: \'https:\' schema zonder specifiek hoofddomein moet niet worden gebruikt (#9).', - detail_tech_data_http_csp_has_data: 'Aanbeveling: \'data:\' schema moet niet worden gebruikt waar dat niet is toegestaan (#7).', - detail_tech_data_http_csp_has_host_without_scheme: 'Aanbeveling: Een domein zonder schema moet niet worden gebruikt (#8). ', - detail_tech_data_http_csp_has_http: 'Aanbeveling: \'http:\' schema moet niet worden gebruikt (#8).', - detail_tech_data_http_csp_has_invalid_host: 'Aanbeveling: Een wildcard (d.w.z. \'*\') of \'127.0.0.1\' moeten niet worden gebruikt (#9 en #10).', - detail_tech_data_http_csp_has_unsafe_eval: 'Aanbeveling: \'unsafe-eval\' moet niet worden gebruikt (#6).', - detail_tech_data_http_csp_has_unsafe_hashes: 'Aanbeveling: \'unsafe-hashes\' moet niet worden gebruikt (#6).', - detail_tech_data_http_csp_has_unsafe_inline: 'Aanbeveling: \'unsafe-inline\' moet niet worden gebruikt (#6).', - detail_tech_data_http_csp_missing_invalid_base_uri: 'Aanbeveling: \'base-uri\' met voldoende veilige waarde moet zijn gedefinieerd (#2).', - detail_tech_data_http_csp_missing_invalid_default_src: 'Aanbeveling: \'default-src\' met voldoende veilige waarde moet zijn gedefinieerd (#1).', - detail_tech_data_http_csp_missing_invalid_form_action: 'Aanbeveling: \'form-action\' met voldoende veilige waarde moet zijn gedefinieerd (#5).', - detail_tech_data_http_csp_missing_invalid_frame_ancestors: 'Aanbeveling: \'frame-ancestors\' met voldoende veilige waarde moet zijn gedefinieerd (#4).', - detail_tech_data_http_csp_missing_invalid_frame_src: 'Aanbeveling: \'frame-src\' (of \'child-src\' of \'default-src\' als fallback) met voldoende veilige waarde moet zijn gedefinieerd (#3).', - detail_tech_data_http_csp_no_policy_found: 'Geen CSP gevonden.', - detail_tech_data_http_csp_policy_found: 'Opgehaalde CSP-waarde: {policy}', - detail_tech_data_http_referrer_policy_bad_invalid: 'Slecht: policy-waarde is niet geldig.', - detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade: 'Slecht: \'no-referrer-when-downgrade\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_bad_origin: 'Slecht: \'origin\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin: 'Slecht: \'origin-when-cross-origin\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_bad_unsafe_url: 'Slecht: \'unsafe-url\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_no_policy: 'Geen Referrer-Policy gevonden.', - 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_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.', - detail_tech_data_http_securitytxt_multi_lang: 'Fout: Het veld \'Preferred-Languages\' moet niet meer dan één keer voorkomen.', - detail_tech_data_http_securitytxt_multiple_csaf_fields: 'Aanbeveling: Meerdere \'CSAF\'-velden zouden moeten worden teruggebracht tot één \'CSAF\'-veld.', - detail_tech_data_http_securitytxt_no_canonical: 'Aanbeveling: Het veld \'Canonical\' zou aanwezig moeten zijn in een ondertekend bestand.', - detail_tech_data_http_securitytxt_no_canonical_match: 'Fout: De web URI van security.txt (d.w.z. bij redirecting ten minste de laatste URI van de redirect-keten) moet worden vermeld in een \'Canonical\'-veld als dat aanwezig is.', - detail_tech_data_http_securitytxt_no_contact: 'Fout: Het veld \'Contact\' moet minstens één keer voorkomen.', - detail_tech_data_http_securitytxt_no_content_type: 'Fout: HTTP Content-Type header moet worden verstuurd.', - detail_tech_data_http_securitytxt_no_csaf_file: 'Fout: Ieder optioneel \'CSAF\'-veld moet verwijzen naar een bestand met de naam \'provider-metadata.json\'.', - detail_tech_data_http_securitytxt_no_encryption: 'Aanbeveling: Het veld \'Encryption\' zou aanwezig moeten zijn wanneer het veld \'Contact\' een e-mailadres bevat.', - detail_tech_data_http_securitytxt_no_expire: 'Fout: Het veld \'Expires\' moet aanwezig zijn.', - detail_tech_data_http_securitytxt_no_https: 'Fout: De web URI moet beginnen met \'https://\' (regel {line_no}).', - detail_tech_data_http_securitytxt_no_line_separators: 'Fout: Elke regel moet eindigen met óf een carriage return en line feed characters óf alleen een line feed character.', - detail_tech_data_http_securitytxt_no_security_txt_404: 'Fout: security.txt kon niet gevonden worden.', - detail_tech_data_http_securitytxt_no_security_txt_other: 'Fout: security.txt kon niet gevonden worden (onverwachte HTTP response code {status_code}).', - detail_tech_data_http_securitytxt_no_space: 'Fout: Veld-scheidingsteken (dubbele punt) moet worden gevolgd door een spatie (regel {line_no}).', - detail_tech_data_http_securitytxt_no_uri: 'Fout: Veldwaarde moet een URI zijn (bijv. beginnend met \'mailto:\') (regel {line_no}).', - detail_tech_data_http_securitytxt_not_signed: 'Aanbeveling: security.txt zou digitaal ondertekend moeten zijn.', - detail_tech_data_http_securitytxt_pgp_data_error: 'Fout: Ondertekende security.txt moet een correct \'ASCII-armored PGP block\' bevatten.', - detail_tech_data_http_securitytxt_pgp_error: 'Fout: Het decoderen of parsen van de ondertekende security.txt moet slagen.', - detail_tech_data_http_securitytxt_prec_ws: 'Fout: Er mag geen spatie staan voor het veld-scheidingsteken (dubbele punt) (regel {line_no}).', - detail_tech_data_http_securitytxt_requested_from: 'security.txt opgevraagd van {hostname}.', - 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 gecodeerd zijn met UTF-8 in Net-Unicode vorm.', - detail_tech_data_insecure: 'insecure', - detail_tech_data_insufficient: 'onvoldoende', - detail_tech_data_no: 'nee', - detail_tech_data_not_applicable: 'niet van toepassing', - detail_tech_data_not_reachable: 'niet bereikbaar', - detail_tech_data_not_testable: 'niet testbaar', - detail_tech_data_not_tested: 'niet getest', - detail_tech_data_phase_out: 'uit te faseren', - detail_tech_data_secure: 'secure', - detail_tech_data_sufficient: 'voldoende', - 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.

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

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.

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.

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.

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.', - detail_web_appsecpriv_http_x_frame_verdict_good: 'Je webserver biedt veilig ingestelde X-Frame-Options aan.', - detail_web_appsecpriv_http_x_xss_exp: 'OUTDATED TEXT; TEST NOT USED

We testen of je webserver een HTTP header voor X-XSS-Protection aanbiedt die een voldoende veilige waarde heeft (dat wil zeggen 1 of 1; mode=block). Deze HTTP header kan worden gebruikt om het beschermingsfilter van browsers tegen reflectieve cross-site scripting (XSS) aanvallen te activeren.

Geldige waardes voor de X-XSS-Protection header zijn:

  • 0 deactiveert het XSS-filter. Deze waarde dient NIET te worden gebruikt.
  • 1 activeert het XSS-filter. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het script opschonen en de onveilige delen verwijderen. Deze waarde is normaal gesproken de standaard-waarde (\'default\') in browsers als een website geen X-XSS-Protection header aanbiedt.
  • 1; mode=block activeert het XSS-filter én de blokkeermodus. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het antwoord blokkeren en de webpagina niet laden. Dit is de aanbevolen waarde.

Mits goed geconfigureerd kan Content-Security-Policy (CSP) vergelijkbare bescherming en meer bieden aan gebruikers van moderne webbrowsers. X-XSS-Protection biedt in dat geval nog altijd bescherming aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-XSS-Protection waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Niveau van vereistheid: Aanbevolen', - detail_web_appsecpriv_http_x_xss_label: 'OUTDATED TEXT; TEST NOT USED

X-XSS-Protection', - detail_web_appsecpriv_http_x_xss_tech_table: 'OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres|X-XSS-Protection waarde', - detail_web_appsecpriv_http_x_xss_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Je webserver biedt geen veilig ingestelde X-XSS-Protection aan.', - detail_web_appsecpriv_http_x_xss_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Je webserver biedt veilig ingestelde X-XSS-Protection aan.', - detail_web_dnssec_exists_exp: 'We testen of je domeinnaam, meer specifiek het SOA-record, ondertekend is met DNSSEC.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.', - detail_web_dnssec_exists_label: 'DNSSEC aanwezigheid', - detail_web_dnssec_exists_tech_table: 'Domein|Registrar', - detail_web_dnssec_exists_verdict_bad: 'Je domein is onveilig oftewel \'insecure\', omdat het niet ondertekend is met DNSSEC.', - detail_web_dnssec_exists_verdict_good: 'Je domein is met DNSSEC ondertekend.', - detail_web_dnssec_exists_verdict_resolver_error: 'Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.', - detail_web_dnssec_exists_verdict_servfail: 'De nameservers van je domeinnaam zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.', - detail_web_dnssec_valid_exp: 'We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \'secure\' en de andere keer \'bogus\' zij', - detail_web_dnssec_valid_label: 'DNSSEC geldigheid', - detail_web_dnssec_valid_tech_table: 'Domein|Status', - detail_web_dnssec_valid_verdict_bad: 'Je domeinnaam is onbetrouwbaar oftewel \'bogus\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).', - detail_web_dnssec_valid_verdict_good: 'Je domeinnaam is veilig oftewel \'secure\', omdat zijn DNSSEC-handtekening geldig is.', - detail_web_dnssec_valid_verdict_unsupported_ds_algo: 'Je domeinnaam is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.', - detail_web_ipv6_web_aaaa_exp: 'We testen of er tenminste één AAAA-record met IPv6-adres voor je webserver is.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.', - detail_web_ipv6_web_aaaa_label: 'IPv6-adressen voor webserver', - 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 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 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.', - 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.

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 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', - detail_web_tls_cert_hostmatch_tech_table: 'Webserver-IP-adres|Niet-overeenkomende domeinen op certificaat', - detail_web_tls_cert_hostmatch_verdict_bad: 'De domeinnaam van je website komt niet overeen met de domeinnaam op je websitecertificaat.', - detail_web_tls_cert_hostmatch_verdict_good: 'De domeinnaam van je website komt overeen met de domeinnaam op je websitecertificaat.', - detail_web_tls_cert_pubkey_exp: '

We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
', - detail_web_tls_cert_pubkey_label: 'Publieke sleutel van certificaat', - detail_web_tls_cert_pubkey_tech_table: 'Webserver-IP-adres|Getroffen handtekening-parameters|Status', - detail_web_tls_cert_pubkey_verdict_bad: 'De digitale handtekening van je websitecertificaat gebruikt onvoldoende veilige parameters.', - detail_web_tls_cert_pubkey_verdict_good: 'De digitale handtekening van je websitecertificaat gebruikt veilige parameters.', - detail_web_tls_cert_pubkey_verdict_phase_out: 'De digitale handtekening van je websitecertificaat gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_cert_signature_exp: '

We testen of de ondertekende fingerprint van het websitecertificaat is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
', - detail_web_tls_cert_signature_label: 'Handtekening van certificaat', - detail_web_tls_cert_signature_tech_table: 'Webserver-IP-adres|Getroffen hashing-algoritme|Status', - detail_web_tls_cert_signature_verdict_bad: 'Je websitecertificaat is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.', - detail_web_tls_cert_signature_verdict_good: 'Je websitecertificaat is ondertekend met een voldoende algoritme voor hashing.', - detail_web_tls_cert_trust_exp: 'We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je webserver alle noodzakelijke tussenliggende certificaten presenteert.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B3-4.', - detail_web_tls_cert_trust_label: 'Vertrouwensketen van certificaat', - 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-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\').', - detail_web_tls_cipher_order_verdict_good: 'Je webserver dwingt zijn eigen cipher-voorkeur af (\'I\'), en biedt ciphers aan conform de voorgeschreven volgorde (\'II\').', - detail_web_tls_cipher_order_verdict_na: 'Deze subtest is niet van toepassing aangezien je webserver alleen \'Goede\' ciphers ondersteunt.', - detail_web_tls_cipher_order_verdict_seclevel_bad: 'Je webserver prefereert niet \'Goede\' boven \'Voldoende\' en dan pas \'Uit te faseren\' ciphers (\'II\').', - detail_web_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

Je webserver biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\'II-B\').', - detail_web_tls_ciphers_exp: '

We testen of je webserver alleen veilige, d.w.z. \'Goede\' en/of \'Voldoende\', ciphers (ook algoritmeselecties genoemd) ondersteunt.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing. Een webserver kan meer dan één algoritmeselectie ondersteunen.

  • Vanaf TLS 1.3 omvat de term \'cipher suite\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \'cipher suite\' ambigu maakt, gebruikt NCSC de term \'algoritmeselectie\' om alle vier de functies aan te duiden.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselecties. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \'Goede\', \'Voldoende\' en \'Uit te faseren\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\'. Achter iedere algoritmeselectie noemen we de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \'Uit te faseren\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_web_tls_ciphers_label: 'Ciphers (Algoritmeselecties)', - detail_web_tls_ciphers_tech_table: 'Webserver-IP-adres|Getroffen ciphers|Status', - detail_web_tls_ciphers_verdict_bad: 'Je webserver ondersteunt een of meer onvoldoende veilige ciphers.', - detail_web_tls_ciphers_verdict_good: 'Je webserver ondersteunt alleen veilige ciphers.', - detail_web_tls_ciphers_verdict_phase_out: 'Je webserver ondersteunt een of meer ciphers die de status uit te faseren hebben omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_compression_exp: '

We testen of je webserver TLS-compressie ondersteunt.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
', - detail_web_tls_compression_label: 'TLS-compressie', - detail_web_tls_compression_tech_table: 'Webserver-IP-adres|TLS-compressie', - detail_web_tls_compression_verdict_bad: 'Je webserver ondersteunt TLS-compressie, wat niet veilig is.', - detail_web_tls_compression_verdict_good: 'Je webserver ondersteunt geen TLS-compressie.', - detail_web_tls_dane_exists_exp: 'We testen of de nameserver van je websitedomein een correct ondertekend TLSA-record voor DANE bevat.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het websitedomein, of als er DANE-gerelateerde DNSSEC-issues zijn (bijv. geen bewijs voor \'Denial of Existence\').

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, Appendix A, onder \'Certificate pinning en DANE\'.

Niveau van vereistheid: Optioneel', - detail_web_tls_dane_exists_label: 'DANE aanwezigheid', - detail_web_tls_dane_exists_tech_table: 'Webserver-IP-adres|DANE TLSA-record aanwezig', - detail_web_tls_dane_exists_verdict_bad: 'Je websitedomein bevat geen TLSA-record voor DANE.', - detail_web_tls_dane_exists_verdict_bogus: 'Je websitedomein bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Vraag je nameserver-beheerder om deze fout op te lossen.', - detail_web_tls_dane_exists_verdict_good: 'Je websitedomein bevat een TLSA-record voor DANE.', - detail_web_tls_dane_rollover_exp: '

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
', - detail_web_tls_dane_rollover_label: 'OUTDATED TEXT; TEST NOT USED

DANE rollover scheme', - detail_web_tls_dane_rollover_tech_table: 'OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme', - detail_web_tls_dane_rollover_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.', - detail_web_tls_dane_rollover_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.', - detail_web_tls_dane_valid_exp: 'We testen of de DANE-fingerprint die je domein presenteert geldig is voor je websitecertificaat.

Met DANE kan je informatie over jouw websitecertificaat publiceren in een speciaal DNS-record, een TLSA-record. Clients, zoals webbrowsers, kunnen het certificaat nu niet alleen via de certificaatautoriteit, maar ook via het TLSA-record controleren op authenticiteit. Een client kan het TLSA-record ook als signaal gebruiken om alleen via HTTPS (en niet via HTTP) te verbinden. DNSSEC is een noodzakelijke randvoorwaarde voor DANE. Helaas ondersteunen nog niet veel webbrowsers DANE-validatie.

Niveau van vereistheid: Aanbevolen (alleen als subtest voor \'DANE aanwezigheid\' is geslaagd)', - detail_web_tls_dane_valid_label: 'DANE geldigheid', - 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_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.', - detail_web_tls_fs_params_verdict_good: 'Je webserver ondersteunt veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', - detail_web_tls_fs_params_verdict_na: 'Deze subtest is niet van toepassing, omdat je webserver niet Diffie-Hellman-sleuteluitwisseling ondersteunt. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.', - detail_web_tls_fs_params_verdict_phase_out: 'Je webserver ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_http_compression_exp: '

We testen of je webserver HTTP-compressie ondersteunt.

Bij het HTTP-protocol wordt compressie vaak gebruikt om de beschikbare bandbreedte efficiënter te gebruiken. HTTP-compressie maakt de beveiligde verbinding met je webserver echter kwetsbaar voor de BREACH-aanval. Weeg de voors en tegens van HTTP-compressie zorgvuldig tegen elkaar af. Wanneer u kiest voor het gebruik van HTTP-compressie, ga dan na of het mogelijk is om hieruit voortvloeiende potentiële applicatie-aanvallen te beperken. Een voorbeeld van een dergelijke maatregel is het beperken van de mate waarin een aanvaller de respons van de server kan beïnvloeden.

Dit testonderdeel controleert of de webserver op rootdirectory-niveau HTTP-compressie ondersteunt, maar controleert geen andere websitebronnen zoals plaatje en scripts.

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

Niveau van vereistheid: Optioneel

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
', - detail_web_tls_http_compression_label: 'HTTP-compressie', - 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.

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.', - detail_web_tls_https_exists_verdict_good: 'Je website biedt HTTPS aan.', - detail_web_tls_https_exists_verdict_other: 'Je webserver is niet bereikbaar.', - detail_web_tls_https_forced_exp: 'We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf \'upgraden\' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie \'Webapplicatie-richtlijnen, Verdieping\' van NCSC, richtlijn U/WA.05.', - detail_web_tls_https_forced_label: 'HTTPS-doorverwijzing', - detail_web_tls_https_forced_tech_table: 'Webserver-IP-adres|HTTPS-doorverwijzing', - detail_web_tls_https_forced_verdict_bad: 'Je webserver ondersteunt zowel HTTP als HTTPS, maar verwijst bezoekers niet automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.', - detail_web_tls_https_forced_verdict_good: 'Je webserver verwijst bezoekers automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.', - detail_web_tls_https_forced_verdict_no_https: 'Deze test is niet uitgevoerd, omdat je webserver geen HTTPS biedt of alleen HTTPS met een te verouderde, onveilige TLS-configuratie.', - detail_web_tls_https_forced_verdict_other: 'Je webserver biedt alleen ondersteuning voor HTTPS en niet voor HTTP.', - detail_web_tls_https_hsts_exp: 'We testen of je webserver HSTS ondersteunt.

Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.

HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt man-in-the-middle-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van tenminste 1 jaar (max-age=31536000) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen.

De test controleert niet of preload wordt gebruikt en of het domein is opgenomen in de HSTS Preload Lijst.

Aanbevelingen voor implementatie

HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze niet bereikbaar zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen.

Daarom adviseren we u om de onderstaande implementatiestappen te volgen:

  1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);

  2. Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina\'s. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.

  3. Begin met 5 minuten (max-age=300);

  4. Verhoog dit naar 1 week (max-age=604800);
  5. Verhoog dit naar 1 maand (max-age=2592000);

  6. Verhoog het naar 1 jaar (max-age=31536000) of meer.

  7. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik includeSubDomains alleen als je er volledig zeker van bent dat alle (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.

  8. Gebruik preload alleen als je heel zeker weet dat je je domein wil laten opnemen in de HSTS Preload Lijst. HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien.

Zie \'Webapplicatie-richtlijnen, Verdieping\' van NCSC, richtlijn U/WA.05.', - detail_web_tls_https_hsts_label: 'HSTS', - detail_web_tls_https_hsts_tech_table: 'Webserver-IP-adres|HSTS-policy', - detail_web_tls_https_hsts_verdict_bad: 'Je webserver biedt geen HSTS-policy aan.', - detail_web_tls_https_hsts_verdict_good: 'Je webserver biedt een HSTS-policy aan.', - detail_web_tls_https_hsts_verdict_other: 'Je webserver biedt een HSTS-policy aan met een geldigheidsduur voor caching (max-age) die niet voldoende lang (d.w.z. korter dan 1 jaar) is.', - detail_web_tls_kex_hash_func_exp: '

We testen of je webserver ondersteuning biedt voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
', - detail_web_tls_kex_hash_func_label: 'Hashfunctie voor sleuteluitwisseling', - detail_web_tls_kex_hash_func_tech_table: 'Webserver-IP-adress|SHA-2-ondersteuning voor handtekeningen', - detail_web_tls_kex_hash_func_verdict_good: 'Je webserver ondersteunt een veilige hashfunctie voor sleuteluitwisseling.', - detail_web_tls_kex_hash_func_verdict_other: 'Het was niet mogelijk om vast te stellen welke hashfunctie je webserver gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).', - detail_web_tls_kex_hash_func_verdict_phase_out: 'Je webserver ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ', - detail_web_tls_ocsp_stapling_exp: '

We testen of je webserver de TLS Certificate Status extension of te wel OCSP stapling ondersteunt.

De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.

Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifiëren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.

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

Niveau van vereistheid: Optioneel

OCSP stapling

  • Goed: Aan
  • Voldoende: Uit
', - detail_web_tls_ocsp_stapling_label: 'OCSP stapling', - detail_web_tls_ocsp_stapling_tech_table: 'Webserver-IP-adres|OCSP stapling', - 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_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.', - detail_web_tls_renegotiation_client_verdict_good: 'Je webserver staat geen client-initiated renegotiation toe.', - detail_web_tls_renegotiation_secure_exp: '

We testen of je webserver secure renegotiation ondersteunt.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \'opnieuw onderhandelen\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
', - detail_web_tls_renegotiation_secure_label: 'Secure renegotiation', - detail_web_tls_renegotiation_secure_tech_table: 'Webserver-IP-adres|Secure renegotiation', - detail_web_tls_renegotiation_secure_verdict_bad: 'Je webserver ondersteunt insecure renegotiation, wat uiteraard niet veilig is.', - detail_web_tls_renegotiation_secure_verdict_good: 'Je webserver ondersteunt secure renegotiation.', - detail_web_tls_version_exp: '

We testen of je webserver alleen veilige TLS-versies ondersteunt.

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

Merk op dat browsermakers hebben aangekondigd dat ze zullen stoppen met de ondersteuning van TLS 1.1 en 1.0. Daardoor zullen websites die geen TLS 1.2 en/of 1.3 ondersteunen onbereikbaar worden.

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_web_tls_version_label: 'TLS-versie', - detail_web_tls_version_tech_table: 'Webserver-IP-adres|TLS-versie|Status', - detail_web_tls_version_verdict_bad: 'Je webserver ondersteunt onvoldoende veilige TLS-versies.', - detail_web_tls_version_verdict_good: 'Je webserver ondersteunt alleen veilige TLS-versies.', - detail_web_tls_version_verdict_phase_out: 'Je webserver ondersteunt TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_zero_rtt_exp: '

We testen of je webserver Zero Round Trip Time Resumption (0-RTT) ondersteunt.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina / opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor early data zoals aangegeven door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging vóór de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-HTTP 425 Too Early, dan wordt aangenomen dat de webserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
', - detail_web_tls_zero_rtt_label: '0-RTT', - detail_web_tls_zero_rtt_tech_table: 'Webserver-IP-adres|0-RTT', - detail_web_tls_zero_rtt_verdict_bad: 'Je webserver ondersteunt 0-RTT, wat niet veilig is.', - detail_web_tls_zero_rtt_verdict_good: 'Je webserver ondersteunt geen 0-RTT.', - detail_web_tls_zero_rtt_verdict_na: 'Deze subtest is niet van toepassing aangezien je webserver TLS 1.3 niet ondersteunt. ', - detail_web_mail_ipv6_ns_aaaa_exp: 'We testen of je domeinnaam tenminste twee nameservers met een IPv6-adres heeft.

Dit sluit aan bij de "Technische eisen voor registratie en gebruik van .nl-domeinnamen" d.d. 13 november 2017 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze test, aangezien zij geen IPv6-connectiviteit bieden.', - detail_web_mail_ipv6_ns_aaaa_label: 'IPv6-adressen voor nameservers', - detail_web_mail_ipv6_ns_aaaa_tech_table: 'Nameserver|IPv6-adres|IPv4-adres', - detail_web_mail_ipv6_ns_aaaa_verdict_bad: 'Geen van de nameservers van je domeinnaam heeft een IPv6-adres.', - detail_web_mail_ipv6_ns_aaaa_verdict_good: 'Twee of meer nameservers van je domeinnaam hebben een IPv6-adres.', - detail_web_mail_ipv6_ns_aaaa_verdict_other: 'Slechts één nameserver van je domeinnaam heeft een IPv6-adres.', - detail_web_mail_ipv6_ns_reach_exp: 'We testen of alle nameservers, die een AAAA-record met IPv6-adres hebben, bereikbaar zijn via IPv6.', - detail_web_mail_ipv6_ns_reach_label: 'IPv6-bereikbaarheid van nameservers', - 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.', - 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.

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 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', - faqs_report_subtest_good: 'Goed: geslaagd voor VEREISTE, AANBEVOLEN of OPTIONELE subtest ⇒ eerste: volledige score / laatste twee: geen impact op score', - faqs_report_subtest_info: 'Ter informatie: gezakt voor OPTIONELE subtest ⇒ geen impact op score', - faqs_report_subtest_not_tested: 'Niet getest, want al gezakt voor gerelateerde bovenliggende subtest ⇒ nulscore', - faqs_report_subtest_title: 'Iconen per subtest', - faqs_report_subtest_warning: 'Waarschuwing: gezakt voor AANBEVOLEN subtest ⇒ geen impact op score', - faqs_report_test_bad: 'Slecht: gezakt voor tenminste één VEREISTE subtest ⇒ geen volledige score voor testcategorie', - faqs_report_test_error: 'Testfout: uitvoeringsfout voor tenminste één subtest ⇒ geen resultaat voor testcategorie', - faqs_report_test_good: 'Goed: geslaagd voor alle subtesten ⇒ volledige score voor testcategorie ', - faqs_report_test_info: 'Ter informatie: gezakt voor tenminste één OPTIONELE subtest ⇒ volledige score voor testcategorie', - faqs_report_test_title: 'Iconen per testcategorie', - faqs_report_test_warning: 'Waarschuwing: gezakt voor tenminste één AANBEVOLEN subtest ⇒ volledige score voor testcategorie ', - faqs_report_title: 'Toelichting op testrapport', - faqs_rpki_title: 'Autorisatie voor routering (RPKI)', - faqs_starttls_title: 'Beveiligd e-mailtransport (STARTTLS en DANE)', - faqs_title: 'Kennisbank', - halloffame_champions_menu: 'Kampioenen!', - halloffame_champions_subtitle: '100% in website- én e-mailtest', - halloffame_champions_text: 'De {{count}} onderstaande domeinnamen scoren 100% in zowel de websitetest als de e-mailtest. Leden van deze Hall of Fame mogen beide 100%-badges gebruiken.', - halloffame_champions_title: 'Hall of Fame - Kampioenen!', - halloffame_mail_badge: 'Badge met tekst: 100%-score in e-mailtest', - halloffame_mail_menu: 'E-mail', - halloffame_mail_subtitle: '100% in e-mailtest', - halloffame_mail_text: 'De {{count}} onderstaande domeinnamen scoren 100% in de e-mailtest. Leden van deze Hall of Fame mogen de 100%-badge voor mail gebruiken.', - halloffame_mail_title: 'Hall of Fame - E-mail', - halloffame_web_badge: 'Badge met tekst: 100%-score in websitetest', - halloffame_web_menu: 'Websites', - halloffame_web_subtitle: '100% in websitetest', - halloffame_web_text: 'De {{count}} onderstaande domeinnamen scoren 100% in de websitetest. Leden van deze Hall of Fame mogen de 100%-badge voor websites gebruiken.', - halloffame_web_title: 'Hall of Fame - Websites', - home_pagetitle: 'Test voor moderne Internetstandaarden zoals IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE.', - home_stats_connection: 'unieke verbindingen', - home_stats_connection_items: '', - home_stats_header: 'Tests in cijfers', - home_stats_mail: 'unieke mail-domeinen', - home_stats_mail_items: '', - home_stats_notpassed: '0-99%:', - home_stats_passed: '100%:', - home_stats_website: 'unieke web-domeinen', - home_stats_website_items: '', - home_teaser: 'Moderne Internetstandaarden zorgen voor meer betrouwbaarheid en verdere groei van het Internet.
Gebruik jij ze al?', - mail_pagetitle: 'E-mailtest:', - mail_title: 'E-mailtest: {{prettyaddr}}', - mail_tweetmessage: 'De%20mailserver%20op%20{{report.domain}}%20scoort%20{{score}}%25%20in%20de%20e-mailtest%20van%20%40Internet_nl%3A', - page_gotocontents: 'Ga naar tekst-inhoud', - page_gotofooter: 'Ga naar de footer', - page_gotomainmenu: 'Ga naar het hoofd-menu', - page_metadescription: 'Test voor moderne Internetstandaarden IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI en security.txt', - page_metakeywords: 'IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, testtool, testen, check, controle, internet, internetstandaarden, open standaarden, moderne standaarden, beveiliging, security, internetbeveiliging, mail, e-mailbeveiliging, website, websitebeveiliging, internetverbinding, beveiligde verbinding, e-mailauthenticatie, encryptie, versleuteling, ciphers, cipher suites, PKI, SSL certificaat, TLS certificaat, websitecertificaat, Platform Internetstandaarden', - page_sitedescription: 'Is jouw internet up-to-date?', - page_sitetitle: 'Internet.nl', - page404_title: 'Pagina niet gevonden!', - probes_auto_redirect: 'Als de test gereed is, word je automatisch doorgestuurd naar de resultaatpagina.', - probes_no_javascript: 'Controleer of de testresultaten beschikbaar zijn. Zo niet, dan word je automatisch teruggeleid naar deze pagina.', - probes_no_javascript_connection: 'JavaScript inactief. Activeer JavaScript om de test toch uit te kunnen voeren.', - probes_no_redirection: 'Testfout. Probeer het later opnieuw, of test een andere domeinnaam.', - probes_test_finished: 'Test klaar! Resultaten beschikbaar...', - probes_test_running: 'Bezig...', - probes_tests_description: 'De onderstaande onderdelen worden getest.', - probes_tests_duration: 'Het testen duurt tussen de 5 en {{cache_ttl}} seconden.', - results_dated_presentation: 'Oude resultaatpresentatie. Doe de test opnieuw.', - results_domain_appsecpriv_http_headers_label: 'HTTP security headers', - results_domain_appsecpriv_other_options_label: 'Andere beveiligingsopties', - results_domain_ipv6_web_server_label: 'Webserver', - results_domain_rpki_web_server_label: 'Webserver', - results_domain_tls_http_headers_label: 'HTTP headers', - results_domain_tls_https_label: 'HTTP', - results_domain_tls_tls_label: 'TLS', - results_domain_mail_ipv6_name_servers_label: 'Nameservers van domein', - results_domain_mail_rpki_name_servers_label: 'Nameservers van domein', - results_domain_mail_tls_certificate_label: 'Certificaat', - results_domain_mail_tls_dane_label: 'DANE', - results_empty_argument_alt_text: 'Geen', - results_explanation_label: 'Testuitleg:', - results_further_testing_connection_label: 'Aanvullende verbindingstesten', - results_further_testing_mail_label: 'Aanvullende e-mailtesten', - results_further_testing_web_label: 'Aanvullende websitetesten', - results_mail_auth_dkim_label: 'DKIM', - results_mail_auth_dmarc_label: 'DMARC', - results_mail_auth_spf_label: 'SPF', - results_mail_dnssec_domain_label: 'E-mailadresdomein', - results_mail_dnssec_mail_servers_label: 'Mailserverdomein(en)', - results_mail_ipv6_mail_servers_label: 'Mailserver(s)', - results_mail_rpki_mail_servers_label: 'Mailserver(s)', - results_mail_rpki_mx_name_servers_label: 'Nameservers van mailserver(s)', - results_mail_tls_starttls_label: 'TLS', - results_no_icon_detail_close: 'sluit', - results_no_icon_detail_open: 'open', - results_no_icon_status_error: 'Error', - results_no_icon_status_failed: 'Gezakt', - results_no_icon_status_info: 'Informatie', - results_no_icon_status_not_tested: 'Niet-testbaar', - results_no_icon_status_passed: 'Geslaagd', - results_no_icon_status_warning: 'Suggestie', - results_panel_button_hide: 'Verberg details', - results_panel_button_show: 'Toon details', - results_perfect_score: 'Gefeliciteerd, je domeinnaam wordt spoedig in de Hall of Fame opgenomen!', - results_permalink: 'Permalink testresultaat {{permadate|date:\'(Y-m-d H:i T)\'}}', - results_rerun_test: 'Herhaal de test', - results_retest_time: 'Seconden tot hertest-mogelijkheid:', - results_score_description: 'Het domein {{prettyaddr}} heeft een testscore van {{score}}%.', - results_tech_details_label: 'Technische details:', - results_test_direct: 'Test direct:', - results_test_email_label: 'Test andere e-mail', - results_test_website_label: 'Test andere website', - results_test_info: 'Toelichting op testrapport', - results_verdict_label: 'Uitslag:', - test_connipv6_failed_description: 'Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.', - test_connipv6_failed_summary: 'Moderne adressen niet bereikbaar (IPv6)', - test_connipv6_info_description: 'Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.', - test_connipv6_info_summary: 'Moderne adressen niet bereikbaar (IPv6)', - test_connipv6_label: 'Moderne adressen bereikbaar (IPv6)', - test_connipv6_passed_description: 'Goed gedaan! Je internetprovider heeft je een modern internetadres (IPv6) gegeven. Daardoor kan je andere computers met moderne adressen bereiken.', - test_connipv6_passed_summary: 'Moderne adressen bereikbaar (IPv6)', - test_connipv6_title: 'Moderne adressen bereikbaar?', - test_connipv6_warning_description: 'Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.', - test_connipv6_warning_summary: 'Moderne adressen niet bereikbaar (IPv6)', - test_connresolver_failed_description: 'Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.', - test_connresolver_failed_summary: 'Domein-handtekeningen niet gecontroleerd (DNSSEC)', - test_connresolver_info_description: 'Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.', - test_connresolver_info_summary: 'Domein-handtekeningen niet gecontroleerd (DNSSEC)', - test_connresolver_label: 'Controle van domein-handtekeningen (DNSSEC)', - test_connresolver_passed_description: 'Goed gedaan! Domein-handtekeningen (DNSSEC) worden voor jou gecontroleerd. Daardoor ben je beschermd tegen vervalste vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen.', - test_connresolver_passed_summary: 'Domein-handtekeningen gecontroleerd (DNSSEC)', - test_connresolver_title: 'Domein-handtekeningen gecontroleerd?', - test_connresolver_warning_description: 'Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.', - test_connresolver_warning_summary: 'Domein-handtekeningen niet gecontroleerd (DNSSEC)', - test_error_summary: 'Fout tijdens uitvoering van test!', - test_mailauth_failed_description: 'Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.', - test_mailauth_failed_summary: 'Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_mailauth_info_description: 'Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.', - test_mailauth_info_summary: 'Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_mailauth_label: 'Echtheidswaarmerken tegen phishing (DMARC, DKIM en SPF)', - test_mailauth_passed_description: 'Goed gedaan! Je domein bevat alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails.', - test_mailauth_passed_summary: 'Echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_mailauth_title: 'Echtheidswaarmerken tegen e-mailphishing?', - test_mailauth_warning_description: 'Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.', - test_mailauth_warning_summary: 'Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_maildnssec_failed_description: 'Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.', - test_maildnssec_failed_summary: 'Niet alle domeinnamen ondertekend (DNSSEC)', - test_maildnssec_info_description: 'Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.', - test_maildnssec_info_summary: 'Niet alle domeinnamen ondertekend (DNSSEC)', - test_maildnssec_label: 'Ondertekende domeinnamen (DNSSEC)', - test_maildnssec_passed_description: 'Goed gedaan! Je e-mailadresdomein en je mailserverdomein(en) zijn ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen daardoor betrouwbaar het IP-adres van je ontvangende mailserver(s) opvragen.', - test_maildnssec_passed_summary: 'Alle domeinnamen ondertekend (DNSSEC)', - test_maildnssec_title: 'Domeinnamen ondertekend?', - test_maildnssec_warning_description: 'Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.', - test_maildnssec_warning_summary: 'Niet alle domeinnamen ondertekend (DNSSEC)', - test_mailipv6_failed_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_failed_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_mailipv6_info_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_info_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_mailipv6_label: 'Modern adres (IPv6)', - test_mailipv6_passed_description: 'Goed gedaan! Je mailserver is bereikbaar voor verzenders met moderne adressen (IPv6). Daardoor is je mailserver volledig onderdeel van het moderne Internet.', - test_mailipv6_passed_summary: 'Bereikbaar via modern internetadres (IPv6)', - 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_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)', - test_mailrpki_label: 'Route-autorisatie (RPKI)', - 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: '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)', - test_mailtls_info_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_info_summary: 'Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)', - 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: 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 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)', - test_mailtls_null_mx_with_other_mx_description: 'Waarschuwing: 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.', - test_mailtls_null_mx_with_other_mx_summary: 'Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)', - test_mailtls_null_mx_without_a_aaaa_description: 'Waarschuwing: 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.', - test_mailtls_null_mx_without_a_aaaa_summary: 'Goed geconfigureerd niet-ontvangend mail domein, maar met overbodig record (STARTTLS en DANE)', - test_mailtls_passed_description: 'Goed gedaan! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) een beveiligde verbinding opzetten. STARTTLS voorkomt dat passieve aanvallers e-mails onderweg naar jou kunnen lezen. DANE beschermt tegen actieve aanvallers, die door manipulatie van het mailverkeer de STARTTLS-encryptie kunnen verwijderen.', - test_mailtls_passed_summary: 'Mailserver-verbinding voldoende beveiligd (STARTTLS en DANE)', - test_mailtls_title: 'Beveiligde mailserver-verbinding?', - test_mailtls_unreachable_description: 'Testfout: tenminste één van jouw ontvangende mailservers was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw mailserver(s).', - test_mailtls_unreachable_summary: 'Onbereikbare ontvangende mailserver (STARTTLS en DANE)', - test_mailtls_untestable_description: 'Testfout: tenminste één van jouw ontvangende mailservers was niet testbaar voor ons. Daardoor was het niet mogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door onder meer SMTP errors en geactiveerde ratelimiting-maatregelen die verbindingen tegenhouden.', - 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. 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. 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. 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. 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)', - test_sitednssec_info_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_info_summary: 'Domeinnaam niet ondertekend (DNSSEC)', - test_sitednssec_label: 'Ondertekende domeinnaam (DNSSEC)', - test_sitednssec_passed_description: 'Goed gedaan! Je domeinnaam is ondertekend met een geldige handtekening (DNSSEC). Daardoor zijn bezoekers die controle van domein-handtekeningen geactiveerd hebben, beschermd tegen gemanipuleerde vertaling van jouw domeinnaam naar kwaadaardige internetadressen.', - test_sitednssec_passed_summary: 'Domeinnaam ondertekend (DNSSEC)', - test_sitednssec_title: 'Domeinnaam ondertekend?', - test_sitednssec_warning_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_warning_summary: 'Domeinnaam niet ondertekend (DNSSEC)', - test_siteipv6_failed_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_failed_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_siteipv6_info_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_info_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_siteipv6_label: 'Modern adres (IPv6)', - test_siteipv6_passed_description: 'Goed gedaan! Je website is bereikbaar voor bezoekers die een moderne internetadres (IPv6) gebruiken, en daardoor volledig onderdeel van het moderne internet.', - test_siteipv6_passed_summary: 'Bereikbaar via moderne internetadres (IPv6)', - 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_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)', - test_siterpki_label: 'Route-autorisatie (RPKI)', - 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: '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)', - test_sitetls_info_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_info_summary: 'Verbinding niet of onvoldoende beveiligd (HTTPS)', - test_sitetls_label: 'Beveiligde verbinding (HTTPS)', - test_sitetls_passed_description: 'Goed gedaan! De verbinding met je website is voldoende beveiligd (HTTPS). Gegevens die onderweg zijn tussen je website en haar bezoekers, zijn daardoor beschermd tegen afluisteren en manipulatie.', - test_sitetls_passed_summary: 'Verbinding voldoende beveiligd (HTTPS)', - test_sitetls_title: 'Beveiligde verbinding?', - test_sitetls_unreachable_description: 'Je webserver was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor HTTPS (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw webserver.', - test_sitetls_unreachable_summary: 'Onbereikbare webserver (HTTPS)', - test_sitetls_warning_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_warning_summary: 'Verbinding niet of onvoldoende beveiligd (HTTPS)', - widget_content_notes: '

Opmerkingen

  • Logo: We raden aan om ons logo op je eigen webserver op te slaan en te gebruiken. Op die manier is er geen contact met onze webserver als je website wordt bezocht.
  • Content-Security-Policy (CSP): Indien je op je website gebruikmaakt van CSP, dan zou je internet.nl moeten toevoegen aan de regels voor form-action en eventueel ook voor img-src als je linkt naar het logo op onze webserver.
', - widget_mail_html_block: 'Test je e-mail', - widget_mail_intro: '

E-mailtest widget

Wil je dat bezoekers van jouw website direct een e-mailtest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

', - widget_site_html_block: 'Test je website', - widget_site_intro: '

Websitetest widget

Wil je dat bezoekers van jouw website direct een websitetest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

', - }, - }, -};const internet_nl_messages = { - en: { - internet_nl: { - about_contact: '

Contact

Internet Standards Platform
c/o ECP
Maanweg 174 (8th floor)
2516 AB The Hague
The Netherlands

CoC number: 27169301

Email

question@internet.nl

PGP public key
Fingerprint: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Expiration date: 19th of March 2025

', - base_about: 'About Internet.nl', - base_accessibility: 'Accessibility', - base_blogs: 'Blogs', - base_contact: 'Contact', - base_copyright: 'Copyright', - base_disclosure: 'Report vulnerability', - base_faqs: 'Knowledge base', - base_halloffame: 'Hall of Fame', - base_halloffame_champions: 'Hall of Fame - Champions!', - base_halloffame_lead: '{{count}} domains with 2 x 100%
Latest entry: {{latest|date:\'d-m-Y\'}}', - base_halloffame_link: 'To Hall of Fame - Champions!', - base_halloffame_mail: 'Hall of Fame - Email', - base_halloffame_web: 'Hall of Fame - Websites', - base_home: 'Home', - base_info: 'Internet.nl is an initiative of the Internet community and the Dutch government.', - base_news: 'News', - base_newslink: 'To the news overview', - base_privacy: 'Privacy statement', - base_test_connection_explain: '

What is tested?

After you start the connection test, we will check if your currently used internet connection offers support for the modern Internet Standards below.

  • IPv6: are websites with modern internet addresses reachable for you?
  • DNSSEC: are domain signatures validated for you?

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see "Explanation of test report".

How to improve?

You can use this test report to improve your internet connection. Usually contacting your internet provider on this will be the best next step. In the communication with your internet provider you can use the permalink (i.e. the URL) of the test report.

Test your connection

', - base_test_connection_label: 'Test your connection', - base_test_connection_text: 'Modern addresses reachable?
Domain signatures validated?', - base_test_connection_title: 'About the connection test', - base_test_explain: 'About the test', - base_test_mail_explain: '

What is tested?

After you enter a domain name of an email service, we will test if the email service offers support for the modern Internet Standards below.

Note: some standards are even relevant if there are no mail servers configured for your domain.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see "Explanation of test report".

How to improve?

You can use this test report to improve your mail service. Usually contacting your mail hoster on this will be the best next step. In the communication with your mail hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the email test into your own website using our widget code.

Test your email

', - base_test_mail_input: 'Your email address:', - base_test_mail_label: 'Test your email', - base_test_mail_text: 'Modern address? Anti-phishing? Secure transport? Route authorisation?', - base_test_mail_title: 'About the email test', - base_test_prechecks_invalid_domain: 'The given domain is invalid!
Explanation: An A and/or AAAA record is necessary for the website test, and a SOA record for the email test.', - base_test_start: 'Start test', - base_test_website_explain: '

What is tested?

After you enter a domain name of a website, we will test if the website offers support for the modern Internet Standards below.

Test report?

After the test is finished, you are directed to a test report. The report contains an overall percentage score and results per test section and per subtest. For more information see "Explanation of test report".

How to improve?

You can use this test report to improve your website. Usually contacting your web hoster on this will be the best next step. In the communication with your web hoster you can use the permalink (i.e. the URL) of the test report.

Widget

You can integrate the website test into your own website using our widget code.

Test your website

', - base_test_website_input: 'Your website domain name:', - base_test_website_label: 'Test your website', - base_test_website_text: 'Modern address? Signed domain? Secure connection? Route authorisation?', - base_test_website_title: 'About the website test', - base_widget_mail: 'Email test widget', - base_widget_site: 'Website test widget', - connection_pagetitle: 'Connection test', - connection_title: 'Connection test', - detail_conn_dnssec_validation_exp: 'We check if the resolvers that you use validate the DNSSEC signatures of our domain name. Resolvers are usually provided by your internet provider. Alternatively you can configure resolvers from another DNS provider. You can even use your own locally installed resolver. Although validation is done in the resolver, the communication from the resolver back to your device (referred to as \'last mile\') could still be tampered with by an attacker. Thus the most secure way is to validate close to the end user device (e.g. by using a locally installed resolver), or make sure that the channel between your resolver and your end user device is secured/trusted.', - detail_conn_dnssec_validation_label: 'DNSSEC validation', - 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 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 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 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.', - detail_conn_ipv6_ipv4_conn_verdict_good: 'You are able to reach computers via DNS on their IPv4 address.', - detail_conn_ipv6_privacy_exp: 'We check if your device uses IPv6 Privacy Extensions for SLAAC (or another IPv6 configuration process than SLAAC) in order to prevent leakage of its potentially privacy sensitive MAC address to computers it connects with over IPV6.', - detail_conn_ipv6_privacy_label: 'Privacy Extensions for IPv6', - detail_conn_ipv6_privacy_verdict_bad: 'You are using SLAAC without \'IPv6 Privacy Extensions\'.', - detail_conn_ipv6_privacy_verdict_good: 'You have enabled \'IPv6 Privacy Extensions\' (or you are not using SLAAC).', - detail_conn_ipv6_resolver_conn_exp: 'We check if at least one of the DNS resolvers that you are using is able to reach our authoritative name servers over IPv6. Usually your internet provider provides the DNS resolver(s).', - 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).

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.', - detail_mail_auth_dkim_verdict_no_email: 'Your domain does not support DKIM records. However because your DMARC and SPF records hint that no mail is sent from your domain, DKIM is not necessary and this subtest is skipped.', - detail_mail_auth_dmarc_exp: 'We check if DMARC is available for your domain. A receiving mail server mayuse your DMARC policy to evaluate how to handle a mail with your domain assender that could not be authenticated with both DKIM and SPF, and it mayuse your mail address from the DMARC record to provide feedback reports onthe authentication to you. Having more than one DMARC record in the same domainis not valid and will lead to a test failure.Note: DMARC requires the SPFdomain (envelope sender, i.e. return-path that shows up in MAIL FROM) andthe DKIM domain (d=) to align with the mail body domain (From:).', - detail_mail_auth_dmarc_label: 'DMARC existence', - 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_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. ', - detail_mail_auth_dmarc_policy_verdict_good: 'Your DMARC policy is sufficiently strict.', - detail_mail_auth_dmarc_policy_verdict_policy: 'Your DMARC policy is not sufficiently strict.', - detail_mail_auth_spf_exp: 'We check if your domain has an SPF record. A receiving mail server can use the IP addresses in your SPF record to authenticate the sending mail server of a received email with your domain as sender. The accompanying policy can be used to take appropriate action if authentication fails. Having more than one SPF record in the same domain is not valid and will lead to a test failure.

For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.', - detail_mail_auth_spf_label: 'SPF existence', - detail_mail_auth_spf_tech_table: 'SPF record', - detail_mail_auth_spf_verdict_bad: 'Your domain does not have a valid SPF record.', - detail_mail_auth_spf_verdict_good: 'Your domain has an SPF record.', - detail_mail_auth_spf_policy_exp: 'We check if the syntax of your SPF record is correct and if it contains a sufficiently strict policy i.e. ~all (softfail) or -all (fail) in order to prevent abuse by phishers and spammers. To be effective against abuse of your domain, a liberal policy i.e. +all (pass) or ?all (neutral) is insufficient. If all is missing and a redirect modifier is not present in your SPF record, the default is ?all.

We also follow include and redirect for valid SPF records. In addition, we check that your SPF record does not exceed the allowed number of 10 DNS lookups making it ineffective. Each of the following SPF terms counts as a DNS lookup: redirect, include, a, mx, ptr and exist. While the SPF terms all, ip4, ip6 and exp do not count as DNS lookups.

Note that if the include or redirect domain consists of macros, we will not follow them as we do not have the necessary information from an actual mail or mail server connection to expand those macros. This means that we do not evaluate the outcome of macros. Moreover, we do not count DNS lookups caused by macros to determine whether the allowed number of DNS lookups has been exceeded.

For sending domains, using ~all (softfail) instead of -all (fail) is usually preferred. This is because when SPF authentication fails with an SPF fail, a receiving mail server may already block the connection without evaluating the DKIM signature and DMARC policy. This can lead to falsely blocked mails (e.g. when mails are automatically forwarded by the receiving mail server to another receiving mail server). Note that a triggered SPF softfail still ensures that a strict DMARC policy protects your domain if DKIM authentication also fails.

For no-mail domains see the good practice on explanation of the "DMARC policy" subtest.', - detail_mail_auth_spf_policy_label: 'SPF policy', - detail_mail_auth_spf_policy_tech_table: 'Domain|SPF record', - detail_mail_auth_spf_policy_verdict_all: 'Your SPF policy is not sufficiently strict.', - detail_mail_auth_spf_policy_verdict_bad: 'Your SPF policy is not syntactically correct.', - detail_mail_auth_spf_policy_verdict_good: 'Your SPF policy is sufficiently strict.', - 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 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 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: '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.', - detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error: 'Unfortunately an error occurred in Internet.nl\'s resolver. Please contact us.', - detail_mail_dnssec_mx_exists_verdict_servfail: 'The name servers of at least one of your mail server domains are broken. They returned an error (SERVFAIL) to our queries for a DNSSEC signature. Please contact your name server operator (often your mail provider) to fix this soon.', - detail_mail_dnssec_mx_valid_exp: 'We check if the domains of your receiving mail servers (MX), more specifically their SOA records, are signed with a valid signature making them \'secure\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \'secure\' one time and \'bogus\' the next.', - detail_mail_dnssec_mx_valid_label: 'DNSSEC validity', - detail_mail_dnssec_mx_valid_tech_table: 'Domain of mail server (MX)|Status', - detail_mail_dnssec_mx_valid_verdict_bad: 'At least one of your signed mail server domains is \'bogus\', because its DNSSEC signature is not valid. Either someone manipulated the responses from its name servers, or your mail server domain has serious DNSSEC configuration errors. The latter makes your receiving mail server unreachable for any sending mail server that validates DNSSEC signatures. You should contact the name server operator (often your mail provider) as soon as possible.', - detail_mail_dnssec_mx_valid_verdict_good: 'All your signed mail server domains are secure, because their DNSSEC signatures are valid.', - detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo: 'At least one of your mail server domains is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.', - detail_mail_dnssec_valid_exp: 'We check if your domain, more specifically its SOA record, is signed with a valid signature making it \'secure\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \'secure\' one time and \'bogus\' the next.', - detail_mail_dnssec_valid_label: 'DNSSEC validity', - detail_mail_dnssec_valid_tech_table: 'Email address domain|Status', - detail_mail_dnssec_valid_verdict_bad: 'Your email address domain is \'bogus\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.', - detail_mail_dnssec_valid_verdict_good: 'Your email address domain is secure, because its DNSSEC signature is valid.', - detail_mail_dnssec_valid_verdict_unsupported_ds_algo: 'Your email address domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.', - detail_mail_ipv6_mx_aaaa_exp: 'We check if there is at least one AAAA record with IPv6 address for every receiving mail server (MX). In case no mail server is defined, we give a notification and we execute other subtests of the mail test that are still relevant.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.

Note that the email test does not fall back to A/AAAA records for mail servers in case of absence of an MX record.', - detail_mail_ipv6_mx_aaaa_label: 'IPv6 addresses for mail server(s)', - detail_mail_ipv6_mx_aaaa_tech_table: 'Mail server (MX)|IPv6 address|IPv4 address', - 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 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: '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.', - 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.', - 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.

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

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 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', - detail_mail_tls_cert_hostmatch_tech_table: 'Mail server (MX)|Unmatched domains on certificate', - detail_mail_tls_cert_hostmatch_verdict_bad: 'The domain name of at least one of your mail servers does not match the domain name on the mail server certificate.', - detail_mail_tls_cert_hostmatch_verdict_good: 'The domain names of all your mail servers match the domain names on your mail server certificates.', - detail_mail_tls_cert_pubkey_exp: '

We check if the (ECDSA or RSA) digital signature of each of your mail server certificates uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
', - detail_mail_tls_cert_pubkey_label: 'Public key of certificate', - detail_mail_tls_cert_pubkey_tech_table: 'Mail server (MX)|Affected signature parameters|Status', - detail_mail_tls_cert_pubkey_verdict_bad: 'The digital signature of at least one of your mail server certificates uses insufficiently secure parameters.', - detail_mail_tls_cert_pubkey_verdict_good: 'The digital signatures of all your mail server certificates use secure parameters.', - detail_mail_tls_cert_pubkey_verdict_phase_out: 'The digital signature of at least one of your mail server certificates uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.', - detail_mail_tls_cert_signature_exp: '

We check if the signed fingerprint of each of your mail server certificates was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
', - detail_mail_tls_cert_signature_label: 'Signature of certificate', - detail_mail_tls_cert_signature_tech_table: 'Mail server (MX)|Affected hash algorithm|Status', - detail_mail_tls_cert_signature_verdict_bad: 'At least one of your mail server certificates is signed using a hash algorithm that is insufficiently secure.', - detail_mail_tls_cert_signature_verdict_good: 'All your mail server certificates are signed using a secure hash algorithm.', - detail_mail_tls_cert_trust_exp: 'We check if we are able to build a valid chain of trust for your mail server certificates.

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

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

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

Requirement level: Optional', - detail_mail_tls_cert_trust_label: 'Trust chain of certificate', - detail_mail_tls_cert_trust_tech_table: 'Mail server (MX)|Untrusted certificate chain', - detail_mail_tls_cert_trust_verdict_bad: 'The trust chain of at least one of your mail server certificates is not complete and/or not signed by a trusted root certificate authority.', - detail_mail_tls_cert_trust_verdict_good: 'The trust chain of all your mail server certificates is complete and signed by a trusted root certificate authority.', - 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 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\').', - detail_mail_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

At least one of your mail servers does not offer ciphers in accordance with the prescribed ordering within a particular security level (\'II-B\').', - detail_mail_tls_ciphers_exp: '

We check if your receiving mail servers (MX) only support secure, i.e. \'Good\' and/or \'Sufficient\', ciphers (also known as algorithm selections).

To prevent us from running into rate limits of receiving mail servers, the test result only contains the first found affected algorithm selections.

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \'cipher suite\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \'cipher suite\' ambiguous, NCSC-NL uses the term \'algorithm selection\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \'Good\', \'Sufficient\' and \'Phase out\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \'IT Security Guidelines for Transport Layer Security (TLS)\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \'Phase out\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_mail_tls_ciphers_label: 'Ciphers (Algorithm selections)', - detail_mail_tls_ciphers_tech_table: 'Mail server (MX)|First found affected cipher|Status', - detail_mail_tls_ciphers_verdict_bad: 'At least one of your mail servers supports one or more insufficiently secure ciphers.', - detail_mail_tls_ciphers_verdict_good: 'All your mail servers support secure ciphers only.', - detail_mail_tls_ciphers_verdict_phase_out: 'At least one of your mail servers supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.', - detail_mail_tls_compression_exp: '

We check if your receiving mail servers (MX) support TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression
  • Insufficient: TLS compression
', - detail_mail_tls_compression_label: 'TLS compression', - detail_mail_tls_compression_tech_table: 'Mail server (MX)|TLS compression', - detail_mail_tls_compression_verdict_bad: 'At least on of your mail servers supports TLS compression, which is not secure.', - detail_mail_tls_compression_verdict_good: 'All your mail servers do not support TLS compression.', - detail_mail_tls_dane_exists_exp: 'We check if the name servers of each of your receiving mail servers (MX) provide a TLSA record for DANE.

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

Note that the test ignores TLSA records of the types PKIX-TA(0) or PKIX-EE(1) as these should not be used for receiving mail servers.

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

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, Appendix A, under \'Certificate pinning and DANE\' (in English).', - detail_mail_tls_dane_exists_label: 'DANE existence', - detail_mail_tls_dane_exists_tech_table: 'Mail server (MX)|DANE TLSA record existent', - 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.

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.', - detail_mail_tls_dane_rollover_verdict_good: 'All your mail server domains have an active DANE scheme for a reliable rollover of certificate keys.', - 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 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.', - detail_mail_tls_fs_params_verdict_good: 'All your mail servers support secure parameters for Diffie-Hellman key exchange.', - detail_mail_tls_fs_params_verdict_na: 'This subtest is not applicable as your mail servers do not support Diffie-Hellman key exchange. Note that RSA is an alternative for key exchange, but has the phase out status.', - detail_mail_tls_fs_params_verdict_phase_out: 'At least one of your mail servers supports parameters for Diffie-Hellman key exchange that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.', - detail_mail_tls_kex_hash_func_exp: '

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

A receiving mail server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The mail server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
', - 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_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', - detail_mail_tls_ocsp_stapling_tech_table: 'OUTDATED TEXT; TEST NOT USED
Mail server (MX)|OCSP stapling', - detail_mail_tls_ocsp_stapling_verdict_bad: 'OUTDATED TEXT; TEST NOT USED
At least one of your mail servers supports OCSP stapling but responds with invalid data', - detail_mail_tls_ocsp_stapling_verdict_good: 'OUTDATED TEXT; TEST NOT USED
Your mail servers support OCSP stapling.', - detail_mail_tls_ocsp_stapling_verdict_ok: 'OUTDATED TEXT; TEST NOT USED
At least one of your mail servers does not support OCSP stapling.', - detail_mail_tls_renegotiation_client_exp: '

We check if a sending mail server can initiate a renegotiation with your receiving mail servers (MX).

Allowing sending mail servers to initiate renegotiation is generally not necessary and opens a receiving mail server to DoS attacks inside a TLS connection. An attacker can perform similar DoS-attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
', - detail_mail_tls_renegotiation_client_label: 'Client-initiated renegotiation', - detail_mail_tls_renegotiation_client_tech_table: 'Mail server (MX)|Client-initiated renegotiation', - detail_mail_tls_renegotiation_client_verdict_bad: 'At least one of your mail servers allows for client-initiated renegotiation, which could have negative impact on the availability of your mail server.', - detail_mail_tls_renegotiation_client_verdict_good: 'All your mail servers do not allow for client-initiated renegotiation.', - detail_mail_tls_renegotiation_secure_exp: '

We check if your mail servers (MX) support secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
', - detail_mail_tls_renegotiation_secure_label: 'Secure renegotiation', - detail_mail_tls_renegotiation_secure_tech_table: 'Mail server (MX)|Secure renegotiation', - detail_mail_tls_renegotiation_secure_verdict_bad: 'At least one of your mail servers supports insecure renegotiation, which is obviously not secure.', - detail_mail_tls_renegotiation_secure_verdict_good: 'All your mail servers support secure renegotiation.', - detail_mail_tls_starttls_exists_exp: 'We check if your receiving mail servers (MX) support STARTTLS. If so, we also check in the subtests of this test category whether STARTTLS is configured sufficiently secure.

Because of performance reasons at most ten mail servers over either IPv6 or IPv4 are tested for STARTTLS and DANE.

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

Non-receiving domain:

  1. Null MX: In case you do not want to receive mail on your domain that has A/AAAA records, we advise you to use "Null MX" (RFC 7505). Note that a "Null MX record" should not be combined with a normal MX record that is pointing to a mail host.

  2. No MX: In case your domain does not have A/AAAA records and you do not want to receive mail on it, we advise you to configure no MX record at all (i.e. even not an "Null MX" record).

  3. If we detect any of the above two cases, the subtests in the STARTTLS and DANE category are not applicable. This also goes for the mail server specific subtests in the categories for IPv6 and DNSSEC. Other subtests of the email test (e.g. for DMARC) are still applicable.

  4. Note that having a "Null MX" record or no MX record could also impact sending mail, because receiving servers may reject email that has an invalid return address.

For a "good practice on domains without mail" see the explanation of the "DMARC policy" subtest.', - detail_mail_tls_starttls_exists_label: 'STARTTLS available', - detail_mail_tls_starttls_exists_tech_table: 'Mail server (MX)|STARTTLS', - 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 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: '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', - detail_mail_tls_version_verdict_bad: 'At least one of your mail servers supports one or more insufficiently secure TLS versions.', - detail_mail_tls_version_verdict_good: 'All your mail servers support secure TLS versions only.', - detail_mail_tls_version_verdict_phase_out: 'At least one of your mail servers supports one or more TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.', - detail_mail_tls_zero_rtt_exp: '

We check if your mail servers (MX) support Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the first handshake message. 0-RTT does not provide protection against replay attacks at the TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your mail servers do not support TLS 1.3, the test is not applicable.For mail servers that support TLS 1.3, the STARTTLS command is issued and a TLSsession is initiated. The amount ofearly datasupport indicated by themail server is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theEHLO command before the TLS handshake but after the STARTTLS command(i.e. no round trips (0-RTT) needed before application data to the server).If the TLS handshake is completed and the mail server responds,then the mail server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
', - detail_mail_tls_zero_rtt_label: '0-RTT', - detail_mail_tls_zero_rtt_tech_table: 'Mail server (MX)|0-RTT', - detail_mail_tls_zero_rtt_verdict_bad: 'At least one of your mail servers supports 0-RTT, which is not secure.', - detail_mail_tls_zero_rtt_verdict_good: 'None of your mail servers support 0-RTT.', - detail_mail_tls_zero_rtt_verdict_na: 'This subtest is not applicable as your mail servers do not support TLS 1.3.', - detail_tech_data_bogus: 'bogus', - detail_tech_data_good: 'good', - detail_tech_data_http_csp_has_bare_https: 'Recommendation: \'https:\' scheme without a specific main domain should not be used (#9).', - detail_tech_data_http_csp_has_data: 'Recommendation: \'data:\' scheme should not be used where that is not permitted (#7).', - detail_tech_data_http_csp_has_host_without_scheme: 'Recommendation: A domain without a scheme should not be used (#8).', - detail_tech_data_http_csp_has_http: 'Recommendation: \'http:\' scheme should not be used (#8).', - detail_tech_data_http_csp_has_invalid_host: 'Recommendation: A wildcard (i.e. \'*\') or \'127.0.0.1\' should not be used (#9 and #10).', - detail_tech_data_http_csp_has_unsafe_eval: 'Recommendation: \'unsafe-eval\' should not be used (#6).', - detail_tech_data_http_csp_has_unsafe_hashes: 'Recommendation: \'unsafe-hashes\' should not be used (#6).', - detail_tech_data_http_csp_has_unsafe_inline: 'Recommendation: \'unsafe-inline\' should not be used (#6).', - detail_tech_data_http_csp_missing_invalid_base_uri: 'Recommendation: \'base-uri\' with sufficiently secure value should be defined (#2).', - detail_tech_data_http_csp_missing_invalid_default_src: 'Recommendation: \'default-src\' with sufficiently secure value should be defined (#1).', - detail_tech_data_http_csp_missing_invalid_form_action: 'Recommendation: \'form-action\' with sufficiently secure value should be defined (#5).', - detail_tech_data_http_csp_missing_invalid_frame_ancestors: 'Recommendation: \'frame-ancestors\' with sufficiently secure value should be defined (#4).', - detail_tech_data_http_csp_missing_invalid_frame_src: 'Recommendation: \'frame-src\' (or child-src\' or \'default-src\' as fallback) with sufficiently secure value should be defined (#3).', - detail_tech_data_http_csp_no_policy_found: 'No CSP found.', - detail_tech_data_http_csp_policy_found: 'Retrieved CSP value: {policy}', - detail_tech_data_http_referrer_policy_bad_invalid: 'Bad: policy value is not valid.', - detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade: 'Bad: \'no-referrer-when-downgrade\' must not be used.', - detail_tech_data_http_referrer_policy_bad_origin: 'Bad: \'origin\' must not be used.', - detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin: 'Bad: \'origin-when-cross-origin\' must not be used.', - detail_tech_data_http_referrer_policy_bad_unsafe_url: 'Bad: \'unsafe-url\' must not be used.', - detail_tech_data_http_referrer_policy_no_policy: 'No Referrer-Policy found.', - 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_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.', - detail_tech_data_http_securitytxt_multi_lang: 'Error: \'Preferred-Languages\' field must not appear more than once.', - detail_tech_data_http_securitytxt_multiple_csaf_fields: 'Recommendation: Multiple \'CSAF\' fields should be brought back to one \'CSAF\' field.', - detail_tech_data_http_securitytxt_no_canonical: 'Recommendation: \'Canonical\' field should be present in a signed file.', - detail_tech_data_http_securitytxt_no_canonical_match: 'Error: The web URI of security.txt (i.e. when redirecting at least the last URI of the redirect chain) must be listed in a \'Canonical\' field if present.', - detail_tech_data_http_securitytxt_no_contact: 'Error: \'Contact\' field must appear at least once.', - detail_tech_data_http_securitytxt_no_content_type: 'Error: HTTP Content-Type header must be sent.', - detail_tech_data_http_securitytxt_no_csaf_file: 'Error: Every optional \'CSAF\' field must point to a file named \'provider-metadata.json\'.', - detail_tech_data_http_securitytxt_no_encryption: 'Recommendation: \'Encryption\' field should be present when \'Contact\' field contains an email address.', - detail_tech_data_http_securitytxt_no_expire: 'Error: \'Expires\' field must be present.', - detail_tech_data_http_securitytxt_no_https: 'Error: Web URI must begin with \'https://\' (line {line_no}).', - detail_tech_data_http_securitytxt_no_line_separators: 'Error: Every line must end with either a carriage return and line feed characters or just a line feed character.', - detail_tech_data_http_securitytxt_no_security_txt_404: 'Error: security.txt could not be located.', - detail_tech_data_http_securitytxt_no_security_txt_other: 'Error: security.txt could not be located (unexpected HTTP response code {status_code}).', - detail_tech_data_http_securitytxt_no_space: 'Error: Field separator (colon) must be followed by a space (line {line_no}).', - detail_tech_data_http_securitytxt_no_uri: 'Error: Field value must be a URI (e.g. beginning with \'mailto:\') (line {line_no}).', - detail_tech_data_http_securitytxt_not_signed: 'Recommendation: security.txt should be digitally signed.', - detail_tech_data_http_securitytxt_pgp_data_error: 'Error: Signed security.txt must contain a correct ASCII-armored PGP block.', - detail_tech_data_http_securitytxt_pgp_error: 'Error: Decoding or parsing of the signed security.txt must succeed.', - detail_tech_data_http_securitytxt_prec_ws: 'Error: There must be no whitespace before the field separator (colon) (line {line_no}).', - detail_tech_data_http_securitytxt_requested_from: 'security.txt requested from {hostname}.', - 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 encoded using UTF-8 in Net-Unicode form.', - detail_tech_data_insecure: 'insecure', - detail_tech_data_insufficient: 'insufficient', - detail_tech_data_no: 'no', - detail_tech_data_not_applicable: 'not applicable', - detail_tech_data_not_reachable: 'not reachable', - detail_tech_data_not_testable: 'not testable', - detail_tech_data_not_tested: 'not tested', - detail_tech_data_phase_out: 'phase out', - detail_tech_data_secure: 'secure', - detail_tech_data_sufficient: 'sufficient', - 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). 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 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 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.

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

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.', - detail_web_appsecpriv_http_x_frame_verdict_good: 'Your web server offers securely configured X-Frame-Options.', - detail_web_appsecpriv_http_x_xss_exp: 'OUTDATED TEXT; TEST NOT USED

We check if your web server provides an HTTP header for X-XSS-Protection that has a sufficiently secure value (i.e. 1 or 1; mode=block). This HTTP header can be used to activate the protection filter of browsers against reflective cross-site scripting (XSS) attacks. Valid values for the X-XSS-Protection header are:

  • 0 disables the XSS filter. This value should NOT be used.
  • 1 enables the XSS filter. If a cross-site scripting attack is detected, the browser will sanitize the script and remove the unsafe parts. This value is usually the default in browsers when a website does not offer an X-XSS-Protection header.
  • 1; mode=block enables the XSS filter. If a cross-site scripting attack is detected, the browser will block the response and prevent rendering the page. This is the recommended value.

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

Requirement level: Recommended', - detail_web_appsecpriv_http_x_xss_label: 'OUTDATED TEXT; TEST NOT USED

X-XSS-Protection', - detail_web_appsecpriv_http_x_xss_tech_table: 'OUTDATED TEXT; TEST NOT USED

Web server IP address|X-XSS-Protection value', - detail_web_appsecpriv_http_x_xss_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Your web server does not offer securely configured X-XSS-Protection.', - detail_web_appsecpriv_http_x_xss_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Your web server offers securely configured X-XSS-Protection.', - detail_web_dnssec_exists_exp: 'We check if your domain, more specifically its SOA record, is DNSSEC signed.

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_web_dnssec_exists_label: 'DNSSEC existence', - detail_web_dnssec_exists_tech_table: 'Domain|Registrar', - detail_web_dnssec_exists_verdict_bad: 'Your domain is insecure, because it is not DNSSEC signed.', - detail_web_dnssec_exists_verdict_good: 'Your domain is DNSSEC signed.', - detail_web_dnssec_exists_verdict_resolver_error: 'Unfortunately an error occurred in Internet.nl\'s resolver. Please contact us.', - detail_web_dnssec_exists_verdict_servfail: 'The name servers of your 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_web_dnssec_valid_exp: 'We check if your domain, more specifically its SOA record, is signed with a valid signature making it \'secure\'.

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

Note that we only test the name server that responds first. If name servers of a domain name have inconsistent configurations, this can lead to varying test results. In that case, for example, the result for this subtest may be \'secure\' one time and \'bogus\' the next.', - detail_web_dnssec_valid_label: 'DNSSEC validity', - detail_web_dnssec_valid_tech_table: 'Domain|Status', - detail_web_dnssec_valid_verdict_bad: 'Your domain is \'bogus\', because the DNSSEC signature is not valid. Either someone manipulated the response from your name server, or your domain has a serious DNSSEC configuration error. The latter makes your domain unreachable for any user who validates DNSSEC signatures. You should contact your name server operator (often your registrar or hosting provider) as soon as possible.', - detail_web_dnssec_valid_verdict_good: 'Your domain is secure, because its DNSSEC signature is valid.', - detail_web_dnssec_valid_verdict_unsupported_ds_algo: 'Your domain is signed with an algorithm that our validating resolver currently does not support. Therefore we are not able to check the validity of its DNSSEC signature.', - detail_web_ipv6_web_aaaa_exp: 'We check if there is at least one AAAA record with IPv6 address for your web server.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginning with ::ffff:) will fail in this subtest, as they do not provide IPv6 connectivity.', - detail_web_ipv6_web_aaaa_label: 'IPv6 addresses for web server', - 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 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 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.', - detail_web_rpki_exists_label: 'Route Origin Authorisation existence', - 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.

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 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', - detail_web_tls_cert_hostmatch_tech_table: 'Web server IP address|Unmatched domains on certificate', - detail_web_tls_cert_hostmatch_verdict_bad: 'The domain name of your website does not match the domain name on your website certificate.', - detail_web_tls_cert_hostmatch_verdict_good: 'The domain name of your website matches the domain name on your website certificate.', - detail_web_tls_cert_pubkey_exp: '

We check if the (ECDSA or RSA) digital signature of your website certificate uses secure parameters.

The verification of certificates makes use of digital signatures. To guarantee the authenticity of a connection, a trustworthy algorithm for certificate verification must be used. The algorithm that is used to sign a certificate is selected by its supplier.The certificate specifies the algorithm for digital signatures that is used by its owner during the key exchange. It is possible to configure multiple certificates to support more than one algorithm.

The security of ECDSA digital signatures depends on the chosen curve. The security of RSA for encryption and digital signatures is tied to the key length of the public key.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B5-1 and table 9 for ECDSA, and guideline B3-3 and table 8 for RSA (in English).

Elliptic curves for ECDSA

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

Length of RSA-keys

  • Good: At least 3072 bit
  • Sufficient: 2048 – 3071 bit
  • Insufficient: Less than 2048 bit
', - detail_web_tls_cert_pubkey_label: 'Public key of certificate', - detail_web_tls_cert_pubkey_tech_table: 'Web server IP address|Affected signature parameters|Status', - detail_web_tls_cert_pubkey_verdict_bad: 'The digital signature of your website certificate uses insufficiently secure parameters.', - detail_web_tls_cert_pubkey_verdict_good: 'The digital signature of your website certificate uses secure parameters.', - detail_web_tls_cert_pubkey_verdict_phase_out: 'The digital signature of your website certificate uses parameters that have a phase out status, because they are known to be fragile and are at risk of of becoming insufficiently secure.', - detail_web_tls_cert_signature_exp: '

We check if the signed fingerprint of the website certificate was created with a secure hashing algorithm.

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

Hash functions for certificate verification

  • Good: SHA-512, SHA-384, SHA-256
  • Insufficient: SHA-1, MD5
', - detail_web_tls_cert_signature_label: 'Signature of certificate', - detail_web_tls_cert_signature_tech_table: 'Web server IP address|Affected hash algorithm|Status', - detail_web_tls_cert_signature_verdict_bad: 'Your website certificate is signed using a hash algorithm that is insufficiently secure.', - detail_web_tls_cert_signature_verdict_good: 'Your website certificate is signed using a secure hash algorithm.', - detail_web_tls_cert_trust_exp: 'We check if we are able to build a valid chain of trust for your website certificate.

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

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B3-4 (in English).', - detail_web_tls_cert_trust_label: 'Trust chain of certificate', - detail_web_tls_cert_trust_tech_table: 'Web server IP address|Untrusted certificate chain', - detail_web_tls_cert_trust_verdict_bad: 'The trust chain of your website certificate is not complete and/or not signed by a trusted root certificate authority.', - detail_web_tls_cert_trust_verdict_good: 'The trust chain of your website certificate is complete and signed by a trusted root certificate authority.', - detail_web_tls_cipher_order_exp: 'We check if your web server enforces its own cipher preference (\'I\'), and offers ciphers in accordance with the prescribed ordering (\'II\').

When your web server supports \'Good\' ciphers only, this subtest is not applicable as the ordering has no significant security advantage.

I. Server enforced cipher preference: The web server enforces its own cipher preference while negotiating with a web browser, and does not accept any preference of the web browser;

II. Prescribed ordering: Ciphers are offered by the web server 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_web_tls_cipher_order_label: 'Cipher order', - detail_web_tls_cipher_order_tech_table: 'Web server IP address|First found affected cipher pair|Violated rule # (\'II-B\')', - detail_web_tls_cipher_order_verdict_bad: 'Your web server does not enforce its own cipher preference (\'I\').', - detail_web_tls_cipher_order_verdict_good: 'Your web server enforces its own cipher preference (\'I\'), and offers ciphers in accordance with the prescribed ordering (\'II\').', - detail_web_tls_cipher_order_verdict_na: 'This subtest is not applicable as your web server supports \'Good\' ciphers only.', - detail_web_tls_cipher_order_verdict_seclevel_bad: 'Your web server does not prefer \'Good\' over \'Sufficient\' over \'Phase out\' ciphers (\'II\').', - detail_web_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

Your web server does not offer ciphers in accordance with the prescribed ordering within a particular security level (\'II-B\').', - detail_web_tls_ciphers_exp: '

We check if your web server only supports secure, i.e. \'Good\' and/or \'Sufficient\', ciphers (also known as algorithm selections).

An algorithm selection consists of ciphers for four cryptographic functions: 1) key exchange, 2) certificate verification, 3) bulk encryption, and 4) hashing. A web server may support more than one algorithm selection.

  • Since TLS 1.3, the term \'cipher suite\' only comprises ciphers used for bulk encryption and hashing. When using TLS 1.3 the ciphers for key exchange and certificate verification are negotiable and not part of the naming of the cipher suite. Because this makes the term \'cipher suite\' ambiguous, NCSC-NL uses the term \'algorithm selection\' to comprise all four cipher functions.
  • NCSC-NL uses the IANA naming convention for algorithm selections. Internet.nl uses the OpenSSL naming convention. Since TLS 1.3 OpenSSL follows the IANA naming convention. A translation between both can be found in the OpenSSL documentation.
  • Note that ciphers using PSK or SRP for key exchange (which are not sufficiently secure) are not detected in this test due to a limitation related to our testing method.

See \'IT Security Guidelines for Transport Layer Security (TLS) v2.1\' from NCSC-NL, guideline B2-1 to B2-4 and table 2, 4, 6 and 7 (in English).

Below you find \'Good\', \'Sufficient\' and \'Phase out\' algorithm selections in the by NCSC-NL prescribed order, based on appendix C of the \'IT Security Guidelines for Transport Layer Security (TLS)\'. Behind every algorithm selection is the minimum TLS version (e.g. [1.2]) that supports this algorithm selection and that is at least \'Phase out\'.

Good:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Sufficient:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Phase out:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_web_tls_ciphers_label: 'Ciphers (Algorithm selections)', - detail_web_tls_ciphers_tech_table: 'Web server IP address|Affected ciphers|Status', - detail_web_tls_ciphers_verdict_bad: 'Your web server supports one or more insufficiently secure ciphers.', - detail_web_tls_ciphers_verdict_good: 'Your web server supports secure ciphers only.', - detail_web_tls_ciphers_verdict_phase_out: 'Your web server supports one or more ciphers that have a phase out status, because they are known to be fragile and are at risk of becoming insufficiently secure.', - detail_web_tls_compression_exp: '

We check if your web server supports TLS compression.

The use of compression can give an attacker information about the secret parts of encrypted communication. An attacker that can determine or control parts of the data sent can reconstruct the original data by performing a large number of requests. TLS compression is used so rarely that disabling it is generally not a problem.

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

Compression option

  • Good: No compression
  • Sufficient: Application-level compression (in this case HTTP compression)
  • Insufficient: TLS compression
', - detail_web_tls_compression_label: 'TLS compression', - detail_web_tls_compression_tech_table: 'Web server IP address|TLS compression', - detail_web_tls_compression_verdict_bad: 'Your web server supports TLS compression, which is not secure.', - detail_web_tls_compression_verdict_good: 'Your web server does not support TLS compression.', - detail_web_tls_dane_exists_exp: 'We check if the name servers of your website domain contain a correctly signed TLSA record for DANE.

As DNSSEC is preconditional for DANE, this test will fail in case DNSSEC is missing on the website domain, or if there are DANE related DNSSEC issues (e.g. no proof of \'Denial of Existence\').

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

Requirement level: Optional', - detail_web_tls_dane_exists_label: 'DANE existence', - detail_web_tls_dane_exists_tech_table: 'Web server IP address|DANE TLSA record existent', - detail_web_tls_dane_exists_verdict_bad: 'Your website domain does not contain a TLSA record for DANE.', - detail_web_tls_dane_exists_verdict_bogus: 'Your website domain does not provide DNSSEC proof that DANE TLSA records do not exist. You should ask your name server operator to fix this issue.', - detail_web_tls_dane_exists_verdict_good: 'Your website domain contains a TLSA record for DANE.', - detail_web_tls_dane_rollover_exp: '

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
', - detail_web_tls_dane_rollover_label: 'OUTDATED TEXT; TEST NOT USED

DANE rollover scheme', - detail_web_tls_dane_rollover_tech_table: 'OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme', - detail_web_tls_dane_rollover_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.', - detail_web_tls_dane_rollover_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.', - detail_web_tls_dane_valid_exp: 'We check if the DANE fingerprint presented by your domain is valid for your web certificate.

DANE allows you to publish information about your website certificate in a special DNS record, called TLSA record. Clients, like web browsers, can check the authenticity of your certificate not only through the certificate authority but also through the TLSA record. A client can also use the TLSA record as a signal to only use HTTPS (and not HTTP). DNSSEC is preconditional for DANE. Unfortunately not much web browsers are supporting DANE validation yet.

Requirement level: Recommended (only if subtest for \'DANE existence\' is passed)', - detail_web_tls_dane_valid_label: 'DANE validity', - 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_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 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 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 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.', - detail_web_tls_https_exists_verdict_good: 'Your website offers HTTPS.', - detail_web_tls_https_exists_verdict_other: 'Your web server is unreachable.', - detail_web_tls_https_forced_exp: 'We check if your web server automatically redirects visitors from HTTP to HTTPS on the same domain (through a 3xx redirect status code like 301 and 302), or if it offers support for only HTTPS and not for HTTP.

In case of redirecting, a domain should firstly upgrade itself by redirecting to its HTTPS version before it may redirect to another domain. This also ensures that the HSTS policy will be accepted by the web browser. Examples of correct redirect order:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Note that this subtest only tests if the given domain correctly redirects from HTTP to HTTPS. An eventual further redirect to a different domain (including a subdomain of the tested domain) is not tested. You could start a separate test to test such a domain that is being redirected to.

See \'Web application guidelines, detailed version\' from NCSC-NL, guideline U/WA.05 (in Dutch).', - detail_web_tls_https_forced_label: 'HTTPS redirect', - detail_web_tls_https_forced_tech_table: 'Web server IP address|HTTPS redirect', - detail_web_tls_https_forced_verdict_bad: 'Your web server does offer support for both HTTP and HTTPS, but does not automatically redirect visitors from HTTP to HTTPS on the same domain.', - detail_web_tls_https_forced_verdict_good: 'Your web server automatically redirects visitors from HTTP to HTTPS on the same domain.', - detail_web_tls_https_forced_verdict_no_https: 'This test could not be performed, because your web server offers either no HTTPS or HTTPS with a very outdated, insecure TLS configuration.', - detail_web_tls_https_forced_verdict_other: 'Your web server only offers support for HTTPS and not for HTTP.', - detail_web_tls_https_hsts_exp: 'We check if your web server supports HSTS.

Browsers remember HSTS per (sub) domain. Not adding a HSTS header to every (sub) domain (in a redirect chain) might leave users vulnerable to MITM attacks. Therefore we check for HSTS on the first contact i.e. before any redirect.

HSTS forces a web browser to connect directly via HTTPS when revisiting your website. This helps preventing man-in-the-middle attacks. We consider a HSTS cache validity period of at least 1 year (max-age=31536000) to be sufficiently secure. A long period is beneficial because it also protects infrequent visitors. However if you want to stop supporting HTTPS (which is generally a poor idea), you will have to wait longer until the validity of the HSTS policy in all browsers that visited your website, has expired.

The test does not check whether preload is used and whether the domain is included in the HSTS Preload List.

Deployment recommendation

HSTS requires your website to fully work over HTTPS. This also includes having a valid certificate from a publicly trusted certificate authority. So when your website does not properly support HTTPS, note that it will not be reachable by browsers that have contacted your website before. A HSTS policy change to revert effects will not have immediate effect for these browsers since they have cached your previous HSTS policy.

Therefore we advise you to follow the implementation steps below:

  1. Make sure that the website on your domain fully works over HTTPS now and in the future (e.g. by having a solid certificate rollover procedure);

  2. Increase the HSTS cache validity period in the stages below. During each stage, carefully check for reachability issues and broken pages. Fix any issues that come up and then wait the full max-age of the stage before moving to the next stage.

  3. Start with 5 minutes (max-age=300);

  4. Increase it to 1 week (max-age=604800);
  5. Increase it to 1 month (max-age=2592000);

  6. Increase it to 1 year (max-age=31536000) or more.

  7. Repeat step 1 and 2 for every single subdomain that you want to secure with HSTS. Only use includeSubDomains if you are fully sure that all the (nested) subdomains of your domain properly support HTTPS now and in the future.

  8. Use preload only if you are very sure that you want your domain to be included in the HSTS Preload List. HSTS preloading is mostly interesting for highly sensitive websites. Administrators who want to enable HSTS preloading for a particular domain should do so with extreme caution. It can affect the reachability of the domain and of any subdomains, and is not easily reversed.

See \'Web application guidelines, detailed version\' from NCSC-NL, guideline U/WA.05 (in Dutch).', - detail_web_tls_https_hsts_label: 'HSTS', - detail_web_tls_https_hsts_tech_table: 'Web server IP address|HSTS policy', - detail_web_tls_https_hsts_verdict_bad: 'Your web server does not offer an HSTS policy.', - detail_web_tls_https_hsts_verdict_good: 'Your web server offers an HSTS policy.', - detail_web_tls_https_hsts_verdict_other: 'Your web server offers an HSTS policy with a cache validity period (max-age) that is not sufficiently long (i.e. less than 1 year).', - detail_web_tls_kex_hash_func_exp: '

We check if your web server supports secure hash functions to create the digital signature during key exchange.

The web server uses a digital signature during the key exchange to prove ownership of the secret key corresponding to the certificate. The web server creates this digital signature by signing the output of a hash function.

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

Requirement level: Recommended

SHA2 support for signatures

  • Good: Yes (SHA-256, SHA-384 or SHA-512 supported)
  • Phase out: No (SHA-256, SHA-384 of SHA-512 not supported)
', - 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 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', - detail_web_tls_ocsp_stapling_tech_table: 'Web server IP address|OCSP stapling', - detail_web_tls_ocsp_stapling_verdict_bad: 'Your web server supports OCSP stapling but the data in the response is not valid.', - detail_web_tls_ocsp_stapling_verdict_good: 'Your web server supports OCSP stapling and the data in the response is valid.', - detail_web_tls_ocsp_stapling_verdict_ok: 'Your web server does not support OCSP stapling.', - detail_web_tls_renegotiation_client_exp: '

We check if a client (usually a web browser) can initiate a renegotiation with your web server.

Allowing clients to initiate renegotiation is generally not necessary and opens a web server to DoS attacks inside a TLS connection. An attacker can perform similar DoS attacks without client-initiated renegotiation by opening many parallel TLS connections, but these are easier to detect and defend against using standard mitigations. Note that client-initiated renegotiation impacts availability and not confidentiality.

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

Requirement level: Optional

Client-initiated renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Sufficient: On
', - detail_web_tls_renegotiation_client_label: 'Client-initiated renegotiation', - detail_web_tls_renegotiation_client_tech_table: 'Web server IP address|Client-initiated renegotiation', - detail_web_tls_renegotiation_client_verdict_bad: 'Your web server allows for client-initiated renegotiation, which could have negative impact on the availability of your website.', - detail_web_tls_renegotiation_client_verdict_good: 'Your web server does not allow for client-initiated renegotiation.', - detail_web_tls_renegotiation_secure_exp: '

We check if your web server supports secure renegotiation.

Older versions of TLS (prior to TLS 1.3) allow forcing a new handshake. This so-called renegotiation was insecure in its original design. The standard was repaired and a safer renegotiation mechanism was added. The old version is since called insecure renegotiation and should be disabled.

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

Insecure renegotiation

  • Good: Off (or N/A for TLS 1.3)
  • Insufficient: On
', - detail_web_tls_renegotiation_secure_label: 'Secure renegotiation', - detail_web_tls_renegotiation_secure_tech_table: 'Web server IP address|Secure renegotiation', - detail_web_tls_renegotiation_secure_verdict_bad: 'Your web server supports insecure renegotiation, which is obviously not secure.', - detail_web_tls_renegotiation_secure_verdict_good: 'Your web server supports secure renegotiation.', - detail_web_tls_version_exp: '

We check if your web server supports secure TLS versions only.

A web server may support more than one TLS version.

Note that browser makers have announced that they will stop supporting TLS 1.1 and 1.0. This will cause websites that do not support TLS 1.2 and/or 1.3 to be unreachable.

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_web_tls_version_label: 'TLS version', - detail_web_tls_version_tech_table: 'Web server IP address|TLS version|Status', - detail_web_tls_version_verdict_bad: 'Your web server supports insufficiently secure TLS versions.', - detail_web_tls_version_verdict_good: 'Your web server supports secure TLS versions only.', - detail_web_tls_version_verdict_phase_out: 'Your web server supports TLS versions that should be phased out deliberately, because they are known to be fragile and at risk of becoming insufficiently secure.', - detail_web_tls_zero_rtt_exp: '

We check if your web server supports Zero Round Trip Time Resumption (0-RTT).

0-RTT is an option in TLS 1.3 that transports application data during the firsthandshake message. 0-RTT does not provide protection against replay attacks atthe TLS layer and therefore should be disabled. Although the risk can be mitigated by not allowing 0-RTT fornon-idempotent requests, such a configuration is often not trivial, reliant on application logic and thus error prone.

If your web server does not support TLS 1.3, the test is not applicable.For web servers that support TLS 1.3, the index / page of the website isfetched using TLS 1.3 and the amount ofearly datasupport indicated by theserver is checked. When more than zero, a second connection is made re-usingthe TLS session details of the first connection but sending theHTTP request before the TLS handshake (i.e. no round trips (0-RTT) neededbefore application data to the server). If the TLS handshake is completed andthe web server responds with anynon-HTTP 425 Too Earlyresponse, then the web server is considered to support 0-RTT.

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

0-RTT

  • Good: Off (or N/A prior to TLS 1.3)
  • Insufficient: On
', - detail_web_tls_zero_rtt_label: '0-RTT', - 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 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', - detail_web_mail_ipv6_ns_aaaa_verdict_bad: 'None of the name servers of your domain has an IPv6 address.', - detail_web_mail_ipv6_ns_aaaa_verdict_good: 'Two or more name servers of your domain have an IPv6 address.', - detail_web_mail_ipv6_ns_aaaa_verdict_other: 'Only one name server of your domain has an IPv6 address.', - detail_web_mail_ipv6_ns_reach_exp: 'We check if all name servers, that have an AAAA record with IPv6 address, are reachable over IPv6.', - detail_web_mail_ipv6_ns_reach_label: 'IPv6 reachability of name servers', - 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.', - 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.

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 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', - faqs_report_subtest_good: 'Good: pass on REQUIRED, RECOMMENDED or OPTIONAL subtest ⇒ first: full score / latter two: no score impact', - faqs_report_subtest_info: 'Informational: fail on OPTIONAL subtest ⇒ no score impact', - faqs_report_subtest_not_tested: 'Not tested, because already failed related parent subtest ⇒ null score', - faqs_report_subtest_title: 'Icons per subtest', - faqs_report_subtest_warning: 'Warning: fail on RECOMMENDED subtest ⇒ no score impact', - faqs_report_test_bad: 'Bad: failed at least one REQUIRED subtest ⇒ no full score in test category', - faqs_report_test_error: 'Test error: execution error for at least one subtest ⇒ no result in test category', - faqs_report_test_good: 'Good: passed all subtests ⇒ full score in test category', - faqs_report_test_info: 'Informational: failed at least one OPTIONAL subtest ⇒ full score in test category ', - faqs_report_test_title: 'Icons per test category', - faqs_report_test_warning: 'Warning: failed at least one RECOMMENDED subtest ⇒ full score in test category ', - faqs_report_title: 'Explanation of test report', - faqs_rpki_title: 'Authorisation for routing (RPKI)', - faqs_starttls_title: 'Secure email transport (STARTTLS and DANE)', - faqs_title: 'Knowledge base', - halloffame_champions_menu: 'Champions!', - halloffame_champions_subtitle: '100% in website and email test', - halloffame_champions_text: 'The {{count}} domains below score 100% in both the website test and the email test. Inductees of this Hall of Fame are allowed to use both 100% badges.', - halloffame_champions_title: 'Hall of Fame - Champions!', - halloffame_mail_badge: 'Badge with text: 100% score in email test', - halloffame_mail_menu: 'Email', - halloffame_mail_subtitle: '100% in email test', - halloffame_mail_text: 'The {{count}} domains below score 100% in the email test. Inductees of this Hall of Fame are allowed to use the 100% mail badge.', - halloffame_mail_title: 'Hall of Fame - Email', - halloffame_web_badge: 'Badge with text: 100% score in website test', - halloffame_web_menu: 'Websites', - halloffame_web_subtitle: '100% in website test', - halloffame_web_text: 'The {{count}} domains below score 100% in the website test. Inductees of this Hall of Fame are allowed to use the 100% website badge.', - halloffame_web_title: 'Hall of Fame - Websites', - home_pagetitle: 'Test for modern Internet Standards like IPv6, DNSSEC, HTTPS, DMARC, STARTTLS and DANE.', - home_stats_connection: 'unique connections', - home_stats_connection_items: '', - home_stats_header: 'Tests in numbers', - home_stats_mail: 'unique mail domains', - home_stats_mail_items: '', - home_stats_notpassed: '0-99%:', - home_stats_passed: '100%:', - home_stats_website: 'unique web domains', - home_stats_website_items: '', - home_teaser: 'Modern Internet Standards provide for more reliability and further growth of the Internet.
Are you using them?', - mail_pagetitle: 'Email test:', - mail_title: 'Email test: {{prettyaddr}}', - mail_tweetmessage: 'The%20mail%20server%20at%20{{report.domain}}%20scores%20{{score}}%25%20in%20the%20email%20test%20of%20%40Internet_nl%3A', - page_gotocontents: 'Go to the content', - 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 certificate, Internet Standards Platform', - page_sitedescription: 'Is your Internet up-to-date?', - page_sitetitle: 'Internet.nl', - page404_title: 'Page not found!', - probes_auto_redirect: 'You will be automatically redirected to the results page when all tests are finished.', - probes_no_javascript: 'Check if the test results are available. If not, you will be redirected here instead.', - probes_no_javascript_connection: 'JavaScript inactive. Please enable JavaScript in order to execute the test.', - probes_no_redirection: 'Test error. Please try again later, or test another domain name.', - probes_test_finished: 'Test finished! Results available...', - probes_test_running: 'Running...', - probes_tests_description: 'The items below are being tested.', - probes_tests_duration: 'The duration of the test is between 5 and {{cache_ttl}} seconds.', - results_dated_presentation: 'Dated result presentation. Please rerun the test.', - results_domain_appsecpriv_http_headers_label: 'HTTP security headers', - results_domain_appsecpriv_other_options_label: 'Other security options', - results_domain_ipv6_web_server_label: 'Web server', - results_domain_rpki_web_server_label: 'Web server', - results_domain_tls_http_headers_label: 'HTTP headers', - results_domain_tls_https_label: 'HTTP', - results_domain_tls_tls_label: 'TLS', - results_domain_mail_ipv6_name_servers_label: 'Name servers of domain', - results_domain_mail_rpki_name_servers_label: 'Name servers of domain', - results_domain_mail_tls_certificate_label: 'Certificate', - results_domain_mail_tls_dane_label: 'DANE', - results_empty_argument_alt_text: 'None', - results_explanation_label: 'Test explanation:', - results_further_testing_connection_label: 'Further connection testing', - results_further_testing_mail_label: 'Further email testing', - results_further_testing_web_label: 'Further website testing', - results_mail_auth_dkim_label: 'DKIM', - results_mail_auth_dmarc_label: 'DMARC', - results_mail_auth_spf_label: 'SPF', - results_mail_dnssec_domain_label: 'Email address domain', - results_mail_dnssec_mail_servers_label: 'Mail server domain(s)', - results_mail_ipv6_mail_servers_label: 'Mail server(s)', - results_mail_rpki_mail_servers_label: 'Mail server(s)', - results_mail_rpki_mx_name_servers_label: 'Name servers of mail server(s)', - results_mail_tls_starttls_label: 'TLS', - results_no_icon_detail_close: 'close', - results_no_icon_detail_open: 'open', - results_no_icon_status_error: 'Error', - results_no_icon_status_failed: 'Failed', - results_no_icon_status_info: 'Information', - results_no_icon_status_not_tested: 'Not testable', - results_no_icon_status_passed: 'Passed', - results_no_icon_status_warning: 'Recommendation', - results_panel_button_hide: 'Hide details', - results_panel_button_show: 'Show details', - results_perfect_score: 'Congratulations, your domain will be added to the Hall of Fame soon!', - results_permalink: 'Permalink test result {{permadate|date:\'(Y-m-d H:i T)\'}}', - results_rerun_test: 'Rerun the test', - results_retest_time: 'Seconds until retest option:', - results_score_description: 'The domain {{prettyaddr}} has a test score of {{score}}%.', - results_tech_details_label: 'Technical details:', - results_test_direct: 'Directly test:', - results_test_email_label: 'Test another email', - results_test_website_label: 'Test another website', - results_test_info: 'Explanation of test report', - results_verdict_label: 'Verdict:', - test_connipv6_failed_description: 'Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.', - test_connipv6_failed_summary: 'Modern addresses not reachable (IPv6)', - test_connipv6_info_description: 'Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.', - test_connipv6_info_summary: 'Modern addresses not reachable (IPv6)', - test_connipv6_label: 'Modern addresses reachable (IPv6)', - test_connipv6_passed_description: 'Well done! Your internet provider has provided you with a modern internet address (IPv6). Therefore you can reach other computers with modern addresses.', - test_connipv6_passed_summary: 'Modern addresses reachable (IPv6)', - test_connipv6_title: 'Modern addresses reachable?', - test_connipv6_warning_description: 'Too bad! Your internet provider has not given you a modern internet address (IPv6), or has not configured everything correctly. Therefore you are not able to reach other computers with modern addresses. Please ask your internet provider for full IPv6 connectivity.', - test_connipv6_warning_summary: 'Modern addresses not reachable (IPv6)', - test_connresolver_failed_description: 'Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.', - test_connresolver_failed_summary: 'Domain signatures not validated (DNSSEC)', - test_connresolver_info_description: 'Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.', - test_connresolver_info_summary: 'Domain signatures not validated (DNSSEC)', - test_connresolver_label: 'Domain signature validation (DNSSEC)', - test_connresolver_passed_description: 'Well done! Domain signatures (DNSSEC) are validated for you. Therefore you are protected against false translation from signed domain names into rogue IP addresses.', - test_connresolver_passed_summary: 'Domain signatures validated (DNSSEC)', - test_connresolver_title: 'Domain signatures validated?', - test_connresolver_warning_description: 'Too bad! Domain signatures (DNSSEC) are not validated for you. Therefore you are not protected against manipulated translation from signed domains into rogue IP addresses. Please ask your internet provider for DNSSEC validation and/or enable it on your own systems.', - test_connresolver_warning_summary: 'Domain signatures not validated (DNSSEC)', - test_error_summary: 'Error during test execution!', - test_mailauth_failed_description: 'Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.', - test_mailauth_failed_summary: 'Not all authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_mailauth_info_description: 'Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.', - test_mailauth_info_summary: 'Not all authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_mailauth_label: 'Authenticity marks against phishing (DMARC, DKIM and SPF)', - test_mailauth_passed_description: 'Well done! Your domain contains all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are able to reliably separate phishing and spam emails abusing your domain in their sender address, from your authentic emails. ', - test_mailauth_passed_summary: 'Authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_mailauth_title: 'Authenticity marks against email phishing?', - test_mailauth_warning_description: 'Too bad! Your domain does not contain all authenticity marks against email forgery (DMARC, DKIM and SPF). Therefore receivers are not able to reliably separate phishing and spam emails abusing your domain in their sender address from your authentic emails. You should ask your mail provider to activate DMARC, DKIM and SPF.', - test_mailauth_warning_summary: 'Not all authenticity marks against email phishing (DMARC, DKIM and SPF)', - test_maildnssec_failed_description: 'Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.', - test_maildnssec_failed_summary: 'Not all domain names signed (DNSSEC)', - test_maildnssec_info_description: 'Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.', - test_maildnssec_info_summary: 'Not all domain names signed (DNSSEC)', - test_maildnssec_label: 'Signed domain names (DNSSEC)', - test_maildnssec_passed_description: 'Well done! Your email address domain and your mail server domain(s) are signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are able to reliably query the IP address of your receiving mail server(s). ', - test_maildnssec_passed_summary: 'All domain names signed (DNSSEC)', - test_maildnssec_title: 'Domain names signed?', - test_maildnssec_warning_description: 'Too bad! Some or all of your email address and mail server domains are not signed with a valid signature (DNSSEC). Therefore senders with enabled domain signature validation, are not able to reliably query the IP address of your receiving mail server(s). An attacker could secretly manipulate the IP address and divert e-mails addressed to you to his/her own mail server. You should ask your name server operator and/or your mail provider to enable DNSSEC.', - test_maildnssec_warning_summary: 'Not all domain names signed (DNSSEC)', - test_mailipv6_failed_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_failed_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_mailipv6_info_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_info_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_mailipv6_label: 'Modern address (IPv6)', - test_mailipv6_passed_description: 'Well done! Your mail server can be reached by senders using modern
addresses (IPv6), making it fully part of the modern Internet.', - test_mailipv6_passed_summary: 'Reachable via modern internet address (IPv6)', - 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_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)', - test_mailrpki_label: 'Route authorisation (RPKI)', - 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: '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)', - test_mailtls_info_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_info_summary: 'Mail server connection not or insufficiently secured (STARTTLS and DANE)', - 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: 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 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)', - test_mailtls_null_mx_with_other_mx_description: 'Warning: 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. ', - test_mailtls_null_mx_with_other_mx_summary: 'Inconsistently configured non-receiving mail domain (STARTTLS and DANE)', - test_mailtls_null_mx_without_a_aaaa_description: 'Warning: 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.', - test_mailtls_null_mx_without_a_aaaa_summary: 'Properly configured non-receiving mail domain, though with unnecessary record (STARTTLS and DANE)', - 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 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 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. 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. 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. 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. 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)', - test_sitednssec_info_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_info_summary: 'Domain name not signed (DNSSEC)', - test_sitednssec_label: 'Signed domain name (DNSSEC)', - test_sitednssec_passed_description: 'Well done! Your domain is signed with a valid signature (DNSSEC). Therefore visitors with enabled domain signature validation, are protected against manipulated translation from your domain into rogue internet addresses.', - test_sitednssec_passed_summary: 'Domain name signed (DNSSEC)', - test_sitednssec_title: 'Domain name signed?', - test_sitednssec_warning_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_warning_summary: 'Domain name not signed (DNSSEC)', - test_siteipv6_failed_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_failed_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_siteipv6_info_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_info_summary: 'Not reachable via modern internet address, or improvement possible (IPv6)', - test_siteipv6_label: 'Modern address (IPv6)', - test_siteipv6_passed_description: 'Well done! Your website is reachable for visitors using a modern internet address (IPv6), making it fully part of the modern Internet.', - test_siteipv6_passed_summary: 'Reachable via modern internet address (IPv6)', - 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_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)', - test_siterpki_label: 'Route authorisation (RPKI)', - 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: '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)', - test_sitetls_info_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_info_summary: 'Connection not or insufficiently secured (HTTPS)', - test_sitetls_label: 'Secure connection (HTTPS)', - 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 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 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', - widget_site_intro: '

Website test widget

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

', - }, - }, -}; \ No newline at end of file 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 deleted file mode 100644 index 9f24d384..00000000 --- a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.js +++ /dev/null @@ -1,852 +0,0 @@ -const internet_nl_messages = { - nl: { - internet_nl: { - about_contact: '

Contact

Platform Internetstandaarden
p/a ECP
Maanweg 174 (8e verdieping)
2516 AB Den Haag

KvK-nummer: 27169301

E-mail

vraag@internet.nl

PGP publieke sleutel
Vingerafdruk: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Vervaldatum: 19 maart 2025

', - base_about: 'Over Internet.nl', - base_accessibility: 'Toegankelijkheid', - base_blogs: 'Blogs', - base_contact: 'Contact', - base_copyright: 'Auteursrecht', - base_disclosure: 'Kwetsbaarheid melden', - base_faqs: 'Kennisbank', - base_halloffame: 'Hall of Fame', - base_halloffame_champions: 'Hall of Fame - Kampioenen!', - base_halloffame_lead: '{{count}} domeinen met 2 x 100%
Laatste toevoeging: {{latest|date:\'d-m-Y\'}}', - base_halloffame_link: 'Naar Hall of Fame - Kampioenen!', - base_halloffame_mail: 'Hall of Fame - E-mail', - base_halloffame_web: 'Hall of Fame - Websites', - base_home: 'Home', - base_info: 'Internet.nl is een initiatief van de internetgemeenschap en de Nederlandse overheid.', - base_news: 'Nieuws', - base_newslink: 'Naar nieuwsoverzicht', - base_privacy: 'Privacyverklaring', - base_test_connection_explain: '

Wat wordt getest?

Nadat je de verbindingstest hebt gestart, testen we of de momenteel door jou gebruikte internetverbinding ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

  • IPv6: zijn websites met moderne internetadressen voor jou bereikbaar?
  • DNSSEC: worden domeinnaam-handtekeningen voor jou gecontroleerd?

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie "Toelichting op testrapport".

Hoe verbeteren?

Het testrapport kan je gebruiken om je internetverbinding te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je internetprovider. In de communicatie met je internetprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Test je verbinding

', - base_test_connection_label: 'Test je verbinding', - base_test_connection_text: 'Moderne adressen bereikbaar?
Domein-handtekeningen gecontroleerd?', - base_test_connection_title: 'Over de verbindingstest', - base_test_explain: 'Over de test', - base_test_mail_explain: '

Wat wordt getest?

Nadat je een e-mailadres hebt opgegeven, testen we of de achterliggende e-mailvoorziening ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Let op: sommige standaarden zijn zelfs relevant als je je domeinnaam niet gebruikt voor het ontvangen en verzenden van e-mail.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie "Toelichting op testrapport".

Hoe verbeteren?

Het testrapport kan je gebruiken om je e-mailvoorziening te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je e-mailprovider. In de communicatie met je e-mailprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de e-mailtest integreren in je eigen website door gebruik te maken van onze widget code.

Test je e-mail

', - base_test_mail_input: 'Jouw e-mailadres:', - base_test_mail_label: 'Test je e-mail', - base_test_mail_text: 'Modern adres? Anti-phishing? Beveiligd transport? Route-autorisatie?', - base_test_mail_title: 'Over de e-mailtest', - base_test_prechecks_invalid_domain: 'De opgegeven domeinnaam is niet geldig!
Toelichting: Een A- en/of AAAA-record is noodzakelijk voor de websitetest, en een SOA-record voor de e-mailtest.', - base_test_start: 'Start test', - base_test_website_explain: '

Wat wordt getest?

Nadat je een domeinnaam van een website heb opgegeven, testen we of de website ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie "Toelichting op testrapport". Als je website een score van 100% heeft, dan wordt deze opgenomen in de Hall of Fame.

Hoe verbeteren?

Het testrapport kan je gebruiken om je website te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je webhoster.In de communicatie met je webhoster kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de websitetest integreren in je eigen website door gebruik te maken van onze widget code.

Test je website

', - base_test_website_input: 'Jouw website-domeinnaam:', - base_test_website_label: 'Test je website', - base_test_website_text: 'Modern adres? Beveiligde verbinding? Beveiligingsopties? Route-autorisatie?', - base_test_website_title: 'Over de websitetest', - base_widget_mail: 'E-mailtest widget', - base_widget_site: 'Websitetest widget', - connection_pagetitle: 'Verbindingstest', - connection_title: 'Verbindingstest', - detail_conn_dnssec_validation_exp: 'We testen of de door jou gebruikte resolvers de DNSSEC-handtekeningen van onze domeinnaam valideren. Resolvers worden normaal gesproken geleverd door je internetprovider. Als alternatief kun je resolvers van een andere DNS provider instellen. Je kan zelfs je eigen lokaal geïnstalleerde resolver gebruiken. Hoewel validatie plaatsvindt op de resolver, kan nog steeds door een aanvaller gerommeld worden met de communicatie tussen de resolver en jouw apparaat (ook wel \'last mile\' genoemd). Het is daarom het meest veilig om zo dicht mogelijk op je apparaat te valideren (bijv. door een lokaal geïnstalleerde resolver te gebruiken), of zorg ervoor dat het kanaal tussen je resolver en je apparaat beveiligd c.q. vertrouwd is.', - detail_conn_dnssec_validation_label: 'DNSSEC-validatie', - detail_conn_dnssec_validation_tech_table: 'DNS-provider', - detail_conn_dnssec_validation_verdict_bad: 'Je bent niet beschermd door validatie van DNSSEC-handtekeningen.', - detail_conn_dnssec_validation_verdict_good: 'Je bent beschermd door validatie van DNSSEC-handtekeningen.', - detail_conn_ipv6_connection_exp: 'We testen of jouw apparaat via zijn huidige internetverbinding in staat is om direct (d.w.z. zonder DNS-vertaling) verbinding te maken met onze webserver via ons bijbehorende IPv6-adres.

Sommige browser add-ons en routers bieden functionaliteit aan voor het filteren van domeinnamen om de privacy te verbeteren of internetgebruik te beperken. Om omzeiling te voorkomen blokkeert deze functionaliteit vaak ook het direct verbinden met IP-adressen waardoor deze subtest faalt.', - detail_conn_ipv6_connection_label: 'IPv6-connectiviteit (direct)', - detail_conn_ipv6_connection_tech_table: 'Geanonimiseerd IPv6-adres|Reverse name|Internetprovider', - detail_conn_ipv6_connection_verdict_bad: 'Je bent niet in staat om computers direct op hun IPv6-adres te bereiken.', - detail_conn_ipv6_connection_verdict_good: 'Je bent in staat om computers direct op hun IPv6-adres te bereiken.', - detail_conn_ipv6_dns_conn_exp: 'We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv6. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv6-adres ophaalt.', - detail_conn_ipv6_dns_conn_label: 'IPv6-connectiviteit (via DNS)', - detail_conn_ipv6_dns_conn_verdict_bad: 'Je bent niet in staat om computers via DNS op hun IPv6-adres te bereiken.', - detail_conn_ipv6_dns_conn_verdict_good: 'Je bent in staat om computers via DNS op hun IPv6-adres te bereiken.', - detail_conn_ipv6_ipv4_conn_exp: 'We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv4. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv4-adres ophaalt.

Niveau van vereistheid: Optioneel', - detail_conn_ipv6_ipv4_conn_label: 'IPv4-connectiviteit (via DNS)', - detail_conn_ipv6_ipv4_conn_tech_table: 'Geanonimiseerd IPv4-adres|Reverse name|Internetprovider', - detail_conn_ipv6_ipv4_conn_verdict_bad: 'Je bent niet in staat om computers via DNS op hun IPv4-adres te bereiken.', - detail_conn_ipv6_ipv4_conn_verdict_good: 'Je bent in staat om computers via DNS op hun IPv4-adres te bereiken.', - detail_conn_ipv6_privacy_exp: 'We testen of je apparaat \'IPv6 Privacy Extensions for SLAAC\' (of een ander IPv6-configuratieproces dan SLAAC) gebruikt om het lekken van zijn mogelijk privacygevoelige MAC-adres naar computers waarmee het via IPv6 verbinding maakt te voorkomen.', - detail_conn_ipv6_privacy_label: 'Privacy Extensions voor IPv6', - detail_conn_ipv6_privacy_verdict_bad: 'Je gebruikt SLAAC zonder \'IPv6 Privacy Extensions\'.', - detail_conn_ipv6_privacy_verdict_good: 'Je hebt \'IPv6 Privacy Extensions\' geactiveerd (of je gebruikt geen SLAAC).', - detail_conn_ipv6_resolver_conn_exp: 'We testen of ten minste één van de door jou gebruikte DNS-resolvers in staat is om onze autoritatieve nameserver te bereiken via IPv6. Vaak levert je internetprovider de DNS-resolver(s).', - 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).

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.', - detail_mail_auth_dkim_verdict_no_email: 'Je domeinnaam ondersteunt geen DKIM-records. Echter omdat je DMARC- en SPF-records aangeven dat er geen mail vanaf je domein wordt verstuurd, is DKIM niet nodig en wordt deze subtest overgeslagen.', - detail_mail_auth_dmarc_exp: 'We testen of DMARC beschikbaar is voor jouw domein. Een ontvangendemailserver kan de DMARC-policy gebruiken om te bepalen hoe om te gaan meteen e-mail met jouw domein als verzender waarvan de authenticatie met zowelDKIM als SPF faalt, en de ontvangende mailserver kan je e-mailadres uit het DMARC-recordgebruiken om je feedbackrapporten over het authenticatieresultaat te sturen. Het hebben van meer dan één DMARC-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt. Let op: DMARC vereist dathet SPF-domein (envelope sender, d.w.z. return-path dat terugkomt inMAIL FROM) en het DKIM-domein (d=) gelijk zijn aan het verzenddomein in hetmailbericht (From:). ', - detail_mail_auth_dmarc_label: 'DMARC aanwezigheid', - 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_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. ', - detail_mail_auth_dmarc_policy_verdict_good: 'Je DMARC-policy is voldoende strikt.', - detail_mail_auth_dmarc_policy_verdict_policy: 'Je DMARC-policy is niet voldoende strikt.', - detail_mail_auth_spf_exp: 'We testen of je domeinnaam een SPF-record heeft. Een ontvangende mailserver kan de IP-adressen in je SPF-record gebruiken om de verzendende mailserver van een ontvangen e-mail met jouw domein als afzender te authenticeren. Het bijbehorende beleid kan worden gebruikt om passende actie te ondernemen als de authenticatie mislukt. Meer dan één SPF-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt.

Voor een "good practice voor domeinnamen zonder mail" zie de uitleg van de "DMARC-policy" subtest.', - detail_mail_auth_spf_label: 'SPF aanwezigheid', - detail_mail_auth_spf_tech_table: 'SPF-record', - detail_mail_auth_spf_verdict_bad: 'Je domeinnaam heeft geen geldig SPF-record.', - detail_mail_auth_spf_verdict_good: 'Je domein heeft een SPF-record.', - detail_mail_auth_spf_policy_exp: 'We controleren of de syntax van je SPF-record geldig is en of deze een voldoende strikte policy, d.w.z. ~all (softfail) of -all (hardfail), bevat om misbruik van je domein door phishers en spammers tegen te gaan. Om misbruik van je domein tegen te gaan is een liberale policy, d.w.z. +all (pass) of ?all (neutral), onvoldoende. Als all ontbreekt en er is geen redirect aanwezig in je SPF-record, dan is de default policy ?all.

We volgen ook include en redirect voor geldige SPF-records. Bovendien controleren we of je SPF-record het toegestane aantal van 10 DNS-opvragingen niet overschrijdt waardoor het geen werking meer heeft. Ieder van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.

Merk op dat als het domein onder include of redirect uit macro\'s bestaat, dan volgen we deze niet omdat we niet over de noodzakelijk informatie van een daadwerkelijke mail of mailserververbinding beschikken om de macro\'s uit te voeren. Dit betekent dat we het gevolg van macro\'s niet beoordelen. Bovendien tellen we de door macro\'s veroorzaakte DNS-opvragingen niet mee om te bepalen of het toegestane aantal DNS-opvragingen is overschreden.

Voor verzendende domeinen heeft het gebruik van ~all (softfail) in plaats van -all (fail) meestal de voorkeur. De reden hiervoor is dat wanneer de SPF-authenticatie faalt met een SPF fail, een ontvangende mailserver de verbinding al kan blokkeren zonder de DKIM-handtekening en het DMARC-beleid te evalueren. Dit kan leiden tot ten onrechte geblokkeerde mails (bijvoorbeeld wanneer mails door de ontvangende mailserver automatisch worden doorgestuurd naar een andere ontvangende mailserver). Merk op dat een getriggerde SPF softfail er nog steeds voor zorgt dat een strikte DMARC policy je domein beschermt als ook de DKIM-authenticatie faalt.

Voor domeinen zonder mail zie de good practice op uitleg van de "DMARC-policy" subtest.', - detail_mail_auth_spf_policy_label: 'SPF policy', - detail_mail_auth_spf_policy_tech_table: 'Domein|SPF-record', - detail_mail_auth_spf_policy_verdict_all: 'Je SPF-policy is niet voldoende strikt.', - detail_mail_auth_spf_policy_verdict_bad: 'Je SPF-policy is syntactisch niet correct.', - detail_mail_auth_spf_policy_verdict_good: 'Je SPF-policy is voldoende strikt.', - detail_mail_auth_spf_policy_verdict_include: 'Je SPF-policy is niet voldoende strikt. Het \'include\'-mechanisme in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.', - detail_mail_auth_spf_policy_verdict_max_lookups: 'Je SPF-policy is niet effectief omdat deze meer dan de toegestane 10 DNS-opvragingen vereist. Elk van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.', - detail_mail_auth_spf_policy_verdict_redirect: 'Je SPF-policy is niet voldoende strikt. De \'redirect modifier\' in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.', - detail_mail_dnssec_exists_exp: 'We testen of de domeinnaam in je e-mailadres, meer specifiek het SOA-record, ondertekend is met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze jouw mailserverdomeinen (MX) kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar een mailserverdomein dat onder controle is van de aanvaller.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.', - detail_mail_dnssec_exists_label: 'DNSSEC aanwezigheid', - detail_mail_dnssec_exists_tech_table: 'E-mailadresdomein|Registrar', - detail_mail_dnssec_exists_verdict_bad: 'Je e-mailadresdomein is onveilig oftewel \'insecure\', omdat het niet ondertekend is met DNSSEC.', - detail_mail_dnssec_exists_verdict_good: 'Je e-mailadresdomein is met DNSSEC ondertekend.', - detail_mail_dnssec_exists_verdict_resolver_error: 'Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.', - detail_mail_dnssec_exists_verdict_servfail: 'De nameservers van je e-mailadresdomein zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.', - detail_mail_dnssec_mx_exists_exp: 'We testen of de domeinnamen van je mailservers (MX), meer specifiek hun SOA-records, ondertekend zijn met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze de IP-adressen en DANE-records van jouw mailservers kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar IP-adressen die onder controle staan van de aanvaller óf de beveiligde mailserver-verbinding afluistert.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

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

De geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.', - detail_mail_dnssec_mx_exists_label: 'DNSSEC aanwezigheid', - detail_mail_dnssec_mx_exists_tech_table: 'Domein van mailserver (MX)|DNSSEC aanwezig', - 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: '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.', - detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error: 'Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.', - detail_mail_dnssec_mx_exists_verdict_servfail: 'De nameservers van tenminste één van je mailserverdomeinen zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je mailprovider) om dit spoedig op te lossen.', - detail_mail_dnssec_mx_valid_exp: 'We testen of de domeinen van je ontvangende mailservers (MX), meer specifiek hun SOA-records, zijn ondertekend met een geldige DNSSEC-handtekening die ze veilig oftewel \'secure\' maakt.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \'secure\' en de andere keer \'bogus\' zijn.', - detail_mail_dnssec_mx_valid_label: 'DNSSEC geldigheid', - detail_mail_dnssec_mx_valid_tech_table: 'Domein van mailserver (MX)|Status', - detail_mail_dnssec_mx_valid_verdict_bad: 'Tenminste één van de ondertekende domeinen van je mailservers is onbetrouwbaar oftewel \'bogus\', omdat zijn DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde de antwoorden van de nameservers, óf je mailserverdomein heeft serieuze DNSSEC-configuratiefouten. Dit laatste maakt je ontvangende mailserver onbereikbaar voor alle verzendende mailservers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met de nameserver-beheerder (vaak je mailprovider).', - detail_mail_dnssec_mx_valid_verdict_good: 'Al de ondertekende domeinnamen van je mailservers zijn veilig oftewel \'secure\', omdat hun DNSSEC-handtekeningen geldig zijn.', - detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo: 'Tenminste één van de domeinen van je mailservers is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.', - detail_mail_dnssec_valid_exp: 'We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \'secure\' en de andere keer \'bogus\' zijn.', - detail_mail_dnssec_valid_label: 'DNSSEC geldigheid', - detail_mail_dnssec_valid_tech_table: 'E-mailadresdomein|Status', - detail_mail_dnssec_valid_verdict_bad: 'Je e-mailadresdomein is onbetrouwbaar oftewel \'bogus\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).', - detail_mail_dnssec_valid_verdict_good: 'Je e-mailadresdomein is veilig oftewel \'secure\', omdat zijn DNSSEC-handtekening geldig is.', - detail_mail_dnssec_valid_verdict_unsupported_ds_algo: 'Je e-mailadresdomein is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.', - detail_mail_ipv6_mx_aaaa_exp: 'We testen of er tenminste één AAAA-record met IPv6-adres voor iedere ontvangende mailserver (MX) is. In het geval er geen mailserver is gedefinieerd, geven we een notificatie en we voeren andere subtesten van de mailtest die nog steeds relevant zijn gewoon uit.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.', - detail_mail_ipv6_mx_aaaa_label: 'IPv6-adressen voor mailserver(s)', - detail_mail_ipv6_mx_aaaa_tech_table: 'Mailserver (MX)|IPv6-adres|IPv4-adres', - 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 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: '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.', - 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.', - 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.

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

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 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', - detail_mail_tls_cert_hostmatch_tech_table: 'Mailserver (MX)|Niet-overeenkomende domeinen op certificaat', - detail_mail_tls_cert_hostmatch_verdict_bad: 'De domeinnaam van tenminste één van je mailservers komt niet overeen met de domeinnaam op het mailservercertificaat.', - detail_mail_tls_cert_hostmatch_verdict_good: 'De domeinnamen van al je mailservers komen overeen met de domeinnamen op je mailservercertificaten.', - detail_mail_tls_cert_pubkey_exp: '

We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
', - detail_mail_tls_cert_pubkey_label: 'Publieke sleutel van certificaat', - detail_mail_tls_cert_pubkey_tech_table: 'Mailserver (MX)|Getroffen handtekening-parameters|Status', - detail_mail_tls_cert_pubkey_verdict_bad: 'De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt onvoldoende veilige parameters.', - detail_mail_tls_cert_pubkey_verdict_good: 'De digitale handtekeningen van al je mailserver-certificaten gebruiken veilige parameters.', - detail_mail_tls_cert_pubkey_verdict_phase_out: 'De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_cert_signature_exp: '

We testen of de ondertekende fingerprint van ieder van je mailserver-certificaten is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
', - detail_mail_tls_cert_signature_label: 'Handtekening van certificaat', - detail_mail_tls_cert_signature_tech_table: 'Mailserver (MX)|Getroffen hashing-algoritme|Status', - detail_mail_tls_cert_signature_verdict_bad: 'Tenminste één van je mailserver-certificaten is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.', - detail_mail_tls_cert_signature_verdict_good: 'Al je mailserver-certificaten zijn ondertekend met een veilig algoritme voor hashing.', - detail_mail_tls_cert_trust_exp: 'We testen of we een geldige vertrouwensketen voor je mailserver-certificaten kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je ontvangende mailserver alle noodzakelijke tussenliggende certificaten presenteert.

Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.

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

Niveau van vereistheid: Optioneel', - detail_mail_tls_cert_trust_label: 'Vertrouwensketen van certificaat', - 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-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\').', - detail_mail_tls_cipher_order_verdict_good: 'Al je mailservers dwingen hun eigen cipher-voorkeur af (\'I\'), en bieden ciphers aan conform de voorgeschreven volgorde (\'II\').', - detail_mail_tls_cipher_order_verdict_na: 'Deze subtest is niet van toepassing aangezien je mailserver alleen \'Goede\' ciphers ondersteunt.', - detail_mail_tls_cipher_order_verdict_seclevel_bad: 'Tenminste één van je mailservers prefereert niet \'Goede\' boven \'Voldoende\' en dan pas \'Uit te faseren\' ciphers (\'II\').', - detail_mail_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

Tenminste een van je mailservers biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\'II-B\').', - detail_mail_tls_ciphers_exp: '

We testen of je ontvangende mailservers (MX) alleen veilige, d.w.z. \'Goede\' en/of \'Voldoende\', ciphers (ook algoritmeselecties genoemd) ondersteunen. Om te voorkomen dat we tegen \'rate limits\' van ontvangende mailservers aanlopen, bevat het testresultaat alleen de eerstgevonden getroffen algoritmeselectie.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing.

  • Vanaf TLS 1.3 omvat de term \'cipher suite\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \'cipher suite\' ambigu maakt, gebruikt NCSC de term \'algoritmeselectie\' om alle vier de functies te omvatten.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselectie. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \'Goede\', \'Voldoende\' en \'Uit te faseren\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\'. Achter iedere algoritmeselectie staat de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \'Uit te faseren\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_mail_tls_ciphers_label: 'Ciphers (Algoritmeselecties)', - detail_mail_tls_ciphers_tech_table: 'Mailserver (MX)|Eerst gevonden onveilige cipher|Status', - detail_mail_tls_ciphers_verdict_bad: 'Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige ciphers.', - detail_mail_tls_ciphers_verdict_good: 'Al je mailservers ondersteunen alleen veilige ciphers.', - detail_mail_tls_ciphers_verdict_phase_out: 'Tenminste één van je mailservers ondersteunt een of meer ciphers die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_compression_exp: '

We testen of je ontvangende mailservers (MX) TLS-compressie ondersteunen.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau
  • Onvoldoende: TLS-compressie
', - detail_mail_tls_compression_label: 'TLS-compressie', - detail_mail_tls_compression_tech_table: 'Mailserver (MX)|TLS-compressie', - detail_mail_tls_compression_verdict_bad: 'Tenminste één van je mailservers ondersteunt TLS-compressie, wat niet veilig is.', - detail_mail_tls_compression_verdict_good: 'Al je mailservers ondersteunen geen TLS-compressie.', - detail_mail_tls_dane_exists_exp: 'We testen of de nameservers van ieder van je ontvangende mailservers (MX) een of meer TLSA-records voor DANE bevatten.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het mailserver-domein.

Merk op dat de test TLSA-records van de types PKIX-TA(0) or PKIX-EE(1) negeert, omdat deze niet gebruikt dienen te worden voor ontvangende mailservers.

De test slaagt daarnaast niet als er geen DNSSEC-bewijs van \'Denial of Existence\' voor TLSA-records is. Als een ondertekend TLSA-record bestaat maar tegelijkertijd is er een \'insecure\' NXDOMAIN voor hetzelfde domein (door verkeerd werkende DNSSEC-ondertekeningssoftware), dan zal de test ook niet slagen. De laatste twee foutscenario\'s kunnen leiden tot afleveringsproblemen van aan jou gerichte e-mails door DANE-validerende mailverzenders.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, Appendix A, onder \'Certificate pinning en DANE\'.', - detail_mail_tls_dane_exists_label: 'DANE aanwezigheid', - detail_mail_tls_dane_exists_tech_table: 'Mailserver (MX)|DANE TLSA-record aanwezig', - 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.

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.', - detail_mail_tls_dane_rollover_verdict_good: 'Al je mailserver-domeinen hebben een actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.', - detail_mail_tls_dane_valid_exp: 'We testen of de DANE-fingerprints die je mailserverdomeinen presenteren geldig zijn voor je mailservercertificaten.

Met DANE kan je informatie over jouw mailservercertificaten publiceren in een speciaal DNS-record, een TLSA-record. Verzendende mailservers kunnen de certificaten nu niet alleen via de certificaatautoriteit, maar ook via de TLSA-records controleren op authenticiteit. Een verzendende mail server kan het TLSA-record ook als signaal gebruiken om alleen via STARTTLS (en niet onversleuteld) te verbinden. Als de DANE-fingerprint van een ontvangende mailserver wordt gecontroleerd door de verzendende mailserver, dan kan een actieve aanvaller die in staat is het berichtenverkeer te manipuleren de STARTTLS-encryptie niet verwijderen.', - detail_mail_tls_dane_valid_label: 'DANE geldigheid', - 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_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.', - detail_mail_tls_fs_params_verdict_good: 'Je mailserver ondersteunt voldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', - detail_mail_tls_fs_params_verdict_na: 'Deze subtest is niet van toepassing, omdat je mailservers niet Diffie-Hellman-sleuteluitwisseling ondersteunen. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.', - detail_mail_tls_fs_params_verdict_phase_out: 'Tenminste één van je mailservers ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_kex_hash_func_exp: '

We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
', - detail_mail_tls_kex_hash_func_label: 'Hashfunctie voor sleuteluitwisseling', - detail_mail_tls_kex_hash_func_tech_table: 'Mailserver (MX)|SHA-2-ondersteuning voor handtekeningen', - detail_mail_tls_kex_hash_func_verdict_good: 'Al je mailservers ondersteunen veilige hashfuncties voor sleuteluitwisseling.', - detail_mail_tls_kex_hash_func_verdict_other: 'Het was niet mogelijk om vast te stellen welke hashfunctie tenminste één van je mailservers gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).', - detail_mail_tls_kex_hash_func_verdict_phase_out: 'Ten minste één van je mailservers ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ', - detail_mail_tls_ocsp_stapling_exp: 'OUTDATED TEXT; TEST NOT USED
TODO', - detail_mail_tls_ocsp_stapling_label: 'OUTDATED TEXT; TEST NOT USED
TODO', - detail_mail_tls_ocsp_stapling_tech_table: 'OUTDATED TEXT; TEST NOT USED
Mailserver (MX)|TODO', - 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_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.', - detail_mail_tls_renegotiation_client_verdict_good: 'Al je mailservers staan geen client-initiated renegotiation toe.', - detail_mail_tls_renegotiation_secure_exp: '

We testen of je mailservers (MX) secure renegotiation ondersteunen.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \'opnieuw onderhandelen\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
', - detail_mail_tls_renegotiation_secure_label: 'Secure renegotiation', - 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_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 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: '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', - detail_mail_tls_version_verdict_bad: 'Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige TLS-versies.', - detail_mail_tls_version_verdict_good: 'Al je mailservers ondersteunen alleen veilige TLS-versies.', - detail_mail_tls_version_verdict_phase_out: 'Tenminste één van je mailservers ondersteunt een of meer TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_mail_tls_zero_rtt_exp: '

We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie geïnitieerd. De omvang van de ondersteuning voor early data zoals aangegeven door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando vóór de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
', - detail_mail_tls_zero_rtt_label: '0-RTT', - detail_mail_tls_zero_rtt_tech_table: 'Mailserver (MX)|0-RTT', - detail_mail_tls_zero_rtt_verdict_bad: 'Tenminste één van je mailservers ondersteunt 0-RTT, wat niet veilig is.', - detail_mail_tls_zero_rtt_verdict_good: 'Geen van je mailservers ondersteunen 0-RTT.', - detail_mail_tls_zero_rtt_verdict_na: 'Deze subtest is niet van toepassing aangezien je mailservers TLS 1.3 niet ondersteunen.', - detail_tech_data_bogus: 'bogus', - detail_tech_data_good: 'goed', - detail_tech_data_http_csp_has_bare_https: 'Aanbeveling: \'https:\' schema zonder specifiek hoofddomein moet niet worden gebruikt (#9).', - detail_tech_data_http_csp_has_data: 'Aanbeveling: \'data:\' schema moet niet worden gebruikt waar dat niet is toegestaan (#7).', - detail_tech_data_http_csp_has_host_without_scheme: 'Aanbeveling: Een domein zonder schema moet niet worden gebruikt (#8). ', - detail_tech_data_http_csp_has_http: 'Aanbeveling: \'http:\' schema moet niet worden gebruikt (#8).', - detail_tech_data_http_csp_has_invalid_host: 'Aanbeveling: Een wildcard (d.w.z. \'*\') of \'127.0.0.1\' moeten niet worden gebruikt (#9 en #10).', - detail_tech_data_http_csp_has_unsafe_eval: 'Aanbeveling: \'unsafe-eval\' moet niet worden gebruikt (#6).', - detail_tech_data_http_csp_has_unsafe_hashes: 'Aanbeveling: \'unsafe-hashes\' moet niet worden gebruikt (#6).', - detail_tech_data_http_csp_has_unsafe_inline: 'Aanbeveling: \'unsafe-inline\' moet niet worden gebruikt (#6).', - detail_tech_data_http_csp_missing_invalid_base_uri: 'Aanbeveling: \'base-uri\' met voldoende veilige waarde moet zijn gedefinieerd (#2).', - detail_tech_data_http_csp_missing_invalid_default_src: 'Aanbeveling: \'default-src\' met voldoende veilige waarde moet zijn gedefinieerd (#1).', - detail_tech_data_http_csp_missing_invalid_form_action: 'Aanbeveling: \'form-action\' met voldoende veilige waarde moet zijn gedefinieerd (#5).', - detail_tech_data_http_csp_missing_invalid_frame_ancestors: 'Aanbeveling: \'frame-ancestors\' met voldoende veilige waarde moet zijn gedefinieerd (#4).', - detail_tech_data_http_csp_missing_invalid_frame_src: 'Aanbeveling: \'frame-src\' (of \'child-src\' of \'default-src\' als fallback) met voldoende veilige waarde moet zijn gedefinieerd (#3).', - detail_tech_data_http_csp_no_policy_found: 'Geen CSP gevonden.', - detail_tech_data_http_csp_policy_found: 'Opgehaalde CSP-waarde: {policy}', - detail_tech_data_http_referrer_policy_bad_invalid: 'Slecht: policy-waarde is niet geldig.', - detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade: 'Slecht: \'no-referrer-when-downgrade\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_bad_origin: 'Slecht: \'origin\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin: 'Slecht: \'origin-when-cross-origin\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_bad_unsafe_url: 'Slecht: \'unsafe-url\' moet niet worden gebruikt.', - detail_tech_data_http_referrer_policy_no_policy: 'Geen Referrer-Policy gevonden.', - 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_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.', - detail_tech_data_http_securitytxt_multi_lang: 'Fout: Het veld \'Preferred-Languages\' moet niet meer dan één keer voorkomen.', - detail_tech_data_http_securitytxt_multiple_csaf_fields: 'Aanbeveling: Meerdere \'CSAF\'-velden zouden moeten worden teruggebracht tot één \'CSAF\'-veld.', - detail_tech_data_http_securitytxt_no_canonical: 'Aanbeveling: Het veld \'Canonical\' zou aanwezig moeten zijn in een ondertekend bestand.', - detail_tech_data_http_securitytxt_no_canonical_match: 'Fout: De web URI van security.txt (d.w.z. bij redirecting ten minste de laatste URI van de redirect-keten) moet worden vermeld in een \'Canonical\'-veld als dat aanwezig is.', - detail_tech_data_http_securitytxt_no_contact: 'Fout: Het veld \'Contact\' moet minstens één keer voorkomen.', - detail_tech_data_http_securitytxt_no_content_type: 'Fout: HTTP Content-Type header moet worden verstuurd.', - detail_tech_data_http_securitytxt_no_csaf_file: 'Fout: Ieder optioneel \'CSAF\'-veld moet verwijzen naar een bestand met de naam \'provider-metadata.json\'.', - detail_tech_data_http_securitytxt_no_encryption: 'Aanbeveling: Het veld \'Encryption\' zou aanwezig moeten zijn wanneer het veld \'Contact\' een e-mailadres bevat.', - detail_tech_data_http_securitytxt_no_expire: 'Fout: Het veld \'Expires\' moet aanwezig zijn.', - detail_tech_data_http_securitytxt_no_https: 'Fout: De web URI moet beginnen met \'https://\' (regel {line_no}).', - detail_tech_data_http_securitytxt_no_line_separators: 'Fout: Elke regel moet eindigen met óf een carriage return en line feed characters óf alleen een line feed character.', - detail_tech_data_http_securitytxt_no_security_txt_404: 'Fout: security.txt kon niet gevonden worden.', - detail_tech_data_http_securitytxt_no_security_txt_other: 'Fout: security.txt kon niet gevonden worden (onverwachte HTTP response code {status_code}).', - detail_tech_data_http_securitytxt_no_space: 'Fout: Veld-scheidingsteken (dubbele punt) moet worden gevolgd door een spatie (regel {line_no}).', - detail_tech_data_http_securitytxt_no_uri: 'Fout: Veldwaarde moet een URI zijn (bijv. beginnend met \'mailto:\') (regel {line_no}).', - detail_tech_data_http_securitytxt_not_signed: 'Aanbeveling: security.txt zou digitaal ondertekend moeten zijn.', - detail_tech_data_http_securitytxt_pgp_data_error: 'Fout: Ondertekende security.txt moet een correct \'ASCII-armored PGP block\' bevatten.', - detail_tech_data_http_securitytxt_pgp_error: 'Fout: Het decoderen of parsen van de ondertekende security.txt moet slagen.', - detail_tech_data_http_securitytxt_prec_ws: 'Fout: Er mag geen spatie staan voor het veld-scheidingsteken (dubbele punt) (regel {line_no}).', - detail_tech_data_http_securitytxt_requested_from: 'security.txt opgevraagd van {hostname}.', - 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 gecodeerd zijn met UTF-8 in Net-Unicode vorm.', - detail_tech_data_insecure: 'insecure', - detail_tech_data_insufficient: 'onvoldoende', - detail_tech_data_no: 'nee', - detail_tech_data_not_applicable: 'niet van toepassing', - detail_tech_data_not_reachable: 'niet bereikbaar', - detail_tech_data_not_testable: 'niet testbaar', - detail_tech_data_not_tested: 'niet getest', - detail_tech_data_phase_out: 'uit te faseren', - detail_tech_data_secure: 'secure', - detail_tech_data_sufficient: 'voldoende', - 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.

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

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.

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.

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.

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.', - detail_web_appsecpriv_http_x_frame_verdict_good: 'Je webserver biedt veilig ingestelde X-Frame-Options aan.', - detail_web_appsecpriv_http_x_xss_exp: 'OUTDATED TEXT; TEST NOT USED

We testen of je webserver een HTTP header voor X-XSS-Protection aanbiedt die een voldoende veilige waarde heeft (dat wil zeggen 1 of 1; mode=block). Deze HTTP header kan worden gebruikt om het beschermingsfilter van browsers tegen reflectieve cross-site scripting (XSS) aanvallen te activeren.

Geldige waardes voor de X-XSS-Protection header zijn:

  • 0 deactiveert het XSS-filter. Deze waarde dient NIET te worden gebruikt.
  • 1 activeert het XSS-filter. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het script opschonen en de onveilige delen verwijderen. Deze waarde is normaal gesproken de standaard-waarde (\'default\') in browsers als een website geen X-XSS-Protection header aanbiedt.
  • 1; mode=block activeert het XSS-filter én de blokkeermodus. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het antwoord blokkeren en de webpagina niet laden. Dit is de aanbevolen waarde.

Mits goed geconfigureerd kan Content-Security-Policy (CSP) vergelijkbare bescherming en meer bieden aan gebruikers van moderne webbrowsers. X-XSS-Protection biedt in dat geval nog altijd bescherming aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-XSS-Protection waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Niveau van vereistheid: Aanbevolen', - detail_web_appsecpriv_http_x_xss_label: 'OUTDATED TEXT; TEST NOT USED

X-XSS-Protection', - detail_web_appsecpriv_http_x_xss_tech_table: 'OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres|X-XSS-Protection waarde', - detail_web_appsecpriv_http_x_xss_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Je webserver biedt geen veilig ingestelde X-XSS-Protection aan.', - detail_web_appsecpriv_http_x_xss_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Je webserver biedt veilig ingestelde X-XSS-Protection aan.', - detail_web_dnssec_exists_exp: 'We testen of je domeinnaam, meer specifiek het SOA-record, ondertekend is met DNSSEC.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.', - detail_web_dnssec_exists_label: 'DNSSEC aanwezigheid', - detail_web_dnssec_exists_tech_table: 'Domein|Registrar', - detail_web_dnssec_exists_verdict_bad: 'Je domein is onveilig oftewel \'insecure\', omdat het niet ondertekend is met DNSSEC.', - detail_web_dnssec_exists_verdict_good: 'Je domein is met DNSSEC ondertekend.', - detail_web_dnssec_exists_verdict_resolver_error: 'Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.', - detail_web_dnssec_exists_verdict_servfail: 'De nameservers van je domeinnaam zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.', - detail_web_dnssec_valid_exp: 'We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer \'secure\' en de andere keer \'bogus\' zij', - detail_web_dnssec_valid_label: 'DNSSEC geldigheid', - detail_web_dnssec_valid_tech_table: 'Domein|Status', - detail_web_dnssec_valid_verdict_bad: 'Je domeinnaam is onbetrouwbaar oftewel \'bogus\', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).', - detail_web_dnssec_valid_verdict_good: 'Je domeinnaam is veilig oftewel \'secure\', omdat zijn DNSSEC-handtekening geldig is.', - detail_web_dnssec_valid_verdict_unsupported_ds_algo: 'Je domeinnaam is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.', - detail_web_ipv6_web_aaaa_exp: 'We testen of er tenminste één AAAA-record met IPv6-adres voor je webserver is.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.', - detail_web_ipv6_web_aaaa_label: 'IPv6-adressen voor webserver', - 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 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 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.', - 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.

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 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', - detail_web_tls_cert_hostmatch_tech_table: 'Webserver-IP-adres|Niet-overeenkomende domeinen op certificaat', - detail_web_tls_cert_hostmatch_verdict_bad: 'De domeinnaam van je website komt niet overeen met de domeinnaam op je websitecertificaat.', - detail_web_tls_cert_hostmatch_verdict_good: 'De domeinnaam van je website komt overeen met de domeinnaam op je websitecertificaat.', - detail_web_tls_cert_pubkey_exp: '

We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
', - detail_web_tls_cert_pubkey_label: 'Publieke sleutel van certificaat', - detail_web_tls_cert_pubkey_tech_table: 'Webserver-IP-adres|Getroffen handtekening-parameters|Status', - detail_web_tls_cert_pubkey_verdict_bad: 'De digitale handtekening van je websitecertificaat gebruikt onvoldoende veilige parameters.', - detail_web_tls_cert_pubkey_verdict_good: 'De digitale handtekening van je websitecertificaat gebruikt veilige parameters.', - detail_web_tls_cert_pubkey_verdict_phase_out: 'De digitale handtekening van je websitecertificaat gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_cert_signature_exp: '

We testen of de ondertekende fingerprint van het websitecertificaat is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
', - detail_web_tls_cert_signature_label: 'Handtekening van certificaat', - detail_web_tls_cert_signature_tech_table: 'Webserver-IP-adres|Getroffen hashing-algoritme|Status', - detail_web_tls_cert_signature_verdict_bad: 'Je websitecertificaat is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.', - detail_web_tls_cert_signature_verdict_good: 'Je websitecertificaat is ondertekend met een voldoende algoritme voor hashing.', - detail_web_tls_cert_trust_exp: 'We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je webserver alle noodzakelijke tussenliggende certificaten presenteert.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B3-4.', - detail_web_tls_cert_trust_label: 'Vertrouwensketen van certificaat', - 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-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\').', - detail_web_tls_cipher_order_verdict_good: 'Je webserver dwingt zijn eigen cipher-voorkeur af (\'I\'), en biedt ciphers aan conform de voorgeschreven volgorde (\'II\').', - detail_web_tls_cipher_order_verdict_na: 'Deze subtest is niet van toepassing aangezien je webserver alleen \'Goede\' ciphers ondersteunt.', - detail_web_tls_cipher_order_verdict_seclevel_bad: 'Je webserver prefereert niet \'Goede\' boven \'Voldoende\' en dan pas \'Uit te faseren\' ciphers (\'II\').', - detail_web_tls_cipher_order_verdict_warning: 'OUTDATED TEXT; VERDICT NOT USED

Je webserver biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau (\'II-B\').', - detail_web_tls_ciphers_exp: '

We testen of je webserver alleen veilige, d.w.z. \'Goede\' en/of \'Voldoende\', ciphers (ook algoritmeselecties genoemd) ondersteunt.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing. Een webserver kan meer dan één algoritmeselectie ondersteunen.

  • Vanaf TLS 1.3 omvat de term \'cipher suite\' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term \'cipher suite\' ambigu maakt, gebruikt NCSC de term \'algoritmeselectie\' om alle vier de functies aan te duiden.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselecties. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan \'Goede\', \'Voldoende\' en \'Uit te faseren\' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0\'. Achter iedere algoritmeselectie noemen we de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste \'Uit te faseren\' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
', - detail_web_tls_ciphers_label: 'Ciphers (Algoritmeselecties)', - detail_web_tls_ciphers_tech_table: 'Webserver-IP-adres|Getroffen ciphers|Status', - detail_web_tls_ciphers_verdict_bad: 'Je webserver ondersteunt een of meer onvoldoende veilige ciphers.', - detail_web_tls_ciphers_verdict_good: 'Je webserver ondersteunt alleen veilige ciphers.', - detail_web_tls_ciphers_verdict_phase_out: 'Je webserver ondersteunt een of meer ciphers die de status uit te faseren hebben omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_compression_exp: '

We testen of je webserver TLS-compressie ondersteunt.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
', - detail_web_tls_compression_label: 'TLS-compressie', - detail_web_tls_compression_tech_table: 'Webserver-IP-adres|TLS-compressie', - detail_web_tls_compression_verdict_bad: 'Je webserver ondersteunt TLS-compressie, wat niet veilig is.', - detail_web_tls_compression_verdict_good: 'Je webserver ondersteunt geen TLS-compressie.', - detail_web_tls_dane_exists_exp: 'We testen of de nameserver van je websitedomein een correct ondertekend TLSA-record voor DANE bevat.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het websitedomein, of als er DANE-gerelateerde DNSSEC-issues zijn (bijv. geen bewijs voor \'Denial of Existence\').

Zie \'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1\' van NCSC, Appendix A, onder \'Certificate pinning en DANE\'.

Niveau van vereistheid: Optioneel', - detail_web_tls_dane_exists_label: 'DANE aanwezigheid', - detail_web_tls_dane_exists_tech_table: 'Webserver-IP-adres|DANE TLSA-record aanwezig', - detail_web_tls_dane_exists_verdict_bad: 'Je websitedomein bevat geen TLSA-record voor DANE.', - detail_web_tls_dane_exists_verdict_bogus: 'Je websitedomein bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Vraag je nameserver-beheerder om deze fout op te lossen.', - detail_web_tls_dane_exists_verdict_good: 'Je websitedomein bevat een TLSA-record voor DANE.', - detail_web_tls_dane_rollover_exp: '

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
', - detail_web_tls_dane_rollover_label: 'OUTDATED TEXT; TEST NOT USED

DANE rollover scheme', - detail_web_tls_dane_rollover_tech_table: 'OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme', - detail_web_tls_dane_rollover_verdict_bad: 'OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.', - detail_web_tls_dane_rollover_verdict_good: 'OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.', - detail_web_tls_dane_valid_exp: 'We testen of de DANE-fingerprint die je domein presenteert geldig is voor je websitecertificaat.

Met DANE kan je informatie over jouw websitecertificaat publiceren in een speciaal DNS-record, een TLSA-record. Clients, zoals webbrowsers, kunnen het certificaat nu niet alleen via de certificaatautoriteit, maar ook via het TLSA-record controleren op authenticiteit. Een client kan het TLSA-record ook als signaal gebruiken om alleen via HTTPS (en niet via HTTP) te verbinden. DNSSEC is een noodzakelijke randvoorwaarde voor DANE. Helaas ondersteunen nog niet veel webbrowsers DANE-validatie.

Niveau van vereistheid: Aanbevolen (alleen als subtest voor \'DANE aanwezigheid\' is geslaagd)', - detail_web_tls_dane_valid_label: 'DANE geldigheid', - 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_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.', - detail_web_tls_fs_params_verdict_good: 'Je webserver ondersteunt veilige parameters voor Diffie-Hellman-sleuteluitwisseling.', - detail_web_tls_fs_params_verdict_na: 'Deze subtest is niet van toepassing, omdat je webserver niet Diffie-Hellman-sleuteluitwisseling ondersteunt. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.', - detail_web_tls_fs_params_verdict_phase_out: 'Je webserver ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_http_compression_exp: '

We testen of je webserver HTTP-compressie ondersteunt.

Bij het HTTP-protocol wordt compressie vaak gebruikt om de beschikbare bandbreedte efficiënter te gebruiken. HTTP-compressie maakt de beveiligde verbinding met je webserver echter kwetsbaar voor de BREACH-aanval. Weeg de voors en tegens van HTTP-compressie zorgvuldig tegen elkaar af. Wanneer u kiest voor het gebruik van HTTP-compressie, ga dan na of het mogelijk is om hieruit voortvloeiende potentiële applicatie-aanvallen te beperken. Een voorbeeld van een dergelijke maatregel is het beperken van de mate waarin een aanvaller de respons van de server kan beïnvloeden.

Dit testonderdeel controleert of de webserver op rootdirectory-niveau HTTP-compressie ondersteunt, maar controleert geen andere websitebronnen zoals plaatje en scripts.

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

Niveau van vereistheid: Optioneel

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
', - detail_web_tls_http_compression_label: 'HTTP-compressie', - 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.

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.', - detail_web_tls_https_exists_verdict_good: 'Je website biedt HTTPS aan.', - detail_web_tls_https_exists_verdict_other: 'Je webserver is niet bereikbaar.', - detail_web_tls_https_forced_exp: 'We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf \'upgraden\' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie \'Webapplicatie-richtlijnen, Verdieping\' van NCSC, richtlijn U/WA.05.', - detail_web_tls_https_forced_label: 'HTTPS-doorverwijzing', - detail_web_tls_https_forced_tech_table: 'Webserver-IP-adres|HTTPS-doorverwijzing', - detail_web_tls_https_forced_verdict_bad: 'Je webserver ondersteunt zowel HTTP als HTTPS, maar verwijst bezoekers niet automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.', - detail_web_tls_https_forced_verdict_good: 'Je webserver verwijst bezoekers automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.', - detail_web_tls_https_forced_verdict_no_https: 'Deze test is niet uitgevoerd, omdat je webserver geen HTTPS biedt of alleen HTTPS met een te verouderde, onveilige TLS-configuratie.', - detail_web_tls_https_forced_verdict_other: 'Je webserver biedt alleen ondersteuning voor HTTPS en niet voor HTTP.', - detail_web_tls_https_hsts_exp: 'We testen of je webserver HSTS ondersteunt.

Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.

HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt man-in-the-middle-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van tenminste 1 jaar (max-age=31536000) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen.

De test controleert niet of preload wordt gebruikt en of het domein is opgenomen in de HSTS Preload Lijst.

Aanbevelingen voor implementatie

HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze niet bereikbaar zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen.

Daarom adviseren we u om de onderstaande implementatiestappen te volgen:

  1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);

  2. Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina\'s. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.

  3. Begin met 5 minuten (max-age=300);

  4. Verhoog dit naar 1 week (max-age=604800);
  5. Verhoog dit naar 1 maand (max-age=2592000);

  6. Verhoog het naar 1 jaar (max-age=31536000) of meer.

  7. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik includeSubDomains alleen als je er volledig zeker van bent dat alle (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.

  8. Gebruik preload alleen als je heel zeker weet dat je je domein wil laten opnemen in de HSTS Preload Lijst. HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien.

Zie \'Webapplicatie-richtlijnen, Verdieping\' van NCSC, richtlijn U/WA.05.', - detail_web_tls_https_hsts_label: 'HSTS', - detail_web_tls_https_hsts_tech_table: 'Webserver-IP-adres|HSTS-policy', - detail_web_tls_https_hsts_verdict_bad: 'Je webserver biedt geen HSTS-policy aan.', - detail_web_tls_https_hsts_verdict_good: 'Je webserver biedt een HSTS-policy aan.', - detail_web_tls_https_hsts_verdict_other: 'Je webserver biedt een HSTS-policy aan met een geldigheidsduur voor caching (max-age) die niet voldoende lang (d.w.z. korter dan 1 jaar) is.', - detail_web_tls_kex_hash_func_exp: '

We testen of je webserver ondersteuning biedt voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

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

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
', - detail_web_tls_kex_hash_func_label: 'Hashfunctie voor sleuteluitwisseling', - detail_web_tls_kex_hash_func_tech_table: 'Webserver-IP-adress|SHA-2-ondersteuning voor handtekeningen', - detail_web_tls_kex_hash_func_verdict_good: 'Je webserver ondersteunt een veilige hashfunctie voor sleuteluitwisseling.', - detail_web_tls_kex_hash_func_verdict_other: 'Het was niet mogelijk om vast te stellen welke hashfunctie je webserver gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).', - detail_web_tls_kex_hash_func_verdict_phase_out: 'Je webserver ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ', - detail_web_tls_ocsp_stapling_exp: '

We testen of je webserver de TLS Certificate Status extension of te wel OCSP stapling ondersteunt.

De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.

Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifiëren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.

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

Niveau van vereistheid: Optioneel

OCSP stapling

  • Goed: Aan
  • Voldoende: Uit
', - detail_web_tls_ocsp_stapling_label: 'OCSP stapling', - detail_web_tls_ocsp_stapling_tech_table: 'Webserver-IP-adres|OCSP stapling', - 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_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.', - detail_web_tls_renegotiation_client_verdict_good: 'Je webserver staat geen client-initiated renegotiation toe.', - detail_web_tls_renegotiation_secure_exp: '

We testen of je webserver secure renegotiation ondersteunt.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten \'opnieuw onderhandelen\' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
', - detail_web_tls_renegotiation_secure_label: 'Secure renegotiation', - detail_web_tls_renegotiation_secure_tech_table: 'Webserver-IP-adres|Secure renegotiation', - detail_web_tls_renegotiation_secure_verdict_bad: 'Je webserver ondersteunt insecure renegotiation, wat uiteraard niet veilig is.', - detail_web_tls_renegotiation_secure_verdict_good: 'Je webserver ondersteunt secure renegotiation.', - detail_web_tls_version_exp: '

We testen of je webserver alleen veilige TLS-versies ondersteunt.

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

Merk op dat browsermakers hebben aangekondigd dat ze zullen stoppen met de ondersteuning van TLS 1.1 en 1.0. Daardoor zullen websites die geen TLS 1.2 en/of 1.3 ondersteunen onbereikbaar worden.

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_web_tls_version_label: 'TLS-versie', - detail_web_tls_version_tech_table: 'Webserver-IP-adres|TLS-versie|Status', - detail_web_tls_version_verdict_bad: 'Je webserver ondersteunt onvoldoende veilige TLS-versies.', - detail_web_tls_version_verdict_good: 'Je webserver ondersteunt alleen veilige TLS-versies.', - detail_web_tls_version_verdict_phase_out: 'Je webserver ondersteunt TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.', - detail_web_tls_zero_rtt_exp: '

We testen of je webserver Zero Round Trip Time Resumption (0-RTT) ondersteunt.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina / opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor early data zoals aangegeven door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging vóór de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-HTTP 425 Too Early, dan wordt aangenomen dat de webserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
', - detail_web_tls_zero_rtt_label: '0-RTT', - detail_web_tls_zero_rtt_tech_table: 'Webserver-IP-adres|0-RTT', - detail_web_tls_zero_rtt_verdict_bad: 'Je webserver ondersteunt 0-RTT, wat niet veilig is.', - detail_web_tls_zero_rtt_verdict_good: 'Je webserver ondersteunt geen 0-RTT.', - detail_web_tls_zero_rtt_verdict_na: 'Deze subtest is niet van toepassing aangezien je webserver TLS 1.3 niet ondersteunt. ', - detail_web_mail_ipv6_ns_aaaa_exp: 'We testen of je domeinnaam tenminste twee nameservers met een IPv6-adres heeft.

Dit sluit aan bij de "Technische eisen voor registratie en gebruik van .nl-domeinnamen" d.d. 13 november 2017 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.

\'IPv4-mapped IPv6 addresses\' (RFC 4291, beginnend met ::ffff:) zullen falen in deze test, aangezien zij geen IPv6-connectiviteit bieden.', - detail_web_mail_ipv6_ns_aaaa_label: 'IPv6-adressen voor nameservers', - detail_web_mail_ipv6_ns_aaaa_tech_table: 'Nameserver|IPv6-adres|IPv4-adres', - detail_web_mail_ipv6_ns_aaaa_verdict_bad: 'Geen van de nameservers van je domeinnaam heeft een IPv6-adres.', - detail_web_mail_ipv6_ns_aaaa_verdict_good: 'Twee of meer nameservers van je domeinnaam hebben een IPv6-adres.', - detail_web_mail_ipv6_ns_aaaa_verdict_other: 'Slechts één nameserver van je domeinnaam heeft een IPv6-adres.', - detail_web_mail_ipv6_ns_reach_exp: 'We testen of alle nameservers, die een AAAA-record met IPv6-adres hebben, bereikbaar zijn via IPv6.', - detail_web_mail_ipv6_ns_reach_label: 'IPv6-bereikbaarheid van nameservers', - 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.', - 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.

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 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', - faqs_report_subtest_good: 'Goed: geslaagd voor VEREISTE, AANBEVOLEN of OPTIONELE subtest ⇒ eerste: volledige score / laatste twee: geen impact op score', - faqs_report_subtest_info: 'Ter informatie: gezakt voor OPTIONELE subtest ⇒ geen impact op score', - faqs_report_subtest_not_tested: 'Niet getest, want al gezakt voor gerelateerde bovenliggende subtest ⇒ nulscore', - faqs_report_subtest_title: 'Iconen per subtest', - faqs_report_subtest_warning: 'Waarschuwing: gezakt voor AANBEVOLEN subtest ⇒ geen impact op score', - faqs_report_test_bad: 'Slecht: gezakt voor tenminste één VEREISTE subtest ⇒ geen volledige score voor testcategorie', - faqs_report_test_error: 'Testfout: uitvoeringsfout voor tenminste één subtest ⇒ geen resultaat voor testcategorie', - faqs_report_test_good: 'Goed: geslaagd voor alle subtesten ⇒ volledige score voor testcategorie ', - faqs_report_test_info: 'Ter informatie: gezakt voor tenminste één OPTIONELE subtest ⇒ volledige score voor testcategorie', - faqs_report_test_title: 'Iconen per testcategorie', - faqs_report_test_warning: 'Waarschuwing: gezakt voor tenminste één AANBEVOLEN subtest ⇒ volledige score voor testcategorie ', - faqs_report_title: 'Toelichting op testrapport', - faqs_rpki_title: 'Autorisatie voor routering (RPKI)', - faqs_starttls_title: 'Beveiligd e-mailtransport (STARTTLS en DANE)', - faqs_title: 'Kennisbank', - halloffame_champions_menu: 'Kampioenen!', - halloffame_champions_subtitle: '100% in website- én e-mailtest', - halloffame_champions_text: 'De {{count}} onderstaande domeinnamen scoren 100% in zowel de websitetest als de e-mailtest. Leden van deze Hall of Fame mogen beide 100%-badges gebruiken.', - halloffame_champions_title: 'Hall of Fame - Kampioenen!', - halloffame_mail_badge: 'Badge met tekst: 100%-score in e-mailtest', - halloffame_mail_menu: 'E-mail', - halloffame_mail_subtitle: '100% in e-mailtest', - halloffame_mail_text: 'De {{count}} onderstaande domeinnamen scoren 100% in de e-mailtest. Leden van deze Hall of Fame mogen de 100%-badge voor mail gebruiken.', - halloffame_mail_title: 'Hall of Fame - E-mail', - halloffame_web_badge: 'Badge met tekst: 100%-score in websitetest', - halloffame_web_menu: 'Websites', - halloffame_web_subtitle: '100% in websitetest', - halloffame_web_text: 'De {{count}} onderstaande domeinnamen scoren 100% in de websitetest. Leden van deze Hall of Fame mogen de 100%-badge voor websites gebruiken.', - halloffame_web_title: 'Hall of Fame - Websites', - home_pagetitle: 'Test voor moderne Internetstandaarden zoals IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE.', - home_stats_connection: 'unieke verbindingen', - home_stats_connection_items: '', - home_stats_header: 'Tests in cijfers', - home_stats_mail: 'unieke mail-domeinen', - home_stats_mail_items: '', - home_stats_notpassed: '0-99%:', - home_stats_passed: '100%:', - home_stats_website: 'unieke web-domeinen', - home_stats_website_items: '', - home_teaser: 'Moderne Internetstandaarden zorgen voor meer betrouwbaarheid en verdere groei van het Internet.
Gebruik jij ze al?', - mail_pagetitle: 'E-mailtest:', - mail_title: 'E-mailtest: {{prettyaddr}}', - mail_tweetmessage: 'De%20mailserver%20op%20{{report.domain}}%20scoort%20{{score}}%25%20in%20de%20e-mailtest%20van%20%40Internet_nl%3A', - page_gotocontents: 'Ga naar tekst-inhoud', - page_gotofooter: 'Ga naar de footer', - page_gotomainmenu: 'Ga naar het hoofd-menu', - page_metadescription: 'Test voor moderne Internetstandaarden IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI en security.txt', - page_metakeywords: 'IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, testtool, testen, check, controle, internet, internetstandaarden, open standaarden, moderne standaarden, beveiliging, security, internetbeveiliging, mail, e-mailbeveiliging, website, websitebeveiliging, internetverbinding, beveiligde verbinding, e-mailauthenticatie, encryptie, versleuteling, ciphers, cipher suites, PKI, SSL certificaat, TLS certificaat, websitecertificaat, Platform Internetstandaarden', - page_sitedescription: 'Is jouw internet up-to-date?', - page_sitetitle: 'Internet.nl', - page404_title: 'Pagina niet gevonden!', - probes_auto_redirect: 'Als de test gereed is, word je automatisch doorgestuurd naar de resultaatpagina.', - probes_no_javascript: 'Controleer of de testresultaten beschikbaar zijn. Zo niet, dan word je automatisch teruggeleid naar deze pagina.', - probes_no_javascript_connection: 'JavaScript inactief. Activeer JavaScript om de test toch uit te kunnen voeren.', - probes_no_redirection: 'Testfout. Probeer het later opnieuw, of test een andere domeinnaam.', - probes_test_finished: 'Test klaar! Resultaten beschikbaar...', - probes_test_running: 'Bezig...', - probes_tests_description: 'De onderstaande onderdelen worden getest.', - probes_tests_duration: 'Het testen duurt tussen de 5 en {{cache_ttl}} seconden.', - results_dated_presentation: 'Oude resultaatpresentatie. Doe de test opnieuw.', - results_domain_appsecpriv_http_headers_label: 'HTTP security headers', - results_domain_appsecpriv_other_options_label: 'Andere beveiligingsopties', - results_domain_ipv6_web_server_label: 'Webserver', - results_domain_rpki_web_server_label: 'Webserver', - results_domain_tls_http_headers_label: 'HTTP headers', - results_domain_tls_https_label: 'HTTP', - results_domain_tls_tls_label: 'TLS', - results_domain_mail_ipv6_name_servers_label: 'Nameservers van domein', - results_domain_mail_rpki_name_servers_label: 'Nameservers van domein', - results_domain_mail_tls_certificate_label: 'Certificaat', - results_domain_mail_tls_dane_label: 'DANE', - results_empty_argument_alt_text: 'Geen', - results_explanation_label: 'Testuitleg:', - results_further_testing_connection_label: 'Aanvullende verbindingstesten', - results_further_testing_mail_label: 'Aanvullende e-mailtesten', - results_further_testing_web_label: 'Aanvullende websitetesten', - results_mail_auth_dkim_label: 'DKIM', - results_mail_auth_dmarc_label: 'DMARC', - results_mail_auth_spf_label: 'SPF', - results_mail_dnssec_domain_label: 'E-mailadresdomein', - results_mail_dnssec_mail_servers_label: 'Mailserverdomein(en)', - results_mail_ipv6_mail_servers_label: 'Mailserver(s)', - results_mail_rpki_mail_servers_label: 'Mailserver(s)', - results_mail_rpki_mx_name_servers_label: 'Nameservers van mailserver(s)', - results_mail_tls_starttls_label: 'TLS', - results_no_icon_detail_close: 'sluit', - results_no_icon_detail_open: 'open', - results_no_icon_status_error: 'Error', - results_no_icon_status_failed: 'Gezakt', - results_no_icon_status_info: 'Informatie', - results_no_icon_status_not_tested: 'Niet-testbaar', - results_no_icon_status_passed: 'Geslaagd', - results_no_icon_status_warning: 'Suggestie', - results_panel_button_hide: 'Verberg details', - results_panel_button_show: 'Toon details', - results_perfect_score: 'Gefeliciteerd, je domeinnaam wordt spoedig in de Hall of Fame opgenomen!', - results_permalink: 'Permalink testresultaat {{permadate|date:\'(Y-m-d H:i T)\'}}', - results_rerun_test: 'Herhaal de test', - results_retest_time: 'Seconden tot hertest-mogelijkheid:', - results_score_description: 'Het domein {{prettyaddr}} heeft een testscore van {{score}}%.', - results_tech_details_label: 'Technische details:', - results_test_direct: 'Test direct:', - results_test_email_label: 'Test andere e-mail', - results_test_website_label: 'Test andere website', - results_test_info: 'Toelichting op testrapport', - results_verdict_label: 'Uitslag:', - test_connipv6_failed_description: 'Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.', - test_connipv6_failed_summary: 'Moderne adressen niet bereikbaar (IPv6)', - test_connipv6_info_description: 'Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.', - test_connipv6_info_summary: 'Moderne adressen niet bereikbaar (IPv6)', - test_connipv6_label: 'Moderne adressen bereikbaar (IPv6)', - test_connipv6_passed_description: 'Goed gedaan! Je internetprovider heeft je een modern internetadres (IPv6) gegeven. Daardoor kan je andere computers met moderne adressen bereiken.', - test_connipv6_passed_summary: 'Moderne adressen bereikbaar (IPv6)', - test_connipv6_title: 'Moderne adressen bereikbaar?', - test_connipv6_warning_description: 'Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.', - test_connipv6_warning_summary: 'Moderne adressen niet bereikbaar (IPv6)', - test_connresolver_failed_description: 'Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.', - test_connresolver_failed_summary: 'Domein-handtekeningen niet gecontroleerd (DNSSEC)', - test_connresolver_info_description: 'Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.', - test_connresolver_info_summary: 'Domein-handtekeningen niet gecontroleerd (DNSSEC)', - test_connresolver_label: 'Controle van domein-handtekeningen (DNSSEC)', - test_connresolver_passed_description: 'Goed gedaan! Domein-handtekeningen (DNSSEC) worden voor jou gecontroleerd. Daardoor ben je beschermd tegen vervalste vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen.', - test_connresolver_passed_summary: 'Domein-handtekeningen gecontroleerd (DNSSEC)', - test_connresolver_title: 'Domein-handtekeningen gecontroleerd?', - test_connresolver_warning_description: 'Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.', - test_connresolver_warning_summary: 'Domein-handtekeningen niet gecontroleerd (DNSSEC)', - test_error_summary: 'Fout tijdens uitvoering van test!', - test_mailauth_failed_description: 'Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.', - test_mailauth_failed_summary: 'Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_mailauth_info_description: 'Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.', - test_mailauth_info_summary: 'Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_mailauth_label: 'Echtheidswaarmerken tegen phishing (DMARC, DKIM en SPF)', - test_mailauth_passed_description: 'Goed gedaan! Je domein bevat alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails.', - test_mailauth_passed_summary: 'Echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_mailauth_title: 'Echtheidswaarmerken tegen e-mailphishing?', - test_mailauth_warning_description: 'Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.', - test_mailauth_warning_summary: 'Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)', - test_maildnssec_failed_description: 'Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.', - test_maildnssec_failed_summary: 'Niet alle domeinnamen ondertekend (DNSSEC)', - test_maildnssec_info_description: 'Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.', - test_maildnssec_info_summary: 'Niet alle domeinnamen ondertekend (DNSSEC)', - test_maildnssec_label: 'Ondertekende domeinnamen (DNSSEC)', - test_maildnssec_passed_description: 'Goed gedaan! Je e-mailadresdomein en je mailserverdomein(en) zijn ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen daardoor betrouwbaar het IP-adres van je ontvangende mailserver(s) opvragen.', - test_maildnssec_passed_summary: 'Alle domeinnamen ondertekend (DNSSEC)', - test_maildnssec_title: 'Domeinnamen ondertekend?', - test_maildnssec_warning_description: 'Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.', - test_maildnssec_warning_summary: 'Niet alle domeinnamen ondertekend (DNSSEC)', - test_mailipv6_failed_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_failed_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_mailipv6_info_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_info_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_mailipv6_label: 'Modern adres (IPv6)', - test_mailipv6_passed_description: 'Goed gedaan! Je mailserver is bereikbaar voor verzenders met moderne adressen (IPv6). Daardoor is je mailserver volledig onderdeel van het moderne Internet.', - test_mailipv6_passed_summary: 'Bereikbaar via modern internetadres (IPv6)', - 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_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)', - test_mailrpki_label: 'Route-autorisatie (RPKI)', - 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: '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)', - test_mailtls_info_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_info_summary: 'Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)', - 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: 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 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)', - test_mailtls_null_mx_with_other_mx_description: 'Waarschuwing: 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.', - test_mailtls_null_mx_with_other_mx_summary: 'Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)', - test_mailtls_null_mx_without_a_aaaa_description: 'Waarschuwing: 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.', - test_mailtls_null_mx_without_a_aaaa_summary: 'Goed geconfigureerd niet-ontvangend mail domein, maar met overbodig record (STARTTLS en DANE)', - test_mailtls_passed_description: 'Goed gedaan! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) een beveiligde verbinding opzetten. STARTTLS voorkomt dat passieve aanvallers e-mails onderweg naar jou kunnen lezen. DANE beschermt tegen actieve aanvallers, die door manipulatie van het mailverkeer de STARTTLS-encryptie kunnen verwijderen.', - test_mailtls_passed_summary: 'Mailserver-verbinding voldoende beveiligd (STARTTLS en DANE)', - test_mailtls_title: 'Beveiligde mailserver-verbinding?', - test_mailtls_unreachable_description: 'Testfout: tenminste één van jouw ontvangende mailservers was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw mailserver(s).', - test_mailtls_unreachable_summary: 'Onbereikbare ontvangende mailserver (STARTTLS en DANE)', - test_mailtls_untestable_description: 'Testfout: tenminste één van jouw ontvangende mailservers was niet testbaar voor ons. Daardoor was het niet mogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door onder meer SMTP errors en geactiveerde ratelimiting-maatregelen die verbindingen tegenhouden.', - 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. 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. 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. 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. 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)', - test_sitednssec_info_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_info_summary: 'Domeinnaam niet ondertekend (DNSSEC)', - test_sitednssec_label: 'Ondertekende domeinnaam (DNSSEC)', - test_sitednssec_passed_description: 'Goed gedaan! Je domeinnaam is ondertekend met een geldige handtekening (DNSSEC). Daardoor zijn bezoekers die controle van domein-handtekeningen geactiveerd hebben, beschermd tegen gemanipuleerde vertaling van jouw domeinnaam naar kwaadaardige internetadressen.', - test_sitednssec_passed_summary: 'Domeinnaam ondertekend (DNSSEC)', - test_sitednssec_title: 'Domeinnaam ondertekend?', - test_sitednssec_warning_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_warning_summary: 'Domeinnaam niet ondertekend (DNSSEC)', - test_siteipv6_failed_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_failed_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_siteipv6_info_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_info_summary: 'Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)', - test_siteipv6_label: 'Modern adres (IPv6)', - test_siteipv6_passed_description: 'Goed gedaan! Je website is bereikbaar voor bezoekers die een moderne internetadres (IPv6) gebruiken, en daardoor volledig onderdeel van het moderne internet.', - test_siteipv6_passed_summary: 'Bereikbaar via moderne internetadres (IPv6)', - 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_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)', - test_siterpki_label: 'Route-autorisatie (RPKI)', - 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: '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)', - test_sitetls_info_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_info_summary: 'Verbinding niet of onvoldoende beveiligd (HTTPS)', - test_sitetls_label: 'Beveiligde verbinding (HTTPS)', - test_sitetls_passed_description: 'Goed gedaan! De verbinding met je website is voldoende beveiligd (HTTPS). Gegevens die onderweg zijn tussen je website en haar bezoekers, zijn daardoor beschermd tegen afluisteren en manipulatie.', - test_sitetls_passed_summary: 'Verbinding voldoende beveiligd (HTTPS)', - test_sitetls_title: 'Beveiligde verbinding?', - test_sitetls_unreachable_description: 'Je webserver was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor HTTPS (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw webserver.', - test_sitetls_unreachable_summary: 'Onbereikbare webserver (HTTPS)', - test_sitetls_warning_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_warning_summary: 'Verbinding niet of onvoldoende beveiligd (HTTPS)', - widget_content_notes: '

Opmerkingen

  • Logo: We raden aan om ons logo op je eigen webserver op te slaan en te gebruiken. Op die manier is er geen contact met onze webserver als je website wordt bezocht.
  • Content-Security-Policy (CSP): Indien je op je website gebruikmaakt van CSP, dan zou je internet.nl moeten toevoegen aan de regels voor form-action en eventueel ook voor img-src als je linkt naar het logo op onze webserver.
', - widget_mail_html_block: 'Test je e-mail', - widget_mail_intro: '

E-mailtest widget

Wil je dat bezoekers van jouw website direct een e-mailtest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

', - widget_site_html_block: 'Test je website', - widget_site_intro: '

Websitetest widget

Wil je dat bezoekers van jouw website direct een websitetest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

', - }, - }, -}; \ No newline at end of file diff --git a/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json new file mode 100644 index 00000000..85e475e5 --- /dev/null +++ b/dashboard/internet_nl_dashboard/static/js/translations/internet_nl.nl.json @@ -0,0 +1,1017 @@ +{ + "about_contact": "

Contact

Platform Internetstandaarden
p/a ECP
Maanweg 174 (8e verdieping)
2516 AB Den Haag

KvK-nummer: 27169301

E-mail

vraag@internet.nl

PGP publieke sleutel
Vingerafdruk: ACB7 8829 4C7E 12BA E922 8C60 D894 E15F 4502 8563
Vervaldatum: 19 maart 2025

", + "base_about": "Over Internet.nl", + "base_accessibility": "Toegankelijkheid", + "base_blogs": "Blogs", + "base_contact": "Contact", + "base_copyright": "Auteursrecht", + "base_disclosure": "Kwetsbaarheid melden", + "base_faqs": "Kennisbank", + "base_halloffame": "Hall of Fame", + "base_halloffame_champions": "Hall of Fame - Kampioenen!", + "base_halloffame_lead": "{{count}} domeinen met 2 x 100%
Laatste toevoeging: {{latest|date:'d-m-Y'}}", + "base_halloffame_link": "Naar Hall of Fame - Kampioenen!", + "base_halloffame_mail": "Hall of Fame - E-mail", + "base_halloffame_web": "Hall of Fame - Websites", + "base_home": "Home", + "base_info": "Internet.nl is een initiatief van de internetgemeenschap en de Nederlandse overheid.", + "base_news": "Nieuws", + "base_newslink": "Naar nieuwsoverzicht", + "base_privacy": "Privacyverklaring", + "base_test_connection_explain": "

Wat wordt getest?

Nadat je de verbindingstest hebt gestart, testen we of de momenteel door jou gebruikte internetverbinding ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

  • IPv6: zijn websites met moderne internetadressen voor jou bereikbaar?
  • DNSSEC: worden domeinnaam-handtekeningen voor jou gecontroleerd?

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\".

Hoe verbeteren?

Het testrapport kan je gebruiken om je internetverbinding te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je internetprovider. In de communicatie met je internetprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Test je verbinding

", + "base_test_connection_label": "Test je verbinding", + "base_test_connection_text": "Moderne adressen bereikbaar?
Domein-handtekeningen gecontroleerd?", + "base_test_connection_title": "Over de verbindingstest", + "base_test_explain": "Over de test", + "base_test_mail_explain": "

Wat wordt getest?

Nadat je een e-mailadres hebt opgegeven, testen we of de achterliggende e-mailvoorziening ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Let op: sommige standaarden zijn zelfs relevant als je je domeinnaam niet gebruikt voor het ontvangen en verzenden van e-mail.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\".

Hoe verbeteren?

Het testrapport kan je gebruiken om je e-mailvoorziening te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je e-mailprovider. In de communicatie met je e-mailprovider kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de e-mailtest integreren in je eigen website door gebruik te maken van onze widget code.

Test je e-mail

", + "base_test_mail_input": "Jouw e-mailadres:", + "base_test_mail_label": "Test je e-mail", + "base_test_mail_text": "Modern adres? Anti-phishing? Beveiligd transport? Route-autorisatie?", + "base_test_mail_title": "Over de e-mailtest", + "base_test_prechecks_invalid_domain": "De opgegeven domeinnaam is niet geldig!
Toelichting: Een A- en/of AAAA-record is noodzakelijk voor de websitetest, en een SOA-record voor de e-mailtest.", + "base_test_start": "Start test", + "base_test_website_explain": "

Wat wordt getest?

Nadat je een domeinnaam van een website heb opgegeven, testen we of de website ondersteuning biedt voor de onderstaande moderne Internetstandaarden.

Testrapport?

Nadat de test is afgerond, wordt een testrapport getoond. Dit rapport bevat een procentuele totaalscore en resultaten per testonderdeel en subtest. Voor meer informatie zie \"Toelichting op testrapport\". Als je website een score van 100% heeft, dan wordt deze opgenomen in de Hall of Fame.

Hoe verbeteren?

Het testrapport kan je gebruiken om je website te verbeteren. Meestal kan je hiervoor het beste contact opnemen met je webhoster.In de communicatie met je webhoster kan je de permalink (oftewel de URL) van het testrapport gebruiken.

Widget

Je kan de websitetest integreren in je eigen website door gebruik te maken van onze widget code.

Test je website

", + "base_test_website_input": "Jouw website-domeinnaam:", + "base_test_website_label": "Test je website", + "base_test_website_text": "Modern adres? Beveiligde verbinding? Beveiligingsopties? Route-autorisatie?", + "base_test_website_title": "Over de websitetest", + "base_widget_mail": "E-mailtest widget", + "base_widget_site": "Websitetest widget", + "connection_pagetitle": "Verbindingstest", + "connection_title": "Verbindingstest", + "detail_conn_dnssec_validation_exp": "We testen of de door jou gebruikte resolvers de DNSSEC-handtekeningen van onze domeinnaam valideren. Resolvers worden normaal gesproken geleverd door je internetprovider. Als alternatief kun je resolvers van een andere DNS provider instellen. Je kan zelfs je eigen lokaal geïnstalleerde resolver gebruiken. Hoewel validatie plaatsvindt op de resolver, kan nog steeds door een aanvaller gerommeld worden met de communicatie tussen de resolver en jouw apparaat (ook wel 'last mile' genoemd). Het is daarom het meest veilig om zo dicht mogelijk op je apparaat te valideren (bijv. door een lokaal geïnstalleerde resolver te gebruiken), of zorg ervoor dat het kanaal tussen je resolver en je apparaat beveiligd c.q. vertrouwd is.", + "detail_conn_dnssec_validation_label": "DNSSEC-validatie", + "detail_conn_dnssec_validation_tech_table": "DNS-provider", + "detail_conn_dnssec_validation_tech_table_dns_provider": "DNS-provider", + "detail_conn_dnssec_validation_verdict_bad": "Je bent niet beschermd door validatie van DNSSEC-handtekeningen.", + "detail_conn_dnssec_validation_verdict_good": "Je bent beschermd door validatie van DNSSEC-handtekeningen.", + "detail_conn_ipv6_connection_exp": "We testen of jouw apparaat via zijn huidige internetverbinding in staat is om direct (d.w.z. zonder DNS-vertaling) verbinding te maken met onze webserver via ons bijbehorende IPv6-adres.

Sommige browser add-ons en routers bieden functionaliteit aan voor het filteren van domeinnamen om de privacy te verbeteren of internetgebruik te beperken. Om omzeiling te voorkomen blokkeert deze functionaliteit vaak ook het direct verbinden met IP-adressen waardoor deze subtest faalt.", + "detail_conn_ipv6_connection_label": "IPv6-connectiviteit (direct)", + "detail_conn_ipv6_connection_tech_table": "Geanonimiseerd IPv6-adres|Reverse name|Internetprovider", + "detail_conn_ipv6_connection_tech_table_anonymized_ipv6_address": "Geanonimiseerd IPv6-adres", + "detail_conn_ipv6_connection_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_connection_tech_table_internet_provider": "Internetprovider", + "detail_conn_ipv6_connection_verdict_bad": "Je bent niet in staat om computers direct op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_connection_verdict_good": "Je bent in staat om computers direct op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_dns_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv6. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv6-adres ophaalt.", + "detail_conn_ipv6_dns_conn_label": "IPv6-connectiviteit (via DNS)", + "detail_conn_ipv6_dns_conn_verdict_bad": "Je bent niet in staat om computers via DNS op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_dns_conn_verdict_good": "Je bent in staat om computers via DNS op hun IPv6-adres te bereiken.", + "detail_conn_ipv6_ipv4_conn_exp": "We testen of jouw apparaat middels zijn huidige internetverbinding in staat is om verbinding te maken met onze webserver via IPv4. Voor deze test bieden we een domeinnaam aan en we verwachten dat je resolver voor deze domeinnaam het bijbehorende IPv4-adres ophaalt.

Niveau van vereistheid: Optioneel", + "detail_conn_ipv6_ipv4_conn_label": "IPv4-connectiviteit (via DNS)", + "detail_conn_ipv6_ipv4_conn_tech_table": "Geanonimiseerd IPv4-adres|Reverse name|Internetprovider", + "detail_conn_ipv6_ipv4_conn_tech_table_anonymized_ipv4_address": "Geanonimiseerd IPv4-adres", + "detail_conn_ipv6_ipv4_conn_tech_table_reverse_name": "Reverse name", + "detail_conn_ipv6_ipv4_conn_tech_table_internet_provider": "Internetprovider", + "detail_conn_ipv6_ipv4_conn_verdict_bad": "Je bent niet in staat om computers via DNS op hun IPv4-adres te bereiken.", + "detail_conn_ipv6_ipv4_conn_verdict_good": "Je bent in staat om computers via DNS op hun IPv4-adres te bereiken.", + "detail_conn_ipv6_privacy_exp": "We testen of je apparaat 'IPv6 Privacy Extensions for SLAAC' (of een ander IPv6-configuratieproces dan SLAAC) gebruikt om het lekken van zijn mogelijk privacygevoelige MAC-adres naar computers waarmee het via IPv6 verbinding maakt te voorkomen.", + "detail_conn_ipv6_privacy_label": "Privacy Extensions voor IPv6", + "detail_conn_ipv6_privacy_verdict_bad": "Je gebruikt SLAAC zonder 'IPv6 Privacy Extensions'.", + "detail_conn_ipv6_privacy_verdict_good": "Je hebt 'IPv6 Privacy Extensions' geactiveerd (of je gebruikt geen SLAAC).", + "detail_conn_ipv6_resolver_conn_exp": "We testen of ten minste één van de door jou gebruikte DNS-resolvers in staat is om onze autoritatieve nameserver te bereiken via IPv6. Vaak levert je internetprovider de DNS-resolver(s).", + "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).

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.", + "detail_mail_auth_dkim_verdict_no_email": "Je domeinnaam ondersteunt geen DKIM-records. Echter omdat je DMARC- en SPF-records aangeven dat er geen mail vanaf je domein wordt verstuurd, is DKIM niet nodig en wordt deze subtest overgeslagen.", + "detail_mail_auth_dmarc_exp": "We testen of DMARC beschikbaar is voor jouw domein. Een ontvangendemailserver kan de DMARC-policy gebruiken om te bepalen hoe om te gaan meteen e-mail met jouw domein als verzender waarvan de authenticatie met zowelDKIM als SPF faalt, en de ontvangende mailserver kan je e-mailadres uit het DMARC-recordgebruiken om je feedbackrapporten over het authenticatieresultaat te sturen. Het hebben van meer dan één DMARC-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt. Let op: DMARC vereist dathet SPF-domein (envelope sender, d.w.z. return-path dat terugkomt inMAIL FROM) en het DKIM-domein (d=) gelijk zijn aan het verzenddomein in hetmailbericht (From:). ", + "detail_mail_auth_dmarc_label": "DMARC aanwezigheid", + "detail_mail_auth_dmarc_tech_table": "DMARC-record|Gevonden op", + "detail_mail_auth_dmarc_tech_table_dmarc_record": "DMARC-record", + "detail_mail_auth_dmarc_tech_table_found_on": "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_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. ", + "detail_mail_auth_dmarc_policy_verdict_good": "Je DMARC-policy is voldoende strikt.", + "detail_mail_auth_dmarc_policy_verdict_policy": "Je DMARC-policy is niet voldoende strikt.", + "detail_mail_auth_spf_exp": "We testen of je domeinnaam een SPF-record heeft. Een ontvangende mailserver kan de IP-adressen in je SPF-record gebruiken om de verzendende mailserver van een ontvangen e-mail met jouw domein als afzender te authenticeren. Het bijbehorende beleid kan worden gebruikt om passende actie te ondernemen als de authenticatie mislukt. Meer dan één SPF-record op hetzelfde domein is niet geldig en zorgt ervoor dat het domein voor de test faalt.

Voor een \"good practice voor domeinnamen zonder mail\" zie de uitleg van de \"DMARC-policy\" subtest.", + "detail_mail_auth_spf_label": "SPF aanwezigheid", + "detail_mail_auth_spf_tech_table": "SPF-record", + "detail_mail_auth_spf_tech_table_spf_record": "SPF-record", + "detail_mail_auth_spf_verdict_bad": "Je domeinnaam heeft geen geldig SPF-record.", + "detail_mail_auth_spf_verdict_good": "Je domein heeft een SPF-record.", + "detail_mail_auth_spf_policy_exp": "We controleren of de syntax van je SPF-record geldig is en of deze een voldoende strikte policy, d.w.z. ~all (softfail) of -all (hardfail), bevat om misbruik van je domein door phishers en spammers tegen te gaan. Om misbruik van je domein tegen te gaan is een liberale policy, d.w.z. +all (pass) of ?all (neutral), onvoldoende. Als all ontbreekt en er is geen redirect aanwezig in je SPF-record, dan is de default policy ?all.

We volgen ook include en redirect voor geldige SPF-records. Bovendien controleren we of je SPF-record het toegestane aantal van 10 DNS-opvragingen niet overschrijdt waardoor het geen werking meer heeft. Ieder van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.

Merk op dat als het domein onder include of redirect uit macro's bestaat, dan volgen we deze niet omdat we niet over de noodzakelijk informatie van een daadwerkelijke mail of mailserververbinding beschikken om de macro's uit te voeren. Dit betekent dat we het gevolg van macro's niet beoordelen. Bovendien tellen we de door macro's veroorzaakte DNS-opvragingen niet mee om te bepalen of het toegestane aantal DNS-opvragingen is overschreden.

Voor verzendende domeinen heeft het gebruik van ~all (softfail) in plaats van -all (fail) meestal de voorkeur. De reden hiervoor is dat wanneer de SPF-authenticatie faalt met een SPF fail, een ontvangende mailserver de verbinding al kan blokkeren zonder de DKIM-handtekening en het DMARC-beleid te evalueren. Dit kan leiden tot ten onrechte geblokkeerde mails (bijvoorbeeld wanneer mails door de ontvangende mailserver automatisch worden doorgestuurd naar een andere ontvangende mailserver). Merk op dat een getriggerde SPF softfail er nog steeds voor zorgt dat een strikte DMARC policy je domein beschermt als ook de DKIM-authenticatie faalt.

Voor domeinen zonder mail zie de good practice op uitleg van de \"DMARC-policy\" subtest.", + "detail_mail_auth_spf_policy_label": "SPF policy", + "detail_mail_auth_spf_policy_tech_table": "Domein|SPF-record", + "detail_mail_auth_spf_policy_tech_table_domain": "Domein", + "detail_mail_auth_spf_policy_tech_table_spf_record": "SPF-record", + "detail_mail_auth_spf_policy_verdict_all": "Je SPF-policy is niet voldoende strikt.", + "detail_mail_auth_spf_policy_verdict_bad": "Je SPF-policy is syntactisch niet correct.", + "detail_mail_auth_spf_policy_verdict_good": "Je SPF-policy is voldoende strikt.", + "detail_mail_auth_spf_policy_verdict_include": "Je SPF-policy is niet voldoende strikt. Het 'include'-mechanisme in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.", + "detail_mail_auth_spf_policy_verdict_max_lookups": "Je SPF-policy is niet effectief omdat deze meer dan de toegestane 10 DNS-opvragingen vereist. Elk van de volgende SPF-termen telt als een DNS-opvraging: redirect, include, a, mx, ptr en exist. Terwijl de SPF-termen all, ip4, ip6 en exp niet tellen als DNS-opvragingen.", + "detail_mail_auth_spf_policy_verdict_redirect": "Je SPF-policy is niet voldoende strikt. De 'redirect modifier' in je SPF-record verwijst naar een onvoldoende strikte SPF-policy of naar een niet-bestaand SPF-record.", + "detail_mail_dnssec_exists_exp": "We testen of de domeinnaam in je e-mailadres, meer specifiek het SOA-record, ondertekend is met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze jouw mailserverdomeinen (MX) kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar een mailserverdomein dat onder controle is van de aanvaller.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", + "detail_mail_dnssec_exists_label": "DNSSEC aanwezigheid", + "detail_mail_dnssec_exists_tech_table": "E-mailadresdomein|Registrar", + "detail_mail_dnssec_exists_tech_table_email_address_domain": "E-mailadresdomein", + "detail_mail_dnssec_exists_tech_table_registrar": "Registrar", + "detail_mail_dnssec_exists_verdict_bad": "Je e-mailadresdomein is onveilig oftewel 'insecure', omdat het niet ondertekend is met DNSSEC.", + "detail_mail_dnssec_exists_verdict_good": "Je e-mailadresdomein is met DNSSEC ondertekend.", + "detail_mail_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", + "detail_mail_dnssec_exists_verdict_servfail": "De nameservers van je e-mailadresdomein zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", + "detail_mail_dnssec_mx_exists_exp": "We testen of de domeinnamen van je mailservers (MX), meer specifiek hun SOA-records, ondertekend zijn met DNSSEC. De handtekening zorgt ervoor dat een verzender, die domeinhandtekeningen controleert, op een betrouwbare wijze de IP-adressen en DANE-records van jouw mailservers kan opvragen. Dit voorkomt dat een aanvaller het antwoord manipuleert en aan jou gerichte mail omleidt naar IP-adressen die onder controle staan van de aanvaller óf de beveiligde mailserver-verbinding afluistert.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

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

De geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", + "detail_mail_dnssec_mx_exists_label": "DNSSEC aanwezigheid", + "detail_mail_dnssec_mx_exists_tech_table": "Domein van mailserver (MX)|DNSSEC aanwezig", + "detail_mail_dnssec_mx_exists_tech_table_domain_of_mail_server_mx": "Domein van mailserver (MX)", + "detail_mail_dnssec_mx_exists_tech_table_dnssec_existent": "DNSSEC aanwezig", + "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": "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.", + "detail_mail_dnssec_mx_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_dnssec_mx_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", + "detail_mail_dnssec_mx_exists_verdict_servfail": "De nameservers van tenminste één van je mailserverdomeinen zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je mailprovider) om dit spoedig op te lossen.", + "detail_mail_dnssec_mx_valid_exp": "We testen of de domeinen van je ontvangende mailservers (MX), meer specifiek hun SOA-records, zijn ondertekend met een geldige DNSSEC-handtekening die ze veilig oftewel 'secure' maakt.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer 'secure' en de andere keer 'bogus' zijn.", + "detail_mail_dnssec_mx_valid_label": "DNSSEC geldigheid", + "detail_mail_dnssec_mx_valid_tech_table": "Domein van mailserver (MX)|Status", + "detail_mail_dnssec_mx_valid_tech_table_domain_of_mail_server_mx": "Domein van mailserver (MX)", + "detail_mail_dnssec_mx_valid_tech_table_status": "Status", + "detail_mail_dnssec_mx_valid_verdict_bad": "Tenminste één van de ondertekende domeinen van je mailservers is onbetrouwbaar oftewel 'bogus', omdat zijn DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde de antwoorden van de nameservers, óf je mailserverdomein heeft serieuze DNSSEC-configuratiefouten. Dit laatste maakt je ontvangende mailserver onbereikbaar voor alle verzendende mailservers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met de nameserver-beheerder (vaak je mailprovider).", + "detail_mail_dnssec_mx_valid_verdict_good": "Al de ondertekende domeinnamen van je mailservers zijn veilig oftewel 'secure', omdat hun DNSSEC-handtekeningen geldig zijn.", + "detail_mail_dnssec_mx_valid_verdict_unsupported_ds_algo": "Tenminste één van de domeinen van je mailservers is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", + "detail_mail_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer 'secure' en de andere keer 'bogus' zijn.", + "detail_mail_dnssec_valid_label": "DNSSEC geldigheid", + "detail_mail_dnssec_valid_tech_table": "E-mailadresdomein|Status", + "detail_mail_dnssec_valid_tech_table_email_address_domain": "E-mailadresdomein", + "detail_mail_dnssec_valid_tech_table_status": "Status", + "detail_mail_dnssec_valid_verdict_bad": "Je e-mailadresdomein is onbetrouwbaar oftewel 'bogus', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", + "detail_mail_dnssec_valid_verdict_good": "Je e-mailadresdomein is veilig oftewel 'secure', omdat zijn DNSSEC-handtekening geldig is.", + "detail_mail_dnssec_valid_verdict_unsupported_ds_algo": "Je e-mailadresdomein is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", + "detail_mail_ipv6_mx_aaaa_exp": "We testen of er tenminste één AAAA-record met IPv6-adres voor iedere ontvangende mailserver (MX) is. In het geval er geen mailserver is gedefinieerd, geven we een notificatie en we voeren andere subtesten van de mailtest die nog steeds relevant zijn gewoon uit.

'IPv4-mapped IPv6 addresses' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.

Merk op dat de e-mailtest niet terugvalt op A/AAAA-records voor mailservers in geval van afwezigheid van een MX-record.", + "detail_mail_ipv6_mx_aaaa_label": "IPv6-adressen voor mailserver(s)", + "detail_mail_ipv6_mx_aaaa_tech_table": "Mailserver (MX)|IPv6-adres|IPv4-adres", + "detail_mail_ipv6_mx_aaaa_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv6_address": "IPv6-adres", + "detail_mail_ipv6_mx_aaaa_tech_table_ipv4_address": "IPv4-adres", + "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 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": "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_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_ipv6_mx_reach_tech_table_unreachable_ipv6_address": "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.", + "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_tech_table_mail_server": "Mailserver", + "detail_mail_rpki_exists_tech_table_ip_address": "IP-adres", + "detail_mail_rpki_exists_tech_table_rpki_route_origin_authorization": "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.", + "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_tech_table_name_server_of_mx": "Nameserver van MX", + "detail_mail_rpki_mx_ns_exists_tech_table_ip_address": "IP-adres", + "detail_mail_rpki_mx_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server_of_mx": "Nameserver van MX", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_mx_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_mx_ns_valid_tech_table_rpki_origin_validation_state": "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 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.

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_tech_table_mail_server": "Mailserver", + "detail_mail_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_mail_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_mail_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", + "detail_mail_tls_cert_hostmatch_tech_table": "Mailserver (MX)|Niet-overeenkomende domeinen op certificaat", + "detail_mail_tls_cert_hostmatch_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Niet-overeenkomende domeinen op certificaat", + "detail_mail_tls_cert_hostmatch_verdict_bad": "De domeinnaam van tenminste één van je mailservers komt niet overeen met de domeinnaam op het mailservercertificaat.", + "detail_mail_tls_cert_hostmatch_verdict_good": "De domeinnamen van al je mailservers komen overeen met de domeinnamen op je mailservercertificaten.", + "detail_mail_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van ieder van je mailserver-certificaten veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", + "detail_mail_tls_cert_pubkey_label": "Publieke sleutel van certificaat", + "detail_mail_tls_cert_pubkey_tech_table": "Mailserver (MX)|Getroffen handtekening-parameters|Status", + "detail_mail_tls_cert_pubkey_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_pubkey_tech_table_affected_signature_parameters": "Getroffen handtekening-parameters", + "detail_mail_tls_cert_pubkey_tech_table_status": "Status", + "detail_mail_tls_cert_pubkey_verdict_bad": "De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt onvoldoende veilige parameters.", + "detail_mail_tls_cert_pubkey_verdict_good": "De digitale handtekeningen van al je mailserver-certificaten gebruiken veilige parameters.", + "detail_mail_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van tenminste één van je mailserver-certificaten gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van ieder van je mailserver-certificaten is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", + "detail_mail_tls_cert_signature_label": "Handtekening van certificaat", + "detail_mail_tls_cert_signature_tech_table": "Mailserver (MX)|Getroffen hashing-algoritme|Status", + "detail_mail_tls_cert_signature_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_signature_tech_table_affected_hash_algorithm": "Getroffen hashing-algoritme", + "detail_mail_tls_cert_signature_tech_table_status": "Status", + "detail_mail_tls_cert_signature_verdict_bad": "Tenminste één van je mailserver-certificaten is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", + "detail_mail_tls_cert_signature_verdict_good": "Al je mailserver-certificaten zijn ondertekend met een veilig algoritme voor hashing.", + "detail_mail_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je mailserver-certificaten kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je ontvangende mailserver alle noodzakelijke tussenliggende certificaten presenteert.

Verzendende mailservers negeren doorgaans of een mailservercertificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit. Zonder DNSSEC is de opvraging van het mailserverdomein kwetsbaar voor manipulatie. Daardoor kan een certificaat dat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit geen enkele authenticiteitswaarde toevoegen. Ontvangende mailservers gebruiken daarom regelmatig zelf-ondertekende certificaten, vaak uitgegeven door een interne (private) certificaatautoriteit. Voor authenticiteit dient een mailserver gebruikt te maken van DNSSEC en DANE.

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

Niveau van vereistheid: Optioneel", + "detail_mail_tls_cert_trust_label": "Vertrouwensketen van certificaat", + "detail_mail_tls_cert_trust_tech_table": "Mailserver (MX)|Onvertrouwde certificaatketen", + "detail_mail_tls_cert_trust_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_cert_trust_tech_table_untrusted_certificate_chain": "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-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_tech_table_mail_server_mx": "Mail server (MX)", + "detail_mail_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "Eerst gevonden getroffen cipher-paren", + "detail_mail_tls_cipher_order_tech_table_violated_rule_ii_b": "Overtreden regel # ('II-B')", + "detail_mail_tls_cipher_order_verdict_bad": "Tenminste één van je mailservers dwingt niet zijn eigen cipher-voorkeur af ('I').", + "detail_mail_tls_cipher_order_verdict_good": "Al je mailservers dwingen hun eigen cipher-voorkeur af ('I'), en bieden ciphers aan conform de voorgeschreven volgorde ('II').", + "detail_mail_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je mailserver alleen 'Goede' ciphers ondersteunt.", + "detail_mail_tls_cipher_order_verdict_seclevel_bad": "Tenminste één van je mailservers prefereert niet 'Goede' boven 'Voldoende' en dan pas 'Uit te faseren' ciphers ('II').", + "detail_mail_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Tenminste een van je mailservers biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau ('II-B').", + "detail_mail_tls_ciphers_exp": "

We testen of je ontvangende mailservers (MX) alleen veilige, d.w.z. 'Goede' en/of 'Voldoende', ciphers (ook algoritmeselecties genoemd) ondersteunen. Om te voorkomen dat we tegen 'rate limits' van ontvangende mailservers aanlopen, bevat het testresultaat alleen de eerstgevonden getroffen algoritmeselectie.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing.

  • Vanaf TLS 1.3 omvat de term 'cipher suite' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term 'cipher suite' ambigu maakt, gebruikt NCSC de term 'algoritmeselectie' om alle vier de functies te omvatten.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselectie. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan 'Goede', 'Voldoende' en 'Uit te faseren' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0'. Achter iedere algoritmeselectie staat de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste 'Uit te faseren' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_mail_tls_ciphers_label": "Ciphers (Algoritmeselecties)", + "detail_mail_tls_ciphers_tech_table": "Mailserver (MX)|Eerst gevonden onveilige cipher|Status", + "detail_mail_tls_ciphers_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_ciphers_tech_table_first_found_affected_cipher": "Eerst gevonden onveilige cipher", + "detail_mail_tls_ciphers_tech_table_status": "Status", + "detail_mail_tls_ciphers_verdict_bad": "Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige ciphers.", + "detail_mail_tls_ciphers_verdict_good": "Al je mailservers ondersteunen alleen veilige ciphers.", + "detail_mail_tls_ciphers_verdict_phase_out": "Tenminste één van je mailservers ondersteunt een of meer ciphers die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_compression_exp": "

We testen of je ontvangende mailservers (MX) TLS-compressie ondersteunen.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau
  • Onvoldoende: TLS-compressie
", + "detail_mail_tls_compression_label": "TLS-compressie", + "detail_mail_tls_compression_tech_table": "Mailserver (MX)|TLS-compressie", + "detail_mail_tls_compression_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_compression_tech_table_tls_compression": "TLS-compressie", + "detail_mail_tls_compression_verdict_bad": "Tenminste één van je mailservers ondersteunt TLS-compressie, wat niet veilig is.", + "detail_mail_tls_compression_verdict_good": "Al je mailservers ondersteunen geen TLS-compressie.", + "detail_mail_tls_dane_exists_exp": "We testen of de nameservers van ieder van je ontvangende mailservers (MX) een of meer TLSA-records voor DANE bevatten.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het mailserver-domein.

Merk op dat de test TLSA-records van de types PKIX-TA(0) or PKIX-EE(1) negeert, omdat deze niet gebruikt dienen te worden voor ontvangende mailservers.

De test slaagt daarnaast niet als er geen DNSSEC-bewijs van 'Denial of Existence' voor TLSA-records is. Als een ondertekend TLSA-record bestaat maar tegelijkertijd is er een 'insecure' NXDOMAIN voor hetzelfde domein (door verkeerd werkende DNSSEC-ondertekeningssoftware), dan zal de test ook niet slagen. De laatste twee foutscenario's kunnen leiden tot afleveringsproblemen van aan jou gerichte e-mails door DANE-validerende mailverzenders.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, Appendix A, onder 'Certificate pinning en DANE'.", + "detail_mail_tls_dane_exists_label": "DANE aanwezigheid", + "detail_mail_tls_dane_exists_tech_table": "Mailserver (MX)|DANE TLSA-record aanwezig", + "detail_mail_tls_dane_exists_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA-record aanwezig", + "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.

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_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_dane_rollover_tech_table_dane_rollover_scheme": "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.", + "detail_mail_tls_dane_rollover_verdict_good": "Al je mailserver-domeinen hebben een actief DANE-schema voor het betrouwbaar vervangen van certificaat-sleutels.", + "detail_mail_tls_dane_valid_exp": "We testen of de DANE-fingerprints die je mailserverdomeinen presenteren geldig zijn voor je mailservercertificaten.

Met DANE kan je informatie over jouw mailservercertificaten publiceren in een speciaal DNS-record, een TLSA-record. Verzendende mailservers kunnen de certificaten nu niet alleen via de certificaatautoriteit, maar ook via de TLSA-records controleren op authenticiteit. Een verzendende mail server kan het TLSA-record ook als signaal gebruiken om alleen via STARTTLS (en niet onversleuteld) te verbinden. Als de DANE-fingerprint van een ontvangende mailserver wordt gecontroleerd door de verzendende mailserver, dan kan een actieve aanvaller die in staat is het berichtenverkeer te manipuleren de STARTTLS-encryptie niet verwijderen.", + "detail_mail_tls_dane_valid_label": "DANE geldigheid", + "detail_mail_tls_dane_valid_tech_table": "Mailserver (MX)|DANE TLSA-record geldig", + "detail_mail_tls_dane_valid_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Sleuteluitwisselingsparameters", + "detail_mail_tls_fs_params_tech_table": "Mailserver (MX)|Getroffen parameters|Veiligheidsniveau", + "detail_mail_tls_fs_params_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_fs_params_tech_table_affected_parameters": "Getroffen parameters", + "detail_mail_tls_fs_params_tech_table_security_level": "Veiligheidsniveau", + "detail_mail_tls_fs_params_verdict_bad": "Tenminste één van je mailservers ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_mail_tls_fs_params_verdict_good": "Je mailserver ondersteunt voldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_mail_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je mailservers niet Diffie-Hellman-sleuteluitwisseling ondersteunen. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", + "detail_mail_tls_fs_params_verdict_phase_out": "Tenminste één van je mailservers ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_kex_hash_func_exp": "

We testen of je mailservers (MX) ondersteuning bieden voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

Een ontvangende mailserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De mailserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, tabel 5.

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", + "detail_mail_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", + "detail_mail_tls_kex_hash_func_tech_table": "Mailserver (MX)|SHA-2-ondersteuning voor handtekeningen", + "detail_mail_tls_kex_hash_func_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "SHA-2-ondersteuning voor handtekeningen", + "detail_mail_tls_kex_hash_func_verdict_good": "Al je mailservers ondersteunen veilige hashfuncties voor sleuteluitwisseling.", + "detail_mail_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie tenminste één van je mailservers gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", + "detail_mail_tls_kex_hash_func_verdict_phase_out": "Ten minste één van je mailservers ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", + "detail_mail_tls_ocsp_stapling_exp": "OUTDATED TEXT; TEST NOT USED
TODO", + "detail_mail_tls_ocsp_stapling_label": "OUTDATED TEXT; TEST NOT USED
TODO", + "detail_mail_tls_ocsp_stapling_tech_table": "OUTDATED TEXT; TEST NOT USED
Mailserver (MX)|TODO", + "detail_mail_tls_ocsp_stapling_tech_table_outdated_text_test_not_used_mail_server_mx": "OUTDATED TEXT; TEST NOT USED
Mailserver (MX)", + "detail_mail_tls_ocsp_stapling_tech_table_ocsp_stapling": "TODO", + "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_label": "Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_tech_table": "Mailserver (MX)|Client-initiated renegotiation", + "detail_mail_tls_renegotiation_client_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "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.", + "detail_mail_tls_renegotiation_client_verdict_good": "Al je mailservers staan geen client-initiated renegotiation toe.", + "detail_mail_tls_renegotiation_secure_exp": "

We testen of je mailservers (MX) secure renegotiation ondersteunen.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten 'opnieuw onderhandelen' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", + "detail_mail_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_mail_tls_renegotiation_secure_tech_table": "Mailserver (MX)|Secure renegotiation", + "detail_mail_tls_renegotiation_secure_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_renegotiation_secure_tech_table_secure_renegotiation": "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_label": "STARTTLS beschikbaar", + "detail_mail_tls_starttls_exists_tech_table": "Mailserver (MX)|STARTTLS", + "detail_mail_tls_starttls_exists_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_starttls_exists_tech_table_starttls": "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 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": "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", + "detail_mail_tls_version_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_version_tech_table_tls_versions": "TLS-versies", + "detail_mail_tls_version_tech_table_status": "Status", + "detail_mail_tls_version_verdict_bad": "Tenminste één van je mailservers ondersteunt een of meer onvoldoende veilige TLS-versies.", + "detail_mail_tls_version_verdict_good": "Al je mailservers ondersteunen alleen veilige TLS-versies.", + "detail_mail_tls_version_verdict_phase_out": "Tenminste één van je mailservers ondersteunt een of meer TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_mail_tls_zero_rtt_exp": "

We testen of je mailservers (MX) Zero Round Trip Time Resumption (0-RTT) ondersteunen.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je mailservers geen TLS 1.3 ondersteunen, dan is deze test niet van toepassing. Voor mailservers die TLS 1.3 ondersteunen, wordt het STARTTLS-commando gegeven en wordt een TLS-sessie geïnitieerd. De omvang van de ondersteuning voor early data zoals aangegeven door de mailserver wordt gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt, maar waarbij het EHLO-commando vóór de TLS handshake maar na het STARTTLS-commando plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de mailserver antwoordt, dan wordt aangenomen dat de mailserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", + "detail_mail_tls_zero_rtt_label": "0-RTT", + "detail_mail_tls_zero_rtt_tech_table": "Mailserver (MX)|0-RTT", + "detail_mail_tls_zero_rtt_tech_table_mail_server_mx": "Mailserver (MX)", + "detail_mail_tls_zero_rtt_tech_table_0_rtt": "0-RTT", + "detail_mail_tls_zero_rtt_verdict_bad": "Tenminste één van je mailservers ondersteunt 0-RTT, wat niet veilig is.", + "detail_mail_tls_zero_rtt_verdict_good": "Geen van je mailservers ondersteunen 0-RTT.", + "detail_mail_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je mailservers TLS 1.3 niet ondersteunen.", + "detail_tech_data_bogus": "bogus", + "detail_tech_data_good": "goed", + "detail_tech_data_http_csp_has_bare_https": "Aanbeveling: 'https:' schema zonder specifiek hoofddomein moet niet worden gebruikt (#9).", + "detail_tech_data_http_csp_has_data": "Aanbeveling: 'data:' schema moet niet worden gebruikt waar dat niet is toegestaan (#7).", + "detail_tech_data_http_csp_has_host_without_scheme": "Aanbeveling: Een domein zonder schema moet niet worden gebruikt (#8). ", + "detail_tech_data_http_csp_has_http": "Aanbeveling: 'http:' schema moet niet worden gebruikt (#8).", + "detail_tech_data_http_csp_has_invalid_host": "Aanbeveling: Een wildcard (d.w.z. '*') of '127.0.0.1' moeten niet worden gebruikt (#9 en #10).", + "detail_tech_data_http_csp_has_unsafe_eval": "Aanbeveling: 'unsafe-eval' moet niet worden gebruikt (#6).", + "detail_tech_data_http_csp_has_unsafe_hashes": "Aanbeveling: 'unsafe-hashes' moet niet worden gebruikt (#6).", + "detail_tech_data_http_csp_has_unsafe_inline": "Aanbeveling: 'unsafe-inline' moet niet worden gebruikt (#6).", + "detail_tech_data_http_csp_missing_invalid_base_uri": "Aanbeveling: 'base-uri' met voldoende veilige waarde moet zijn gedefinieerd (#2).", + "detail_tech_data_http_csp_missing_invalid_default_src": "Aanbeveling: 'default-src' met voldoende veilige waarde moet zijn gedefinieerd (#1).", + "detail_tech_data_http_csp_missing_invalid_form_action": "Aanbeveling: 'form-action' met voldoende veilige waarde moet zijn gedefinieerd (#5).", + "detail_tech_data_http_csp_missing_invalid_frame_ancestors": "Aanbeveling: 'frame-ancestors' met voldoende veilige waarde moet zijn gedefinieerd (#4).", + "detail_tech_data_http_csp_missing_invalid_frame_src": "Aanbeveling: 'frame-src' (of 'child-src' of 'default-src' als fallback) met voldoende veilige waarde moet zijn gedefinieerd (#3).", + "detail_tech_data_http_csp_no_policy_found": "Geen CSP gevonden.", + "detail_tech_data_http_csp_policy_found": "Opgehaalde CSP-waarde: {policy}", + "detail_tech_data_http_referrer_policy_bad_invalid": "Slecht: policy-waarde is niet geldig.", + "detail_tech_data_http_referrer_policy_bad_no_referrer_when_downgrade": "Slecht: 'no-referrer-when-downgrade' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_bad_origin": "Slecht: 'origin' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_bad_origin_when_cross_origin": "Slecht: 'origin-when-cross-origin' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_bad_unsafe_url": "Slecht: 'unsafe-url' moet niet worden gebruikt.", + "detail_tech_data_http_referrer_policy_no_policy": "Geen Referrer-Policy gevonden.", + "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_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.", + "detail_tech_data_http_securitytxt_multi_lang": "Fout: Het veld 'Preferred-Languages' moet niet meer dan één keer voorkomen.", + "detail_tech_data_http_securitytxt_multiple_csaf_fields": "Aanbeveling: Meerdere 'CSAF'-velden zouden moeten worden teruggebracht tot één 'CSAF'-veld.", + "detail_tech_data_http_securitytxt_no_canonical": "Aanbeveling: Het veld 'Canonical' zou aanwezig moeten zijn in een ondertekend bestand.", + "detail_tech_data_http_securitytxt_no_canonical_match": "Fout: De web URI van security.txt (d.w.z. bij redirecting ten minste de laatste URI van de redirect-keten) moet worden vermeld in een 'Canonical'-veld als dat aanwezig is.", + "detail_tech_data_http_securitytxt_no_contact": "Fout: Het veld 'Contact' moet minstens één keer voorkomen.", + "detail_tech_data_http_securitytxt_no_content_type": "Fout: HTTP Content-Type header moet worden verstuurd.", + "detail_tech_data_http_securitytxt_no_csaf_file": "Fout: Ieder optioneel 'CSAF'-veld moet verwijzen naar een bestand met de naam 'provider-metadata.json'.", + "detail_tech_data_http_securitytxt_no_encryption": "Aanbeveling: Het veld 'Encryption' zou aanwezig moeten zijn wanneer het veld 'Contact' een e-mailadres bevat.", + "detail_tech_data_http_securitytxt_no_expire": "Fout: Het veld 'Expires' moet aanwezig zijn.", + "detail_tech_data_http_securitytxt_no_https": "Fout: De web URI moet beginnen met 'https://' (regel {line_no}).", + "detail_tech_data_http_securitytxt_no_line_separators": "Fout: Elke regel moet eindigen met óf een carriage return en line feed characters óf alleen een line feed character.", + "detail_tech_data_http_securitytxt_no_security_txt_404": "Fout: security.txt kon niet gevonden worden.", + "detail_tech_data_http_securitytxt_no_security_txt_other": "Fout: security.txt kon niet gevonden worden (onverwachte HTTP response code {status_code}).", + "detail_tech_data_http_securitytxt_no_space": "Fout: Veld-scheidingsteken (dubbele punt) moet worden gevolgd door een spatie (regel {line_no}).", + "detail_tech_data_http_securitytxt_no_uri": "Fout: Veldwaarde moet een URI zijn (bijv. beginnend met 'mailto:') (regel {line_no}).", + "detail_tech_data_http_securitytxt_not_signed": "Aanbeveling: security.txt zou digitaal ondertekend moeten zijn.", + "detail_tech_data_http_securitytxt_pgp_data_error": "Fout: Ondertekende security.txt moet een correct 'ASCII-armored PGP block' bevatten.", + "detail_tech_data_http_securitytxt_pgp_error": "Fout: Het decoderen of parsen van de ondertekende security.txt moet slagen.", + "detail_tech_data_http_securitytxt_prec_ws": "Fout: Er mag geen spatie staan voor het veld-scheidingsteken (dubbele punt) (regel {line_no}).", + "detail_tech_data_http_securitytxt_requested_from": "security.txt opgevraagd van {hostname}.", + "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 gecodeerd zijn met UTF-8 in Net-Unicode vorm.", + "detail_tech_data_insecure": "insecure", + "detail_tech_data_insufficient": "onvoldoende", + "detail_tech_data_no": "nee", + "detail_tech_data_not_applicable": "niet van toepassing", + "detail_tech_data_not_reachable": "niet bereikbaar", + "detail_tech_data_not_testable": "niet testbaar", + "detail_tech_data_not_tested": "niet getest", + "detail_tech_data_phase_out": "uit te faseren", + "detail_tech_data_secure": "secure", + "detail_tech_data_sufficient": "voldoende", + "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_csp_tech_table_findings": "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\".

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_referrer_policy_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_securitytxt_tech_table_findings": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_x_content_type_tech_table_x_content_type_options_value": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_appsecpriv_http_x_frame_tech_table_x_frame_options_value": "X-Frame-Options waarde", + "detail_web_appsecpriv_http_x_frame_verdict_bad": "Je webserver biedt geen veilig ingestelde X-Frame-Options aan.", + "detail_web_appsecpriv_http_x_frame_verdict_good": "Je webserver biedt veilig ingestelde X-Frame-Options aan.", + "detail_web_appsecpriv_http_x_xss_exp": "OUTDATED TEXT; TEST NOT USED

We testen of je webserver een HTTP header voor X-XSS-Protection aanbiedt die een voldoende veilige waarde heeft (dat wil zeggen 1 of 1; mode=block). Deze HTTP header kan worden gebruikt om het beschermingsfilter van browsers tegen reflectieve cross-site scripting (XSS) aanvallen te activeren.

Geldige waardes voor de X-XSS-Protection header zijn:

  • 0 deactiveert het XSS-filter. Deze waarde dient NIET te worden gebruikt.
  • 1 activeert het XSS-filter. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het script opschonen en de onveilige delen verwijderen. Deze waarde is normaal gesproken de standaard-waarde ('default') in browsers als een website geen X-XSS-Protection header aanbiedt.
  • 1; mode=block activeert het XSS-filter én de blokkeermodus. Als een cross-site scripting aanval wordt gedetecteerd, dan zal de browser het antwoord blokkeren en de webpagina niet laden. Dit is de aanbevolen waarde.

Mits goed geconfigureerd kan Content-Security-Policy (CSP) vergelijkbare bescherming en meer bieden aan gebruikers van moderne webbrowsers. X-XSS-Protection biedt in dat geval nog altijd bescherming aan bezoekers van oudere browsers die geen CSP ondersteunen. Bovendien kan X-XSS-Protection waardevolle bescherming aan alle bezoekers bieden, indien CSP niet (goed) is ingesteld voor de desbetreffende website.

Niveau van vereistheid: Aanbevolen", + "detail_web_appsecpriv_http_x_xss_label": "OUTDATED TEXT; TEST NOT USED

X-XSS-Protection", + "detail_web_appsecpriv_http_x_xss_tech_table": "OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres|X-XSS-Protection waarde", + "detail_web_appsecpriv_http_x_xss_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Webserver-IP-adres", + "detail_web_appsecpriv_http_x_xss_tech_table_x_xss_protection_value": "X-XSS-Protection waarde", + "detail_web_appsecpriv_http_x_xss_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt geen veilig ingestelde X-XSS-Protection aan.", + "detail_web_appsecpriv_http_x_xss_verdict_good": "OUTDATED TEXT; TEST NOT USED

Je webserver biedt veilig ingestelde X-XSS-Protection aan.", + "detail_web_dnssec_exists_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, ondertekend is met DNSSEC.

Als een domein via CNAME doorverwijst naar een ander domein, dan checken we (conform de DNSSEC-standaard) ook of het CNAME-domein ondertekend is met DNSSEC. Als het CNAME-domein niet ondertekend is, dan zal deze subtest een negatief resultaat tonen.

Let op: de geldigheid van de ondertekening wordt niet getest in deze subtest maar wel in de volgende subtest.", + "detail_web_dnssec_exists_label": "DNSSEC aanwezigheid", + "detail_web_dnssec_exists_tech_table": "Domein|Registrar", + "detail_web_dnssec_exists_tech_table_domain": "Domein", + "detail_web_dnssec_exists_tech_table_registrar": "Registrar", + "detail_web_dnssec_exists_verdict_bad": "Je domein is onveilig oftewel 'insecure', omdat het niet ondertekend is met DNSSEC.", + "detail_web_dnssec_exists_verdict_good": "Je domein is met DNSSEC ondertekend.", + "detail_web_dnssec_exists_verdict_resolver_error": "Helaas is in de resolver van Internet.nl een fout opgetreden. Neem a.j.b. contact met ons op.", + "detail_web_dnssec_exists_verdict_servfail": "De nameservers van je domeinnaam zijn kapot. Ze gaven een foutmelding (SERVFAIL) terug op onze bevragingen voor een DNSSEC-handtekening. Vraag de nameserver-beheerder (vaak je registrar en/of hostingprovider) om dit spoedig op te lossen.", + "detail_web_dnssec_valid_exp": "We testen of je domeinnaam, meer specifiek het SOA-record, is ondertekend met een geldige DNSSEC-handtekening.

Als een domeinnaam via CNAME verwijst naar een ander ondertekend domeinnaam, dan checken we (conform de DNSSEC-standaard) ook of de ondertekening van het CNAME-domein geldig is. Als de ondertekening van de CNAME-domeinnaam niet geldig is, dan zal deze subtest een negatief resultaat tonen.

Merk op dat we alleen de nameserver testen die als eerste reageert. Als nameservers van een domeinnaam inconsistente configuraties hebben, kan dit leiden tot variërende testresultaten. In dat geval kan het resultaat voor deze subtest bijvoorbeeld de ene keer 'secure' en de andere keer 'bogus' zij", + "detail_web_dnssec_valid_label": "DNSSEC geldigheid", + "detail_web_dnssec_valid_tech_table": "Domein|Status", + "detail_web_dnssec_valid_tech_table_domain": "Domein", + "detail_web_dnssec_valid_tech_table_status": "Status", + "detail_web_dnssec_valid_verdict_bad": "Je domeinnaam is onbetrouwbaar oftewel 'bogus', omdat de DNSSEC-handtekening niet geldig is. Óf iemand manipuleerde het antwoord van jouw nameserver, óf je domeinnaam heeft een serieuze DNSSEC-configuratiefout. Dit laatste maakt je domeinnaam onbereikbaar voor alle gebruikers die DNSSEC-handtekeningen controleren. Neem zo spoedig mogelijk contact op met je nameserver-beheerder (vaak je registrar of hostingprovider).", + "detail_web_dnssec_valid_verdict_good": "Je domeinnaam is veilig oftewel 'secure', omdat zijn DNSSEC-handtekening geldig is.", + "detail_web_dnssec_valid_verdict_unsupported_ds_algo": "Je domeinnaam is ondertekend met een algoritme dat onze validerende resolver momenteel nog niet ondersteunt. Daardoor zijn we niet in staat de geldigheid van zijn DNSSEC-handtekening te controleren.", + "detail_web_ipv6_web_aaaa_exp": "We testen of er tenminste één AAAA-record met IPv6-adres voor je webserver is.

'IPv4-mapped IPv6 addresses' (RFC 4291, beginnend met ::ffff:) zullen falen in deze subtest, aangezien zij geen IPv6-connectiviteit bieden.", + "detail_web_ipv6_web_aaaa_label": "IPv6-adressen voor webserver", + "detail_web_ipv6_web_aaaa_tech_table": "Webserver|IPv6-adres|IPv4-adres", + "detail_web_ipv6_web_aaaa_tech_table_web_server": "Webserver", + "detail_web_ipv6_web_aaaa_tech_table_ipv6_address": "IPv6-adres", + "detail_web_ipv6_web_aaaa_tech_table_ipv4_address": "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 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 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_tech_table_web_server": "Webserver", + "detail_web_ipv6_web_reach_tech_table_unreachable_ipv6_address": "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.", + "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_tech_table_web_server": "Webserver", + "detail_web_rpki_exists_tech_table_ip_address": "IP-adres", + "detail_web_rpki_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_web_server": "Webserver", + "detail_web_rpki_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_rpki_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_rpki_valid_tech_table_rpki_origin_validation_state": "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 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", + "detail_web_tls_cert_hostmatch_tech_table": "Webserver-IP-adres|Niet-overeenkomende domeinen op certificaat", + "detail_web_tls_cert_hostmatch_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_hostmatch_tech_table_unmatched_domains_on_certificate": "Niet-overeenkomende domeinen op certificaat", + "detail_web_tls_cert_hostmatch_verdict_bad": "De domeinnaam van je website komt niet overeen met de domeinnaam op je websitecertificaat.", + "detail_web_tls_cert_hostmatch_verdict_good": "De domeinnaam van je website komt overeen met de domeinnaam op je websitecertificaat.", + "detail_web_tls_cert_pubkey_exp": "

We testen of de (ECDSA of RSA) digitale handtekening van je websitecertificaat veilige parameters gebruikt.

Bij de verificatie van certificaten wordt gebruik gemaakt van digitale handtekeningen. Om de authenticiteit van de verbindingte garanderen, moet een betrouwbaar algoritme voor certificaatverificatie gekozen worden. Het algoritme dat gebruikt wordt om een certificaat te ondertekenen, wordt door de certificaatleverancier geselecteerd.

Het certificaat specificeert het algoritme voor digitale handtekeningen dat tijdens de sleuteluitwisseling door zijn eigenaar wordt gebruikt. Het is mogelijk om meerdere certificaten te configureren, zodat er ook meer dan één algoritme ondersteund kan worden.

De veiligheid van de ECDSA-digitale-handtekeningen is afhankelijk van de geselecteerde kromme. De veiligheid van RSA voor de versleuteling en digitale handtekeningen houdt verband met de sleutellengte van de publieke sleutel.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, richtlijn B5-1 en tabel 9 voor ECDSA, en richtlijn B3-3 en tabel 8 voor RSA.

Elliptische krommen voor ECDSA

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

Lengte van RSA-sleutels

  • Goed: Minimaal 3072 bit
  • Voldoende: 2048 – 3071 bit
  • Onvoldoende: Minder dan 2048 bit
", + "detail_web_tls_cert_pubkey_label": "Publieke sleutel van certificaat", + "detail_web_tls_cert_pubkey_tech_table": "Webserver-IP-adres|Getroffen handtekening-parameters|Status", + "detail_web_tls_cert_pubkey_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_pubkey_tech_table_affected_signature_parameters": "Getroffen handtekening-parameters", + "detail_web_tls_cert_pubkey_tech_table_status": "Status", + "detail_web_tls_cert_pubkey_verdict_bad": "De digitale handtekening van je websitecertificaat gebruikt onvoldoende veilige parameters.", + "detail_web_tls_cert_pubkey_verdict_good": "De digitale handtekening van je websitecertificaat gebruikt veilige parameters.", + "detail_web_tls_cert_pubkey_verdict_phase_out": "De digitale handtekening van je websitecertificaat gebruikt parameters die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_cert_signature_exp": "

We testen of de ondertekende fingerprint van het websitecertificaat is gemaakt met een veilig algoritme voor hashing.

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

Hashfuncties voor certificaatverificatie

  • Goed: SHA-512, SHA-384, SHA-256
  • Onvoldoende: SHA-1, MD5
", + "detail_web_tls_cert_signature_label": "Handtekening van certificaat", + "detail_web_tls_cert_signature_tech_table": "Webserver-IP-adres|Getroffen hashing-algoritme|Status", + "detail_web_tls_cert_signature_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_signature_tech_table_affected_hash_algorithm": "Getroffen hashing-algoritme", + "detail_web_tls_cert_signature_tech_table_status": "Status", + "detail_web_tls_cert_signature_verdict_bad": "Je websitecertificaat is ondertekend met een algoritme voor hashing dat onvoldoende veilig is.", + "detail_web_tls_cert_signature_verdict_good": "Je websitecertificaat is ondertekend met een voldoende algoritme voor hashing.", + "detail_web_tls_cert_trust_exp": "We testen of we een geldige vertrouwensketen voor je websitecertificaat kunnen opbouwen.

Er is sprake van een geldige vertrouwensketen, als je certificaat is uitgegeven door een publiekelijk vertrouwde certificaatautoriteit én je webserver alle noodzakelijke tussenliggende certificaten presenteert.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, richtlijn B3-4.", + "detail_web_tls_cert_trust_label": "Vertrouwensketen van certificaat", + "detail_web_tls_cert_trust_tech_table": "Webserver-IP-adres|Onvertrouwde certificaatketen", + "detail_web_tls_cert_trust_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_cert_trust_tech_table_untrusted_certificate_chain": "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-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_tech_table_web_server_ip_address": "Webserver IP-adres", + "detail_web_tls_cipher_order_tech_table_first_found_affected_cipher_pair": "Eerst gevonden getroffen cipher-paren", + "detail_web_tls_cipher_order_tech_table_violated_rule_ii_b": "Overtreden regel # ('II-B')", + "detail_web_tls_cipher_order_verdict_bad": "Je webserver dwingt niet zijn eigen cipher-voorkeur af ('I').", + "detail_web_tls_cipher_order_verdict_good": "Je webserver dwingt zijn eigen cipher-voorkeur af ('I'), en biedt ciphers aan conform de voorgeschreven volgorde ('II').", + "detail_web_tls_cipher_order_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver alleen 'Goede' ciphers ondersteunt.", + "detail_web_tls_cipher_order_verdict_seclevel_bad": "Je webserver prefereert niet 'Goede' boven 'Voldoende' en dan pas 'Uit te faseren' ciphers ('II').", + "detail_web_tls_cipher_order_verdict_warning": "OUTDATED TEXT; VERDICT NOT USED

Je webserver biedt niet ciphers aan conform de voorgeschreven volgorde binnen een bepaald veiligheidsniveau ('II-B').", + "detail_web_tls_ciphers_exp": "

We testen of je webserver alleen veilige, d.w.z. 'Goede' en/of 'Voldoende', ciphers (ook algoritmeselecties genoemd) ondersteunt.

Een algoritmeselectie bestaat uit ciphers voor vier cryptografische functies: 1) sleuteluitwisseling, 2) certificaatverificatie, 3) bulkversleuteling, en 4) hashing. Een webserver kan meer dan één algoritmeselectie ondersteunen.

  • Vanaf TLS 1.3 omvat de term 'cipher suite' alleen ciphers voor bulkversleuteling en hashing. Als TLS 1.3 gebruikt wordt dan zijn de ciphers voor sleuteluitwisseling en certificaatverificatie onderhandelbaar en niet langer onderdeel van de naam van de cipher suite. Omdat dit de term 'cipher suite' ambigu maakt, gebruikt NCSC de term 'algoritmeselectie' om alle vier de functies aan te duiden.
  • NCSC gebruikt de IANA-naamgeving voor algoritmeselecties. Internet.nl hanteert de OpenSSL-naamgeving. Vanaf TLS 1.3 volgt OpenSSL de IANA-naamgeving. Een vertaling tussen beide is onderdeel van de OpenSSL-documentation.
  • Merk op dat ciphers die PSK of SRP gebruiken voor sleuteluitwisseling (die onvoldoende veilig zijn) in deze test niet worden gedetecteerd vanwege een beperking die samenhangt met onze testwijze.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, richtlijn B2-1 t/m B2-4 en tabel 2, 4, 6 en 7.

Hieronder staan 'Goede', 'Voldoende' en 'Uit te faseren' algoritmeselecties in de door NCSC voorgeschreven volgorde, gebaseerd op bijlage C van de 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.0'. Achter iedere algoritmeselectie noemen we de minimale TLS-versie (bijv. [1.2]) die deze algoritmeselectie ondersteunt en die tenminste 'Uit te faseren' is.

Goed:

  • ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
  • ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
  • ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]

Voldoende:

  • ECDHE-ECDSA-AES256-SHA384 [1.2]
  • ECDHE-ECDSA-AES256-SHA [1.0]
  • ECDHE-ECDSA-AES128-SHA256 [1.2]
  • ECDHE-ECDSA-AES128-SHA [1.0]
  • ECDHE-RSA-AES256-SHA384 [1.2]
  • ECDHE-RSA-AES256-SHA [1.0]
  • ECDHE-RSA-AES128-SHA256 [1.2]
  • ECDHE-RSA-AES128-SHA [1.0]
  • DHE-RSA-AES256-GCM-SHA384 [1.2]
  • DHE-RSA-CHACHA20-POLY1305 [1.2]
  • DHE-RSA-AES128-GCM-SHA256 [1.2]
  • DHE-RSA-AES256-SHA256 [1.2]
  • DHE-RSA-AES256-SHA [1.0]
  • DHE-RSA-AES128-SHA256 [1.2]
  • DHE-RSA-AES128-SHA [1.0]

Uit te faseren:

  • ECDHE-ECDSA-DES-CBC3-SHA [1.0]
  • ECDHE-RSA-DES-CBC3-SHA [1.0]
  • DHE-RSA-DES-CBC3-SHA [1.0]
  • AES256-GCM-SHA384 [1.2]
  • AES128-GCM-SHA256 [1.2]
  • AES256-SHA256 [1.2]
  • AES256-SHA [1.0]
  • AES128-SHA256 [1.2]
  • AES128-SHA [1.0]
  • DES-CBC3-SHA [1.0]
", + "detail_web_tls_ciphers_label": "Ciphers (Algoritmeselecties)", + "detail_web_tls_ciphers_tech_table": "Webserver-IP-adres|Getroffen ciphers|Status", + "detail_web_tls_ciphers_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_ciphers_tech_table_affected_ciphers": "Getroffen ciphers", + "detail_web_tls_ciphers_tech_table_status": "Status", + "detail_web_tls_ciphers_verdict_bad": "Je webserver ondersteunt een of meer onvoldoende veilige ciphers.", + "detail_web_tls_ciphers_verdict_good": "Je webserver ondersteunt alleen veilige ciphers.", + "detail_web_tls_ciphers_verdict_phase_out": "Je webserver ondersteunt een of meer ciphers die de status uit te faseren hebben omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_compression_exp": "

We testen of je webserver TLS-compressie ondersteunt.

Het gebruik van compressie kan een aanvaller informatie bieden over geheime delen van versleutelde communicatie. Een aanvaller die in staat is om een deel van de verzonden data te achterhalen of te beïnvloeden, kan door middel van een groot aantal verzoeken stukje bij beetje de oorspronkelijke data reconstrueren. TLS-compressie wordt zo weinig gebruikt dat het geen kwaadkan om deze optie uit te schakelen.

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

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", + "detail_web_tls_compression_label": "TLS-compressie", + "detail_web_tls_compression_tech_table": "Webserver-IP-adres|TLS-compressie", + "detail_web_tls_compression_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_compression_tech_table_tls_compression": "TLS-compressie", + "detail_web_tls_compression_verdict_bad": "Je webserver ondersteunt TLS-compressie, wat niet veilig is.", + "detail_web_tls_compression_verdict_good": "Je webserver ondersteunt geen TLS-compressie.", + "detail_web_tls_dane_exists_exp": "We testen of de nameserver van je websitedomein een correct ondertekend TLSA-record voor DANE bevat.

Aangezien DNSSEC een noodzakelijke randvoorwaarde is voor DANE, zal een domeinnaam niet slagen voor de test als DNSSEC ontbreekt op het websitedomein, of als er DANE-gerelateerde DNSSEC-issues zijn (bijv. geen bewijs voor 'Denial of Existence').

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, Appendix A, onder 'Certificate pinning en DANE'.

Niveau van vereistheid: Optioneel", + "detail_web_tls_dane_exists_label": "DANE aanwezigheid", + "detail_web_tls_dane_exists_tech_table": "Webserver-IP-adres|DANE TLSA-record aanwezig", + "detail_web_tls_dane_exists_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_dane_exists_tech_table_dane_tlsa_record_existent": "DANE TLSA-record aanwezig", + "detail_web_tls_dane_exists_verdict_bad": "Je websitedomein bevat geen TLSA-record voor DANE.", + "detail_web_tls_dane_exists_verdict_bogus": "Je websitedomein bevat geen DNSSEC-bewijs dat DANE TLSA-records niet bestaan. Vraag je nameserver-beheerder om deze fout op te lossen.", + "detail_web_tls_dane_exists_verdict_good": "Je websitedomein bevat een TLSA-record voor DANE.", + "detail_web_tls_dane_rollover_exp": "

OUTDATED TEXT; TEST NOT USED

We check if your website domain has a proper DANE rolloverscheme to handle DANE certificate rollovers. Having a DANE rollover schemein place is not required. It will be proven useful when there is a need toupdate your DANE certificate and you want to ensure that DANE validationwill continue to work during the transition period. The way to achievethis is by publishing two different TLSA records. The configurations ofthe TLSA record types are the following:

  • record type 3 1 1 (current key) + record type 3 1 1 (future key), or
  • record type 3 1 1 (current key) + record type 2 1 1 (trusted CA).
", + "detail_web_tls_dane_rollover_label": "OUTDATED TEXT; TEST NOT USED

DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table": "OUTDATED TEXT; TEST NOT USED

Web server IP address|DANE rollover scheme", + "detail_web_tls_dane_rollover_tech_table_outdated_text_test_not_used_web_server_ip_address": "OUTDATED TEXT; TEST NOT USED

Web server IP address", + "detail_web_tls_dane_rollover_tech_table_dane_rollover_scheme": "DANE rollover scheme", + "detail_web_tls_dane_rollover_verdict_bad": "OUTDATED TEXT; TEST NOT USED

Your website domain does not have a proper scheme forrolling DANE certificates.", + "detail_web_tls_dane_rollover_verdict_good": "OUTDATED TEXT; TEST NOT USED

Your website domain has a proper scheme for rolling DANEcertificates.", + "detail_web_tls_dane_valid_exp": "We testen of de DANE-fingerprint die je domein presenteert geldig is voor je websitecertificaat.

Met DANE kan je informatie over jouw websitecertificaat publiceren in een speciaal DNS-record, een TLSA-record. Clients, zoals webbrowsers, kunnen het certificaat nu niet alleen via de certificaatautoriteit, maar ook via het TLSA-record controleren op authenticiteit. Een client kan het TLSA-record ook als signaal gebruiken om alleen via HTTPS (en niet via HTTP) te verbinden. DNSSEC is een noodzakelijke randvoorwaarde voor DANE. Helaas ondersteunen nog niet veel webbrowsers DANE-validatie.

Niveau van vereistheid: Aanbevolen (alleen als subtest voor 'DANE aanwezigheid' is geslaagd)", + "detail_web_tls_dane_valid_label": "DANE geldigheid", + "detail_web_tls_dane_valid_tech_table": "Webserver-IP-adres|DANE TLSA-record geldig", + "detail_web_tls_dane_valid_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_dane_valid_tech_table_dane_tlsa_record_valid": "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_label": "Sleuteluitwisselingsparameters", + "detail_web_tls_fs_params_tech_table": "Webserver-IP-adres|Getroffen parameters|Status", + "detail_web_tls_fs_params_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_fs_params_tech_table_affected_parameters": "Getroffen parameters", + "detail_web_tls_fs_params_tech_table_status": "Status", + "detail_web_tls_fs_params_verdict_bad": "Je webserver ondersteunt onvoldoende veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_web_tls_fs_params_verdict_good": "Je webserver ondersteunt veilige parameters voor Diffie-Hellman-sleuteluitwisseling.", + "detail_web_tls_fs_params_verdict_na": "Deze subtest is niet van toepassing, omdat je webserver niet Diffie-Hellman-sleuteluitwisseling ondersteunt. Let op: RSA is een alternatief voor sleuteluitwisseling, maar heeft de status uit te faseren.", + "detail_web_tls_fs_params_verdict_phase_out": "Je webserver ondersteunt parameters voor Diffie-Hellman-sleuteluitwisseling die de status uit te faseren hebben, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_http_compression_exp": "

We testen of je webserver HTTP-compressie ondersteunt.

Bij het HTTP-protocol wordt compressie vaak gebruikt om de beschikbare bandbreedte efficiënter te gebruiken. HTTP-compressie maakt de beveiligde verbinding met je webserver echter kwetsbaar voor de BREACH-aanval. Weeg de voors en tegens van HTTP-compressie zorgvuldig tegen elkaar af. Wanneer u kiest voor het gebruik van HTTP-compressie, ga dan na of het mogelijk is om hieruit voortvloeiende potentiële applicatie-aanvallen te beperken. Een voorbeeld van een dergelijke maatregel is het beperken van de mate waarin een aanvaller de respons van de server kan beïnvloeden.

Dit testonderdeel controleert of de webserver op rootdirectory-niveau HTTP-compressie ondersteunt, maar controleert geen andere websitebronnen zoals plaatje en scripts.

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

Niveau van vereistheid: Optioneel

Compressie-optie

  • Goed: Geen compressie
  • Voldoende: Compressie op applicatieniveau (in dit geval HTTP-compressie)
  • Onvoldoende: TLS-compressie
", + "detail_web_tls_http_compression_label": "HTTP-compressie", + "detail_web_tls_http_compression_tech_table": "Webserver-IP-adres|HTTP-compressie", + "detail_web_tls_http_compression_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_http_compression_tech_table_http_compression": "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.

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_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_https_exists_tech_table_https_existent": "HTTPS aanwezig", + "detail_web_tls_https_exists_verdict_bad": "Je website biedt geen HTTPS aan.", + "detail_web_tls_https_exists_verdict_good": "Je website biedt HTTPS aan.", + "detail_web_tls_https_exists_verdict_other": "Je webserver is niet bereikbaar.", + "detail_web_tls_https_forced_exp": "We testen of je webserver bezoekers automatisch doorverwijst van HTTP naar HTTPS op dezelfde domeinnaam (via een 3xx redirect status code zoals 301 en 302), óf dat deze ondersteuning biedt voor alleen HTTPS en niet voor HTTP.

In geval van doorverwijzing moet de domeinnaam eerst zelf 'upgraden' door een redirect naar zijn HTTPS-versie, voordat deze eventueel doorverwijst naar een andere domeinnaam. Dit zorgt er ook voor dat een webbrowser de HSTS-policy kan accepteren. Voorbeelden van correcte redirect-volgorde:

  • http://example.nl ⇒ https://example.nl ⇒ https://www.example.nl
  • http://www.example.nl ⇒ https://www.example.nl

Merk op dat deze subtest alleen test of de opgegeven domeinnaam goed doorverwijst van HTTP naar HTTPS. Een eventuele verdere doorverwijzing naar een andere domeinnaam (inclusief een subdomeinnaam van het geteste domeinnaam) wordt niet getest. Je kan een afzonderlijke test starten om een dergelijke domeinnaam waarnaar wordt doorverwezen zelf te testen.

Zie 'Webapplicatie-richtlijnen, Verdieping' van NCSC, richtlijn U/WA.05.", + "detail_web_tls_https_forced_label": "HTTPS-doorverwijzing", + "detail_web_tls_https_forced_tech_table": "Webserver-IP-adres|HTTPS-doorverwijzing", + "detail_web_tls_https_forced_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_https_forced_tech_table_https_redirect": "HTTPS-doorverwijzing", + "detail_web_tls_https_forced_verdict_bad": "Je webserver ondersteunt zowel HTTP als HTTPS, maar verwijst bezoekers niet automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", + "detail_web_tls_https_forced_verdict_good": "Je webserver verwijst bezoekers automatisch door van HTTP naar HTTPS op dezelfde domeinnaam.", + "detail_web_tls_https_forced_verdict_no_https": "Deze test is niet uitgevoerd, omdat je webserver geen HTTPS biedt of alleen HTTPS met een te verouderde, onveilige TLS-configuratie.", + "detail_web_tls_https_forced_verdict_other": "Je webserver biedt alleen ondersteuning voor HTTPS en niet voor HTTP.", + "detail_web_tls_https_hsts_exp": "We testen of je webserver HSTS ondersteunt.

Browsers onthouden HSTS per (sub-)domein. Het niet toevoegen van HSTS voor ieder (sub-)domein (in een redirect-keten) kan gebruikers kwetsbaar maken voor MITM-aanvallen. Om die reden testen we HSTS bij het eerste contact, d.w.z. voordat een eventuele doorverwijzing plaatsvindt.

HSTS dwingt af dat een webbrowser direct via HTTPS verbindt bij terugkerend bezoek. Dit helpt man-in-the-middle-aanvallen te voorkomen. Een cache-geldigheidsduur voor HSTS van tenminste 1 jaar (max-age=31536000) achten we voldoende veilig. Een lange geldigheidsduur heeft als voordeel dat ook infrequente bezoekers beschermd zijn. Het nadeel is dat wanneer je wil stoppen met HTTPS (wat over het algemeen een slecht idee is), je langer moet wachten totdat de geldigheid van de HSTS-policy in alle browsers die je website bezochten, is verlopen.

De test controleert niet of preload wordt gebruikt en of het domein is opgenomen in de HSTS Preload Lijst.

Aanbevelingen voor implementatie

HSTS vereist dat je website volledig over HTTPS werkt. Dit houdt ook in dat je website een geldig certificaat moet hebben van een publiekelijk vertrouwde certificaatautoriteit. Dus wanneer je website geen goede ondersteuning voor HTTPS biedt, dan zal deze niet bereikbaar zijn voor browsers die je website eerder hebben benaderd. Een wijziging van je HSTS-policy om de effecten terug te draaien, zal voor deze browsers niet onmiddellijk effect hebben, aangezien zij je vorige HSTS-policy in de cache hebben opgeslagen.

Daarom adviseren we u om de onderstaande implementatiestappen te volgen:

  1. Zorg ervoor dat de website op je domein nu en in de toekomst volledig over HTTPS werkt (o.a. door een gedegen certificaat rollover procedure te hebben);

  2. Verhoog de geldigheidsduur van de HSTS-cache in de onderstaande fasen. Controleer tijdens elke fase zorgvuldig op bereikbaarheidsproblemen en niet goed werkende pagina's. Los eventuele problemen op en wacht dan de volledige cacheduur van de fase af voordat je naar de volgende fase gaat.

  3. Begin met 5 minuten (max-age=300);

  4. Verhoog dit naar 1 week (max-age=604800);
  5. Verhoog dit naar 1 maand (max-age=2592000);

  6. Verhoog het naar 1 jaar (max-age=31536000) of meer.

  7. Herhaal stap 1 en 2 voor elk subdomein dat je met HSTS wilt beveiligen. Gebruik includeSubDomains alleen als je er volledig zeker van bent dat alle (geneste) subdomeinen van je domein HTTPS goed ondersteunen, nu en in de toekomst.

  8. Gebruik preload alleen als je heel zeker weet dat je je domein wil laten opnemen in de HSTS Preload Lijst. HSTS-preloading is vooral interessant voor de meest gevoelige websites. Beheerders die HSTS-preloading voor een bepaald domein willen inschakelen, moeten dit uiterst bedachtzaam doen. Het kan gevolgen hebben voor de bereikbaarheid van het domein en van eventuele subdomeinen, en is niet snel terug te draaien.

Zie 'Webapplicatie-richtlijnen, Verdieping' van NCSC, richtlijn U/WA.05.", + "detail_web_tls_https_hsts_label": "HSTS", + "detail_web_tls_https_hsts_tech_table": "Webserver-IP-adres|HSTS-policy", + "detail_web_tls_https_hsts_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_https_hsts_tech_table_hsts_policy": "HSTS-policy", + "detail_web_tls_https_hsts_verdict_bad": "Je webserver biedt geen HSTS-policy aan.", + "detail_web_tls_https_hsts_verdict_good": "Je webserver biedt een HSTS-policy aan.", + "detail_web_tls_https_hsts_verdict_other": "Je webserver biedt een HSTS-policy aan met een geldigheidsduur voor caching (max-age) die niet voldoende lang (d.w.z. korter dan 1 jaar) is.", + "detail_web_tls_kex_hash_func_exp": "

We testen of je webserver ondersteuning biedt voor veilige hashfuncties om tijdens sleuteluitwisseling de digitale handtekening te maken.

De webserver maakt tijdens de sleuteluitwisseling gebruik van een digitale handtekening om het eigenaarschap te bewijzen van de geheime sleutel die bij het certificaat hoort. De webserver creëert deze digitale handtekening door het ondertekenen van de output van een hashfunctie.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, tabel 5.

Niveau van vereistheid: Aanbevolen

SHA2-ondersteuning voor handtekeningen

  • Goed: Ja (ondersteuning van SHA-256, SHA-384 of SHA-512)
  • Uit te faseren: Nee (geen ondersteuning van SHA-256, SHA-384 of SHA-512)
", + "detail_web_tls_kex_hash_func_label": "Hashfunctie voor sleuteluitwisseling", + "detail_web_tls_kex_hash_func_tech_table": "Webserver-IP-adress|SHA-2-ondersteuning voor handtekeningen", + "detail_web_tls_kex_hash_func_tech_table_web_server_ip_address": "Webserver-IP-adress", + "detail_web_tls_kex_hash_func_tech_table_sha2_support_for_signatures": "SHA-2-ondersteuning voor handtekeningen", + "detail_web_tls_kex_hash_func_verdict_good": "Je webserver ondersteunt een veilige hashfunctie voor sleuteluitwisseling.", + "detail_web_tls_kex_hash_func_verdict_other": "Het was niet mogelijk om vast te stellen welke hashfunctie je webserver gebruikt. Dit kan veroorzaakt worden doordat de gebruikte cipher-combinatie geen handtekening voor certificaatverificatie heeft (bijv. deze gebruikt RSA-sleuteluitwisseling of is anoniem d.w.z. anon).", + "detail_web_tls_kex_hash_func_verdict_phase_out": "Je webserver ondersteunt geen veilige hashfunctie voor sleuteluitwisseling. Deze instelling dien je weloverwogen uit te faseren, omdat deze het risico loopt in de toekomst onvoldoende veilig te worden. ", + "detail_web_tls_ocsp_stapling_exp": "

We testen of je webserver de TLS Certificate Status extension of te wel OCSP stapling ondersteunt.

De webbrowser kan de geldigheid van het certificaat van de webserver via het OCSP-protocol controleren bij de certificaatleverancier. Dat OCSP-protocol verschaft de certificaatleverancier informatie over browsers die met de betreffende webserver communiceren. Dit kan een privacy-risico vormen. Een server kan de OCSP-informatie ook zelf verstrekken (OCSP stapling). Dit lost niet alleen het privacy-risico op, maar vereist ook geen connectiviteit tussen de webbrowser en certificaatleverancier en dit gaat dan ook sneller.

Als we verbinden met je webserver dan verzoeken we via de TLS Certificate Status extension om OCSP-data op te nemen in het antwoord van de webserver. Als je webserver OCSP-data heeft opgenomen in het antwoord, dan verifiëren we of de OCSP-data valide is, d.w.z. correct ondertekend door een bekende certificaatleverancier. Let op: we gebruiken de OCSP-data niet om de geldigheid van het certificaat te controleren.

Zie 'ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS) v2.1' van NCSC, tabel 15.

Niveau van vereistheid: Optioneel

OCSP stapling

  • Goed: Aan
  • Voldoende: Uit
", + "detail_web_tls_ocsp_stapling_label": "OCSP stapling", + "detail_web_tls_ocsp_stapling_tech_table": "Webserver-IP-adres|OCSP stapling", + "detail_web_tls_ocsp_stapling_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_ocsp_stapling_tech_table_ocsp_stapling": "OCSP stapling", + "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_label": "Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_tech_table": "Webserver-IP-adres|Client-initiated renegotiation", + "detail_web_tls_renegotiation_client_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_renegotiation_client_tech_table_client_initiated_renegotiation": "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.", + "detail_web_tls_renegotiation_client_verdict_good": "Je webserver staat geen client-initiated renegotiation toe.", + "detail_web_tls_renegotiation_secure_exp": "

We testen of je webserver secure renegotiation ondersteunt.

In de oudere versies van TLS (vóór TLS 1.3) is het tot stand brengen van een nieuwe handshake toegestaan. Dit zogeheten 'opnieuw onderhandelen' (renegotiation) was in het oorspronkelijke ontwerp onveilig. Inmiddels is de standaard gerepareerd en is er een veiliger renegotiation-mechanisme beschikbaar. De oude versie wordt sindsdien als insecure renegotiation aangeduid en deze moet derhalve uitgeschakeld worden.

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

Insecure renegotiation

  • Goed: Uit (of n.v.t. voor TLS 1.3)
  • Onvoldoende: Aan
", + "detail_web_tls_renegotiation_secure_label": "Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table": "Webserver-IP-adres|Secure renegotiation", + "detail_web_tls_renegotiation_secure_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_renegotiation_secure_tech_table_secure_renegotiation": "Secure renegotiation", + "detail_web_tls_renegotiation_secure_verdict_bad": "Je webserver ondersteunt insecure renegotiation, wat uiteraard niet veilig is.", + "detail_web_tls_renegotiation_secure_verdict_good": "Je webserver ondersteunt secure renegotiation.", + "detail_web_tls_version_exp": "

We testen of je webserver alleen veilige TLS-versies ondersteunt.

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

Merk op dat browsermakers hebben aangekondigd dat ze zullen stoppen met de ondersteuning van TLS 1.1 en 1.0. Daardoor zullen websites die geen TLS 1.2 en/of 1.3 ondersteunen onbereikbaar worden.

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_web_tls_version_label": "TLS-versie", + "detail_web_tls_version_tech_table": "Webserver-IP-adres|TLS-versie|Status", + "detail_web_tls_version_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_version_tech_table_tls_version": "TLS-versie", + "detail_web_tls_version_tech_table_status": "Status", + "detail_web_tls_version_verdict_bad": "Je webserver ondersteunt onvoldoende veilige TLS-versies.", + "detail_web_tls_version_verdict_good": "Je webserver ondersteunt alleen veilige TLS-versies.", + "detail_web_tls_version_verdict_phase_out": "Je webserver ondersteunt TLS-versies die je weloverwogen dient uit te faseren, omdat bekend is dat deze fragiel zijn en het risico lopen in de toekomst onvoldoende veilig te worden.", + "detail_web_tls_zero_rtt_exp": "

We testen of je webserver Zero Round Trip Time Resumption (0-RTT) ondersteunt.

0-RTT is een optie in TLS 1.3 waarmee applicatiedata wordt getransporteerd tijdens het eerste handshake-bericht. 0-RTT biedt echter geen bescherming tegen replay-aanvallen op de TLS-laag en dient daarom uitgezet te worden. Alhoewel het risico gemitigeerd kan worden door 0-RTT niet toe te staan voor non-idempotent requests, is een dergelijke configuratie vaak niet triviaal, afhankelijk van applicatielogica en daardoor foutgevoelig.

Als je webserver geen TLS 1.3 ondersteunt, dan is deze test niet van toepassing. Voor webservers die TLS 1.3 ondersteunen, wordt de indexpagina / opgehaald via TLS 1.3 en daarbij wordt de omvang van de ondersteuning voor early data zoals aangegeven door de webserver gecontroleerd. Indien deze groter is dan nul, dan wordt een tweede verbinding gemaakt waarbij de TLS-sessiedetails van de eerste connectie worden hergebruikt maar de HTTP opvraging vóór de TLS handshake plaatsvindt (d.w.z. geen round trips (0-RTT) nodig voordat applicatiedata naar de server gaat). Als de TLS handshake slaagt en de webserver antwoordt met een non-HTTP 425 Too Early, dan wordt aangenomen dat de webserver 0-RTT ondersteunt.

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

0-RTT

  • Goed: Uit (of n.v.t. voor oudere versies dan TLS 1.3)
  • Onvoldoende: Aan
", + "detail_web_tls_zero_rtt_label": "0-RTT", + "detail_web_tls_zero_rtt_tech_table": "Webserver-IP-adres|0-RTT", + "detail_web_tls_zero_rtt_tech_table_web_server_ip_address": "Webserver-IP-adres", + "detail_web_tls_zero_rtt_tech_table_0_rtt": "0-RTT", + "detail_web_tls_zero_rtt_verdict_bad": "Je webserver ondersteunt 0-RTT, wat niet veilig is.", + "detail_web_tls_zero_rtt_verdict_good": "Je webserver ondersteunt geen 0-RTT.", + "detail_web_tls_zero_rtt_verdict_na": "Deze subtest is niet van toepassing aangezien je webserver TLS 1.3 niet ondersteunt. ", + "detail_web_mail_ipv6_ns_aaaa_exp": "We testen of je domeinnaam tenminste twee nameservers met een IPv6-adres heeft.

Dit sluit aan bij de \"Technische eisen voor registratie en gebruik van .nl-domeinnamen\" d.d. 13 november 2017 van SIDN (beheerder van het .nl-domein) waarin staat dat iedere .nl-domeinnaam tenminste twee nameservers moeten hebben.

'IPv4-mapped IPv6 addresses' (RFC 4291, beginnend met ::ffff:) zullen falen in deze test, aangezien zij geen IPv6-connectiviteit bieden.", + "detail_web_mail_ipv6_ns_aaaa_label": "IPv6-adressen voor nameservers", + "detail_web_mail_ipv6_ns_aaaa_tech_table": "Nameserver|IPv6-adres|IPv4-adres", + "detail_web_mail_ipv6_ns_aaaa_tech_table_name_server": "Nameserver", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv6_address": "IPv6-adres", + "detail_web_mail_ipv6_ns_aaaa_tech_table_ipv4_address": "IPv4-adres", + "detail_web_mail_ipv6_ns_aaaa_verdict_bad": "Geen van de nameservers van je domeinnaam heeft een IPv6-adres.", + "detail_web_mail_ipv6_ns_aaaa_verdict_good": "Twee of meer nameservers van je domeinnaam hebben een IPv6-adres.", + "detail_web_mail_ipv6_ns_aaaa_verdict_other": "Slechts één nameserver van je domeinnaam heeft een IPv6-adres.", + "detail_web_mail_ipv6_ns_reach_exp": "We testen of alle nameservers, die een AAAA-record met IPv6-adres hebben, bereikbaar zijn via IPv6.", + "detail_web_mail_ipv6_ns_reach_label": "IPv6-bereikbaarheid van nameservers", + "detail_web_mail_ipv6_ns_reach_tech_table": "Nameserver|Onbereikbaar IPv6-adres", + "detail_web_mail_ipv6_ns_reach_tech_table_name_server": "Nameserver", + "detail_web_mail_ipv6_ns_reach_tech_table_unreachable_ipv6_address": "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.", + "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_tech_table_name_server": "Nameserver", + "detail_web_mail_rpki_ns_exists_tech_table_ip_address": "IP-adres", + "detail_web_mail_rpki_ns_exists_tech_table_rpki_route_origin_authorization": "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.

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_tech_table_name_server": "Nameserver", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_prefix": "BGP Route Prefix", + "detail_web_mail_rpki_ns_valid_tech_table_bgp_route_origin_asn": "BGP Route Origin ASN", + "detail_web_mail_rpki_ns_valid_tech_table_rpki_origin_validation_state": "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 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", + "faqs_report_subtest_good": "Goed: geslaagd voor VEREISTE, AANBEVOLEN of OPTIONELE subtest ⇒ eerste: volledige score / laatste twee: geen impact op score", + "faqs_report_subtest_info": "Ter informatie: gezakt voor OPTIONELE subtest ⇒ geen impact op score", + "faqs_report_subtest_not_tested": "Niet getest, want al gezakt voor gerelateerde bovenliggende subtest ⇒ nulscore", + "faqs_report_subtest_title": "Iconen per subtest", + "faqs_report_subtest_warning": "Waarschuwing: gezakt voor AANBEVOLEN subtest ⇒ geen impact op score", + "faqs_report_test_bad": "Slecht: gezakt voor tenminste één VEREISTE subtest ⇒ geen volledige score voor testcategorie", + "faqs_report_test_error": "Testfout: uitvoeringsfout voor tenminste één subtest ⇒ geen resultaat voor testcategorie", + "faqs_report_test_good": "Goed: geslaagd voor alle subtesten ⇒ volledige score voor testcategorie ", + "faqs_report_test_info": "Ter informatie: gezakt voor tenminste één OPTIONELE subtest ⇒ volledige score voor testcategorie", + "faqs_report_test_title": "Iconen per testcategorie", + "faqs_report_test_warning": "Waarschuwing: gezakt voor tenminste één AANBEVOLEN subtest ⇒ volledige score voor testcategorie ", + "faqs_report_title": "Toelichting op testrapport", + "faqs_rpki_title": "Autorisatie voor routering (RPKI)", + "faqs_starttls_title": "Beveiligd e-mailtransport (STARTTLS en DANE)", + "faqs_title": "Kennisbank", + "halloffame_champions_menu": "Kampioenen!", + "halloffame_champions_subtitle": "100% in website- én e-mailtest", + "halloffame_champions_text": "De {{count}} onderstaande domeinnamen scoren 100% in zowel de websitetest als de e-mailtest. Leden van deze Hall of Fame mogen beide 100%-badges gebruiken.", + "halloffame_champions_title": "Hall of Fame - Kampioenen!", + "halloffame_mail_badge": "Badge met tekst: 100%-score in e-mailtest", + "halloffame_mail_menu": "E-mail", + "halloffame_mail_subtitle": "100% in e-mailtest", + "halloffame_mail_text": "De {{count}} onderstaande domeinnamen scoren 100% in de e-mailtest. Leden van deze Hall of Fame mogen de 100%-badge voor mail gebruiken.", + "halloffame_mail_title": "Hall of Fame - E-mail", + "halloffame_web_badge": "Badge met tekst: 100%-score in websitetest", + "halloffame_web_menu": "Websites", + "halloffame_web_subtitle": "100% in websitetest", + "halloffame_web_text": "De {{count}} onderstaande domeinnamen scoren 100% in de websitetest. Leden van deze Hall of Fame mogen de 100%-badge voor websites gebruiken.", + "halloffame_web_title": "Hall of Fame - Websites", + "home_pagetitle": "Test voor moderne Internetstandaarden zoals IPv6, DNSSEC, HTTPS, DMARC, STARTTLS en DANE.", + "home_stats_connection": "unieke verbindingen", + "home_stats_connection_items": "", + "home_stats_header": "Tests in cijfers", + "home_stats_mail": "unieke mail-domeinen", + "home_stats_mail_items": "", + "home_stats_notpassed": "0-99%:", + "home_stats_passed": "100%:", + "home_stats_website": "unieke web-domeinen", + "home_stats_website_items": "", + "home_teaser": "Moderne Internetstandaarden zorgen voor meer betrouwbaarheid en verdere groei van het Internet.
Gebruik jij ze al?", + "mail_pagetitle": "E-mailtest:", + "mail_title": "E-mailtest: {{prettyaddr}}", + "mail_tweetmessage": "De%20mailserver%20op%20{{report.domain}}%20scoort%20{{score}}%25%20in%20de%20e-mailtest%20van%20%40Internet_nl%3A", + "page_gotocontents": "Ga naar tekst-inhoud", + "page_gotofooter": "Ga naar de footer", + "page_gotomainmenu": "Ga naar het hoofd-menu", + "page_metadescription": "Test voor moderne Internetstandaarden IPv6, DNSSEC, HTTPS, HSTS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI en security.txt", + "page_metakeywords": "IPv6, DNSSEC, HTTPS, HSTS, TLS, DMARC, DKIM, SPF, STARTTLS, DANE, RPKI, security.txt, CSP, Content Security Policy, security headers, test, testtool, testen, check, controle, internet, internetstandaarden, open standaarden, moderne standaarden, beveiliging, security, internetbeveiliging, mail, e-mailbeveiliging, website, websitebeveiliging, internetverbinding, beveiligde verbinding, e-mailauthenticatie, encryptie, versleuteling, ciphers, cipher suites, PKI, SSL certificaat, TLS certificaat, websitecertificaat, Platform Internetstandaarden", + "page_sitedescription": "Is jouw internet up-to-date?", + "page_sitetitle": "Internet.nl", + "page404_title": "Pagina niet gevonden!", + "probes_auto_redirect": "Als de test gereed is, word je automatisch doorgestuurd naar de resultaatpagina.", + "probes_no_javascript": "Controleer of de testresultaten beschikbaar zijn. Zo niet, dan word je automatisch teruggeleid naar deze pagina.", + "probes_no_javascript_connection": "JavaScript inactief. Activeer JavaScript om de test toch uit te kunnen voeren.", + "probes_no_redirection": "Testfout. Probeer het later opnieuw, of test een andere domeinnaam.", + "probes_test_finished": "Test klaar! Resultaten beschikbaar...", + "probes_test_running": "Bezig...", + "probes_tests_description": "De onderstaande onderdelen worden getest.", + "probes_tests_duration": "Het testen duurt tussen de 5 en {{cache_ttl}} seconden.", + "results_dated_presentation": "Oude resultaatpresentatie. Doe de test opnieuw.", + "results_domain_appsecpriv_http_headers_label": "HTTP security headers", + "results_domain_appsecpriv_other_options_label": "Andere beveiligingsopties", + "results_domain_ipv6_web_server_label": "Webserver", + "results_domain_rpki_web_server_label": "Webserver", + "results_domain_tls_http_headers_label": "HTTP headers", + "results_domain_tls_https_label": "HTTP", + "results_domain_tls_tls_label": "TLS", + "results_domain_mail_ipv6_name_servers_label": "Nameservers van domein", + "results_domain_mail_rpki_name_servers_label": "Nameservers van domein", + "results_domain_mail_tls_certificate_label": "Certificaat", + "results_domain_mail_tls_dane_label": "DANE", + "results_empty_argument_alt_text": "Geen", + "results_explanation_label": "Testuitleg:", + "results_further_testing_connection_label": "Aanvullende verbindingstesten", + "results_further_testing_mail_label": "Aanvullende e-mailtesten", + "results_further_testing_web_label": "Aanvullende websitetesten", + "results_mail_auth_dkim_label": "DKIM", + "results_mail_auth_dmarc_label": "DMARC", + "results_mail_auth_spf_label": "SPF", + "results_mail_dnssec_domain_label": "E-mailadresdomein", + "results_mail_dnssec_mail_servers_label": "Mailserverdomein(en)", + "results_mail_ipv6_mail_servers_label": "Mailserver(s)", + "results_mail_rpki_mail_servers_label": "Mailserver(s)", + "results_mail_rpki_mx_name_servers_label": "Nameservers van mailserver(s)", + "results_mail_tls_starttls_label": "TLS", + "results_no_icon_detail_close": "sluit", + "results_no_icon_detail_open": "open", + "results_no_icon_status_error": "Error", + "results_no_icon_status_failed": "Gezakt", + "results_no_icon_status_info": "Informatie", + "results_no_icon_status_not_tested": "Niet-testbaar", + "results_no_icon_status_passed": "Geslaagd", + "results_no_icon_status_warning": "Suggestie", + "results_panel_button_hide": "Verberg details", + "results_panel_button_show": "Toon details", + "results_perfect_score": "Gefeliciteerd, je domeinnaam wordt spoedig in de Hall of Fame opgenomen!", + "results_permalink": "Permalink testresultaat {{permadate|date:'(Y-m-d H:i T)'}}", + "results_rerun_test": "Herhaal de test", + "results_retest_time": "Seconden tot hertest-mogelijkheid:", + "results_score_description": "Het domein {{prettyaddr}} heeft een testscore van {{score}}%.", + "results_tech_details_label": "Technische details:", + "results_test_direct": "Test direct:", + "results_test_email_label": "Test andere e-mail", + "results_test_website_label": "Test andere website", + "results_test_info": "Toelichting op testrapport", + "results_verdict_label": "Uitslag:", + "test_connipv6_failed_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", + "test_connipv6_failed_summary": "Moderne adressen niet bereikbaar (IPv6)", + "test_connipv6_info_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", + "test_connipv6_info_summary": "Moderne adressen niet bereikbaar (IPv6)", + "test_connipv6_label": "Moderne adressen bereikbaar (IPv6)", + "test_connipv6_passed_description": "Goed gedaan! Je internetprovider heeft je een modern internetadres (IPv6) gegeven. Daardoor kan je andere computers met moderne adressen bereiken.", + "test_connipv6_passed_summary": "Moderne adressen bereikbaar (IPv6)", + "test_connipv6_title": "Moderne adressen bereikbaar?", + "test_connipv6_warning_description": "Helaas! Je internetprovider heeft je geen modern internetadres (IPv6) gegeven, of niet alles correct ingesteld. Je kan daardoor andere computers met moderne adressen niet bereiken. Vraag je internetprovider om volledige IPv6-connectiviteit.", + "test_connipv6_warning_summary": "Moderne adressen niet bereikbaar (IPv6)", + "test_connresolver_failed_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", + "test_connresolver_failed_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", + "test_connresolver_info_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", + "test_connresolver_info_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", + "test_connresolver_label": "Controle van domein-handtekeningen (DNSSEC)", + "test_connresolver_passed_description": "Goed gedaan! Domein-handtekeningen (DNSSEC) worden voor jou gecontroleerd. Daardoor ben je beschermd tegen vervalste vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen.", + "test_connresolver_passed_summary": "Domein-handtekeningen gecontroleerd (DNSSEC)", + "test_connresolver_title": "Domein-handtekeningen gecontroleerd?", + "test_connresolver_warning_description": "Helaas! Domein-handtekeningen (DNSSEC) worden voor jou nu niet gecontroleerd. Daardoor ben je niet beschermd tegen gemanipuleerde vertaling van ondertekende domeinnamen naar kwaadaardige IP-adressen. Vraag je internetprovider om DNSSEC-validatie en/of activeer het op je eigen systemen.", + "test_connresolver_warning_summary": "Domein-handtekeningen niet gecontroleerd (DNSSEC)", + "test_error_summary": "Fout tijdens uitvoering van test!", + "test_mailauth_failed_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", + "test_mailauth_failed_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_mailauth_info_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", + "test_mailauth_info_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_mailauth_label": "Echtheidswaarmerken tegen phishing (DMARC, DKIM en SPF)", + "test_mailauth_passed_description": "Goed gedaan! Je domein bevat alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails.", + "test_mailauth_passed_summary": "Echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_mailauth_title": "Echtheidswaarmerken tegen e-mailphishing?", + "test_mailauth_warning_description": "Helaas! Je domein bevat niet alle echtheidswaarmerken tegen e-mailvervalsing (DMARC, DKIM en SPF). Ontvangers kunnen daardoor niet betrouwbaar phishing- of spammails die jouw domeinnaam in hun afzenderadres misbruiken, scheiden van jouw echte e-mails. Vraag je mailprovider om DMARC, DKIM en SPF te activeren.", + "test_mailauth_warning_summary": "Niet alle echtheidswaarmerken tegen e-mailphishing (DMARC, DKIM en SPF)", + "test_maildnssec_failed_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", + "test_maildnssec_failed_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", + "test_maildnssec_info_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", + "test_maildnssec_info_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", + "test_maildnssec_label": "Ondertekende domeinnamen (DNSSEC)", + "test_maildnssec_passed_description": "Goed gedaan! Je e-mailadresdomein en je mailserverdomein(en) zijn ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen daardoor betrouwbaar het IP-adres van je ontvangende mailserver(s) opvragen.", + "test_maildnssec_passed_summary": "Alle domeinnamen ondertekend (DNSSEC)", + "test_maildnssec_title": "Domeinnamen ondertekend?", + "test_maildnssec_warning_description": "Helaas! De domeinen van je e-mailadres en mailserver(s) zijn niet (allemaal) ondertekend met een geldige handtekening (DNSSEC). Verzenders die domeinhandtekeningen controleren, kunnen nu niet betrouwbaar het IP-adres van je ontvangende e-mailserver(s) opvragen. Een aanvaller kan het IP-adres daardoor ongemerkt manipuleren en aan jou gestuurde e-mails omleiden naar een eigen mailserver. Vraag je nameserver-beheerder en/of je mailprovider om DNSSEC te activeren.", + "test_maildnssec_warning_summary": "Niet alle domeinnamen ondertekend (DNSSEC)", + "test_mailipv6_failed_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_failed_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_mailipv6_info_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_info_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_mailipv6_label": "Modern adres (IPv6)", + "test_mailipv6_passed_description": "Goed gedaan! Je mailserver is bereikbaar voor verzenders met moderne adressen (IPv6). Daardoor is je mailserver volledig onderdeel van het moderne Internet.", + "test_mailipv6_passed_summary": "Bereikbaar via modern internetadres (IPv6)", + "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_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)", + "test_mailrpki_label": "Route-autorisatie (RPKI)", + "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": "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)", + "test_mailtls_info_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_info_summary": "Mailserver-verbinding niet of onvoldoende beveiligd (STARTTLS en DANE)", + "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: 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 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)", + "test_mailtls_null_mx_with_other_mx_description": "Waarschuwing: 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.", + "test_mailtls_null_mx_with_other_mx_summary": "Tegenstrijdig geconfigureerd niet-ontvangend maildomein (STARTTLS en DANE)", + "test_mailtls_null_mx_without_a_aaaa_description": "Waarschuwing: 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.", + "test_mailtls_null_mx_without_a_aaaa_summary": "Goed geconfigureerd niet-ontvangend mail domein, maar met overbodig record (STARTTLS en DANE)", + "test_mailtls_passed_description": "Goed gedaan! Verzendende mailservers die beveiligd e-mailtransport (STARTTLS en DANE) ondersteunen, kunnen met jouw ontvangende mailserver(s) een beveiligde verbinding opzetten. STARTTLS voorkomt dat passieve aanvallers e-mails onderweg naar jou kunnen lezen. DANE beschermt tegen actieve aanvallers, die door manipulatie van het mailverkeer de STARTTLS-encryptie kunnen verwijderen.", + "test_mailtls_passed_summary": "Mailserver-verbinding voldoende beveiligd (STARTTLS en DANE)", + "test_mailtls_title": "Beveiligde mailserver-verbinding?", + "test_mailtls_unreachable_description": "Testfout: tenminste één van jouw ontvangende mailservers was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw mailserver(s).", + "test_mailtls_unreachable_summary": "Onbereikbare ontvangende mailserver (STARTTLS en DANE)", + "test_mailtls_untestable_description": "Testfout: tenminste één van jouw ontvangende mailservers was niet testbaar voor ons. Daardoor was het niet mogelijk om de test voor STARTTLS en DANE (volledig) uit te voeren. Dit kan worden veroorzaakt door onder meer SMTP errors en geactiveerde ratelimiting-maatregelen die verbindingen tegenhouden.", + "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. 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. 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. 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. 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)", + "test_sitednssec_info_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_info_summary": "Domeinnaam niet ondertekend (DNSSEC)", + "test_sitednssec_label": "Ondertekende domeinnaam (DNSSEC)", + "test_sitednssec_passed_description": "Goed gedaan! Je domeinnaam is ondertekend met een geldige handtekening (DNSSEC). Daardoor zijn bezoekers die controle van domein-handtekeningen geactiveerd hebben, beschermd tegen gemanipuleerde vertaling van jouw domeinnaam naar kwaadaardige internetadressen.", + "test_sitednssec_passed_summary": "Domeinnaam ondertekend (DNSSEC)", + "test_sitednssec_title": "Domeinnaam ondertekend?", + "test_sitednssec_warning_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_warning_summary": "Domeinnaam niet ondertekend (DNSSEC)", + "test_siteipv6_failed_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_failed_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_siteipv6_info_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_info_summary": "Niet bereikbaar via modern internetadres, of verbetering mogelijk (IPv6)", + "test_siteipv6_label": "Modern adres (IPv6)", + "test_siteipv6_passed_description": "Goed gedaan! Je website is bereikbaar voor bezoekers die een moderne internetadres (IPv6) gebruiken, en daardoor volledig onderdeel van het moderne internet.", + "test_siteipv6_passed_summary": "Bereikbaar via moderne internetadres (IPv6)", + "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_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)", + "test_siterpki_label": "Route-autorisatie (RPKI)", + "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": "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)", + "test_sitetls_info_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_info_summary": "Verbinding niet of onvoldoende beveiligd (HTTPS)", + "test_sitetls_label": "Beveiligde verbinding (HTTPS)", + "test_sitetls_passed_description": "Goed gedaan! De verbinding met je website is voldoende beveiligd (HTTPS). Gegevens die onderweg zijn tussen je website en haar bezoekers, zijn daardoor beschermd tegen afluisteren en manipulatie.", + "test_sitetls_passed_summary": "Verbinding voldoende beveiligd (HTTPS)", + "test_sitetls_title": "Beveiligde verbinding?", + "test_sitetls_unreachable_description": "Je webserver was niet bereikbaar voor ons. Daardoor was het onmogelijk om de test voor HTTPS (volledig) uit te voeren. Dit kan worden veroorzaakt door netwerkconnectiviteitsproblemen of door het niet accepteren van connecties door jouw webserver.", + "test_sitetls_unreachable_summary": "Onbereikbare webserver (HTTPS)", + "test_sitetls_warning_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_warning_summary": "Verbinding niet of onvoldoende beveiligd (HTTPS)", + "widget_content_notes": "

Opmerkingen

  • Logo: We raden aan om ons logo op je eigen webserver op te slaan en te gebruiken. Op die manier is er geen contact met onze webserver als je website wordt bezocht.
  • Content-Security-Policy (CSP): Indien je op je website gebruikmaakt van CSP, dan zou je internet.nl moeten toevoegen aan de regels voor form-action en eventueel ook voor img-src als je linkt naar het logo op onze webserver.
", + "widget_mail_html_block": "Test je e-mail", + "widget_mail_intro": "

E-mailtest widget

Wil je dat bezoekers van jouw website direct een e-mailtest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

", + "widget_site_html_block": "Test je website", + "widget_site_intro": "

Websitetest widget

Wil je dat bezoekers van jouw website direct een websitetest kunnen starten?
Neem dan de HTML- en CSS-code uit onderstaande tekstvakken op in de broncode van je website.

" +} \ No newline at end of file diff --git a/dashboard/internet_nl_dashboard/tests/test_translation.py b/dashboard/internet_nl_dashboard/tests/test_translation.py index 321c5a9a..840ba1e3 100644 --- a/dashboard/internet_nl_dashboard/tests/test_translation.py +++ b/dashboard/internet_nl_dashboard/tests/test_translation.py @@ -8,7 +8,6 @@ from requests import Response from dashboard.internet_nl_dashboard.logic.internet_nl_translations import ( - convert_vue_i18n_format, get_locale_content, get_po_as_dictionary_v2, load_as_po_file, @@ -50,9 +49,6 @@ def test_convert_vue_i18n_format(db, tmpdir) -> None: list_po_content = load_as_po_file(content) assert len(list_po_content) > 10 - formatted = convert_vue_i18n_format("nl", list_po_content) - assert len(formatted) > 1000 - # create the expected directory structure # doesn't understand parents=true, even though it's python 3.6... LocalPath is a mute version of the system one? # It's terrible, so we have to write the directory structure ourselves, as if we are living in the 90's. From 2718206ba55cdf7d5d89095930e2231ec3e02207 Mon Sep 17 00:00:00 2001 From: stitch1 Date: Wed, 19 Feb 2025 17:20:49 +0100 Subject: [PATCH 9/9] fix a N+1 issue while logging in production --- .../scanners/scan_internet_nl_per_account.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dashboard/internet_nl_dashboard/scanners/scan_internet_nl_per_account.py b/dashboard/internet_nl_dashboard/scanners/scan_internet_nl_per_account.py index 3476dbf7..7937ffd9 100644 --- a/dashboard/internet_nl_dashboard/scanners/scan_internet_nl_per_account.py +++ b/dashboard/internet_nl_dashboard/scanners/scan_internet_nl_per_account.py @@ -152,7 +152,7 @@ def check_running_dashboard_scans(**kwargs) -> Task: .only("id") ) - log.debug(f"Checking the state of scan {scans}.") + log.debug(f"Checking the state of scan {[scan.id for scan in scans]}.") tasks = [progress_running_scan(scan.id) for scan in scans] # All transactional state stuff is done now, so remove the lock