Generale

SSL (e il suo successore, TLS ) è un protocollo che opera direttamente su TCP (sebbene ci siano anche implementazioni per protocolli basati su datagrammi come UDP). In questo modo, i protocolli su livelli più alti (come HTTP) possono essere lasciati invariati mentre s fino a fornire una connessione sicura. Sotto il livello SSL, HTTP è identico a HTTPS.

Quando si utilizza correttamente SSL / TLS, tutto ciò che un utente malintenzionato può vedere sul cavo è lIP e la porta a cui si è connessi, allincirca quanti dati si stanno inviando e quale crittografia e compressione vengono utilizzate. Può anche terminare la connessione, ma entrambe le parti sapranno che la connessione è stata interrotta da una terza parte.

Nelluso tipico, laggressore sarà anche in grado di capire a quale hostname ti stai connettendo (ma non il resto dellURL): sebbene HTTPS stesso non esponga il nome host, il tuo browser di solito dovrà prima effettuare una richiesta DNS per scoprire a quale indirizzo IP inviare la richiesta.

Alta a livello di descrizione del protocollo

Dopo aver costruito una connessione TCP, lhandshake SSL viene avviato dal client. Il client (che può essere un browser così come qualsiasi altro programma come Windows Update o PuTTY) invia una serie di specifiche:

• quale versione di SSL / TLS è in esecuzione,
• cosa ciphersuites vuole usare e
• cosa metodi di compressione che desidera utilizzare.

Il server identifica la versione SSL / TLS più alta supportata sia da esso che dal client, sceglie una ciphersuite da una delle opzioni del client (se ne supporta una) e opzionalmente sceglie un metodo di compressione.

Dopo aver completato la configurazione di base, il server invia il suo certificato. Questo certificato deve essere considerato attendibile dal client stesso o da una parte di cui il client si fida. Ad esempio, se il client si fida di GeoTrust, allora il client può considerare attendibile il certificato di Google.com perché GeoTrust certificato crittograficamente di Google.

Dopo aver verificato il certificato ed essere certi che questo server sia veramente chi afferma di essere (e non un uomo al centro), viene scambiata una chiave. Può essere una chiave pubblica, a ” PreMasterSecret ” o semplicemente niente, a seconda della ciphersuite scelta. Sia il server che il client possono ora calcolare la chiave per crittografia simmetrica ^{whynot PKE?} . Il client comunica al server che dora in poi tutte le comunicazioni saranno crittografate, e invia un messaggio crittografato e autenticato al server.

Il server verifica che il MAC (utilizzato per lautenticazione) sia corretto e che il messaggio possa essere correttamente decrittografato. Quindi restituisce un messaggio, che il client verifica come bene.

Lhandshake è ora terminato e i due host possono comunicare in modo sicuro. Per ulteriori informazioni, vedi technet.microsoft.com/en-us/library/cc785811 e en.wikipedia .org / wiki / Secure_Sockets_Layer .

Per chiudere la connessione, viene utilizzato un “avviso” close_notify. Se un utente malintenzionato tenta di terminare la connessione terminando la connessione TCP (iniettando un pacchetto FIN), entrambe le parti sapranno che la connessione è stata terminata in modo improprio. La connessione non può essere compromessa da questo, ma solo interrotta.

Qualche dettaglio in più

Perché puoi fidarti di Google.com affidandoti a GeoTrust?

Un sito web vuole comunicare con te in modo sicuro. Per provare la sua identità e assicurarti che non sia un malintenzionato, devi avere la chiave pubblica del server “s . Tuttavia, difficilmente puoi memorizzare tutte le chiavi da tutti i siti web sulla terra, il database sarebbe enorme e gli aggiornamenti dovrebbero essere eseguiti ogni ora!

La soluzione a questo è Autorità di certificazione, o CA in breve.Quando hai installato il tuo sistema operativo o browser, probabilmente è stato fornito un elenco di CA attendibili. Questo elenco può essere modificato a piacimento; puoi rimuovere chi non ti fidi, aggiungere altri o persino creare la tua CA (anche se sarai lunico a fidarsi di questa CA, quindi non è molto utile per il sito web pubblico). In questo elenco di CA, viene memorizzata anche la chiave pubblica della CA.

Quando il server di Google ti invia il suo certificato, menziona anche che è firmato da GeoTrust. Se ti fidi di GeoTrust, puoi verificare (utilizzando la chiave pubblica di GeoTrust) che GeoTrust abbia realmente firmato il certificato del server. Per firmare un certificato da soli, è necessaria la chiave privata, nota solo a GeoTrust. In questo modo un utente malintenzionato non può firmare un certificato da solo e affermare erroneamente di essere Google.com. Quando il certificato è stato modificato anche di un solo bit, il segno non sarà corretto e il client lo rifiuterà.

Quindi, se conosco la chiave pubblica, il server può provare la sua identità?

Sì. In genere, la chiave pubblica crittografa e la chiave privata decrittografa. Crittografa un messaggio con la chiave pubblica del server, invialo e se il server può ripetere il messaggio originale, ha appena dimostrato di aver ottenuto la chiave privata senza rivelare la chiave.

Questo è il motivo è così importante poter fidarsi della chiave pubblica: chiunque può generare una coppia di chiavi pubblica / privata, anche un attaccante. Non vuoi finire per usare la chiave pubblica di un attaccante!

Se una delle CA di cui ti fidi è stata compromessa, un utente malintenzionato può utilizzare la chiave privata rubata per firmare un certificato per qualsiasi sito web che desidera. Quando laggressore può inviare un certificato contraffatto al tuo client, firmato da lui stesso con la chiave privata di una CA di cui ti fidi, il tuo client non sa che la chiave pubblica è contraffatta, firmata con una chiave privata rubata.

Ma una CA può farmi fidare di qualsiasi server voglia!

Sì, ed è qui che arriva la fiducia in. Devi fidarti della CA per non creare certificati come preferiscono. Quando organizzazioni come Microsoft, Apple e Mozilla si fidano di una CA, tuttavia, la CA deve avere controlli; unaltra organizzazione li controlla periodicamente per assicurarsi che tutto funzioni ancora secondo alle regole.

Lemissione di un certificato viene eseguita se, e solo se, il registrante può dimostrare di essere il proprietario del dominio per il quale è stato emesso il certificato.

Cosè questo MAC per lautenticazione dei messaggi?

Ogni messaggio è firmato con un cosiddetto codice di autenticazione del messaggio o MAC in breve. Se siamo daccordo su una chiave e una crittografia hashing, puoi verificare che il mio messaggio provenga da me e io posso verificare che il tuo messaggio provenga da te.

Ad esempio con la chiave ” graffetta corretta della batteria del cavallo ” e il messaggio ” esempio “, Posso calcolare il MAC ” 58393 “. Quando ti invio questo messaggio con il MAC (conosci già la chiave), puoi eseguire lo stesso calcolo e abbinare il MAC calcolato con il MAC che ho inviato.

