it-swarm.dev

Cosa è cambiato tra TLS e DTLS

Che cosa hanno dovuto cambiare gli autori DTLS (TLS over UDP) in modo che potesse funzionare senza TCP?

Punti bonus: qualcuna delle differenze del protocollo influisce sul modo in cui dovrebbe essere utilizzata, sia in termini di interfaccia che di buone pratiche?

35
tylerl

DTLS è attualmente (versione 1.2) definito in RFC 6347 spiegando le differenze con TLS 1.2 ( RFC 5246 ). La maggior parte degli elementi TLS viene riutilizzata con solo le differenze minime.

Il contesto è che il client e il server vogliono scambiarsi molti dati come "datagrammi"; entrambi davvero entrambi vogliono inviare una lunga sequenza di byte, con un ordine definito, ma non godono il lusso di TCP =. TCP fornisce un tunnel bidirezionale affidabile per i byte, dove tutti i byte alla fine raggiungono il destinatario nello stesso ordine di quello utilizzato dal mittente; TCP lo raggiunge attraverso un complesso Assemblaggio di messaggi di conferma, timeout di trasmissione e riemissioni, ciò consente a TLS semplicemente supponiamo che i dati rimarranno incolumi in condizioni normali; in altre parole, TLS lo ritiene sufficiente per rilevare alterazioni, poiché tali alterazioni si verificheranno solo quando sono sotto attacco.

D'altra parte, DTLS funziona su datagrammi che possono essere persi, duplicati o ricevuti nell'ordine sbagliato. Per far fronte a ciò, DTLS utilizza alcuni meccanismi extra e un po 'di clemenza in più.

