Using OCI Network Firewall for SSL decryption

Oracle Cloud Infrastructure (OCI) Network Firewall is a cloud native firewall service that extends our next-generation firewall (NGFW) capabilities to protect OCI workloads and helps provide centralized protection against cyberattacks without the operational and management complexities associated with deploying a third- party virtual firewall appliance. OCI Network Firewall is based on Palo Alto NGFW technology.

Almost all enterprises use traditional firewalls to protect their workloads exposed to the internet (North-south traffic) and internal traffic (East-west traffic). However, more customers realize that a traditional firewall filtering just IP headers and focusing up to layer 4 (the transport layer) isn’t enough. Advanced attacks are more and more sophisticated, taking place at layers 4–7 of the OSI model, focusing mostly on the application layer.

An NGFW is part of the third generation of firewall technology, combining a traditional firewall with other network device filtering functions, such as an application firewall using in-line deep packet inspection (DPI) and an intrusion prevention system (IPS). Other techniques might also be employed, such as TLS/SSL encrypted traffic inspection, website filtering, QoS or bandwidth management, antivirus inspection, and third-party identity management integration.

This blog post explains how to use some of these features with the OCI Network Firewall to inspect TLS/SSL encrypted connections and then applying intrusion detection and prevention systems (IDS and IPS) to the traffic flows.

SSL/TLS traffic inspection

One of the main uses of an NGFW is apply IDS and IPS controls to the traffic, including encrypted traffic over SSL/TLS secure channels. To accomplish this task, the NGFW must decrypt the SSL/TLS encrypted traffic. It sounds contradictory that a secure encrypted channel can be decrypted by the NGFW software. But as a trusted device, the NGFW can be configured to decrypt incoming SSL/TLS connections to servers within OCI to outgoing connections by “impersonating” the remote server, both transparent to the end user.

Inbound inspection mode

This scenario is commonly used with web applications and HTTPS REST interfaces that are exposed to external clients. The OCI Network Firewall decrypts and inspects inbound SSL/TLS traffic from clients toward servers in OCI, using the certificate of the server imported onto the network firewall. The network firewall applies different decryption techniques based on the type of master key exchange in use between the client or server: RSA or DHE/ECDHE.

For RSA-based exchanges, the OCI Network Firewall performs SSL inbound inspection without terminating the SSL/TLS connection. Using the preinstalled X.509 private key of the server, the OCI Network Firewall can decrypt and capture the master key exchange, using the negotiated symmetric key between client and server to decrypt the subsequent encrypted session traffic.

For DHE/ECDHE based key exchanges, the OCI Network Firewall acts as a proxy between the external client and the internal server, using the server certificate with its private key. The Diffie Hellman key exchange doesn’t transmit a master key. Both parties generate the master key using calculations based on exchanging benign material, so no key exists to intercept. The next section explains this proxy technique.

Forward proxy mode

In SSL forward proxy mode, the OCI Network Firewall acts as middleman between the internal client and the external server, like with inbound inspection when using DHE/ECDHE key exchange. The proxy mode is required because the network firewall can’t capture the master key being negotiated or generated between the two parties. With DHE/ECDHE master key exchange, no actual master key exchange happens. With RSA, the external server X509 certificate private key isn’t available to import on to the OCI Network Firewall and therefore the symmetric key cannot be intercepted.

The OCI Network Firewall, between the client and server, ends the SSL/TLS session from the client and creates a new one for the server.

Neither the client or server are aware of this proxy and always believe that they’re connecting directly to each other. To achieve this goal, the OCI Network Firewall creates a copy of the received server certificate and signs it with a local Certificate Authority (CA) certificate and its private key. All the clients within the internal network must also trust this local CA. Without this trust, the client sees certificate errors because it can’t validate the server certificate regenerated or impersonated by the Network Firewall.

For inbound DHE/ECDHE, the local CA element isn’t required. The internal X.509 server certificate and its private key are installed and used by the network firewall to end the TLS session with the external client. The network firewall then creates a separate session to the internal server and proxies the two sessions together, while the client believes that it’s connected to the server directly.

Tutorial

The tutorial, Use OCI Network Firewall for SSL forward proxy and inbound inspection using Decryption rules, demonstrates the techniques described in this blog post. The tutortial also has more details about cryptography, including a comprehensive introduction to TLS, and covers topics such as encryption, certificates, and handshakes. Whether you're a beginner or have some knowledge of cryptography, this tutorial can help you understand TLS and its role in securing network communications.

Conclusion

The OCI Network Firewall provides advanced security features that traditional firewalls lack, including deep packet inspection and intrusion prevention and detection functions. The OCI Network Firewall offers cloud native security with best-in-class NGFW capabilities, enabling centralized protection against cyberattacks. With SSL/TLS inspection, the network firewall can decrypt and inspect encrypted traffic over SSL/TLS secure channels, providing comprehensive security coverage. Using Oracle Cloud Infrastructure Network Firewall with SSL/TLS inspection, customers can protect their workloads against sophisticated attacks that take place at layers 4–7 of the OSI model.

For more information, see the following resources:

• OCI Network Firewall

• Defense in Depth, Layering using OCI Network Firewall

• OCI Network Firewall - Concepts and Deployment