Riferimenti TLS: le edizioni con cui si giudica un server
Un riferimento è una linea guida pubblicata per i server TLS. Un controllo TLS giudica la configurazione del server rispetto ai riferimenti che scegli, quello di Mozilla per impostazione predefinita, e un rilievo contro uno qualsiasi di essi imposta lo stato del controllo come hai scelto sul controllo stesso. I rilievi al di fuori vengono comunque registrati e contano per la valutazione a lucchetti, ma non generano mai avvisi.
Un riferimento ha senso solo in un’edizione precisa: lo stesso server può rispettare l’edizione di un anno e non quella dell’anno dopo. Ogni riferimento di questa pagina è fissato a un’edizione, ogni risultato registra l’edizione che lo ha giudicato, e un’edizione cambia solo con una modifica elencata in fondo a questa pagina.
I quattro riferimenti
| Riferimento | Per | Edizione |
|---|---|---|
| Mozilla intermediate | La maggior parte dei siti pubblici; ciò a cui mirano i comuni generatori di configurazione. Quello predefinito. | 6.0 |
| BSI TR-02102-2 e TR-02103 | Il settore pubblico tedesco e i suoi fornitori | TR-02102-2 2026-01, TR-02103 1.0 |
| NIST SP 800-52 | I sistemi federali statunitensi e i quadri che vi rimandano, profilo riservato all’amministrazione | Rev. 2 |
| Linee guida TLS dell’NCSC-NL | L’amministrazione olandese e i suoi fornitori, la sanità e la finanza olandesi | 2025-05 |
Mozilla intermediate mozilla
Mozilla, l’azienda che sviluppa Firefox, pubblica linee guida TLS per i server in tre profili. Intermediate è il profilo per i siti che devono servire un’ampia gamma di client, ed è quello prodotto dalla maggior parte dei generatori di configurazione.
Un’allowlist: la linea guida nomina le versioni, le suite di cifratura, i gruppi, i tipi di certificato e le firme che accetta, e tutto il resto è un rilievo. Si citano solo le sue chiavi. Dove non dice nulla (compressione, rinegoziazione, Key Usage), non rivendica nulla, e quei rilievi contano solo per la valutazione. Il suo profilo modern viene giudicato accanto e mostrato in ogni risultato a titolo informativo; non si può scegliere, perché nessuno dovrebbe ricevere un avviso per non raggiungerlo.
Fonte
- Mozilla Server Side TLS 6.0: https://ssl-config.mozilla.org/guidelines/6.0.json
BSI TR-02102-2 e TR-02103 bsi
Il BSI (Bundesamt für Sicherheit in der Informationstechnik) è l’autorità federale tedesca per la sicurezza informatica. Le sue linee guida tecniche TR-02102-2, su TLS, e TR-02103, sui certificati, fissano il livello per l’amministrazione federale tedesca, che spesso le richiede anche ai propri fornitori.
Il BSI dà a ogni meccanismo un anno fino al quale può essere usato, quindi un rilievo può comparire il primo giorno di un anno nuovo senza che sul server sia cambiato nulla, e la clausola relativa indica l’anno. La linea guida dice che un meccanismo non elencato non è necessariamente insicuro; le sue tabelle restano però l’elenco con cui si confronta un audit secondo essa, quindi un rilievo dice «al di fuori del riferimento», mai «insicuro». È severa sui certificati: in pratica un sito pubblico la rispetta solo con un certificato ECDSA sotto un intermedio ECDSA, perché le chiavi RSA sotto i 3000 bit e le firme RSA PKCS #1 v1.5 non sono più raccomandate. Due regole sui certificati non vengono valutate, perché ogni certificato pubblicamente attendibile le viola per le regole del CA/Browser Forum: Certificate Policies critiche e un soggetto senza l’indirizzo del server.
Fonti
- BSI TR-02102-2: https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-2.pdf
- BSI TR-02103: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf
NIST SP 800-52 nist
Il NIST, il National Institute of Standards and Technology degli Stati Uniti, stabilisce gli standard di sicurezza seguiti dalle agenzie federali statunitensi. La Special Publication 800-52 è la sua guida alla scelta e alla configurazione di TLS.
Il profilo riservato all’amministrazione, perché chi sceglie NIST chiede il livello federale. È un’allowlist per sua esplicita dichiarazione. I suoi elenchi approvati escludono ChaCha20 e X25519, quindi la maggior parte dei server fuori da un’installazione in modalità FIPS non lo rispetta solo per questo. Richiede un certificato di una CA che offra OCSP, quindi i certificati delle CA che hanno abbandonato OCSP non lo rispettano. Consente l’HMAC troncato solo per client con risorse limitate, di cui nessun controllo esterno può sapere, quindi conta come rilievo. La revisione è del 2019; non ne esiste una più recente.
Fonte
- NIST SP 800-52 Rev. 2: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
Linee guida TLS dell’NCSC-NL ncsc_nl
L’NCSC-NL è il Centro nazionale per la sicurezza informatica dei Paesi Bassi, che fa capo al Ministero della Giustizia e della Sicurezza. Le sue linee guida TLS sono il riferimento per il governo olandese e i suoi fornitori e sono molto seguite nella sanità e nella finanza olandesi.
Ogni impostazione è classificata Good, Sufficient, To be phased out o Insufficient. «To be phased out» e «Insufficient» sono rilievi, quindi rispettare questo riferimento significa che non si offre nulla di più debole di Sufficient. Le linee guida non fissano una scadenza per la dismissione e la lasciano all’operatore. Una suite di cifratura si classifica secondo la sua parte più debole. Le chiavi RSA sotto i 3072 bit vanno dismesse, quindi la maggior parte dei certificati RSA pubblici non lo rispetta. Il profilo del certificato esce dall’ambito delle linee guida, quindi le sue regole contano solo per la valutazione.
Fonte
- Linee guida TLS dell’NCSC-NL: https://www.ncsc.nl/en/transport-layer-security/tls-security-guidelines
Quali regole conta ogni riferimento
Ogni rilievo e la clausola con cui ciascun riferimento lo conta. Una cella vuota significa che il riferimento non dice nulla in merito. I codici dei rilievi sono quelli del dettaglio del risultato.
| Rilievo | Mozilla 6.0 | BSI 2026-01 | NIST Rev. 2 | NCSC-NL 2025-05 |
|---|---|---|---|---|
accepts_3des | ciphers | not in Tables 3–5 | §3.3.1.1 | Table 8: Insufficient |
accepts_anon | ciphers | not in Tables 3–5 | §3.3.1 | Table 2: Insufficient |
accepts_cbc | ciphers | Table 8: To be phased out | ||
accepts_dhe | ciphers | §3.3.1.1 Table 3 (TLS 1.2 DHE up to 2029) | Table 6: To be phased out | |
accepts_export | ciphers | not in Tables 3–5 | §3.3.1 | Table 2: Insufficient |
accepts_null | ciphers | not in Tables 3–5 | §3.3.1 | Tables 6, 8: Insufficient |
accepts_rc4 | ciphers | not in Tables 3–5 | §3.3.1 | Table 8: Insufficient |
accepts_sha1_mac | ciphers | not in Tables 3–5 | Table 9: Insufficient | |
accepts_ssl3 | tls_versions | §3.2 | §3.1 | Table 1: Insufficient |
accepts_static_kex | ciphers | RSA key transport, not in Tables 3–5; §3.3.1.2 Table 4 (up to 2026) | Table 6: Insufficient | |
accepts_tls10 | tls_versions | §3.2 | §3.1 | Table 1: Insufficient |
accepts_tls11 | tls_versions | §3.2 | §3.1 (should not) | Table 1: Insufficient |
accepts_tls12 | §3.2 Table 2 (TLS 1.2 up to 2031) | |||
cbc_without_etm | §3.3.4.5 | §3.4.2.7 | ||
cert_type_not_allowed | certificate_types | §3.3.3 Table 7 | §3.2 | Table 2: Insufficient |
curve_not_allowed | certificate_curves | §3.6.2 | §3.2, Table 3-1 | Tables 3, 5: Insufficient |
eku_any_purpose | Table 3-1 | |||
heartbeat_enabled | §3.3.4.6 | |||
insecure_renegotiation | §3.3.4.1 | §3.4.1.1 | Table 11: Insufficient | |
kex_group_not_allowed | tls_curves | §3.3.2 Table 6, §3.4.2 Table 10 | §3.3.1, §3.4.2.2 | Tables 3, 6, 7: Insufficient |
key_usage_mismatch | TR-02103 (1.0) §4.1.3 | Table 3-1 | ||
key_usage_not_critical | TR-02103 (1.0) Table 34 | Table 3-1 | ||
long_lifespan | maximum_certificate_lifespan | Table 3-1 | ||
no_aki | TR-02103 (1.0) Table 30 | Table 3-1 | ||
no_extended_master_secret | §3.3.4.7 | §3.4.1.3 | ||
no_fallback_scsv | §3.4.2.1 | |||
no_hsts | hsts_min_age | |||
no_key_usage | TR-02103 (1.0) Table 30 | Table 3-1 | ||
no_ocsp_responder | §3.2, Table 3-1 | |||
no_ocsp_stapling | ocsp_staple | §3.4.1.5 | ||
no_pq_hybrid | §3.1.3 (classical key agreement alone up to 2031) | |||
no_required_kex_group | §3.3.2 Table 6, §3.4.2 Table 10 | §3.4.2.2 | ||
no_server_auth_eku | TR-02103 (1.0) §4.1.4 | Table 3-1 | ||
no_tls13 | §3.1 | |||
pkcs1_handshake_signature | §3.3.3 Table 7 (rsa up to 2025) | |||
pkcs1_signature | §3.3.3 Table 7, §3.4.3 Table 12 (up to 2025) | |||
short_hsts | hsts_min_age | |||
suite_not_allowed | ciphers | not in Tables 3–5 | §3.3.1.1 | Table 8: Insufficient |
tls13_suite_not_allowed | ciphersuites | §3.4.4 Table 13 | §3.3.1.2 | Table 8: Insufficient |
tls_compression | §3.3.4.3 | §3.7 | Table 10: Insufficient | |
truncated_hmac | §3.3.4.2 | §3.4.2 item 8 | ||
version_intolerant | §3.1 | |||
weak_chain_key | §3.6 | §3.3.3 | ||
weak_dh | dh_param_size | §3.6.1 Table 14 | §3.3.1, §3.3.3 | Table 7: Insufficient |
weak_handshake_hash | §3.3.3 Table 8 | §3.3.3 | Table 9: Insufficient | |
weak_key | certificate_curves; rsa_key_size | §3.6.1 Table 14 | §3.2.1 Table 3-1, §3.3.3 | Table 3: Insufficient; Table 4: Insufficient |
weak_signature | certificate_signatures | §3.3.3 Table 8, §3.4.3 Table 12 | §3.3.3 | Table 9: Insufficient |
wildcard | TR-02103 (1.0) §4.1.2 |
Questa tabella è generata dalle regole che applicano i controlli, e un test fallisce se le due differiscono.
Che cosa nessun controllo esterno vede
Alcuni requisiti di queste linee guida riguardano come un server si comporta con client che non siamo noi, o che cosa gira al suo interno. Non vengono giudicati, e un server non perde nulla per essi:
- la rinegoziazione avviata dal client, i dati 0-RTT e le modalità a chiave precondivisa e di ripresa;
- gli schemi di firma di un handshake TLS 1.3, che sono cifrati;
- le firme dei certificati con SHA-224, che il nostro lettore di certificati non riconosce;
- l’interno del server: moduli crittografici validati, generazione di numeri casuali, aggiornamenti.
Registro delle modifiche
| Data | Modifica |
|---|---|
| 2026-10-17 | Prime edizioni: Mozilla 6.0; BSI TR-02102-2 2026-01 con TR-02103 1.0; NIST SP 800-52 Rev. 2; NCSC-NL 2025-05. |