Una storia di due fonti: TLS * difesa * contro Man-in-the-Middle, o no?

Per citare la parte importante dell'articolo a cui fai riferimento:

The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a man-in-the-middle attack.

TLS è utilizzato in diversi casi d'uso. Alcuni di questi casi coinvolgono un singolo trasporto end-to-end del messaggio, ad esempio facendo in modo che un client invii un messaggio a un server Web che viene quindi elaborato direttamente dal server. In questo caso TLS protegge con successo contro gli attacchi uomo nel mezzo.

Ma TLS viene anche utilizzato quando sono coinvolti più hop. In questo caso il trasporto è protetto solo con TLS tra questi hop ma un uomo nel mezzo su uno di questi hop può intercettare i dati non crittografati. Questo caso d'uso è tipico per la posta (ad esempio SMTP) ma lo si trova anche con HTTPS quando si utilizza un proxy inverso, una rete di distribuzione del contenuto o simile. In questi casi, TLS fornisce solo la sicurezza hop-by-hop ma non la sicurezza end-to-end. Quest'ultimo può essere ottenuto crittografando il messaggio prima del trasporto e decodificandolo dopo che è stato completato il trasporto completo (cioè tutto il luppolo). Per la posta questo di solito è fatto con PGP o S / MIME.

Immagina due diversi scenari:

Chiamate tipiche / dirette

Hai un client e un server. Il client invia un messaggio al server; il server fa qualcosa con la richiesta, crea una risposta e annulla la memoria che conteneva la richiesta originale. La richiesta non viene inoltrata a nessun altro sistema.

In questo caso, il trasporto va bene e non è particolarmente suscettibile a MitM, assumendo che tu abbia configurato il tuo livello di trasporto sicurezza corretta . Ci sono molte configurazioni che puoi rovinare, ma dovresti essere in grado di controllarle e correggerle usando un pen-test.

Chiamate che coinvolgono tre o più parti

Hai un client, un server di applicazioni e un server specifico per il dominio (ad esempio, un server che esegue il middleware di un host bancario). Il client invia un messaggio al server delle applicazioni; il server delle applicazioni analizza i messaggi, autentica il chiamante e inoltra una parte di esso all'host bancario.

In questa situazione, un protocollo di sicurezza a livello di messaggio consentirà all'host bancario di credere che il messaggio di richiesta sia stato ricevuto dal client originale intatto e non molestato. Se si stava utilizzando la sicurezza del trasporto, è possibile che il server delle applicazioni abbia fatto qualcosa di pericoloso, poiché avrebbe decodificato e crittografato nuovamente il messaggio. Con la sicurezza del livello messaggi, puoi crittografare o firmare parti del messaggio e passarlo intatto.

Utilizzo della sicurezza del trasporto con un intermediario di fiducia

Detto questo, se il server delle applicazioni è affidabile, l'host bancario può autenticare il server delle applicazioni (tramite la sicurezza del trasporto) se utilizza i certificati client. Con questo tipo di configurazione è possibile utilizzare la sicurezza del livello di trasporto con il rischio che l'attacco MitM sia adeguatamente mitigato.

The claim is that "transport mode" security is insecure:

"Transport mode is the least secure option and should be avoided."

Direi che stai leggendo male il documento. Non dice che la modalità di trasporto è insicura; dice che è l'opzione meno sicura e, implicitamente, tra l'insieme di opzioni di cui parla.

Non dovresti considerare la sicurezza come un binario si / no; piuttosto, dovresti vederlo in termini più concreti, come un elenco dei modi in cui il sistema potrebbe essere attaccato. Nel loro caso, anche se la sicurezza del trasporto è configurata il più strongmente possibile (certificati SSL tra ogni client e il server), ci sono scenari in cui la comunicazione passa attraverso più hop SSL (es. C'è un proxy di bilanciamento del carico tra il client e il punto finale). Se uno qualsiasi dei server in tale catena viene violato, l'autore dell'attacco può interrompere entrambi:

1. Riservatezza: l'autore dell'attacco è in grado di leggere il contenuto del carico utile.
2. Autenticità: l'autore dell'attacco è in grado di falsificare messaggi che appaiono come se provenissero dal client.

Un altro modo di metterlo: se si utilizza il sistema in quella configurazione, i client possono fidarsi potenzialmente dei server intermedi per non falsificare i messaggi. Non è più sicuro di quei server intermedi.

Le altre due opzioni che offrono sono quelle che chiamano "sicurezza dei messaggi" e "credenziali dei messaggi". Queste opzioni consentono ai client di essere meno affidabili del server:

• In modalità di sicurezza dei messaggi, il client crittografa ogni messaggio con una chiave che i server intermedi non hanno, solo l'endpoint finale. Quindi se un utente malintenzionato entra in un server intermedio può solo eliminare messaggi (e forse non in modo non rilevabile).
• Non spiegano la modalità credenziali del messaggio abbastanza bene da poter capire molto bene la sua sicurezza. Il client non crittografa i messaggi, quindi un utente malintenzionato che si rompe nel proxy può sicuramente leggerli. Il vantaggio rispetto alla sicurezza del trasporto sembra essere che con la sicurezza del trasporto ogni hop è autenticato (il client si autentica con il proxy, il proxy si autentica con l'endpoint), ma con le credenziali del messaggio il client si autentica sull'endpoint. Non riesco a capire se un utente malintenzionato che si intromette nel proxy sia in grado di falsificare messaggi. (Cattiva documentazione!)

Nota che per tutte e tre le modalità c'è uno scenario un po ' in cui un utente malintenzionato causa un errore qualcosa . Di nuovo, la sicurezza non è un problema sì / no.

Citazione dal tuo link:

When using a transport like HTTPS, this mode has the advantage of being efficient in its performance and well understood because of its prevalence on the Internet. The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a man-in-the-middle attack.

Sciocchezze.

Mentre "TLS" potrebbe benissimo essere usato in questo modo, ad es. in alcuni protocolli P2P in cui tutti gli host sono considerati attendibili per qualche motivo, la stragrande maggioranza dei casi d'uso sono sistemi end-to-end (incluso HTTPS). L'autore non sembra sapere molto su questo argomento.

Per i siti Web, per quanto ne sappiamo, HTTPS è sufficiente per prevenire MITM.