Note:
- This tutorial requires access to Oracle Cloud. To sign up for a free account, see Get started with Oracle Cloud Infrastructure Free Tier.
- It uses example values for Oracle Cloud Infrastructure credentials, tenancy, and compartments. When completing your lab, substitute these values with ones specific to your cloud environment.
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.
- Understand the basics of SSL/TLS encryption and how it works.
- Configure a Next Generation Firewall in OCI Cloud to perform SSL forward proxy and inbound inspection.
- Create decryption rules to intercept SSL/TLS traffic and inspect it for threats.
- Implement advanced cryptography concepts such as Perfect Forward Secrecy (PFS) and Certificate Pinning to enhance the security of your network.
- Troubleshoot common issues that may arise during the configuration and implementation of SSL forward proxy and inbound inspection.
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
- An active Oracle Cloud Infrastructure (OCI) tenancy. You must have the necessary permissions to create and manage network security resources in OCI.
- A basic understanding of SSL/TLS encryption and how it works. This includes knowledge of X.509 certificates, public key infrastructure (PKI), and cryptographic protocols such as RSA and Diffie-Hellman.
- Familiarity with network security concepts such as firewalls, intrusion detection/prevention systems, and network monitoring tools.
- A virtual cloud network (VCN) and subnet(s) set up in OCI, with appropriate routing rules, Internet Gateway, and security lists configured.
- An OCI Network Firewall instance created in your VCN.
- SSL/TLS certificates created by openssl.
- A good understanding of how to use the OCI Console or OCI CLI to create and manage network security resources.
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
OCI Network firewall policy consists of lists which include:
-
Applications lists where you can create a list of applications and define protocol types and port ranges for each.
-
URL Lists where you can create a list of URLs that you can allow or deny access to.
-
IP Address lists where you can create a list of IPv4 and IPv6 addresses or CIDR ranges that you can allow or deny access to.
-
Above lists can be used to create Decryption and Security rules in the firewall policy to allow, drop, Intrusion Detection, Intrusion prevention and Reject the traffic in case of Security rules and Decrypt traffic with SSL forward proxy and SSL inbound inspection.
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.
-
To access OCI Network Firewall, log in to your OCI console and navigate to the Identity & Security tab.
-
You can get started by choosing the network firewall policies and start creating your policy for firewall.
-
For our test case, to do a SSH on Linux machine from Internet through OCI network Firewall, we have created an Application list for port 22, IP address list which defines the Linux public IP and private IP and a security rule which allows the application list for source as any and destination as our IP address list.
-
Application list:
-
IP address list:
-
Security Rule.
-
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:
This tutorial assumes a basic understanding of network security and cryptography concepts. If you are new to these topics, we recommend going through the details in this section.
If you already have the necessary skills/knowledge, you can skip this section and proceed to Task 1.
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.
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.
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:
- country (countryName, C),
- organization (organizationName, O),
- organizational unit (organizationalUnitName, OU),
- distinguished name qualifier (dnQualifier),
- state or province name (stateOrProvinceName, ST),
- common name (commonName, CN)
- serial number (serialNumber).
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:
- The company/website that needs to have a signed certificate will create something called CSR (Certificate Signing Request) which is nothing but a X509 certificate as described above, including the public Key and all the identity data.
- This text file with .CSR extension will be sent to a designated CA company, that will evaluate the identity of the certificate, the domain name (Common name or Subject Alternative name, i.e. www.mycompanydomain.com, *.mycompany.com, etc). The identification process will include automatic checking of the private key from the company/website. Notice the CA now has the public key, so it can “challenge” the company/website to be able to decrypt something with is private key (previously encrypted with the public one) to demonstrate ownership of the certificate private key, etc.
- Once the identity of the company has been proved, the CA will sign the CSR by adding a piece of information to the CSR. The piece of information (the signature) will be the CSR information/content hashed (https://en.wikipedia.org/wiki/Cryptographic_hash_function and then encrypted with the private key of the CA certificate. The hashing of the CSR information/content will make sure the encrypted data hasn’t been manipulated.
- Now, the CSR becomes a real X509 digital certificate ready to be used in any TLS connection: “CSR+the Signature” -> final X509 Certificate
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:
- In order to check/validate that a X.509 is real, we need to validate the signature of the certificate (remember, signature is the encrypted “hashed” part of the certificate). This signature has been “created” by one of the trusted CAs companies in the world by using its private Key, and as we all know already, anything than has been encrypted by one private key, CAN ONLY BE DECRYPTED by its public key counterpart.
- The validation process will require having a CA Trusted Store of public keys from all the CA authorities we do trust in the internet (DigiCert, Oracle, VeriSign, etc). Once we receive the certificate (including the signature part), the validation process of the signature consists in “trying” to decrypt the signature with at least one of the public keys from our CA Trusted Store. If that is a positive (decryption completed), then that CA was the one signing the CSR with its private key. Again, remember, anything encrypted with a private key can ONLY be decrypted with its public key and the other way around.
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.
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:
- Rivest, Shamir, Adleman ( RSA )
- Diffie-Hellman exchange ( DHE ) and Elliptic Curve Diffie-Hellman exchange ( ECDHE )
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:
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
-
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.
-
Create a Vault in OCI.
-
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" } }
-
In the network firewall policy, add the mapped secret.
-
Choose Mapped Secret type as SSL forward Proxy or SSL inbound inspection.
-
Choose the Vault created.
-
Choose the secret.
-
Add the mapped secret.
-
-
Create a Decryption Profile.
-
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.
-
Add a Decryption Profile.
-
-
Create a Decryption Rule.
-
Select Source IP addresses from the IP address list you have created in the policy or choose any.
-
Select Destination IP addresses from the IP address list you have created in the policy or choose any.
-
Select Action for decrypting traffic with SSL forward proxy, SSL inbound or no decryption.
-
Choose the Decryption Profile and Mapped Secret.
-
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.
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.
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.
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:
Security Rule:
Now what will happen when the Linux machine tries to access *.oracle.com on the Internet through the OCI Network Firewall.
-
First Decryption rule for SSL forward proxy takes place and you will get a Decryption rule hit count increase on metrics and then it will check in security rule if *.oracle.com is being allowed or not.
-
In our case it is allowed, and we will be able to see on Linux the reachability for *.oracle.com.
-
As mentioned, by default all traffic is denied access on OCI Network firewall. If the Linux machine tries to reach any other https URL over the Internet, the Decryption rule first take place and then the traffic will be reset as by default it is denied.
-
You can view the details from the OCI Network Firewall logs.
-
When we try to reach oracle.com from the Linux machine:
-
When we try to reach any other URL:
-
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
For any other URL:
Related Links
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.
Use OCI Network Firewall for SSL forward proxy and inbound inspection using Decryption rule
F79849-01
March 2023
Copyright © 2023, Oracle and/or its affiliates.