7.1 SSL Certificate Inspection vs Deep SSL/SSH Inspection

7.1 SSL Certificate Inspection vs Deep SSL/SSH Inspection

Modern enterprise network traffic is overwhelmingly encrypted. Industry statistics indicate that over 85% to 90% of web traffic utilizes Secure Sockets Layer (SSL) or Transport Layer Security (TLS) encryption. While encryption ensures confidentiality and privacy, it creates a massive security blind spot. Malicious actors frequently leverage encrypted HTTPS channels to bypass perimeter controls, deliver malware payloads, establish covert Command and Control (C2) communication channels, and exfiltrate sensitive enterprise data.

Without inspection of encrypted traffic, Next-Generation Firewall (NGFW) security profiles—including Antivirus, Intrusion Prevention System (IPS), Web Filtering, Application Control, and Data Loss Prevention (DLP)—are virtually blind to encrypted threats. FortiOS 7.6 addresses this challenge by providing two primary inspection modes within security profiles: SSL Certificate Inspection (also known as Server Name Indication / SNI inspection) and Deep SSL/SSH Inspection (Full Content Decryption / Man-in-the-Middle proxy).

---

1. SSL Certificate Inspection (SNI & SAN Inspection)

SSL Certificate Inspection is a lightweight, non-intrusive inspection mechanism. It evaluates only the unencrypted header information exchanged during the initial SSL/TLS handshake phase without decrypting the underlying application payload.

Mechanics of Certificate Inspection