Un utente malintenzionato può modificare il messaggio ma non conosce la chiave. Non può calcolare il MAC corretto e saprai che il messaggio non è autentico.

Includendo un numero di sequenza durante il calcolo del MAC, puoi eliminare replay attacchi . SSL lo fa.

Hai detto che il client invia una chiave, che viene quindi utilizzata per la configurazione crittografia simmetrica. Cosa impedisce a un utente malintenzionato di utilizzarlo?

La chiave pubblica del server lo fa. Poiché abbiamo verificato che la chiave pubblica appartiene realmente al server e a nessun altro, noi può crittografare la chiave utilizzando la chiave pubblica. Quando il server la riceve, può decrittografarla con la chiave privata. Quando qualcun altro la riceve, non può decrittografarla.

Anche per questo la dimensione della chiave è importante: Più grandi sono le chiavi pubblica e privata, più difficile sarà violare la chiave che il client invia al server.

Come violare SSL

In sintesi :

• Prova se lutente ignora gli avvisi del certificato;
• Lapplicazione può caricare dati da un canale non crittografato (ad esempio HTTP), che può essere manomesso;
• Una pagina di accesso non protetta che invia a HTTPS può essere modificata in modo che venga inviata a HTTP;
• Le applicazioni senza patch possono essere vulnerabile per exploit come BEAST e CRIME;
• Ricorrere ad altri metodi suc h come attacco fisico;
• Sfrutta i canali secondari come la lunghezza del messaggio e il tempo preso per formare il messaggio;
• Attendi attacchi quantistici .

Vedi anche: Uno schema con molti vettori di attacco contro SSL di Ivan Ristic ^(png)

In dettaglio:

Non cè niente di semplice e diretto modo; SSL è sicuro se eseguito correttamente. Tuttavia, un utente malintenzionato può provare se lutente ignora gli avvisi sui certificati , il che interromperebbe immediatamente la sicurezza. Quando un utente esegue questa operazione, laggressore non ha bisogno di una chiave privata da una CA per falsificare un certificato, deve semplicemente inviare un certificato tutto suo.

Un altro modo potrebbe essere un difetto nel applicazione (lato server o lato client). Un semplice esempio è nei siti web: se una delle risorse utilizzate dal sito web (come unimmagine o uno script) viene caricata su HTTP, la riservatezza non può più essere garantita. Anche se i browser non inviare lintestazione del referer HTTP quando si richiedono risorse non protette da una pagina protetta ( source ), è comunque possibile che qualcuno che intercetta il traffico indovini dove ti trovi “stai visitando da; ad esempio, se sanno che le immagini X, Y e Z sono utilizzate su una pagina, possono indovinare che stai visitando quella pagina quando vedono che il tuo browser richiede quelle tre immagini contemporaneamente. Inoltre, durante il caricamento di Javascript, lintera pagina può essere compromessa. Un utente malintenzionato può eseguire qualsiasi script sulla pagina, modificando ad esempio a chi andrà la transazione bancaria.

Quando ciò accade (una risorsa caricata su HTTP), il browser invia un avviso di contenuto misto: Chrome , Firefox , Internet Explorer 9

Un altro trucco per HTTP è quando la pagina di accesso non è protetta e si invia a una pagina https. ” Ottimo, ” lo sviluppatore probabilmente ha pensato, ” ora salvo il carico del server e il la password è ancora inviata crittografata! ” Il problema è sslstrip , uno strumento che modifica la pagina di accesso non sicura in modo che invia da qualche parte in modo che lattaccante possa leggerlo.

Ci sono stati anche vari attacchi negli ultimi anni, come la vulnerabilità di rinegoziazione TLS , sslsniff , BEAST e, molto recentemente, CRIMINE . Tuttavia, tutti i browser comuni sono protetti contro tutti questi attacchi, quindi queste vulnerabilità non rappresentano un rischio se utilizzi un browser aggiornato.

Ultimo ma non meno importante, puoi ricorrere ad altri metodi per ottenere le informazioni che SSL ti nega di ottenere. Se puoi già vedere e manomettere la connessione dellutente, potrebbe non essere così difficile sostituire uno dei suoi download .exe con un keylogger, o semplicemente attaccare fisicamente quella persona. La crittografia può essere piuttosto sicura, ma gli esseri umani e lerrore umano è ancora un fattore debole. Secondo questo documento di Verizon , il 10% delle violazioni dei dati ha coinvolto attacchi fisici (vedere pagina 3), quindi ” è sicuramente qualcosa da tenere a mente.

Commenti

• Sarei interessato a qualche spiegazione in più per ” viene scambiata una chiave ” con la chiave simmetrica. Come può succedere che qualcuno con uno sniffer di pacchetti non possa accedere.
• @Yehosef Bella domanda! Ho dimenticato di spiegarlo nella mia risposta. Guardandosi intorno, si scopre che in realtà cè una domanda dedicata a questo: security.stackexchange.com/q/6290/10863
• @ Iwazaru Tutte le CA lo fanno sin dal primo giorno. Lo scopo di un certificato è fornire la chiave pubblica per un determinato dominio e il punto di firmarlo per dimostrare che è davvero la chiave giusta per il dominio. Consenti a ‘ s Encrypt di fare esattamente quello che dovrebbe: verificare che sei il proprietario del dominio e firmare il certificato (con la tua chiave) se puoi provarlo. Ora tutti coloro che si fidano di Let ‘ s Encrypt, che è praticamente ogni browser, si fideranno di quel certificato.
• Ehm, no. TLS è effettivamente implementato su TCP.
• Ho trovato questo processo di handshake SSL grafico , molto chiaro.

Poiché il concetto generale di SSL è già stato trattato in alcune altre domande (ad es. questo e quello ), questa volta andrò per i dettagli. I dettagli sono importanti. Questa risposta sarà alquanto dettagliata.

Cronologia

SSL è un protocollo con una lunga storia e diverse versioni.I primi prototipi provenivano da Netscape quando stavano sviluppando le prime versioni del loro browser di punta, Netscape Navigator (questo browser ha ucciso Mosaic nei primi tempi delle Browser Wars, che infuriano ancora, anche se con nuovi concorrenti). La versione 1 non è mai stata resa pubblica, quindi non sappiamo come fosse. La versione 2 di SSL è descritta in una bozza che può essere letta lì ; ha una serie di punti deboli, alcuni dei quali piuttosto gravi, quindi è deprecato e le implementazioni SSL / TLS più recenti non lo supportano (mentre i vecchi sono disattivati per impostazione predefinita). Non parlerò più della versione 2 di SSL, tranne che come riferimento occasionale.