Le principali differenze sono:

  1. Record espliciti . Con TLS, hai one flusso lungo di byte, che l'implementazione TLS decide di dividere in record come ritiene opportuno; questa divisione è trasparente per le applicazioni. Non così con DTLS: ogni record DTLS è mappato a un datagramma. I dati vengono ricevuti e inviati su base record e un record viene ricevuto completamente o per niente. Inoltre, le applicazioni devono gestire da sole il percorso MTU discovery.

  2. Numeri di sequenza espliciti . I record TLS includono un MAC che garantisce l'integrità del record e l'input MAC include un numero di sequenza del record che verifica così che nessun record è stato perso, duplicato o riordinato . In TLS, questo numero di sequenza (un numero intero a 64 bit) è implicito (è sempre uno in più rispetto al record precedente). In DTLS, il numero di sequenza è esplicito in ciascun record (quindi si tratta di un sovraccarico di 8 byte per record, non un grosso problema). Il numero di sequenza viene inoltre suddiviso in un "Epoch" a 16 bit e un numero di sottosequenza a 48 bit, per gestire meglio le rinegoziazioni della suite di crittografia.

  3. Le modifiche sono tollerate . I datagrammi possono essere persi, duplicati, riordinati o persino modificati. Questo è un "fatto di vita" che TLS vorrebbe aborrire, ma DTLS accetta. Pertanto, client e server dovrebbero tollerare un po 'di abuso; usano un meccanismo "finestra" per dare un senso ai record che sono "un po 'in anticipo" (se ricevono i record nell'ordine 1 2 5 3 4 6, la finestra manterrà il record "5" in un buffer fino ai record 3 e 4 vengono ricevuti o il destinatario decide che i record 3 e 4 sono andati persi e devono essere saltati). I duplicati POSSONO essere avvertiti, così come i record per i quali il MAC non corrisponde; ma, in generale, i record anomali (mancanti, duplicati, troppo presto oltre l'ambito della finestra, troppo vecchi, modificati ...) vengono semplicemente eliminati.

    Ciò significa che l'implementazione DTLS non (e, in realtà, non può) distinguere tra il "rumore" normale (errori casuali che possono verificarsi) e un attacco attivo. Possono usare una certa soglia (se ci sono troppi errori, avvisare l'utente).

  4. Crittografia senza stato . Poiché i record potrebbero andare persi, la crittografia non deve utilizzare uno stato che viene modificato con ogni record. In pratica, questo non significa RC4.

  5. Nessuna terminazione verificata . DTLS non ha la nozione di un end-of-connection verificato come quello che TLS fa con close_notify messaggio di avviso. Ciò significa che quando un destinatario smette di ricevere datagrammi dal peer, non può sapere se il mittente ha cessato volontariamente di inviare o se il resto dei dati è andato perso. Si noti che una cosa del genere è stata considerata uno dei peccati capitali di SSL 2.0, ma per DTLS, questo sembra essere OK. Spetta a qualsiasi formato di dati che viene trasmesso entro DTLS per provvedere alla risoluzione esplicita, se una cosa del genere è necessaria.

  6. Frammentazione e riemissione . I messaggi di handshake possono superare la lunghezza naturale del datagramma e quindi possono essere suddivisi su più record. La sintassi dei messaggi di handshake è estesa per gestire questi frammenti. La gestione dei frammenti richiede buffer, pertanto è probabile che le implementazioni DTLS richiedano un po 'più RAM rispetto alle implementazioni TLS (ovvero, implementazioni ottimizzate per i sistemi embedded dove RAM è scarso; le implementazioni TLS per desktop e server allocano solo buffer abbastanza grandi e DTLS non sarà peggio per loro. La riammissione avviene attraverso una macchina a stati, che è un po 'più complessa da implementare rispetto alla semplice stretta di mano TLS (ma l'RFC descrive bene).

  7. Protezione contro DoS/spoof . Poiché un datagramma può essere inviato "così com'è", è soggetto a spoofing IP: un malfattore può inviare un datagramma con un indirizzo sorgente falso. In particolare un messaggio ClientHello. Se il server DTLS alloca le risorse quando riceve un ClientHello, allora c'è ampio spazio per DoS . Nel caso di TLS, un ClientHello si verifica solo dopo che l'handshake a tre vie di TCP è completato, il che implica che il client utilizza un indirizzo IP di origine che può effettivamente ricevere Essere in grado di fare un server senza mostrare il tuo IP reale è un'arma potente, quindi DTLS include una difesa opzionale.

    Il meccanismo difensivo in DTLS è un "cookie": il client invia il suo ClientHello, al quale il server risponde con un messaggio HelloVerifyRequest che contiene un cookie opaco, che il client deve inviare come secondoClientHello. Il server dovrebbe disporre di un tipo di cookie che può essere verificato senza memorizzare lo stato; vale a dire un cookie con un timestamp e un MAC (stranamente, la RFC allude a tale meccanismo ma non lo specifica completamente - è probabile che alcune implementazioni lo sbaglieranno).

    Questo meccanismo di cookie è in realtà un'emulazione dell'handshake a tre vie TCP. Implica un ulteriore roundtrip, ovvero riporta DTLS alle prestazioni TLS-over-TCP per l'handshake iniziale.

A parte questo, DTLS è simile a TLS. Le suite di crittografia non RC4 di TLS si applicano a DTLS. DTLS 1.2 è protetto dagli attacchi tipo BEAST poiché, come TLS 1.2, include IV casuale per record quando si utilizza la crittografia CBC.

Per riassumere, le funzionalità extra di DTLS vengono concettualmente importate da TCP (finestra di ricezione, riassemblaggio con numeri di sequenza, riemissioni, cookie di connessione ...) lanciato su un TLS normale (l'unica importante omissione è la mancanza di messaggi di riconoscimento) Il protocollo è più indulgente per quanto riguarda le modifiche e non include una "fine della trasmissione" verificata (ma si suppone che DTLS sia impiegato in contesti in cui ciò non avrebbe comunque senso).

Il dominio di applicazione di DTLS è veramente distinto da quello di TLS; è pensato per essere applicato ad applicazioni di streaming di dati in cui le perdite sono meno importanti della latenza, ad es. VoIP o feed video live. Per una data applicazione, TLS ha molto più senso di DTLS, o il contrario; la migliore pratica è scegliere il protocollo appropriato.

51
Thomas Pornin

Esistono differenze fondamentali tra DTLS e il protocollo TLS (Transport Layer Security) di cui il programmatore dell'applicazione deve essere consapevole del fatto che l'altra risposta mancante/implicita non esiste!

Il protocollo DTLS fornisce la riservatezza delle comunicazioni per i protocolli datagramma. Contrariamente alla risposta LUNGA molto apprezzata e generalmente informativa al momento della stesura di questo documento (archivio) , DTLS non è non utilizzato quando TCP non è disponibile (dalle app che non godono del lusso del TCP. La differenza fondamentale è che mentre un'implementazione DTLS gestisce i problemi di riordino e perdita dei pacchetti, lo fa solo per i pacchetti utilizzati per l'handshake DTLS (e la selezione di cifratura). Tuttavia, i pacchetti DTLS contenenti payload (dati dell'applicazione) non forniscono il loro payload in modo più affidabile rispetto ai pacchetti DTLS (in genere UDP) che li incapsulano Il lato positivo è che DTLS fornisce i dati delle applicazioni più velocemente e con una latenza inferiore. Per i punti bonus: ecco perché DTLS viene utilizzato per proteggere le applicazioni di streaming in cui le perdite sono meno importanti della latenza, ad esempio VoIP, feed di video in diretta e MMO gaming. TLS ha lo scopo di fornire un flusso di dati affidabile e con crittografia autenticata, end-to-end. DTLS è destinato alla consegna di applicat dati ionici autenticati e crittografati end-to-end, ma con una latenza inferiore rispetto a quella ottenibile quando è garantita la consegna di tutti i dati dell'applicazione.

Inoltre, mentre il protocollo DTLS (v1.2) deriva dal protocollo TLS (v1.2) e reclami per "fornire garanzie di sicurezza equivalenti", non lo fa . 2 Nel 2013, i ricercatori hanno identificato le principali carenze di sicurezza sia nelle implementazioni DTLS che nel protocollo DTLS stesso, che sono state corrette, almeno nelle implementazioni GnuTLS e OpenSSL . 2

PS: DTLS 1.3 è in fase di sviluppo .

0
Matthew Elvey