Note:

Use OCI Network Firewall for SSL forward proxy and inbound inspection using Decryption rule

Introduction

The Oracle Cloud Infrastructure (OCI) Network Firewall service is a cloud-based managed firewall solution that utilizes the next-generation firewall technology (NGFW) from Palo Alto Networks. With its cutting-edge machine learning-powered firewall capabilities, the OCI Network Firewall service provides top-notch protection for your OCI workloads, all while being effortless to use within the OCI ecosystem.

The OCI Network Firewall inspects all requests, including transport layer security (TLS) encrypted traffic, as it passes through the firewall. Based on your user-defined firewall policy rules, the service can take a variety of actions, including allow, reject, drop, intrusion detection, or prevention. With these robust features, OCI Network Firewall is a powerful tool for safeguarding your OCI workloads from a variety of security threats.

Objectives

The objective of this tutorial is to provide a comprehensive guide to implementing SSL forward proxy and inbound inspection using decryption rules in Next Generation Firewall in OCI Cloud.

By following this tutorial, you will have a solid understanding of SSL forward proxy and inbound inspection using decryption rules, and be able to apply this knowledge to secure your network infrastructure in OCI Cloud.

Prerequisites

Note: It is recommended that you have a test environment set up in OCI for experimenting with firewall configurations and decryption rules before implementing them in a Production environment.

Architecture

Architecture

OCI Network firewall policy consists of lists which include:

Test case

For this tutorial, we have created a SSH connection to the Linux machine (in Public Subnet: 129.146.201.118) over the Internet by having a security rule in the firewall policy.

Now you have an idea on how lists can be used to create security rules for your firewall. By using this rule, we have done a SSH to the Linux machine.

Understand TLS/SSL encryption technology

Note:

TLS is a cryptographic protocol that provides end-to-end security for any data sent between applications over the Internet. Most common scenarios are in secure web browsing. However, it can and should also be used for other applications such as e-mail, file transfers, video/audioconferencing, instant messaging and voice-over-IP, and so on.

It is important to understand that TLS does not secure data on end systems. It does ensure the secure delivery of data over the Internet, avoiding possible eavesdropping and/or alteration of the content being sent (in-transit). TLS is normally implemented on top of TCP in order to encrypt Application Layer protocols such as HTTP, FTP, SMTP and IMAP, although it can also be implemented on UDP, DCCP and SCTP as well.

To protect the data, TLS relies on cryptography technology in order to encrypt/decrypt the in-transit data being sent over the internet. We will be covering terms and concepts such as symmetric and asymmetric cryptography, public key infrastructure (PKI), and X.509 digital certificates.

To set up, configure and apply Next Generation Firewall to your network, you need to understand how TLS connections (such as https) works, including digital X.509 certificates configuration and deployment.

Encryption and types

The idea behind encryption is precisely to conceal or hide (encrypt) the information we want to send from A to B in an “insecure channel”. An insecure channel is a channel or a path where we cannot guarantee that no one will intercept, steal, or modify (eavesdrop) the information transmitted from A to B and the other way around.

Cryptography allows us to secure the information travelling through an insecure channel, by encrypting (concealing) the original data toward its destination. Once received by the receiver, the receiver will be able to decrypt the received encrypted data to its original value.

There are two types of encryptions: Symmetric and Asymmetric.

Symmetric encryption

In order to encrypt/decrypt a chunk of data, symmetric encryption engines use exactly the same key to encrypt and decrypt the data. This is normally called the Master key or shared secret.

Master Key encryption

Though it sounds like an easy way to achieve encryption, the main problem here is distributing the master key between the two parties over an insecure channel. This master key exchange process will be addressed in this tutorial using different techniques, including one technique explained in the following section: Asymmetric encryption.

Some of more common symmetric encryption algorithms are: AES128, AES256, Serpent, Camelia, etc.

Asymmetric encryption

Asymmetric encryption/cryptography, uses a pair of related keys with a special relationship: Any data that you encrypt with one of the pairs keys can be decrypted ONLY BY the other pair key, and the other way around.

Asymmetric encryption

We normally refer to this pair keys as Public key and Private key. The public key can be shared with everyone, whereas the private key must be kept secret.

Asymmetric encryption solves the problem of key distribution by using public keys for encryption and private keys for decryption (or the other way around). The tradeoff, however, is that asymmetric encryption systems are very slow by comparison to symmetric systems and require much more computing power because of their vastly longer key lengths.

Symmetric encryption algorithms are much faster and require less computational power, but their main weakness is key distribution, because the same key is used to encrypt and decrypt information, that key must be distributed to anyone needs to access the data.

TLS uses asymmetric and symmetric encryption, and not only for encrypting data but for authenticating the parties involved in the connection. Here is where X.509 certificates take action.

X.509 certificates

An X.509 certificate is a digital certificate based on the widely accepted International Telecommunications Union (ITU) X.509 standard, which defines the format of public key infrastructure ( PKI ) certificates. A X.509 certificate is architected using a key pair consisting of a related public key and a private key. As we have mentioned above, this key pair is precisely the pair of keys that are used in asymmetric encryption, where we choose one to be public and the other to be private. Remember, anything that you encrypt with one of the keys can be only decrypted by the other key, and the other way around.