When an endpoint initiates a connection to a secure web server (e.g., https://www.example.com), the client sends an unencrypted TLS Client Hello packet. In modern TLS (TLS 1.2 and TLS 1.3 without ECH/ESNI), the Client Hello includes the Server Name Indication (SNI) extension, which specifies the target domain hostname in plain text. During the subsequent Server Hello response, the remote web server returns its public X.509 digital certificate, containing the Subject Alternative Name (SAN) and Common Name (CN) fields.

FortiGate intercepts these initial unencrypted handshake packets and extracts the domain name. It evaluates the domain against configured Firewall Policies, Web Filter profiles, and Domain Reputation databases. Once the domain is inspected and permitted, FortiGate allows the TLS handshake to complete directly between the client and the destination server.

+--------+       Client Hello (SNI: example.com)      +-----------+       Client Hello (SNI)       +---------------+
|        | -----------------------------------------> |           | ----------------------------> |               |
| Client |                                            | FortiGate |                               | Target Server |
|        | <----------------------------------------- | (Cert-Insp| <---------------------------- | (example.com) |
+--------+       Server Hello (Server Public Cert)    +-----------+    Server Hello (Server Cert)  +---------------+
                                                            |
                                                  [ Evaluates SNI/SAN ]
                                                  [   No Decryption   ]

Key Attributes & Advantages

• No Endpoint CA Requirement: Because FortiGate does not terminate the TLS session or re-sign certificates, client endpoints do not require custom Root CA certificates installed in their operating system or browser trust stores.
• Zero Latency & Low Resource Footprint: Certificate Inspection does not perform complex cryptographic decryption or re-encryption, resulting in minimal CPU and memory overhead.
• Privacy Compliance: Protects user privacy by leaving encrypted payloads untouched, making it ideal for environments with strict data privacy mandates.

Limitations

• Payload Blindness: FortiGate cannot inspect HTTP headers, POST request bodies, URI file paths (e.g., https://example.com/malware.exe appears only as example.com), or application data.
• Incompatible Security Profiles: Deep Antivirus file scanning, IPS signature matching inside TLS streams, Data Loss Prevention (DLP), and deep Web Filter keyword matching cannot function under Certificate Inspection.

---

2. Deep SSL/SSH Inspection (Full Decryption / Man-in-the-Middle Proxy)

Deep SSL/SSH Inspection transforms the FortiGate unit into an active, transparent Man-in-the-Middle (MitM) proxy. FortiGate decrypts the SSL/TLS stream, inspects cleartext payload contents using active security profiles, and re-encrypts the traffic before forwarding it to the recipient.

Step-by-Step TLS Handshake Decryption Sequence

1. Client Handshake Termination: The client sends a TLS Client Hello to an external HTTPS server. FortiGate intercepts the packet and terminates the client's TLS session locally.
2. Server Handshake & Certificate Validation: FortiGate initiates a separate, independent TLS connection to the remote destination server. FortiGate receives and validates the destination server's public certificate against FortiOS trusted Certificate Authority (CA) stores, checking expiration dates, revocation status (CRL/OCSP), and issuer trust.
3. Substitute Certificate Generation: FortiGate dynamically generates a brand-new substitute server certificate. This certificate mirrors the subject name, domain, and validity dates of the original server certificate.
4. Certificate Re-signing: FortiGate signs the newly created substitute certificate using its own installed Certificate Authority (CA) certificate (such as the default Fortinet_CA_SSL or an Enterprise Subordinate CA).
5. Client TLS Completion: FortiGate completes the TLS handshake with the client by presenting the substitute certificate. If the client endpoint trusts FortiGate's CA, the browser accepts the certificate without error.
6. Cleartext Payload Scanning: Data sent between client and server flows through two distinct TLS tunnels. As packets transition through FortiGate, the engine decrypts payloads into plain text in system RAM. FortiGate routes cleartext data through active security engines (Antivirus, IPS, Web Filter, Application Control, DLP).
7. Forwarding: If no security threats or policy violations are detected, FortiGate re-encrypts the data stream and forwards it across the second TLS leg.

+--------+     TLS Leg 1 (Client <-> FortiGate)     +-----------+     TLS Leg 2 (FortiGate <-> Server)    +---------------+
|        | ===[ Encrypted with Substitute Cert ]===> | FortiGate | ===[ Encrypted with Server Cert ]====> |               |
| Client |                                          |   MitM    |                                         | Target Server |
|        | <==[ Signed by FortiGate Root/Sub CA ]=== |   Proxy   | <==[ Validated by FortiOS CA Store ]=== | (example.com) |
+--------+                                          +-----------+
                                                          |
                                              +-----------------------+
                                              | Cleartext Payload in  |
                                              |      System RAM       |
                                              |-----------------------|
                                              |  AV | IPS | Web | DLP |  |
                                              +-----------------------+

---

3. Flow-Based vs Proxy-Based Deep Inspection Architecture

FortiOS 7.6 supports two operational architecture modes for Deep Inspection: Proxy-Based and Flow-Based.

Proxy-Based Deep Inspection

In Proxy-Based mode, FortiGate establishes explicit connection sockets for both client and server legs. Traffic is fully buffered in memory, allowing complete protocol reconstruction and detailed payload manipulation.

• Capabilities: Supports advanced features such as Client Certificate Pass-Through, full HTTP header modification, strict protocol compliance verification, and complex DLP file reconstruction.
• Performance Trade-Off: Buffering complete sockets introduces minor processing latency and consumes higher RAM per concurrent connection.

Flow-Based Deep Inspection

In Flow-Based mode, FortiGate scans packet streams inline as they pass through the security architecture without full socket buffering.

• Capabilities: Analyzes stream chunks using pattern matching algorithms. Operates at near-wire speeds with significantly lower latency and minimal memory allocation.
• SPU Acceleration: Fully optimized for Fortinet Security Processing Units (SPUs), making flow-based inspection the preferred mode for high-throughput enterprise perimeters.

---

4. Hardware Acceleration & SPU Offloading (CP9 / NP7)

Deep SSL Inspection imposes intensive computational demands due to asymmetric cryptography (RSA 2048/4096-bit or ECC curve negotiation) during handshakes, combined with high-volume symmetric bulk encryption/decryption (AES-GCM, ChaCha20-Poly1305).

To prevent CPU bottlenecking and conserve system RAM, FortiGate appliances utilize specialized Security Processing Units (SPUs):

• Content Processor 9 (CP9): Dedicated SPU co-processor designed specifically to offload cryptographic processing. CP9 handles asymmetric RSA/ECC key exchanges, signature generation, bulk AES decryption/encryption, and pattern-matching signature checks for IPS and Antivirus engines in hardware.
• Network Processor 7 (NP7): Works in tandem with CP9 to offload established flow-based fast-path sessions. Once CP9 and FortiOS validate an encrypted flow, NP7 offloads packet forwarding, maintaining multi-gigabit throughput.

---

5. CLI Configuration: config firewall ssl-ssh-profile

In FortiOS 7.6, SSL inspection behavior is defined within SSL/SSH profiles and applied directly to Firewall Policies.

# Creating a custom Deep SSL/SSH Inspection Profile in FortiOS 7.6 CLI
config firewall ssl-ssh-profile
    edit "Enterprise-Deep-Inspection"
        set comment "Custom Deep Inspection Profile for Enterprise Edge Policy"
        config https
            set ports 443 8443
            set status deep-inspection
            set client-certificate pass
            set unsupported-ssl-version block
            set untrusted-server-cert block
            set cert-validation-timeout block
        end
        config ftps
            set ports 990
            set status deep-inspection
        end
        config imaps
            set ports 993
            set status deep-inspection
        end
        config pop3s
            set ports 995
            set status deep-inspection
        end
        config smtps
            set ports 465 587
            set status deep-inspection
        end
        config ssh
            set ports 22
            set status deep-inspection
            set ssh-policy-check enable
        end
    next
end

Applying SSL Inspection Profile to a Firewall Policy

config firewall policy
    edit 10
        set name "Corporate-Outbound-Access"
        set srcintf "port2"
        set dstintf "port1"
        set srcaddr "Corp-LAN-Subnet"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "HTTPS" "SMTPS" "IMAPS"
        set utm-status enable
        set ssl-ssh-profile "Enterprise-Deep-Inspection"
        set av-profile "Enterprise-AV"
        set ips-sensor "Enterprise-IPS"
        set webfilter-profile "Enterprise-WebFilter"
        set nat enable
    next
end