Perché Cloudflare è un attacco MITM? [chiuso]

Sfortunatamente, non puoi contrastarlo senza essere tecnicamente scorretto.

Per Wikipedia, la definizione di un attacco Man in the Middle :

"In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other."

I proprietari di siti Web che configurano il proprio sito per utilizzare Cloudflare non credono che stiano comunicando direttamente con i visitatori, quindi sotto la definizione tecnica non è un attacco MitM.

Cloudflare è contratto e pagato dal proprietario del sito per eseguire il servizio che Cloudflare sta facendo. Pertanto, per definizione, Cloudflare fa parte della rete di fornitori di servizi del proprietario del sito e fintanto che Cloudflare fornisce servizi come specificato nel contratto, non è un utente malintenzionato e il servizio fornito non è un attacco.

Dire che Cloudflare è un MitM è analogo a dire che eBay / Amazon sono MitM tra te e i venditori. Chiedere ai browser di bloccare Cloudflare è come chiedere ai browser di bloccare eBay / Amazon perché non ti piacciono i termini e le condizioni del mercato.

Ciò che i provider CDN come Cloudflare stanno facendo è in realtà molto meglio della situazione precedente a Cloudflare e ai fornitori di CDN come è avvenuto. Prima che CDN diventi un luogo comune, molti ISP implementano un proxy di caching tra te e il fornitore di contenuti (questo in realtà è ancora comune nei paesi con un'infrastruttura internet meno sviluppata). In molti casi, l'ISP modificherebbe la pagina che gli utenti stanno visualizzando, di solito inserendo i propri annunci nella pagina ed eventualmente esplorando il sito per capire quali annunci pubblicare. I termini e le condizioni di questo "servizio" di solito sono effettivamente nascosti all'utente e non vengono quasi mai portati all'attenzione dell'utente quando l'utente si è registrato per il proprio servizio Internet. La maggior parte degli utenti non si accorgerebbe mai che il proprio ISP sta facendo questo e di solito non c'è modo per gli utenti di controllare quali siti o parte della pagina dovrebbero essere memorizzati nella cache e quali dovrebbero essere pubblicati direttamente.

Quando è arrivato CDN, i tavoli sono girati. Invece di lavorare per l'ISP dell'utente, ora il proxy caching funziona per il content provider. Il fornitore di contenuti sceglie esplicitamente di utilizzare Cloudflare invece di essere forzato dal proprio fornitore di servizi Internet. E poiché i fornitori di contenuti conoscono meglio i loro contenuti, hanno il controllo su quale parte del loro sito può utilizzare la cache condivisa e quale parte della pagina dovrebbe utilizzare la connessione diretta. L'unico inconveniente effettivo è che con CDN, i termini e le condizioni per il servizio di memorizzazione nella cache sono ora accettati dal fornitore di contenuti, piuttosto che dall'utente.

I fornitori di contenuti attenti alla sicurezza che desiderano utilizzare una rete CDN di solito dispongono di due server, uno che serve in blocco e contenuto pubblico attraverso la rete CDN e un server statico protetto che fornisce dati sensibili per la sicurezza. Se il tuo fornitore di contenuti non sta facendo tale separazione e sta servendo informazioni riservate al servizio personale usando un fornitore di servizi che non è adatto allo scopo, allora dovresti incolpare il tuo fornitore di contenuti, non il fornitore di servizi, perché è responsabilità del fornitore di contenuti proteggere il tuo personale dati ed è la scelta del fornitore di contenuti di utilizzare Cloudflare.

Se il browser principale inizia a bloccare i principali fornitori di CDN per impostazione predefinita, molti proprietari di siti probabilmente rimuoveranno HTTPS per consentire che il loro contenuto venga memorizzato nella cache dagli ISP. Non torneremo in un mondo con HTTPS onnipresente e senza CDN.

(In quanto segue mi riferisco al protocollo di sicurezza del livello di trasporto precedentemente noto come SSL come "TLS", perché tutte le versioni del SSL originale non sono più sicure e non dovrebbero essere utilizzate.)

Il problema è che chiunque abbia depositato il rapporto Bugzilla ha in mente un programma: niente di meno che una catena ininterrotta end-to-end di qualità TLS è un attacco MITM e quindi da temere. Mozilla ha sottolineato nella sua risposta a questo rapporto che Cloudflare è un CDN (Content Delivery Network) che significa che devono fare quello che stanno facendo con TLS per fare ciò che il loro cliente sta pagando per.

Troy Hunt (l'autore e il manutentore di "Sono stato pasticciato?") spiega nel seguente post del blog che l'alternativa a Cloudflare in molti casi è di operare con nessuna crittografia a livello di trasporto (perché il fornitore di servizi all'origine non può gestirlo): link

Questa pagina spiega anche come, TLS o nessun TLS, gli attori a livello di stato nazione possono sempre accedere ai tuoi contenuti. Non dovresti utilizzare CloudFlare per tutto ciò che è così sensibile che l'intercettazione dei dati è pericolosa per la tua salute.

HTTPS fornisce la crittografia end-to-end del traffico tra il browser e il server che detiene la chiave privata corrispondente al certificato TLS.

Quando si visita un sito Web HTTPS sul CDN di cloudflare, cloudflare detiene la chiave privata per il certificato presentato al browser (ed è piuttosto ovvio che si tratta di cloudflare, ad esempio il nome comune del certificato è in genere sni241623.cloudflaressl.com con un dozzina circa di nomi alternativi oggetto per i siti che serve). Oppure puoi eseguire un whois sull'indirizzo IP corrispondente al nome di dominio che stai visitando; troverai che è di proprietà di cloudflare.

Nota per un sito che utilizza cloudflare, il proprietario deve indirizzare i propri record DNS ai server di cloudflare, a quel punto hanno effettivamente consegnato a cloudflare il pieno controllo del proprio sito Web (purché i record DNS puntino ai server di cloudflare). Possono provare il controllo di un dominio alle autorità di certificazione che emetteranno i certificati per il tuo dominio su cloudflare.

Ora cloudflare ha il controllo per intercettare e registrare qualsiasi interazione dell'utente con il tuo sito web o silenziosamente manomettere il contenuto, se lo desiderano.

Tuttavia, questo non è un attacco Man-in-the-Middle, perché il proprietario del sito Web ha dato il permesso a cloudflare di fare tutto questo. Quindi non è un attacco, è una connessione sicura a cloudflare (che il proprietario del sito web ha dato il permesso di pubblicare i contenuti con il loro nome di dominio).

Non è diverso da un'azienda che esternalizza il proprio sito Web a una terza parte che progetta e ospita il sito web. C'è una terza parte che potrebbe fare cose nefande, ma è stata data la piena autorizzazione dal proprietario appropriato.

Oppure è come quanti siti web vengono eseguiti su host condivisi o acquistano server virtuali virtuali, dove gli amministratori della società di hosting possono ottenere tutti i dati sul server, se lo desiderano. Se qualche amministratore del tuo host VPS con accesso root ai server desiderava davvero le chiavi private per il server web in esecuzione, può ottenerle. (Si noti che cose come la cifratura completa del disco all'interno della VM possono essere aggirate, perché controllano l'hardware dell'host e possono leggere la memoria della VM.) Ancora una volta, le persone che usano host / VPS condivisi hanno scelto di fidarsi delle aziende per essere affidabili.

Alla fine, questo è tutto ciò che hai. Devi fidarti che l'organizzazione che gestisce il sito Web dall'altra parte è affidabile con qualsiasi dato tu fornisca navigando lì. Quando si visitano siti Web sul cloudflare, parte del trust CDN è in cloudflare.

(Ciò è in contrasto con i veri attacchi MitM, in cui alcuni intermediari attaccanti che non hanno accesso autorizzato intercorrono e / o alterano il traffico di rete).