La versione 3 di SSL (che chiamerò “SSLv3”) era un protocollo avanzato che funziona ancora oggi ed è ampiamente supportato. Sebbene sia ancora una proprietà di Netscape Communications (o di chi ne possiede al giorno doggi), il protocollo è stato pubblicato come “RFC storica” ( RFC 6101 ). Nel frattempo, il protocollo è stato standardizzato, con un nuovo nome per evitare problemi legali; il nuovo nome è TLS .

Finora sono state prodotte tre versioni di TLS, ciascuna con il suo RFC dedicata: TLS 1.0 , TLS 1.1 e TLS 1.2 . Sono internamente molto simili tra loro e con SSLv3, al punto che unimplementazione può facilmente supportare SSLv3 e tutte e tre le versioni di TLS con almeno il 95% del codice comune. Tuttavia, internamente, tutte le versioni sono designate da un numero di versione con il formato major.minor ; SSLv3 è quindi 3.0, mentre le versioni TLS sono, rispettivamente, 3.1, 3.2 e 3.3. Pertanto, non cè da meravigliarsi che TLS 1.0 a volte sia chiamato SSL 3.1 (e non è nemmeno corretto). SSL 3.0 e TLS 1.0 differiscono solo per alcuni minuti dettagli. TLS 1.1 e 1.2 non sono ancora ampiamente supportati, anche se cè un impulso per questo, a causa di possibili punti deboli (vedi sotto, per l “attacco BEAST”). SSLv3 e TLS 1.0 sono supportati “ovunque” (anche IE 6.0 li conosce).

Contesto

SSL mira a fornire un tunnel bidirezionale sicuro per dati arbitrari. Considera TCP , il noto protocollo per linvio di dati su Internet. TCP funziona sui “pacchetti” IP e fornisce un tunnel bidirezionale per i byte; funziona per i valori di ogni byte e li invia a due flussi che possono funzionare simultaneamente. TCP gestisce il duro lavoro di suddividere i dati in pacchetti, riconoscerli, riassemblarli nellordine corretto, rimuovere i duplicati e ritrasmettere i pacchetti persi. Dal punto di vista dellapplicazione che utilizza TCP, ci sono solo due flussi, ei pacchetti sono invisibili; in particolare, i flussi non sono suddivisi in “messaggi” (spetta allapplicazione prendere le proprie regole di codifica se desidera avere messaggi, e questo è esattamente ciò che HTTP lo fa).

TCP è affidabile in presenza di “incidenti”, ovvero errori di trasmissione dovuti a hardware instabile, congestione della rete, persone con smartphone che escono dal raggio di una determinata stazione base e altri eventi non dannosi. Tuttavia, un individuo malintenzionato (l “aggressore”) con un accesso al supporto di trasporto potrebbe leggere tutti i dati trasmessi e / o alterarli intenzionalmente, e TCP non protegge da questo. SSL.

SSL presume che funzioni su un protocollo simile a TCP, che fornisce un flusso affidabile; SSL non implementa la riemissione di pacchetti persi e cose del genere. Laggressore è dovrebbe essere in grado di interrompere completamente la comunicazione in un modo inevitabile (ad esempio, può tagliare i cavi) quindi il compito di SSL è:

• rilevare alterazioni (lautore dellattacco non deve essere in grado di alterare i dati silenziosamente );
• garantire la riservatezza (il lautore dellattacco non deve acquisire la conoscenza dei dati scambiati).

SSL soddisfa questi obiettivi in misura ampia (ma non assoluta).

Record

SSL è a strati e il livello inferiore è il protocollo di registrazione . Tutti i dati inviati in un tunnel SSL vengono suddivisi in record . In rete (il socket TCP sottostante o un supporto simile a TCP), un record ha questo aspetto:

HH V1:V2 L1:L2 data

dove:

• HH è un singolo byte che indica il tipo di dati nel record.Sono definiti quattro tipi: change_cipher_spec (20), alert (21), handshake (22) e application_data ( 23).
• V1: V2 è la versione del protocollo, su due byte. Per tutte le versioni attualmente definite, V1 ha valore 0x03, mentre V2 ha valore 0x00 per SSLv3, 0x01 per TLS 1.0, 0x02 per TLS 1.1 e 0x03 per TLS 1.2.
• L1: L2 è la lunghezza di data, in byte (la convenzione big-endian è usato: la lunghezza è 256 * L1 + L2). La lunghezza totale di data non può superare 18432 byte, ma in pratica non può nemmeno raggiungere quel valore.

Quindi un record ha cinque- intestazione byte, seguita da un massimo di 18 kB di dati. data è il punto in cui vengono applicati la crittografia simmetrica e i controlli di integrità. Quando viene emesso un record, si suppone che sia il mittente che il destinatario concordino su quali algoritmi crittografici sono attualmente applicati e con quali chiavi; questo accordo si ottiene tramite il protocollo di handshake, descritto nella sezione successiva. A quel punto viene applicata anche la compressione.

In tutti i dettagli, la creazione di un record funziona in questo modo:

• Inizialmente, ci sono alcuni byte da trasferire ; questi sono dati dellapplicazione o altri tipi di byte. Questo payload consiste al massimo di 16384 byte, ma forse di meno (un payload di lunghezza 0 è legale, ma risulta che a Internet Explorer 6.0 non piace affatto ) .
• Il payload viene quindi compresso con qualsiasi algoritmo di compressione attualmente concordato. La compressione è stateful e quindi può dipendere dal contenuto dei record precedenti. In pratica, la compressione è “nulla” (nessuna compressione) o “Deflate” ( RFC 3749 ), questultimo attualmente è cortesemente ma fermamente mostrato luscita door nel contesto Web, a causa del recente attacco CRIME . La compressione mira ad accorciare i dati, ma deve necessariamente espanderli leggermente in alcune situazioni sfavorevoli (a causa del principio dei casellari ). SSL consente unespansione di massimo 1024 byte. Ovviamente, la compressione nulla non si espande (ma non si accorcia mai); Deflate si espanderà al massimo di 10 byte se limplementazione è valida.
• Il payload compresso viene quindi protetto dalle alterazioni e crittografato. Se gli algoritmi di crittografia e integrità correnti sono “nulli”, questo passaggio non è necessario. In caso contrario, viene aggiunto un MAC , quindi un po di riempimento (a seconda dellalgoritmo di crittografia) e il risultato viene crittografato. Questi passaggi inducono nuovamente una certa espansione, che lo standard SSL limita a 1024 byte extra (combinata con la massima espansione dalla fase di compressione, questo ci porta a 18432 byte, a cui dobbiamo aggiungere lintestazione di 5 byte).