As you can imagine, the public part of the key pair, as its name implies, is public and can be freely distributed. The private key must be kept safely, and often encrypted using a master key in symmetric encryption mode, so nobody can use it even if is stolen.

In addition to the public key, the X.509 certificate contains other information that represents an identity (a hostname, or an organization, or an individual), therefore the x.509 certificate binds this identity to the contained public key.

The structure of an X.509 v3 digital certificate is as follows:

Certificate

Version Number

Serial Number

Signature Algorithm ID

Issuer Name

Validity period

Not Before

Not After

Subject name

Subject Public Key Info

Public Key Algorithm

Subject Public Key This is the public KEY

Issuer Unique Identifier (optional)

Subject Unique Identifier (optional)

Extensions (optional)

…

Certificate Signature Algorithm

Certificate Signature

The public key is bound to an identity represented in Subject name which is a string with the following format:

where, Subject: C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com

So, this identity belongs to Google, in US country, State California and a common name as *.google.com.

We can use this certificate to serve two purposes: distribute our public key AND authenticate our identity to others. Having this in mind, any computer/mobile/device out there, when receiving our certificate, it will own our public key and identity, therefore, it will be able to send encrypted information using the public key, and only we will be able to decrypt it (with the private key). In addition, the certificate has our identity inside, so the device receiving it will be able to trust this identity and be sure it is exchanging information with the right identity.

As we have mentioned above, asymmetric encryption via public/private keys is much slower than symmetric encryption (x4 or more) so it is not viable. In addition, we haven’t explained how the device receiving the certificate can really trust the identity inside the certificate. At the end, the X.509 certificate is just a piece of text received over an insecure channel. To trust/authenticate a received certificate, we require a Certificate Authority, an organization that is trusted to sign digital certificates. A Certificate Authority verifies identity and legitimacy of company or individual that requested a certificate and if the verification is successful, CA issues signed certificate. Examples of CA organizations are Oracle, VeriSign , D-Trust, DigiCert among many others.

So, from a cryptography perspective, how this signing process works? Again, we will be using the power of asymmetric encryption for this, as follows:

So, now that we have our X.509 certificate ready to take action. How a computer/mobile/device receiving this certificate during a TLS connection can verify if it is a valid X.509 certificate? Again, we will use the power of the asymmetric encryption, as follows:

Now that we know we have a valid certificate that includes the domain name where we are trying to connect to, for example, www.mycompanycomain.com (included in the common name or Subject Alternative name fields from Certificate), the computer/mobile/browser will make sure that we are actually connecting to that DNS domain name (www.mycompanycomain.com) and not to other one. This is a mandatory validation, since anyone can steal the X.509 certificate and try to use it from another DNS domain server (www.myfakecompany.com, etc) and it would pass the CA signature validation process.

So, now all the computers/mobiles/devices out there can download the public key of our Certificate and send encrypted data so only we can decrypt it. As the asymmetric encryption is much slower than symmetric encryption (x4 or more), it is not viable. The solution is to use both, and this is where SSL/TLS is required.

TLS basics

TLS is a cryptographic protocol that provides end-to-end security of data being sent between applications over the Internet. It is mostly familiar to users through its use in secure web browsing, and in particular the padlock icon that appears in web browsers when a secure session is established.

TLS uses a combination of symmetric and asymmetric cryptography , as this provides a good compromise between performance and security when transmitting data securely. Remember that asymmetric cryptography requires 4x or more computational power than symmetric cryptography. However, symmetric cryptography requires the same master key in both sides of the communication to be able to encrypt/decrypt the message, so the goal for using symmetric encryption is, to be able to exchange the master key (or shared secret) between the two parties over an insecure channel first and then start using this master key to secure the communication, encrypting/decrypting every message being sent/received using the chosen symmetric engine.

TLS, hacker image

In order to exchange a master key over an insecure channel, TLS will use two different techniques that follows the same goal, which is to exchange the master key/shared secret securely in an insecure channel:

RSA methodology will rely on using the power of asymmetric encryption (private and public key) to exchange the master key over an insecure channel.

DHE/ECDHE will rely on using mathematical calculations to generate the same master key between two parties over an insecure channel. Both parties will exchange certain benign information that will be mixed with their privileged information as it travels over an insecure channel and can be captured without any risk. At the end of the negotiation, both mathematical calculations of the two parties will end up on the same common secret or master key. More information https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

These two key exchange methodologies take place during a process called TLS handshake.

TLS handshake unmasked

An SSL/TLS handshake is a negotiation between two parties on a network – such as a browser and web server – to establish the details of their connection. During that negotiation, the two parties will authenticate (using X509 certificates), agree a cipher suite (how the master key will be exchanged and what cryptography engines will be used, such as AES256, 128, hashing such as SHA1, 2, etc) and finally, when the authentication occurs (valid certificate received) and agreement on how to establish a secure channel is done , then, we will have a secure channel from both parties. These are the actual steps:

