Su una connessione HTTPS il Security Gateway, da solo, vede indirizzi, porte e poco altro: il contenuto viaggia cifrato fra client e server. HTTPS Inspection è la funzione che permette al gateway di terminare quella sessione TLS, leggerla in chiaro e ricifrarla. Tutto il modulo ruota attorno a una domanda sola: chi si fida di chi, e sulla base di quale certificato.

Due sessioni TLS al posto di una

Quando una regola di HTTPS Inspection ha azione Inspect, il gateway non inoltra la sessione originale: ne chiude una verso il client e ne apre una nuova verso il server di destinazione. In mezzo il traffico è leggibile e viene consegnato ai Software Blade abilitati. La policy si scrive in SmartConsole e in R82 è divisa in Inbound Policy e Outbound Policy. Le colonne sono Source, Destination, Services (per default https e HTTP_and_HTTPS_proxy), Site Category, Action e Blade: l’azione è Inspect oppure Bypass, e la colonna Blade restringe quali blade ispezionano quel traffico. Nella policy inbound compare in più la colonna Certificate. Il gateway va poi abilitato all’ispezione nel proprio oggetto, e serve l’installazione della Access Control Policy.

Outbound: il certificato della CA dell’organizzazione

In direzione outbound è il client interno a uscire. Il gateway deve presentargli un certificato valido per il nome richiesto: lo genera al momento e lo firma con un certificato CA proprio, creato oppure importato sul Security Management Server. Quel certificato CA va esportato e distribuito ai client, tipicamente via GPO nell’archivio Trusted Root Certification Authorities. È il passo che le installazioni dimenticano: senza, la firma non risale ad alcuna autorità conosciuta dal browser. Un caso particolare riguarda i browser basati su Chromium, che ammettono HTTP/3 solo se il certificato è firmato da una CA già presente nel loro elenco e non accettano per HTTP/3 un certificato aggiunto a mano: è una limitazione di progetto, non un errore di configurazione.

Inbound e la fiducia verso i server esterni

L’ispezione inbound protegge un server pubblicato dall’organizzazione. Qui il gateway non genera nulla: impersona il server usando il certificato vero e la relativa chiave privata, esportati dal server in un file p12 e importati in SmartConsole. Sul fronte opposto, quando è il gateway a comportarsi da client verso un sito esterno, deve giudicare il certificato che riceve: si appoggia al pacchetto Trusted CAs, un elenco preconfigurato che Check Point aggiorna, e controlla la revoca con OCSP, ripiegando su CRL dove OCSP non è supportato. Il trattamento dei certificati untrusted, revoked ed expired si configura a parte, scegliendo fra presentare un certificato autofirmato e bloccare. Su IPv6 puro la validazione CRL non è disponibile.

Che cosa guadagna e che cosa costa l’ispezione

Il guadagno è la visibilità. Senza traffico decifrato, Application Control, URL Filtering, Content Awareness e DLP da un lato, IPS, Anti-Virus, Anti-Bot, Threat Emulation, Threat Extraction e Zero Phishing dall’altro, lavorano su un flusso che non possono leggere. Il costo è doppio. Sul piano delle prestazioni, decifrare e ricifrare è oneroso: R82 offre il Learning Mode, che applica l’ispezione a una quota ridotta di traffico per misurarne l’impatto prima del Full Inspection, e il Bypass Under Load, che sospende l’ispezione quando il carico di CPU supera la soglia. Sul piano funzionale, ogni destinazione messa in Bypass è una zona cieca voluta: si escludono per scelta le categorie finanziarie e sanitarie, i servizi di aggiornamento e le applicazioni con certificate pinning, che confrontano il certificato ricevuto con uno incorporato nel codice e rifiutano qualunque intermediario. Resta il Fail Mode: Fail-Open privilegia la continuità del servizio, Fail-Close la sicurezza.

Trappole tipiche d’esame

  • L’avviso del browser non si cura con una regola. Se gli utenti vedono un certificato non attendibile, il rimedio è la distribuzione del certificato CA outbound nell’archivio delle autorità fidate dei client, non una regola in più né il passaggio da Inspect a Bypass. Un gateway che firma correttamente con una CA che nessuno conosce produce lo stesso sintomo di un gateway configurato male.
  • Degrado di prestazioni: la leva attesa non è spegnere. Davanti a CPU satura la sequenza corretta è misurare con il Learning Mode, ridurre il volume con regole di Bypass mirate e tenere il Bypass Under Load come rete di protezione.
  • Applicazione che si rompe solo a ispezione attiva. Quando a fallire è un client applicativo e non un browser, la causa tipica è il certificate pinning: si risolve con un Bypass su quella destinazione, non aggiungendo certificati ai client.
  • Confondere le due direzioni. Outbound genera certificati firmandoli con la CA dell’organizzazione, inbound importa certificato e chiave privata del server. Se la domanda nomina un file p12, parla di inbound.
  • Confondere i due archivi. Il certificato CA outbound serve a farsi fidare dai client, il pacchetto Trusted CAs serve al gateway per fidarsi dei server esterni: ruoli opposti, non intercambiabili.