​Un cliente, vittima di ramsomware, diceva: "dicono che mi hanno bucato il firewall". Abbiamo risposto che non credevamo che fosse successo. E abbiamo pensato che dire che gli avevano "bucato" il firewall sarebbe stato come dire che gli avevano "scas­si­na­to" una serratura che era stata lasciata aperta. E il buco era aperto per necessità, non per distrazione.

Tanto, ma proprio tanto tempo fa, siamo stati a una conferenza Microsoft a Barcellona. Lì, tra le molte presentazioni interessanti, ne abbiamo vista una di un esperto di si­cu­rez­za, che ci ha colpito per almeno due motivi:

• Diceva cose intelligenti, e l'intelligenza è merce rara
• Aveva senso dell'umorismo, cosa non frequente tra gli esperti di sicurezza, che si prendono molto sul serio perché sono sempre sotto attacco.
  

In quella presentazione, tra le varie cose, abbiamo sentito questo nuovo (allora) a­cro­ni­mo, UFTP. Oggi lo si può trovare come UFBP ma il significato è esattamente lo stesso: Universal Firewall Traversal (oppure Bypass) Protocol.

Il problema è noto: far passare dai firewall protocolli specifici di un'applicazione può essere difficile, se non impossibile. Non perché sia tecnicamente difficile da fare, ma perché i responsabili del firewall non lo vogliono fare. E poi non è nemmeno detto che ci sia un responsabile a cui chiedere. Se ad esempio sono ospite da un cliente o in un albergo, non solo probabilmente non posso chiedere che facciano qualcosa di spe­ci­fi­co per me, ma appunto non so nemmeno a chi chiedere. E poi, chi gestisce il firewall non può stare lì a rispondere a ogni tipo di richiesta, altrimenti alla fine più che con un firewall si troverà con una fetta di groviera.

E quindi a un certo punto qualcuno ha osservato che HTTP/HTTPS (i protocolli del web) sono quasi sempre aperti, sono il passpartout dei firewall. E che quindi la cosa più semplice da fare era di usare HTTP come vettore, una specie di cavallo di Troia in­for­ma­ti­co, per trasportare protocolli che con HTTP non hanno nulla a che fare.  Ed ecco che HTTP è diventato, per scherzo, UFBP, il protocollo passpartout da usare per pas­sa­re dai firewall.
Oggi ci sono tantissime cose che "fingono" di essere HTTP: ad esempio terminal server, molte VPN, i protocolli di sincronizzazione di Exchange. E sempre su HTTP passano cose che con il World Wide Web hanno poco, anzi nulla a che fare, come ad esempio i web services, che hanno dentro la parola web, ma sono delle API.

E, indubbiamente, questo modo di comunicare su internet ha semplificato un sacco di cose, ma ha un prezzo.

Per capire meglio il problema vorremmo fare un'analogia. Supponiamo che un i­po­te­ti­co censore voglia controllare tutte le comunicazioni che passano in un certo canale. Ora, trattandosi di un censore ignorante (del resto, fa il censore), questo signore co­no­sce solo l'Italiano, e quindi decide di imporre che su quel canale si comunichi es­clu­si­va­men­te in lingua Italiana.
E, come dicono da queste parti, "fatta la legge, trovato l'inganno". Consideriamo il mes­sag­gio sotto:
Questo è un messaggio in italiano. Lettera acca, lettera e, elle, elle, lettera o, spazio, v doppia, lettera o, erre ,elle, di, Punto. Fine del messaggio.
Crediamo si possa dire che questo messaggio:

• È in Italiano.
  
• Rispetta la lettera della legge.
  
• Non ne rispetta l'intento.
  
• Contiene un messaggio non in italiano.
• È mostruosamente inefficiente.
  
• Per capirlo serve sapere l'inglese.
  

Usare HTTP per trasmettere roba che in realtà non è HTTP ha più o meno gli in­con­ve­nien­ti dell'esempio, anche se non così estremi. Ad esempio active-sync trasmette tutti i contenuti codificati Base64, in modo che siano sempre solo testo. Così facendo si but­ta­no 2 bit ogni 8, cioè si spreca il 25% della banda. Inoltre, far passare di tutto per HTTP, limita la capacità del firewall di distinguere e bloccare gli abusi. Ad esempio è im­pro­ba­bi­le che un firewall sappia entrare nel merito di una connessione Mapi over HTTP per bloccarla se non corretta.
Un esempio di questo problema è l'episodio di marzo 2021, quando, tutti di corsa hanno dovuto aggiornare i server Exchange accessibili da Internet perché  Hafnium, un gruppo di hacker, stava sfruttando una qualche debolezza di Exchange per entrare nei server e da lì nelle reti. A tutt'oggi non ci risulta esista un firewall che protegga un server privo delle patch. Al massimo rivelano i malware che i pirati iniettano nei server dopo che l'attacco è avvenuto con successo.
L'uso sistematico di HTTP per gran parte delle comunicazioni ha comunque un im­por­tan­te vantaggio: standardizza e mette a fattor comune tutte le parti presenti in tutti i protocolli come ad esempio l'autenticazione. E così facendo semplifichiamo l'im­ple­men­ta­zio­ne e aumentiamo la sicurezza.

Il risultato di tutto questo è che il ruolo del firewall è cambiato. Non entra più tanto nel merito della "conversazione" che passa, perché non la può comprendere, ma cerca in quello che passa le "firme" del contenuto malevolo, in un modo simile agli antivirus. Un po' come se il censore dell'esempio cercasse la parola "hello" e bloccasse messaggi che la contenessero, non perché ne capisse il significato ma perché gli è stato detto essere pericolosa.
Ma tra antivirus e firewall c'è un'importante differenza: l'antivirus ha modo di vedere il malware nella sua forma finale, quella che il sistema sta per eseguire, mentre il firewall ne vede una forma  transitoria, potenzialmente alterata dai vincoli imposti dal mezzo trasmissivo, quindi il firewall potrebbe essere meno efficace. In compenso il firewall le cose le vede prima che arrivino, e può quindi bloccarle prima che diventino pericolose.

Quindi: se HTTP serve a trasmettere di tutto, e non solo a trasferire ipertesti, allora forse potremmo cambiarlo di nome (UFBP?), e soprattutto adattarlo e renderlo il più possibile d'uso generale, rimuovendo limiti che avrebbero senso se si trattasse solo di HTML, e magari aggiungendo meccanismi per minimizzare l'uso di banda, facilitare la trasmissione di contenuti binari, aumentare la sicurezza. Insomma, definiamo un nuovo protocollo.

E il buon, vecchio HTTP lo teniamo per le pagine web…