TLS handshake

Notice in the graph above, we are using RSA (private/public key) to exchange the master key (or shared secret) to be used in the agreed symmetric encryption engine (i.e. AES256 ) during the cipher suite negotiation. If DHE/ECDHE were used, instead of using public and private key to exchange the master key, both parties would use DHE calculations, exchanging benign material, to end up calculating the same result in both sides. That result will become the master key (shared secret) to be used for symmetric encryption.

Task 1: Use OCI Network Firewall for SSL forward proxy and inbound inspection using Decryption rule

  1. Create two self-signed certificates using openssl for both outbound traffic and inbound inspection using open SSL on the Linux machine. Update the Linux machine to trust the certificate.

    self-signed certificates Creation

  2. Create a Vault in OCI.

    Vault

  3. After the Vault is created, Create a Key. The Secret contents must be in the following format.

    {

"caCertOrderedList":

[

"-----BEGIN CERTIFICATE

-----END CERTIFICATE-----\n"

],

"certKeyPair":

{

"cert" : "-----BEGIN CERTIFICATE

-----END CERTIFICATE----\n",

"key": "-----BEGIN RSA PRIVATE KEY

-----END RSA PRIVATE KEY----\n"

}

}

  4. In the network firewall policy, add the mapped secret.

    1. Choose Mapped Secret type as SSL forward Proxy or SSL inbound inspection.

    2. Choose the Vault created.

    3. Choose the secret.

    4. Add the mapped secret.

      Mapped Secret

  5. Create a Decryption Profile.

    1. Choose SSL Forward Proxy and check the Server Certificate verification options or choose the SSL inbound inspection and check the unsupported mode checks which are needed for your traffic.

      decryption profile forward

      decryption profile inbound

    2. Add a Decryption Profile.

      Adding decryption profile

  6. Create a Decryption Rule.

    1. Select Source IP addresses from the IP address list you have created in the policy or choose any.

    2. Select Destination IP addresses from the IP address list you have created in the policy or choose any.

      Destination IP address

    3. Select Action for decrypting traffic with SSL forward proxy, SSL inbound or no decryption.

    4. Choose the Decryption Profile and Mapped Secret.

      Decryption profile chosing

Once the policy is updated with the decryption rule, it can be attached to the firewall.

Task 2: Attach a policy to the firewall

When you are creating the Network Firewall, it will give you an option to choose the policy which should be attached to the firewall.

NetworkFirewall attachment

We have created a Decryption rule to decrypt traffic through SSL forward proxy and one for SSL inbound inspection. As mentioned for SSL outbound connection, all the traffic from our public subnet is going to OCI Network Firewall and through OCI Network Firewall, it is taking a path from Internet Gateway to Internet.

For inbound inspection, it goes through the Internet Gateway taking the next HOP as the firewall and then accessing our Linux machine in the public subnet.

As per the decryption rule, for source IP address we use the Hub-Linux-Machine and for any destination IP address, the traffic should be decrypted by SSL forward proxy and for inbound connections for source as any and destination as Hub-Linux-Machine it should decrypt the traffic with SSL inbound inspection.

Decryption rules

Note: For any traffic hitting the firewall, it first checks the Decryption rules and then security rules.

Question: How can I identify that the Decryption rule is in place for traffic hitting the firewall?

Answer: This can be seen on the metrics with a name of Decryption rule hit count attached to the firewall.

Every time the Linux machine tries to reach https websites on the Internet or for any inbound connections to the Linux machine on https, the Decryption rule hit count increases.

Network Firewall Metric

Task 3: Use the Decryption rule with a security rule to allow or deny traffic

Adding to the above use case, let us see how the Decryption rule can be used with a security rule to allow or deny traffic. As mentioned in the start of the test case we could use lists to allow or deny the traffic.

Here we have already created a Decryption rule for SSL forward proxy and inbound SSL inspection. For test purpose, we have created a security rule for outbound connections from the Hub Linux machine to Internet to allow access to *.oracle.com.

Note: By default, all traffic is denied access on the OCI Network firewall. A rule needs to be created for the traffic which should be allowed.

URL list:

URL List

Security Rule:

Security Rule

Now what will happen when the Linux machine tries to access *.oracle.com on the Internet through the OCI Network Firewall.

Question: How can I see which rule is taking place for the traffic?

Answer: It can be seen in the OCI Network Firewall logs.

For oracle.com

Network Firewall Logs 1

For any other URL:

Network Firewall Logs 2

Acknowledgments

Authors - Luis Catalán Hernández (OCI Cloud Network Specialist and Multi Cloud), Sachin Sharma (OCI Senior Cloud Specialist)

More Learning Resources

Explore other labs on docs.oracle.com/learn or access more free learning content on the Oracle Learning YouTube channel. Additionally, visit education.oracle.com/learning-explorer to become an Oracle Learning Explorer.

For product documentation, visit Oracle Help Center.