Che danno può fare un MITM al traffico crittografato e cosa si può fare al riguardo?

Supponendo che la crittografia sia implementata correttamente e che la chiave non sia compromessa, tutto ciò che un aggressore MITM può ottenere modificando i dati lo trasforma in una spazzatura imprevedibile. Quando A e B eseguono qualsiasi verifica di plausibilità sui dati, dovrebbero notarlo.

Quindi cosa può fare l'attaccante?

1. Elimina completamente la comunicazione semplicemente filtrando tutto
2. Trasforma la comunicazione in assurdità apportando alcune modifiche casuali (contromisura: aggiungi un hash a ciascun messaggio per rilevare e scartare i messaggi danneggiati)
3. Inserisci ancora più sciocchezze nella comunicazione sperando di esaurire le risorse (attacco DOS)
4. Reinvia messaggio precedentemente osservato ("replay attack"). Anche se non riescono a capire un messaggio, se hanno osservato che l'invio di un messaggio specifico ha causato qualcosa, l'invio dello stesso messaggio potrebbe causare nuovamente la stessa cosa (contromisura: aggiungere un timestamp a ciascun messaggio e scartare i messaggi che sono troppo vecchi. Il timestamp dovrebbe essere incluso nel calcolo dell'hash).
5. Crea una copia del testo cifrato nel caso in cui in qualche modo riesca a ottenere la chiave di crittografia in futuro.

Aggiungere alcune possibili minacce a ciò che @Philipp ha detto. Non si specifica quale modalità di cifratura è in uso.

In caso di modalità ECB (assolutamente scoraggiato), poiché i blocchi crittografati non sono randomizzati, un attaccante sarà in grado di distinguere blocchi identici. Con una certa conoscenza del messaggio inviato, un utente malintenzionato può decodificare l'intera comunicazione

Nel caso in cui sia in uso una modalità malleabile come CBC, un utente malintenzionato che conosce parte del testo in chiaro potrebbe riuscire a manomettere il messaggio.

Alcune modalità che usano nonce, come CTR, hanno un limite su quanti blocchi puoi cifrare senza perdere la sicurezza. Se la quantità di blocchi crittografati supera tale limite, un utente malintenzionato potrebbe recuperare anche il testo in chiaro

Inoltre, anche se non è ancora pratico con l'hardware corrente, l'acquisizione di traffico sufficiente consentirà all'utente malintenzionato di eseguire un attacco di compleanno

L'utente malintenzionato può modificare i dati in modo malevolo per tentare di sfruttare potenziali vulnerabilità nel codice di decrittografia. Ad esempio, se utilizzi TLS, esiste la possibilità che tu stia utilizzando OpenSSL per questo, in modo che l'attaccante possa provare a creare pacchetti per sfruttare i bug OpenSSL, possibilmente ottenendo l'esecuzione di codice in modalità remota per divulgare la tua chiave e decifrare l'intera comunicazione, o compromettere la macchina per un accesso successivo.

Assume a server and a client that are each on physically secure, uncompromised networks. However, between each network is an attacker that is capable of viewing traffic.

Questo in pratica significa: "Assumi A, il lancio A dalla finestra, e smetti di assumerlo."

The traffic between the two devices is encrypted with 256-bit AES using a key shared by a physical side channel (thumb drive).

Ciò rende irrilevante il resto della configurazione.

The two device's firewalls are set to drop all traffic not from each other's IP address.

Questo è inutile e non aggiunge molto in termini di sicurezza. È banale riscrivere l'intestazione TCP e falsificare la fonte.

Sembra che tu stia dicendo: "Il punto A e il punto B usano la crittografia end-to-end con una chiave simmetrica nota come A e B, e mai trasmessa in banda. Se un attaccante compromette [qualsiasi parte] della rete tra A e B, cosa può fare l'attaccante fare contro cosa possono conoscere ? "

Supponendo che tu stia usando AES256 per codificare i tuoi dati prima di lasciare il punto A, e il punto B decrittalo, quindi l'intermediario non può fare molto.

Cosa possono sapere - che le transazioni e le conversazioni di dati avvengono tra i due punti insieme ad altri metadati.

Cosa possono fare - bloccare, reindirizzare, memorizzare nella cache e manomettere in altro modo il traffico.

Poiché la tua configurazione non menziona l'autenticazione, solo la crittografia, quindi un attacco MiTM potrebbe (in questa configurazione) decrittografare i tuoi dati, memorizzarli nella cache, quindi ricrittografarli e inviarli. Né il punto A né B ne sono a conoscenza.

"Come decifrano i miei dati ???" - se questo è un attore di livello statale con risorse, possiamo supporre che abbiano le risorse per l'ingegnere sociale stesse una copia della chiave, o il malware ne ha rilevato una copia quando si trovava nell'unità USB di un computer, ecc.).

Il tuo problema principale è che stai usando la crittografia senza autenticazione. Ora, se si utilizza la crittografia con firma e autenticazione dei messaggi, se il MiTM sta manomettendo del tutto il traffico, entrambi gli endpoint lo sapranno. (Beh ... potrebbe sapere a seconda dell'implementazione).