Il MAC è, di solito, HMAC con una delle solite funzioni hash (principalmente MD5, SHA-1 o SHA-256) (con SSLv3, questo non è il “vero” HMAC ma qualcosa di molto simile e, per quanto ne sappiamo, sicuro come HMAC). La crittografia utilizzerà una crittografia a blocchi in modalità CBC o la RC4 stream cipher. Si noti che, in teoria, potrebbero essere impiegati altri tipi di modalità o algoritmi, ad esempio, una di queste modalità ingegnose che combinano crittografia e controlli di integrità; ci sono anche alcune RFC per questo . In pratica, tuttavia, le implementazioni distribuite non ne sono ancora a conoscenza, quindi fanno HMAC e CBC. Fondamentalmente, il MAC viene prima calcolato e aggiunto ai dati e il risultato viene crittografato. Questo è MAC-then-encrypt e in realtà non è una buona idea . Il MAC viene calcolato sulla concatenazione del payload (compresso) e un numero di sequenza, in modo che un aggressore industrioso non possa scambiare i record.

Handshake

handshake è un protocollo che viene riprodotto allinterno del protocollo di registrazione. Il suo obiettivo è stabilire gli algoritmi e le chiavi che devono essere utilizzati per i record. Consiste di messaggi . Ogni messaggio di handshake inizia con unintestazione di quattro byte, un byte che descrive il tipo di messaggio, quindi tre byte per la lunghezza del messaggio (convenzione big-endian). I successivi messaggi di handshake vengono quindi inviati con i record contrassegnati con il tipo “handshake” (il primo byte dellintestazione di ogni record ha valore 22).

Nota i livelli: i messaggi di handshake, completi di quattro- byte, vengono quindi inviati come record e ogni record anche ha la propria intestazione. Inoltre, è possibile inviare più messaggi di handshake allinterno dello stesso record e un determinato messaggio di handshake può essere suddiviso in più record.Dal punto di vista del modulo che costruisce i messaggi di handshake, i “record” sono solo un flusso su cui possono essere inviati byte; è ignaro delleffettiva suddivisione di quel flusso in record.

Handshake completo

Inizialmente, client e server “concordano” sulla crittografia nulla senza MAC e compressione nulla. Ciò significa che il record che invieranno per primo verrà inviato come testo in chiaro e non protetto.

Il primo messaggio di una stretta di mano è un ClientHello. È il messaggio con cui il client dichiara la sua intenzione di fare un po di SSL. Notare che “client” è un ruolo simbolico; significa “la parte che parla per prima”. Accade così che nel contesto HTTPS, che è HTTP-allinterno-SSL-allinterno-TCP, tutti e tre i livelli abbiano una nozione di “client” e “server” e sono tutti daccordo (il client TCP è anche il client SSL e il client HTTP), ma è una specie di coincidenza.

Il messaggio ClientHello contiene:

• il protocollo massimo versione che il client desidera supportare;
• il “client random” (32 byte, di cui 28 dovrebbero essere generati con un generatore di numeri crittograficamente forte);
• il ” ID sessione “(nel caso in cui il client desideri riprendere una sessione con un handshake abbreviato, vedere sotto);
• lelenco delle” suite di cifratura “di cui il client è a conoscenza, ordinate in base alle preferenze del cliente;
• lelenco degli algoritmi di compressione di cui il cliente è a conoscenza, ordinati in base alle preferenze del cliente;
• alcune estensioni opzionali.

A cipher suite è un identificatore simbolico a 16 bit per un set di crittografie c algoritmi. Ad esempio, la suite di crittografia TLS_RSA_WITH_AES_128_CBC_SHA ha valore 0x002F e significa che “i record utilizzano la crittografia HMAC / SHA-1 e AES con una chiave a 128 bit e lo scambio della chiave avviene tramite crittografia una chiave casuale con la “chiave pubblica RSA del server”.

Il server risponde a ClientHello con un ServerHello che contiene:

• la versione del protocollo che il client e il server utilizzeranno ;
• il “server casuale” (32 byte, con 28 byte casuali);
• lID di sessione per questa connessione;
• la suite di crittografia che verrà utilizzata;
• lalgoritmo di compressione che verrà utilizzato;
• facoltativamente, alcune estensioni.

Lhandshake completo ha questo aspetto:

 Client Server ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data 

