Quale impatto sulla sicurezza è causato da un server TLS che continua l'handshake quando viene presentato con un SNI non valido?

Question

Quale impatto sulla sicurezza è causato da un server TLS che continua l'handshake quando viene presentato con un SNI non valido?

#1 da (4 voti)

3

RFC 6066 definisce Indicazione del nome del server come estensione, per cui ai server web virtualizzati può essere fornita un'estensione SNI per sapere quale certificato deve essere presentato.

Si riporta quanto segue sui casi in cui il nome del server indicato non corrisponde a un nome conosciuto (enfasi mia):

If the server understood the ClientHello extension but does not recognize the server name, the server SHOULD take one of two actions: either abort the handshake by sending a fatal-level unrecognized_name(112) alert or continue the handshake. It is NOT RECOMMENDED to send a warning-level unrecognized_name(112) alert, because the client's behavior in response to warning-level alerts is unpredictable. If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. TLS implementations are encouraged to make information available to application callers about warning- level alerts that were received or sent during a TLS handshake. Such information can be useful for diagnostic purposes.

Qual è il potenziale impatto sulla sicurezza di continuare l'handshake quando viene inviato un SNI non valido? Sto pensando in particolare ai casi in cui viene fornito un dominio interamente o un sottodominio errato. Qual è la logica di compatibilità dietro non rifiutare tali richieste? I miei test limitati hanno dimostrato che l'invio di "microsoft.com" nel campo SNI a un servizio TLS su google.com non ha rifiutato il mio contenuto, mentre fare lo stesso con un servizio abilitato CloudFlare ha causato l'avviso fatale.

error-handling public-key-infrastructure tls certificates

posta Polynomial 14.04.2016 - 16:39

fonte

1 risposta

Leggi altre domande sui tag error-handling public-key-infrastructure tls certificates

Certificato SSL nel mio hosting mi fa cambiare il mio codice java? Come utilizzare AES-CBC per la crittografia LUKS, quando il testo cifrato non è statico?

score 4 · Accepted Answer

Non c'è alcun impatto sulla sicurezza di interrompere o continuare l'handshake: la sicurezza si basa sui test eseguiti dal client, non dal server. Questo è il motivo per cui l'estensione è chiamata indicazione . Ciò che importa è che il client verifichi debitamente che la chiave pubblica del server apparente sia effettivamente posseduta dal server previsto. L'SNI è un modo per il client di trasmettere al server un suggerimento sul processo che il client utilizzerà per quella verifica: cioè, il client verificherà che il certificato del server sia valido, e che sia identifica un nome server specifico.

Anche se il server vede che l'SNI corrisponde al proprio certificato, il client deve comunque eseguire tutti i controlli.

In caso di mancata corrispondenza SNI (il client invia un nome per il quale il server non ha un certificato corrispondente), mantenere la stretta di mano può essere utile per inviare un messaggio di errore esplicito. L'utente umano, dal lato del cliente, dovrà "cliccare attraverso" l'avviso, e gli utenti umani dovrebbero essere addestrati a non farlo, ma se lo fanno, allora potrebbero vedere una pagina inviata dal server che dichiarerà esattamente ("Questo non è il sito Web che stai cercando"). Con un avviso a livello di SSL, tutto ciò che l'utente vedrà sarà il generico "Impossibile connettersi, controlla la tua connessione Internet" che è terribilmente disinformativo.