Il traffico web viaggia dentro TLS, e un gateway che non lo apre applica le proprie protezioni a un contenuto che non può leggere. Questo modulo chiede di saper spiegare perché l’HTTPS Inspection esiste, come funziona il meccanismo e a quale prezzo si compra quella visibilità.

Il punto cieco

La documentazione R82 lo dice senza attenuanti: i Security Gateway non possono ispezionare il traffico HTTPS perché è cifrato. Non è una limitazione di licenza o di dimensionamento, è una conseguenza del protocollo. Fra client e server esiste una sessione cifrata di cui il gateway vede l’involucro — indirizzi, porte, metadati — e non il contenuto.

La conseguenza pratica è che i blade abilitati continuano a lavorare, ma su qualcosa che non possono leggere. La guida Security Gateway elenca otto Software Blade in grado di ispezionare il traffico HTTPS quando l’HTTPS Inspection è attiva: Anti-Bot, Anti-Virus, Application Control, Content Awareness, Data Loss Prevention, IPS, Threat Emulation e URL Filtering. La guida Threat Prevention, dal proprio punto di vista, cita IPS, Anti-Virus, Anti-Bot, Threat Emulation, Threat Extraction e Zero Phishing. Le due liste guardano lo stesso fatto da due angoli: senza ispezione, quelle protezioni non vedono ciò che passa dentro la sessione cifrata.

Da qui la risposta alla domanda «perché serve»: non per curiosità sul traffico degli utenti, ma perché senza ispezione un malware scaricato via HTTPS, un file che esce dall’azienda via HTTPS e un’applicazione vietata dalla policy ma raggiunta via HTTPS sono tutti ugualmente invisibili.

Come il gateway apre la busta

Il meccanismo è descritto in modo compatto: il Security Gateway crea nuove connessioni SSL con il sito o il server esterno, e può così decifrare e ispezionare il traffico HTTPS che usa quelle nuove connessioni. In pratica la sessione si spezza in due tratte, client verso gateway e gateway verso server, con il gateway nel mezzo.

Perché il client accetti la prima tratta, il gateway deve presentargli un certificato, che firma con la propria CA outbound. La si crea in SmartConsole nelle Gateway Properties, sezione HTTPS Inspection, allo Step 1, con il pulsante Create: si indicano il nome di dominio dell’organizzazione (DN), una password per la chiave privata e le date di validità; il certificato si salva con estensione .cer.

Averlo non basta: i client devono fidarsene. Si esporta da Security Policies > HTTPS Inspection > Outbound Policy, con Outbound Certificates, e si distribuisce alle macchine — tipicamente via Windows Group Policy — nello store Trusted Root Certification Authorities. Sul versante opposto il gateway usa un Trusted CA package quando si collega ai server HTTPS per conto dei client interni.

Ispezionare non vuol dire ispezionare tutto

La policy vive in Security Policies view > HTTPS Inspection e in R82 è divisa in Inbound Policy e Outbound Policy. Le regole hanno le colonne No., Name, Source, Destination, Services — con https sulla 443 e HTTP_and_HTTPS proxy sulla 8080 fra i valori predefiniti —, Site Category, Action, Track, Blade, Install On e, solo nell’Inbound Policy, Certificate.

L’azione è binaria. Inspect: il gateway intercetta la connessione HTTPS. Bypass: non la intercetta. Il Bypass è lo strumento con cui si tiene fuori dall’ispezione ciò che non si vuole decifrare, e l’esempio della documentazione è proprio una regola sulla Site Category Financial Services con azione Bypass, per non aprire il traffico bancario degli utenti. La colonna Blade, che di default vale All, permette invece di limitare quali Software Blade ispezionano il traffico decifrato da quella regola.

R82 aggiunge il supporto all’ispezione di HTTP/3 e i session log, che danno una vista aggregata delle connessioni per indirizzo sorgente, indirizzo destinazione, SNI, azione e finestra temporale.

Trappole tipiche d’esame

  • L’avviso del browser non si risolve nella policy. Se gli utenti vedono un errore sul certificato, di norma la CA outbound non è stata distribuita nello store Trusted Root Certification Authorities dei client. La regola può essere perfetta: manca il passo di distribuzione, cioè export da Outbound Certificates e deploy, tipicamente via Group Policy.
  • Creare la CA ed esportarla sono due passi in due posti diversi. Il Create sta nelle Gateway Properties, sezione HTTPS Inspection; l’export sta nella Outbound Policy. Una domanda che chiede dove si esporta il certificato non si risolve nelle proprietà del gateway.
  • Il degrado di prestazioni nasce dall’ispezionare senza distinzioni. Decifrare e ricifrare costa; la colonna Blade vale All di default e le regole di Bypass esistono per non pagare quel costo dove non serve. La risposta corretta a uno scenario di prestazioni è quasi sempre restringere l’ambito, non spegnere la funzione.
  • Le applicazioni che si rompono non sono un difetto dell’ispezione. Un client che valida per conto proprio il certificato del server, o che non usa lo store di sistema, rifiuta il certificato presentato dal gateway. Il rimedio previsto è una regola di Bypass mirata su quella destinazione, non la disattivazione generale dell’ispezione.
  • Inbound e Outbound non hanno le stesse colonne. La colonna Certificate esiste solo nell’Inbound Policy, dove indica il certificato del server da proteggere. Da R82 le due policy sono separate: una risposta che mescola le due è sbagliata anche quando i nomi delle colonne sembrano familiari.
  • Bypass significa «non intercetto», non «non registro». La regola conserva la propria colonna Track: quello che si perde è la visibilità dei Software Blade sul contenuto della connessione, non l’esistenza della regola e del suo log.