Fully updated TLS test in new version of Internet.nl

What is TLS?

The open standard Transport Layer Security (TLS) can be used to secure connections between systems. This includes, for example, the connection between your browser and the server hosting the website you are visiting. It can also be used to secure the connection between mailservers. TLS ensures that third parties cannot simply intercept the data being transmitted over the network.

Why is securely configured TLS important?

TLS has many configuration options. Some of these options contain vulnerabilities that weaken security. It is therefore important to configure TLS to avoid those options. On the other hand, compatibility with other systems must also be taken into account. Certain options may be robust, but are not yet supported by all other systems, which could hinder interoperability.

NCSC's latest TLS guidelines

In mid 2025, the NCSC-NL published a major update of the "ICT Security Guidelines for Transport Layer Security (TLS)". These guidelines help to configure TLS securely while ensuring compatibility with other systems. They are based on international best practices such as IETF BCP 195. This update is also expected to be incorporated into the "Decree on secure connections to government websites and web applications" (in Dutch).

Update in Internet.nl

From today, you can use Internet.nl to test whether the TLS configuration of your web server or your incoming mail server is compliant with these updated TLS guidelines. NCSC-NL recognises four different security levels. Settings with a security level of 'Good' and 'Sufficient' pass the Internet.nl test. In the case of 'To be phased out' settings, a warning will be displayed. 'Insufficient' settings result in failure of the test and also lead to a lower score.

The new version is now available on the Internet.nl website, where you can test individual domain names. It is expected that the new version will also become available on the batch API and web-based dashboard within a few weeks.

Post-quantum cryptography

The TLS guidelines also address post-quantum cryptography. Quantum-secure cryptographic algorithms have a security rating of 'Good'. Internet.nl does not currently show whether a server supports one or more of these algorithms. This is, however, on the roadmap and will be included in a future release.

About Internet.nl

The test tool Internet.nl is an initiative of the Dutch Internet Standards Platform which is a collaboration of partners from the Internet community and the Dutch government. The aim of the platform is to jointly increase the use of modern Internet standards to make the Internet more accessible, safer and more reliable for everyone. The code of Internet.nl is available under an open source license.

Release notes 1.11

TLS updates for NCSC 2025 guidelines

All tests were updated to match the 2025-05 version of the NCSC TLS guidelines. Most significant changes:

• The list of good/sufficient/phase out/insufficient TLS versions, TLS authentication, curves, hashes, key exchange algorithms, FFDHE groups, RSA key lengths, and bulk encryption algorithms were updated to match the new guidelines.
• A test for Extended Master Secret (RFC7627) was added.
• Client-initiated renegotiation is now acceptable, if limited to less than 10 renegotiations.
• All checks on certificates apply to all certificates sent by the server, except root certificates (according to our trust store). In previous versions, the certificate selection was different per test.

Other TLS updates

• Certificates that do not have OCSP enabled, which means stapling is not possible, are now detected as such. Several issues with OCSP stapling reliability were also resolved.
• Issues were fixed where the cipher order failed to detect some bad scenarios, including some where servers preferred RSA over ECDHE, or CBC over POLY1305.
• CCM_8 ciphers are now detected when enabled on a server.
• OLD ciphers are no longer detected.
• The cipher order test no longer separates between "the server cipher order preference is wrong" and "the server has no preference".

Significant internal changes

• Upgraded to Django 5, Python 3.13, and Debian Trixie base image.
• Switched TLS implementation to sslyze/nassl based reimplementation.
• Switched to pyproject/uv.lock for project dependencies, replacing requirements files.
• Added post-quantum hybrid ECDHE-MLKEM for TLS 1.3 in our web server.
• Outgoing traffic now uses the configured public IPv4/IPv6 addresses.
• Routinator can now be configured with an allowlist for shared instances.

Bug fixes

• Fixed simhash exception when both address families fail.
• Fixed JSON serialization of sets in batch results.
• Fixed report generation locking for results views.

API changes

This release has API version 2.7.0.

The changes noted above are reflected in the API as well, e.g. which ciphers are considered bad, as listed in the API output, along with score impacts.

Additionally, the API structure changes are: - OCSP stapling has a new status not_in_cert (not_tested), for when a certificate does not have OCSP enabled, therefore stapling is neither required nor possible. - The cipher order status no longer returns not_prescribed or not_seclevel for new tests. The insufficient status is now bad (failed) for preferring phase out over good and/or sufficient, regardless of the reason (server not enforcing any preference or server enforcing wrong preference). - cert_signature_phase_out was added to the TLS details, listing certificate signature algorithms that are at phase-out level (warning). Analogous to the existing cert_signature_bad. - extended_master_secret was added to the TLS details, with values: supported (good), not_supported (failed), na_no_tls_1_2 (good), unknown (not_tested). - client_reneg in the TLS details was changed from a boolean to a string enum with values: not_allowed (good), allowed_with_low_limit (info), allowed_with_too_high_limit (failed).