About TLS Inspection Feature

• A feature of Firewall premium that allows us to inspect encypted outbound traffic
• Decrypts outbound traffic, processes the data, then encrypts the data and sends it to the outbound destination
• Works only for outbound traffic. Does not works for inbound encypted traffic
  • Why not for inbound TLS inspection?: because there are other services for inbound TLS termination i.e. Application Gateway, Azure Frontdoor
  • Inbound TLS inspection is supported with Azure Application Gateway allowing end-to-end encryption
• TLS inspection requires opt-in at the application rule level
• To properly configure Azure Firewall Premium TLS inspection, valid Intermediate CA certificate is required

Setup

Root CA certificate and Intermediate CA certificate:

• Create Root CA certificate using openssl tool (save your private key properly)
• Put Root CA certificate into “Trusted Root Certificate Authorities” of client (i.e. Azure VM)
• Sign Intermediate CA certificate using root CA certificate
• Upload “.pfx” (Intermediate CA public certificate and private key) to Azure Key Vault

Key Vault:

• Create Azure Key Vault
• Intermediate CA public certificate and private key will be stored in Key Vault (“.pfx”)

Managed Identity:

• Create “User Assigned Managed Identity” resource. This Managed Identity will be used by Firewall to get certificate from Key Vault
• Allow Managed Identity to access Key Vault:
  • Assign role to managed identity for RBAC based vault access
  • Set access policy for Managed Identity for policy based vault access

Firewall Policy Setting:

• Go to target Firewall Policy > TLS inspection
• Select “Enabled” > Use existing Managed Indentity, Key Vault and Certificate

Or alternatively let Firewall to create those for you

Generate Self-signed Certificates Using Openssl

Install chocolatey and then install Openssl using chocolatey:

choco install openssl

Create a folder “workdir” and create following files in that folder:

• openssl.cnf: inputs, will be used by PowerShell script
• self_signed_cert.ps1: will generate certificates using openssl

openssl.cnf

[ req ]
default_bits        = 4096
distinguished_name  = req_distinguished_name
string_mask         = utf8only
default_md          = sha512

[ req_distinguished_name ]
countryName                     = JP
stateOrProvinceName             = Tokyo
localityName                    = Japan
0.organizationName              = Hovermind
organizationalUnitName          = ITDept
commonName                      = HM
emailAddress                    = hassan@hovermind.com

[ rootCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ interCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign

[ server_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth

self_signed_cert.ps1

# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 3650 -out rootCA.crt -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA' -config openssl.cnf -extensions rootCA_ext

# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA'

# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 3650 -sha256 -extfile openssl.cnf -extensions interCA_ext

# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password 'pass:'

Write-Host ""
Write-Host "================"
Write-Host "Successfully generated root and intermediate CA certificates"
Write-Host "   - rootCA.crt/rootCA.key - Root CA public certificate and private key"
Write-Host "   - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
Write-Host "   - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
Write-Host "================"

Open PowerShell core as Admin in workdir and execute script “./self_signed_cert”

Upload Certificate to Key Vault

• Create Azure KeyVault if does not exist
  • The Key Vault Networking must be set to allow access from All networks
  • Create a dedicated KeyVault for TLS inspection only if main KeyVault is using private endpoint for compliance requirements
• Upload “interCA.pfx” to KeyVault (Certificate Authorities)
  • Certificate must be password-less PFX (Pkcs12) with a certificate and a private key
  • Do not set password when importing “interCA.pfx”

User Assigned Managed Identity for Key Vault Access

• Create user assigned managed identity
  • Go to: https://portal.azure.com/#blade/HubsExtension/BrowseResource/resourceType/Microsoft.ManagedIdentity%2FuserAssignedIdentities
  • ”+ Create” > Fillup details
  • Create user assigned managed identity “uami-tlsinspection-hsystem-devqa-japaneast”
  • “uami-tlsinspection-hsystem-devqa-japaneast” will be used by Firewall to access certificate
• Create “vault access policy” to allow Managed Identity to access Key Vault certificate

Firewall TLS Inspection Setting

• Go to: https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.Network%2FfirewallPolicies
• Select target policy > TLS inspection
• Set “Enabled” > Select Managed Identity, Key Vault and Certificate
• Save
• Note: we need to set “TLS inspection” checked while creating application rule for outbound traffic

Testing TLS Inspection Using Azure VM

Scenario

• Both VM and Firewall are in Hub VNet
• VM is deployed in “UtilitySubnet” (10.150.196.0/24)
• VM Private IP: 10.150.196.4
• Firewall is deployed in “AzureFirewallSubnet” (10.150.193.0/24)
• Firewall private IP: 10.150.193.4

VM

• Provision Azure VM
• If VM NIC or VM subnet has NSG, then make sure that RDP from “AzureFirewallSubnet” is allowed
• Create a route table and attach it to VM subnet, and then override “0.0.0.0/0” route to force traffic through Firewall
• UDR to force VM outbound traffic through Firewall
  • Route name: ForceOutbound-ThroughFirewall
  • Address prefix: 0.0.0.0/0 (Route Table Configuration > Propagate gateway routes: NO)
  • Next hop type: Virtual appliance
  • Next hop address: 10.10.193.4 (Firewall Private IP)

Firewall

• DNAT rule
  • Since outbound traffic from VM subnet will go through Firewall, “asymmetric routing” will happen if we directly connect to VM. We have access VM using Firewall public IP
  • Create DNAT rule in Firewall policy to allow RDP inbound to VM (so that we can access VM using Firewall public IP)
• Application rule with TLS inspection
  • We will test TLS inspection for domain “github.com”
  • Create application rule with FQDN “github.com” and enable TLS inspection while creating application rule
• Firewall DNAT rule to allow RDP to VM
  • Name: RDPToVM
  • Source Type: IP Address
  • Source IP Addresses: *
  • Destination IP Addresses: 20.191.173.32 (public IP of the Firewall)
  • Protocol: TCP
  • Destination Ports: 3389
  • Translated Type: IP Address
  • Translated address: 10.150.196.4 (private IP of VM)
  • Translated port: 3389
• Firewall Application Rule to test TLS inspection for Github
  • Name: InspectTLS-ForVMOuntboundTraffic
  • Source Type: IP Address
  • Source IP Address: 10.150.196.4 (VM private IP)
  • Destination Type: FQDN
  • Target FQDNs: github.com,*.github.com,*.githubassets.com
  • TLS inspection: enable (checkbox)
  • Protocol: Https:443

Now connect to VM using Firewall public IP. Open browser and visit github.com

• Browser would not trust TLS certificate issued by Firewall (using intermediate CA certificate)
• We need to put “rootCA.crt” into “Trusted Root Certificate Authorities” of VM
  • Copy “rootCA.crt” to VM
  • Right click > Install
• Refresh the browser and TLS inspection will work fine

Production Workload

• For production, we should use the corporate PKI to create an Intermediate CA certificate
• A corporate PKI leverages the existing infrastructure and handles the Root CA distribution to all corporate managed machines
• https://docs.microsoft.com/en-us/azure/firewall/premium-deploy-certificates-enterprise-ca