(Questo schema è stato spudoratamente copiato dalla RFC.

Vediamo ClientHello e ServerHello. Quindi, il server invia alcuni altri messaggi, che dipendono dalla suite di cifratura e da qualche altro parametro rs:

• Certificato: il certificato del server, che contiene la sua chiave pubblica. Di più su quello sotto. Questo messaggio viene quasi sempre inviato, tranne se la suite di crittografia richiede un handshake senza certificato.
• ServerKeyExchange: alcuni valori extra per lo scambio di chiavi, se ciò che è nel certificato non è sufficiente. In particolare, le suite di crittografia “DHE” utilizzano uno scambio di chiavi Diffie-Hellman effimero, che richiede quel messaggio.
• CertificateRequest: un messaggio che richiede che il client anche si identifichi con un proprio certificato. Questo messaggio contiene lelenco dei nomi dei trust anchor (noti anche come “certificati radice”) che il server utilizzerà per convalidare il certificato client.
• ServerHelloDone: un messaggio marker (di lunghezza zero) che dice che il server è terminato e il client dovrebbe ora parlare.

Il client deve quindi rispondere con:

• Certificato: il certificato client, se il server ne ha richiesto uno. Esistono sottili variazioni tra le versioni (con SSLv3, il client deve omettere questo messaggio se non dispone di un certificato; con TLS 1.0+, nella stessa situazione, deve inviare un Certificate messaggio con un elenco di certificati vuoto).
• ClientKeyExchange: la parte client dello scambio di chiavi effettivo (ad esempio, un valore casuale crittografato con la chiave RSA del server).
• CertificateVerify: a firma digitale calcolata dal client su tutti i precedenti messaggi di handshake. Questo messaggio viene inviato quando il server ha richiesto un certificato client e il client ha rispettato. Questo è il modo in cui il client dimostra al server che realmente “possiede” la chiave pubblica che è codificata nel certificato che ha inviato.

Quindi il client invia un ChangeCipherSpec messaggio, che non è un messaggio di handshake: ha il suo tipo di record, quindi verrà inviato in un record tutto suo.Il suo contenuto è puramente simbolico (un singolo byte di valore 1). Questo messaggio indica il punto in cui il client passa alla suite di crittografia e alle chiavi appena negoziate. I record successivi dal client verranno quindi crittografati.

Il messaggio Finished è un checksum crittografico calcolato su tutti i precedenti messaggi di handshake (sia dal client che dal server). Poiché viene emesso dopo ChangeCipherSpec, è anche coperto dal controllo di integrità e dalla crittografia. Quando il server riceve quel messaggio e ne verifica il contenuto, ottiene una prova che ha effettivamente parlato con lo stesso client da sempre. Questo messaggio protegge lhandshake da alterazioni (laggressore non può modificare i messaggi di handshake e continuare a ricevere il messaggio Finished).

Il server finalmente risponde con il proprio ChangeCipherSpec quindi Finished. A quel punto, lhandshake è terminato e il client e il server possono scambiarsi i dati dellapplicazione (in record crittografati contrassegnati come tali).

Da ricordare: il client suggerisce ma il server sceglie . La suite di cifratura è nelle mani del server. I server cortesi dovrebbero seguire le preferenze del client (se possibile), ma possono fare diversamente e alcuni lo fanno effettivamente (ad esempio come parte della protezione contro BEAST).

Handshake abbreviato

Nellhandshake completo, il server invia un “ID sessione” (cioè un gruppo di massimo 32 byte) al client. Successivamente, il client può tornare indietro e inviare lo stesso ID di sessione come parte del suo ClientHello. Ciò significa che il client ricorda ancora la suite di crittografia e le chiavi dellhandshake precedente e vorrebbe riutilizzare questi parametri. Se il server anche ricorda la suite di crittografia e le chiavi, copia lID di sessione specifico nel suo ServerHello, quindi segue handshake abbreviato :

 Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data 

Lhandshake abbreviato è più breve: meno messaggi, no attività di crittografia asimmetrica e, soprattutto, latenza ridotta . I browser Web e i server lo fanno molto. Un tipico browser Web aprirà una connessione SSL con un handshake completo, quindi eseguirà handshake abbreviati per tutte le altre connessioni allo stesso server: le altre connessioni si apriranno in parallelo, e anche le connessioni successive allo stesso server. In effetti, i server Web tipici chiudono le connessioni dopo 15 secondi di inattività, ma ricorderanno le sessioni (la suite di crittografia e le chiavi) per molto più tempo (possibilmente per ore o addirittura giorni).

Scambio di chiavi

Esistono diversi algoritmi di scambio di chiavi che SSL può utilizzare. Questo è specificato dalla suite di cifratura; ogni algoritmo di scambio di chiavi funziona con alcuni tipi di chiave pubblica del server. Gli algoritmi di scambio delle chiavi più comuni sono:

• RSA: la chiave del server è di tipo RSA. Il client genera un valore casuale (il ” pre-master secret “di 48 byte, di cui 46 casuali) e lo crittografa con la chiave pubblica del server. Non esiste ServerKeyExchange.
• DHE_RSA: la chiave del server è di tipo RSA, ma utilizzata solo per firma. Lo scambio di chiavi effettivo utilizza Diffie-Hellman. Il server invia un messaggio ServerKeyExchange contenente i parametri DH (modulo, generatore) e una chiave pubblica DH appena generata; inoltre, il server firma questo messaggio. Il client risponderà con un ClientKeyExchange messaggio che contiene anche una chiave pubblica DH appena generata. Il DH restituisce il “segreto pre-master “.
• DHE_DSS: come DHE_RSA, ma il server ha una chiave DSS (” DSS “è anche noto come “DSA” ). DSS è un algoritmo di sola firma.

Gli algoritmi di scambio di chiavi meno comunemente usati includono:

• DH: la chiave del server è di tipo Diffie-Hellman (stiamo parlando di un certificato che contiene un Tasto DH). Questo era “popolare” in un modo amministrativo (il governo federale degli Stati Uniti ne imponeva luso) quando il brevetto RSA era ancora attivo (questo era durante il secolo precedente). Nonostante la spinta burocratica, non è mai stato distribuito così ampiamente come RSA.
• DH_anon: come le suite DHE, ma senza la firma del server. Questa è una suite di cifratura senza certificati. Per costruzione, è vulnerabile agli attacchi Man-in-the-Middle , quindi molto raramente abilitato.
• PSK: chiave precondivisa suite di crittografia. Lo scambio di chiavi solo simmetrico, basato su un segreto condiviso prestabilito.
• SRP: lapplicazione del protocollo SRP che è un protocollo di scambio chiavi autenticato con password . Il client e il server si autenticano a vicenda per quanto riguarda un segreto condiviso, che può essere una password a bassa entropia (mentre PSK richiede un segreto condiviso ad alta entropia). Molto elegante. Non ancora ampiamente supportato.
• Una chiave RSA effimera: come DHE ma con una coppia di chiavi RSA appena generata. Poiché la generazione di chiavi RSA è costosa, questa non è unopzione popolare ed è stata specificata solo come parte delle suite di cifratura “export” che rispettavano le normative statunitensi di esportazione precedenti al 2000 sulla crittografia (cioè chiavi RSA al massimo di 512 bit). Nessuno lo fa al giorno doggi.
• Varianti degli DH* algoritmi con curve ellittiche . Molto alla moda. Dovrebbe diventare comune in futuro.

Certificati e autenticazione

I certificati digitali sono contenitori per chiavi asimmetriche. Hanno lo scopo di risolvere la distribuzione delle chiavi. Vale a dire, il client desidera utilizzare la chiave pubblica del server. Laggressore tenterà di fare in modo che il client utilizzi la chiave pubblica attaccante “. Quindi il client deve avere un modo per assicurarsi che stia utilizzando la chiave giusta.

SSL dovrebbe utilizzare X.509 . Questo è uno standard per i certificati. Ogni certificato è firmato da una Autorità di certificazione . Lidea è che il client conosca intrinsecamente le chiavi pubbliche di una manciata di CA (questi sono i “trust anchor” o “certificati root”). Con queste chiavi, il client può verificare la firma calcolata da una CA su un certificato che è stato rilasciato al server. Questo processo può essere esteso in modo ricorsivo: una CA può emettere un certificato per unaltra CA (ad esempio firmare la struttura del certificato che contiene il nome e la chiave dellaltra CA). Una catena di certificati che inizia con una CA radice e termina con il certificato del server, con i certificati CA intermedi in mezzo, ogni certificato viene firmato relativamente alla chiave pubblica che è codificata nel certificato precedente, è chiamata, senza fantasia, a catena di certificati .

Quindi il client dovrebbe fare quanto segue:

• Ottenere una catena di certificati che termina con il certificato del server. Si suppone che il messaggio Certificate dal server contenga, precisamente, una catena di questo tipo.
• Convalida la catena, cioè verificando tutte le firme e nomi e i vari bit X.509. Inoltre, il client dovrebbe controllare lo stato di revoca di tutti i certificati nella catena, che è complesso e pesante (i browser web ora lo fanno, più o meno, ma è uno sviluppo recente).
• Verificare che il nome del server previsto sia effettivamente scritto nel certificato del server. Poiché il client non desidera solo utilizzare una chiave pubblica convalidata, vuole anche utilizzare la chiave pubblica di un server specifico . Vedi RFC 2818 per i dettagli su come eseguire questa operazione in un contesto HTTPS .

Il modello di certificazione con certificati X.509 è stato spesso criticato, non proprio per motivi tecnici, ma piuttosto per ragioni politico-economiche, concentra il potere di convalida nelle mani di pochi giocatori , che non sono necessariamente ben intenzionati, o almeno non sempre competente . Di tanto in tanto vengono pubblicate proposte per altri sistemi (ad es. Convergenza o

Dopo la lunga presentazione di SSL nella risposta precedente , andiamo con le cose divertenti, vale a dire:

Attacchi a SSL

Ci sono stati molti attacchi a SSL, alcuni basati su errori di implementazione, altri su vere debolezze del protocollo.

Bisogna ricordare che mentre SSL è uno dei protocolli più attaccati (dato che ha un profilo molto alto: unapplicazione di successo per SSL sembra molto bella nellabstract di un articolo di ricerca), SSL è anche uno dei protocolli più riparati .È da considerarsi robusto proprio perché tutti i metodi noti per attaccare i protocolli di trasporto sono stati provati su SSL e SSL è stato patchato dove appropriato.

Rollback della versione

Allinizio di SSLv3, SSLv2 era ancora ampiamente utilizzato e quindi i client inviavano comunemente messaggi, che indicavano semplicemente che anche SSLv3 era supportato; il server quindi prenderebbe il suggerimento e risponderebbe in dialetto SSLv3 + (vedere lAppendice E di RFC 2246 per i dettagli). Poiché SSLv2 aveva dei punti deboli, era nel migliore interesse dellaggressore fare in modo che un client e un server, entrambi conoscendo SSLv3, parlassero comunque tra loro usando SSLv2. Questo è chiamato un attacco di rollback della versione . Il concetto si estende formalmente anche alle versioni successive.

Sono stati aggiunti Kludges per rilevare i tentativi di rollback. Per i rollback back-to-SSLv2, un client che conosce SSLv3 + dovrebbe utilizzare un riempimento speciale per il passaggio di crittografia RSA (SSLv2 supportava solo lo scambio di chiavi basato su RSA): in PKCS # 1 , i dati che devono essere crittografati dovrebbero essere riempiti con un numero di byte casuali; un client compatibile con SSLv3 dovrebbe quindi impostare ciascuno degli ultimi otto byte di riempimento sul valore fisso 0x03. Il server quindi controlla questi byte; se vengono trovati gli otto 0x03, allora molto probabilmente viene tentato un rollback e il server rifiuta il tentativo (un client solo SSLv2 ha probabilità solo 255 ^-8 di utilizzare tali byte di riempimento per pura mancanza di fortuna, quindi i falsi positivi si verificano a un tasso trascurabile).

Per i rollback a una vecchia versione di SSL / TLS, ma non precedente a SSLv3, è stato aggiunto un altro kludge: nel segreto pre-master di 48 byte che il client crittografa con la chiave RSA del server, i primi due byte non sono casuali, ma dovrebbero essere uguali alla “versione massima del protocollo supportata” che il client ha scritto per prima nella sua ClientHello messaggio. Sfortunatamente, alcuni client hanno sbagliato, e questo kludge funziona solo con uno scambio di chiavi basato su RSA, quindi la protezione contro il rollback è molto limitata. Fortunatamente, SSLv3 + ha unaltra protezione molto più potente contro rollback, ovvero che i messaggi di handshake vengono sottoposti ad hashing insieme quando vengono creati i messaggi Finished. Questo professionista protegge dai rollback a meno che la “vecchia versione” non sia così debole che lattaccante potrebbe rompere completamente lintera crittografia prima della fine dellhandshake stesso. Questo non è ancora successo (SSLv3 è ancora ragionevolmente robusto).

Weak Cipher Suites

Alcune delle suite di cifratura standard sono intenzionalmente deboli in qualche modo. Ci sono:

• alcune suite di crittografia senza crittografia, solo controllo di integrità, ad es. TLS_RSA_WITH_NULL_SHA;
• alcune suite di cifratura con crittografia a 40 bit, come TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (suite di cifratura pensate per rispettare le rigide regole di esportazione degli Stati Uniti del secolo scorso – queste norme sono state per lo più revocate alla fine dellera di Bill Clinton);
• alcune suite di crittografia con crittografia a 56 bit, come TLS_RSA_WITH_DES_CBC_SHA. Il DES a 56 bit è fragile con la tecnologia esistente , ma è ancora un po difficile per un dilettante (anche uno studente annoiato con accesso a poche centinaia di macchine universitarie ), quindi tendo a qualificare DES a 56 bit come “forza media”.

Questo apre la strada a una variante degli attacchi di rollback della versione, in cui laggressore costringe client e server a concordare su una suite di cifratura debole, lidea è che lattaccante modifichi lelenco delle suite di cifratura annunciate dal client. Questo è utilizzabile per lattaccante se la suite di cifratura selezionata è così debole che può romperla per ricalcolare un apparentemente corretto Finished messaggio. In realtà, il MAC utilizzato in SSLv3 + (anche se basato su MD5) è abbastanza robusto da impedirlo. Quindi nessuna preoccupazione reale qui. Inoltre, la mia opinione è che qualsiasi vera debolezza qui è quando un client o un server accetta di utilizzare una suite di crittografia debole.

Per impostazione predefinita, i browser Web moderni non consentono luso di tali suite di crittografia deboli.

Furto di chiave privata

Se una connessione SSL utilizza lo scambio di chiavi RSA, e un utente malintenzionato conserva una copia dei record, quindi più tardi (possibilmente mesi dopo, possibilmente controllando tutti i backup su dischi rigidi o nastri scartati) ottiene una copia della chiave privata, quindi può svelare lhandshake e decifrare i dati.

Perfect Forward Secrecy si tratta di contrastare questo “in seguito”. Puoi ottenerlo utilizzando le suite di cifratura DHE. Con una suite di cifratura DHE, la chiave privata effettiva che potrebbe essere utilizzata per svelare lhandshake è la chiave Diffie-Hellman effimera, non la chiave privata RSA (o DSS) del server.Essendo effimero, esisteva solo nella RAM e non è mai stato scritto sul disco rigido; come tale, dovrebbe essere molto più resistente a ulteriori furti.

Quindi la lezione è: di regola, prova a usare una suite di cifratura DHE se possibile. Dovresti comunque fare attenzione ai tuoi backup e non lasciare che la tua chiave privata fuoriesca, ma, almeno, le suite DHE rendono tale perdita un po meno problematica, specialmente se si verifica dopo la fine della durata della chiave (cioè il certificato corrispondente non è più valido).

Disturbi del certificato

Lintera attività dei certificati è un punto dolente in SSL.

Tecnicamente, SSL è abbastanza indipendente da X.509. Le catene di certificati vengono scambiate come BLOB opachi. Ad un certo punto, il client deve utilizzare la chiave pubblica del server, ma il client è libero di “conoscere” quella chiave in qualsiasi modo ritenga opportuno. In alcuni scenari specifici in cui è possibile utilizzare SSL, il client conosce già il server “s chiave pubblica (codificata nel codice) e ignora semplicemente il certificato inviato dal server. Tuttavia, nel caso comune di HTTPS, il client esegue la convalida della catena di certificati del server come descritto in X.509 ( leggilo a spese della tua sanità mentale; sei stato avvertito).

Ciò produce un numero di vettori di attacco, ad esempio:

• La convalida implica la verifica che i certificati sono ancora validi alla data corrente. Come fa la macchina client a conoscere la data corrente? Con il suo orologio interno, ed eventualmente parlando con server NTP (in un modo abbastanza non protetto!). Il client potrebbe essere spento per diversi minuti, ore, giorni, persino anni (lho visto) e, in una certa misura, un potente aggressore potrebbe forzarlo giocherellando con i messaggi NTP. Ciò consentirebbe lattaccante di utilizzare certificati obsoleti che sono stati revocati anni fa. Nota un fatto divertente: il “client random” e il “server random” devono contenere 28 byte casuali e la data e lora locali (oltre 4 byte) .Questa inclusione of time doveva essere parte di una soluzione alternativa contro gli attacchi basati sul tempo. Non sono a conoscenza di alcuna implementazione che lo controlli veramente.

• Fino al 2003 circa, limplementazione della convalida del certificato in Internet Explorer / Windows non elaborava lestensione “Basic Constraints” propriamente. Leffetto finale era che chiunque con un certificato da 100 € poteva agire come CA ed emettere “certificati” con nome e chiavi scelti arbitrariamente.

• X .509 include una funzione di contenimento dei danni chiamata revoca : si tratta di pubblicare un elenco di certificati banditi, che hanno un bellaspetto, crittograficamente parlando, ma non dovrebbero essere attendibili (ad esempio la loro chiave privata è stata rubata, o contengono un nome errato). La revoca funziona solo se le parti coinvolte (ad esempio i browser) accettano di scaricare elenchi di revoche giganteschi (che possono essere lunghi diversi megabyte!) O di contattare i server OCSP . I browser moderni ora lo fanno, ma un po a malincuore, e molti accetteranno comunque di connettersi se non riuscissero a ottenere informazioni sullo stato di revoca in modo tempestivo (perché lutente umano non è paziente). La situazione generale migliora nel corso degli anni, ma abbastanza lentamente.

• Alcuni CA root hanno commesso alcuni errori in passato (ad esempio Comodo e DigiNotar). Ciò ha comportato lemissione di certificati falsi (il nome è www.microsoft.com ma la chiave privata non è affatto nelle mani di Microsoft …). Questi errori sono stati scoperti e i certificati revocati, ma sollevano ancora alcune domande scomode (ad esempio, ci sono altre CA che hanno avuto tali problemi ma non li hanno rivelati o, peggio ancora, non li hanno mai notati?).

X.509 è un insieme molto complesso di algoritmi, tecnologie, specifiche e comitati, ed è molto difficile farlo bene. Cercare di decodificare i certificati X.509 “manualmente” in un linguaggio di programmazione non protetto come il C è un modo semplice per ottenere buffer overflow.

Bleichenbacher Attacks

Daniel Bleichenbacher trovò nel 1998 un bellattacco contro RSA. Quando si crittografa un dato con RSA (come accade per il messaggio ClientKeyExchange in SSL), i dati da crittografare devono essere riempiti in ordine per creare una sequenza di byte della stessa lunghezza del modulo RSA. Il riempimento consiste principalmente di byte casuali, ma cè un po di struttura (in particolare, i primi due byte dopo il riempimento devono essere 0x00 0x02).

Dopo la decrittografia (sul server, quindi), il riempimento deve essere trovato e rimosso. Accade così che, in quel momento, quando il server decifrava ma otteneva un riempimento non valido (i byte 0x00 0x02 non cerano), lo segnalasse con un messaggio di avviso (come da specifica SSL), mentre un riempimento valido risultava il server utilizza il valore apparentemente decrittografato e continua con lhandshake.

Questo genere di cose è noto come oracolo di riempimento . Consente a un utente malintenzionato di inviare una sequenza arbitraria di byte come se fosse un segreto pre-master crittografato e sapere se la decrittografia di quella sequenza produrrebbe un riempimento valido o meno. Si tratta di “semplici informazioni a 1 bit, ma è sufficiente per recuperare la chiave privata con alcuni milioni di richieste (con stringhe” crittografate “abilmente predisposte).

Soluzione: quando la decrittografia risulta non valida riempimento, il server continua a utilizzare un segreto pre-master casuale. Lhandshake fallirà in seguito, con i messaggi Finished. Tutte le attuali implementazioni di SSL lo fanno.

Loracolo di riempimento colpisce ancora

Unaltra area in cui è stato trovato un oracolo di riempimento è nel record stessi. Considera la crittografia CBC e HMAC. I dati da crittografare vengono prima MAC, quindi il risultato viene crittografato. Con la crittografia CBC, i dati da crittografare devono avere una lunghezza che è un multiplo della dimensione del blocco (8 byte per 3DES, 16 byte per AES). Quindi viene applicato un certo riempimento, con una certa struttura.

A quel tempo (lattacco è stato scoperto da Vaudenay nel 2002), quando unimplementazione SSL stava elaborando una ricezione d record, ha restituito messaggi di avviso distinti per queste due condizioni:

• Al momento della decrittografia, non è stata trovata alcuna struttura di riempimento valida.
• Al momento della decrittografia, è stato trovato un riempimento valido, ma poi il MAC è stato verificato e non corrispondeva.

Questo è un oracolo di riempimento e che può essere utilizzato per recuperare alcuni dati crittografati. Richiede un aggressore attivo, ma non è così difficile. Vaudenay lo ha implementato ed è stato esteso al caso in cui unimplementazione SSL modificata restituisse lo stesso messaggio di avviso in entrambi i casi, ma ha impiegato più tempo per tornare nel secondo caso, a causa del tempo impiegato per ricalcolare il MAC (una bella dimostrazione di a timing attack ).

Poiché le persone non imparano mai, limplementazione Microsoft di SSL utilizzata in ASP.NET era ancora senza patch nel 2010 (otto anni dopo!), quando Rizzo e Duong reimplementarono lattacco di Vaudenay e costruirono una dimostrazione che recuperò i cookie HTTP.

Vedi questa pagina per alcuni suggerimenti. Si noti che se SSL avesse utilizzato encrypt-then-MAC , tali problemi sarebbero stati evitati (i record difettosi sarebbero stati rifiutati a livello MAC, prima anche considerando la decrittazione).

BEAST

Lattacco BEAST è di nuovo da Duong e Rizzo e, ancora una volta, è il remake di un vecchio attacco (di Philip Rogaway nel 2002). Per avere lidea, considera CBC . In questa modalità di funzionamento, ogni blocco di dati viene prima XORed con il risultato della crittografia del blocco precedente; e questo “è il risultato dello XOR che è criptato. Questo è fatto per” randomizzare “i blocchi ed evitare le fughe che si trovano con la modalità ECB. Poiché il primo blocco non ha un blocco “precedente”, deve esserci un vettore di inizializzazione (IV), che svolge il ruolo del blocco precedente per il primo blocco.

Si scopre che se un utente malintenzionato può controllare parte dei dati che devono essere crittografati e può anche prevedere lIV che verrà utilizzato, allora può trasformare la macchina di crittografia in unaltra decrittazione Oracle e utilizzarlo per recuperare altri dati crittografati (che lattaccante non sceglie). Tuttavia, in SSLv3 e TLS 1.0, lattaccante può prevedere lIV per un record: è lultimo blocco di il record precedente! Quindi lattaccante deve essere in grado di inviare alcuni dati nel flusso, al fine di “spingere” i dati di destinazione, nel punto in cui limplementazione ha costruito e inviato il record precedente (tipicamente quando vale 16 kB di dati sono stati accumulati), ma non ha iniziato a costruire quello successivo.

TLS 1.1+ è protetto da questo perché in TLS 1.1 (e versioni successive), viene utilizzato un IV casuale per record. Per SSLv3 e TLS 1.0, una soluzione alternativa consiste nellinviare record di lunghezza zero: ovvero record con un payload di lunghezza zero, ma con un MAC, un riempimento e una crittografia, e il MAC viene calcolato da una chiave segreta e sulla sequenza numero, quindi questo svolge il ruolo di un generatore di numeri casuali. Sfortunatamente, IE 6.0 si blocca sui record di lunghezza zero. Altre strategie prevedono una divisione 1 / n-1 (un record di n byte viene inviato come due record, uno con un singolo byte di carico utile, laltro con il restante n-1 ).

Unaltra soluzione alternativa consiste nel forzare luso di una suite di cifratura non CBC quando possibile: il server seleziona una suite di cifratura basata su RC4 se ce nè una nellelenco delle suite di cifratura inviata dal client, anche se il client avrebbe preferito una suite di crittografia basata su CBC. Questo strumento può dirti se un dato server apparentemente si comporta in questo modo.(Nota: BEAST è un attacco al client , ma, selezionando una suite di cifratura RC4, il server può proteggere un client incauto.)

Vedi questa pagina per alcuni suggerimenti. Sebbene TLS 1.1 sia del 2006, lattacco BEAST potrebbe costringere i fornitori di browser a eseguire finalmente laggiornamento.

CRIME

Come per qualsiasi franchise di Hollywood, Duong e Rizzo hanno pubblicato nel 2012 il sequel del sequel. CRIME sfrutta una fuga di notizie che è stata teorizzata anni fa ma che è stata dimostrata chiaramente solo nella dimostrazione che hanno recentemente pubblicato. CRIME sfrutta la compressione, nella stessa configurazione dellattacco BEAST (lattaccante può inviare alcuni propri dati in una connessione SSL, dove vengono inviati anche dati di destinazione interessanti come un cookie). In parole povere, lattaccante inserisce nei suoi dati un valore potenziale per la stringa di destinazione e, se corrisponde, la compressione rende i record risultanti più brevi. Vedi questa domanda per unanalisi (pre-cognitiva).

CRIME viene evitato non utilizzando affatto la compressione a livello di TLS, che è cosa fanno ora i browser. Internet Explorer e IIS non hanno mai implementato la compressione a livello di TLS in primo luogo (per una volta, la sciatteria ha salvato la giornata); Firefox e Chrome lo hanno implementato e disattivato questestate (sono stati avvertiti da Duong e Rizzo, che sono abbastanza responsabili nella loro attività).

CRIME mostra perché ho scritto, verso linizio del mio Spiegazioni SSL :

SSL soddisfa questi obiettivi in larga misura (ma non assoluta).

In effetti, la crittografia perde la lunghezza dei dati crittografati. Non esiste una buona soluzione nota contro questo. E la lunghezza da sola può rivelare molte cose. Ad esempio, osservando con un monitor di rete una connessione SSL, possiamo individuare le “strette di mano extra” allinterno del flusso (perché il primo byte di ogni record identifica il tipo di dati nel record e non è crittografato); con la lunghezza dei record, è abbastanza facile vedere se il client ha fornito un certificato o meno.

Poodle

( edit: questa sezione è stata aggiunta il 15-10-2014)

Lattacco “Poodle” sfrutta un difetto specifico di SSL 3.0 con suite di crittografia basate su CBC. Si basa su una caratteristica spesso trascurata di SSL 3.0: la maggior parte dei byte di riempimento vengono ignorati. In TLS 1.0, il riempimento (byte aggiunti in un record per rendere la lunghezza compatibile con la crittografia CBC, che elabora solo blocchi completi) è completamente specificato; tutti i byte devono avere un valore specifico e il destinatario lo verifica. In SSL 3.0, il riempimento del contenuto dei byte viene ignorato, il che consente a un aggressore di eseguire alterazioni che passano per lo più inosservate. Lalterazione influisce solo sui dati non applicativi ma può essere utilizzata come un oracolo di decrittazione in un modo vagamente simile a BEAST.

Maggiori dettagli possono essere letti in questo risposta .

Il futuro

Gli esseri umani non imparano mai. Cè molta pressione per aggiungere estensioni ingegnose a SSL per molti motivi che sembrano sempre buoni allinizio, ma possono causare problemi aggiuntivi.

Considera, ad esempio, SSL FalseStart . Principalmente, si tratta del client che invia i dati dellapplicazione subito dopo aver inviato il suo messaggio Finished (in una stretta di mano completa), senza attendere per il Finished messaggio dal server. Ciò riduce la latenza, il che è positivo e ben intenzionato. Tuttavia, cambia la situazione della sicurezza: prima di aver ricevuto il messaggio Finished dal server, questultimo viene autenticato solo implicitamente (il client non ha ancora la prova che il server designato fosse realmente coinvolto tutto; sa solo che qualunque cosa invia sarà leggibile solo dal server previsto). Questo può avere degli impatti; ad esempio, un utente malintenzionato potrebbe emulare il server fino a quel momento e forzare, ad esempio, il client a utilizzare una suite di crittografia basata su CBC o la compressione TLS. Pertanto, se un client implementa FalseStart, allora diminuisce lefficacia delle misure di protezione contro BEAST e CRIME, come potrebbe altrimenti essere imposto dal server.

(Google ha disabilitato FalseStart questa primavera, apparentemente a causa di problemi di compatibilità con alcuni server. In ogni caso, la “riduzione della latenza del 30%” sembrava strana, perché FalseStart avrebbe avuto una certa influenza solo su handshake completi, non abbreviati, quindi non lo faccio ” Non credo in questi presunti benefici; non a quella portata, almeno.)

Commenti

• Limpegno profuso per fornire buone informazioni attraverso questo sito è davvero pazzo ed estremamente ammirevole. Molto apprezzato.
• Vedi anche tools.ietf.org / html / rfc7457