Attacchi in SSL e SSH

Poiché la connessione SSH scambia una chiave in modo tale che solo i titolari delle due chiavi private possano avere accesso alla chiave condivisa, non è possibile per i router inserire informazioni significative. Potrebbero tentare di iniettare informazioni, ma poiché le informazioni che iniettano non sono crittografate con la chiave di crittografia condivisa di comune accordo, verranno visualizzate come spazzatura all'altra estremità e se lo stream era in modalità concatenamento, sarebbe anche potenzialmente corrompe l'intera sessione.

SSL utilizza un meccanismo simile in cui l'utente finale sarà in grado di dire da quale server sono state inviate le informazioni e solo il server a cui l'utente finale intendeva parlare può ottenere l'accesso alla chiave di crittografia selezionata dal client.

L'unica cosa che non può essere determinata necessariamente è se il client B è in realtà il client a meno che non dispongano anche di una coppia di chiavi pubblica / privata che è stata firmata o conosciuta in precedenza. Sia SSL che SSH hanno meccanismi per supportare l'autenticazione reciproca, ma spesso solo il server è autenticato contro una CA.

Indipendentemente da ciò, mentre R1 o R2 (o chiunque) potevano affermare di essere B, non sapevano quale fosse la richiesta di B in entrambi i sistemi, quindi non potevano provare a convincere B che erano in realtà A fintanto che B tentava una stretta di mano con la chiave pubblica di A.

L'intera ragione per cui SSL e SSH sono stati definiti era precisamente per impedire attacchi passivi e attivi da qualsiasi posizione tra i due punti finali. In particolare, i tuoi router R1 e R2:

1. non può apprendere i dati trasferiti da A a B ( riservatezza );
2. non può alterare i dati trasferiti ( integrità );
3. non può impersonare A o B ( autenticità ).

Nel caso specifico di inserimento di nuovi dati all'interno del tunnel, vediamo come viene evitato nel caso di SSL (SSH è simile): in SSL / TLS , i dati vengono inviati come successivi record . Ogni record contiene fino a 16 kB di dati. Una volta che l'iniziale handshake ha avuto luogo (questo è dove avvengono i certificati e la crittografia asimmetrica), entrambi gli endpoint condividono una chiave di sessione K (chiamata "chiave master" in SSL terminologia), da cui calcolano alcune chiavi utilizzate per crittografare e autenticare il record. In particolare, per ogni record è calcolato un codice di autenticazione dei messaggi , che può essere visualizzato come una sorta di hash con chiave; il mittente calcola il MAC e il ricevitore lo ricalcola. La proprietà crittografica del MAC è che, senza la conoscenza della chiave MAC, non è possibile forgiare una coppia (d, m) tale che m sia il MAC per dati d .

Il MAC è calcolato sulla concatenazione dei dati del record e, soprattutto, un numero di sequenza del record. A causa del MAC, gli attaccanti non possono inserire record extra, riprodurre vecchi record, rimuovere record o modificare l'ordine dei record, perché ciò richiederebbe la ricalcolo del MAC per i nuovi dati o il numero di sequenza - e, senza la chiave, è un no go .

Si noti che i router R1 e R2 possono ancora modificare i dati o bloccarli; le alterazioni sono rilevate in modo affidabile dal ricevitore, ma se l'attaccante vuole semplicemente tagliare i fili, beh, può farlo. Niente in SSL (o SSH) prova a recuperare dalle alterazioni.