Verifichi se una versione TLS è ancora supportata
Inserisca una versione TLS e scopra subito se è ancora valida: TLS 1.3 e TLS 1.2 risultano supportate, TLS 1.0 e TLS 1.1 obsolete, ciascuna con il passo successivo per la Sua revisione di sicurezza. Gratis nel Suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Esempio risolto
- Versione
- TLS 1.3
- Stato
- supported
Questo strumento classifica TLS 1.0, TLS 1.1, TLS 1.2 o TLS 1.3 secondo un’interpretazione chiara e stabile delle linee guida comuni del settore. Indica se la versione fornita è obsoleta, ne comunica lo stato di supporto e propone brevemente il passo successivo. Le versioni non riconosciute generano un errore esplicito, rendendo lo strumento adatto a revisioni, script, liste di controllo e documentazione ripetibili.
Comprenda il significato del risultato
Un risultato supportato significa che la versione del protocollo non è generalmente considerata obsoleta dalle attuali linee guida prevalenti del settore. In questo strumento, TLS 1.2 e TLS 1.3 sono supportati, mentre TLS 1.0 e TLS 1.1 sono obsoleti. La classificazione riguarda intenzionalmente soltanto la versione del protocollo.
Non dimostra che uno specifico server sia configurato in modo sicuro, che un certificato sia valido o che tutte le suite di cifratura abilitate siano appropriate. Un servizio TLS 1.2 può comunque presentare impostazioni deboli, mentre un client moderno può fallire per problemi relativi al certificato, al nome host o alla catena di attendibilità. Utilizzi lo stato restituito come un elemento preciso di una revisione della sicurezza più ampia.
La risposta comprende indicatori booleani sia per l’obsolescenza sia per il supporto, così l’automazione può usare il risultato senza interpretare il testo, oltre a una raccomandazione leggibile destinata ai rapporti. Poiché la mappatura è fissa e deterministica, lo stesso input riconosciuto riceve sempre la medesima classificazione, semplificando confronti e prove di audit.
Inserisca e normalizzi una versione TLS
Fornisca una versione alla volta. Le forme canoniche sono TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3. Il confronto non distingue maiuscole e minuscole, ignora gli spazi esterni e accetta anche la comune notazione TLSv1.2.
L’output restituisce sempre un’etichetta canonica come TLS 1.2, utile per uniformare i valori raccolti da inventari o annotazioni di configurazione. Lo strumento rifiuta intenzionalmente valori incompleti o sconosciuti invece di tentare di interpretarli. SSL 3.0, TLS 2.0, parole come «più recente» e stringhe incomplete non vengono associate silenziosamente a un protocollo supportato.
Questo comportamento rigoroso è importante nei controlli automatici: un refuso deve arrestare il flusso o generare un’eccezione visibile, non superare per errore una regola di sicurezza. Se sta leggendo un file di configurazione, estragga prima la versione effettiva del protocollo dalla sintassi specifica del prodotto e poi la invii. Se un sistema abilita più versioni, le controlli separatamente e consideri ogni versione obsoleta abilitata come motivo per riesaminare la configurazione.
Applichi la classificazione a una revisione di sicurezza
Utilizzi questo controllo quando un inventario delle risorse, un questionario, un manifesto di distribuzione o la risposta di un fornitore indica una versione TLS e Lei necessita di una classificazione preliminare coerente. TLS 1.0 o TLS 1.1 obsoleti dovrebbero normalmente generare un’attività di migrazione: verifichi quali client dipendono ancora dalla vecchia versione, abiliti TLS 1.2 o TLS 1.3, collaudi l’interoperabilità e infine rimuova il protocollo precedente. Un risultato supportato per TLS 1.2 o TLS 1.3 non conclude la valutazione.
Prosegua controllando certificati, catene di attendibilità, convalida del nome host, scelte di cifratura e firma, livelli di aggiornamento delle librerie e versioni realmente negoziate dalle reti pertinenti. I requisiti possono inoltre essere più severi delle linee guida comuni, soprattutto per contratto, normativa, riferimento della piattaforma o standard interno. In tali casi, consideri come autorità finale la politica applicabile più rigorosa.
Il browser è utile per rapide revisioni manuali, mentre la risposta strutturata si adatta ai processi di conformità e ai controlli ripetibili.
Casi d'uso
Esaminare la configurazione di riferimento
Classifichi ogni versione TLS citata nella configurazione di un server o bilanciatore prima di approvarla.
Uniformare i questionari dei fornitori
Converta risposte in formati diversi in un’etichetta e in uno stato di supporto coerenti.
Segnalare i protocolli precedenti
Crei un’attività di migrazione quando una voce dell’inventario riporta TLS 1.0 o TLS 1.1.
Domande frequenti
Quali versioni TLS sono riconosciute?
Sono riconosciute TLS 1.0, TLS 1.1, TLS 1.2 e TLS 1.3, compresa la notazione TLSv senza distinzione tra maiuscole e minuscole.
Quali versioni sono considerate obsolete?
TLS 1.0 e TLS 1.1 sono classificati come obsoleti. TLS 1.2 e TLS 1.3 sono classificati come supportati.
Una versione supportata rende il server completamente sicuro?
No. Il risultato riguarda solo l’obsolescenza della versione, non certificati, cifrature, aggiornamenti dell’implementazione o configurazione.
Cosa fare se un server accetta ancora TLS 1.0?
Pianifichi una migrazione. TLS 1.0 e TLS 1.1 sono obsolete: individui i client che ne dipendono ancora e li porti a TLS 1.2 o TLS 1.3. Se il sistema abilita più versioni, verifichi ciascuna separatamente.
Perché SSL 3.0 o TLS 2.0 vengono rifiutati?
Perché lo strumento riconosce solo TLS 1.0, 1.1, 1.2 e 1.3 e non tira mai a indovinare. SSL 3.0, TLS 2.0, parole come «latest» o versioni incomplete vengono rifiutate apertamente invece di passare per errore come supportate.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo stack
curl -X POST https://api.kit.forhosting.com/security/tls-version-support-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"version":"TLS 1.2"}'const res = await fetch("https://api.kit.forhosting.com/security/tls-version-support-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"version": "TLS 1.2"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/tls-version-support-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"version": "TLS 1.2"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/tls-version-support-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"version":"TLS 1.2"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"version":"TLS 1.2"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/tls-version-support-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Esempio di richiesta
{
"version": "TLS 1.2"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.tls_version_support_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Applichi la classificazione a una revisione di sicurezza
Il prezzo dell’API è $0.002 per richiesta quando automatizza la consultazione.
Domande tecniche
Che cosa accade con una versione sconosciuta?
La richiesta restituisce un errore invalid_input che elenca le quattro versioni TLS riconosciute, senza formulare ipotesi.
Quanto costa una verifica tramite API?
Ogni richiesta API costa $0.002. La capacità esegue una classificazione deterministica della versione per richiesta.