# Inspecting SSL/TLS traffic with TLS inspection configurations in AWS Network Firewall TLS inspection configurationsSession holding for TLS inspection is now available You can now enable session holding in firewall policies that have an associated TLS inspection configuration.Removed Regional availability constraint for outbound SSL/TLS inspection Network Firewall now supports inspection of outbound SSL/TLS traffic in all Regions that Network Firewall is available in. For information about available Regions, see [AWS Network Firewall endpoints and quotas]() in the *Amazon Web Services General Reference*.Outbound SSL/TLS inspection is available in Israel (Tel Aviv) and Europe (Ireland) Network Firewall now supports inspection of outbound SSL/TLS traffic in the Israel (Tel Aviv) Region and the Europe (Ireland) Region.TLS inspection configurations now available in all Regions TLS inspection configurations are now available in all Regions that AWS Network Firewall is available in. For more information, see [What's New with AWS](https://aws.amazon.com/about-aws/whats-new/2023/05/aws-network-firewall-ingress-tls-inspection-all-regions/).TLS inspection configurations now available in additional Regions TLS inspection configurations are now available in additional Regions. For more information, see [What's New with AWS](https://aws.amazon.com/about-aws/whats-new/2023/04/aws-network-firewall-ingress-tls-inspection-new-regions/).New chapter on TLS inspection configurations Network Firewall now supports TLS inspection configurations. Use TLS inspection configurations with your firewall policy to enable decryption and re-encryption of the SSL/TLS traffic going through your firewall. AWS Network Firewall uses *TLS inspection configurations* to decrypt your firewall's inbound and outbound SSL/TLS traffic. After decryption, Network Firewall inspects the traffic according to your firewall policy's stateful rules, and then re-encrypts it before sending it to its destination. You can enable inspection of your firewall's inbound traffic, outbound traffic, or both. To use TLS inspection with your firewall, you must import or provision certificates to AWS Certificate Manager, create a TLS inspection configuration, add that configuration to a new firewall policy, and then associate that policy with your firewall. Pricing for using TLS inspection configurations is based on the amount of traffic that Network Firewall inspects—which appears on your bill as advanced inspection—and the number of deployed firewall endpoints. For information about TLS inspection configuration pricing, see [Network Firewall pricing](https://aws.amazon.com/network-firewall/pricing/). To use the AWS pricing calculator to check Network Firewall costs, see [Network Firewall pricing calculator](https://calculator.aws/#/addService/networkfirewall). **Topics** + [ # Considerations when working with TLS inspection configurations in AWS Network Firewall ](tls-inspection-considerations.md) + [ # Logging for TLS inspection in AWS Network Firewall ](tls-inspection-logging.md) + [ # Using SSL/TLS certificates with TLS inspection configurations in AWS Network Firewall ](tls-inspection-certificate-requirements.md) + [ # TLS inspection configuration settings in AWS Network Firewall ](tls-inspection-settings.md) + [ # Using session holding with TLS inspection in AWS Network Firewall ](session-holding-tls.md) + [ # Managing your TLS inspection configuration in Network Firewall ](managing-tls-configuration.md) # Considerations when working with TLS inspection configurations in AWS Network Firewall Considerations when working with TLS inspection configurationsStateful rules match on `TLS.SNI` for decrypted traffic With TLS inspection, Network Firewall now matches on the `TLS.SNI` keyword in stateful rules, even when it decrypts traffic. Before you implement TLS inspection configuration in Network Firewall, understand the following considerations and limitations. **Conditions for dropping traffic** Network Firewall drops non-TLS traffic that matches the conditions of the TLS inspection configuration scope configuration. For example, if the TLS inspection configuration scope configuration includes `port 80` as `plain HTTP`, Network Firewall drops this traffic because the service can't identify it as TLS traffic. Network Firewall also drops TLS traffic if the client hello message in the TLS handshake doesn't include a server name, or if the server name that's presented in the client hello doesn't match the server name indication (SNI) that's presented in the downstream server certificate. **Decrypted payload inspection for HTTP2** Network Firewall supports decrypted payload inspection for HTTP2. **Impact on existing flows** When you add a TLS inspection configuration to an existing firewall, Network Firewall interrupts traffic flows that match the criteria defined by the TLS inspection configuration scope configuration. New connections to the firewall begin SSL/TLS decryption and inspection. When you add new TLS inspection configuration to a firewall and there's ongoing TLS traffic that matches the scope criteria, the firewall drops the traffic. **Initial latency** Some latency is expected during the initial connection due to the TCP and TLS handshakes that occur before data can flow to the firewall. If you enable certificate revocation checking for outbound TLS inspection, you can expect additional latency when you initially connect to a new domain over a firewall. We recommend that you conduct your own testing using your rulesets to ensure that TLS inspection configuration meets your performance expectations. **Inspection capabilities** TLS inspection is available for the request and the response for HTTPS traffic and other TCP-based application protocols that use TLS, such as Secure Mail Transfer Protocol Secure (SMTPS), and Post Office Protocol 3 Secure (POP3s). At the network layer, TLS inspection supports both IPv4 and IPv6 traffic. **Managed rules** You can use AWS managed rules with TLS inspection. However, due to the TLS decryption, TLS keywords don't initiate inspection within the stateful engine. You can benefit from non-TLS rules within managed rule groups and find increased visibility of those rules because the decrypted traffic is visible to the inspection engine. You can also create custom rules based on inner protocols, which are available for inspection. For example, you can match with an HTTP header within the decrypted HTTPS stream. For more information about using managed rules with Network Firewall, see [Managed rule groups in AWS Network Firewall](nwfw-managed-rule-groups.md). **Stateful rules** Network Firewall ends the TLS connection that's initiated by the client and decrypts traffic before it reaches the stateful inspection engine. As a result, the traffic doesn't match any TLS-based keywords except for `TLS.SNI`. You can still use all TLS keywords in the stateful rule for traffic that doesn’t match the TLS inspection scope. Application rules that are based on decrypted payloads are applied, for example, rules that are based on HTTP keywords. **Note** `TLS.SNI` keyword rules are still matched for traffic that's in TLS scope, even though the traffic is decrypted before it reaches the stateful inspection engine. If you configure a drop or reject action for a stateful rule that matches the traffic scope that's defined in the TLS inspection configuration, Network Firewall closes the connections to clients as soon as it detects a payload bearing packet that matches the drop or reject rule. Your traffic is re-encrypted before leaving the Network Firewall host. **Supported TLS versions** TLS versions 1.1, 1.2, and 1.3 are supported. **TLS cipher suites and SNI** Network Firewall terminates the TLS connection that's initiated by the client, and the TLS Server Name Identifier (SNI) must match a configured certificate. Network Firewall uses TLS 1.3 to initiate the forward connection to the server. The client cipher suites must include one or more of the following: ``` TLS 1.1 & TLS 1.2 AES128-GCM-SHA256 AES128-SHA AES128-SHA256 AES256-GCM-SHA384 AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA TLS 1.3 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ``` **Idle timeouts** The expected idle timeout for the TLS engine for established connections is about 120 seconds, while the idle timeout for connections that are not yet established is about 5 seconds. **Limitations** The following limitations apply to TLS inspection configurations: + Cross-signed root certificates aren't supported. AWS Certificate Manager public certificates are cross-signed but can be used for TLS inspection. For more information, see [Using SSL/TLS certificates with TLS inspection configurations in AWS Network Firewall](tls-inspection-certificate-requirements.md). + Decryption of TLS protocols that rely upon StartTLS aren't supported. + Network Firewall publishes separate CloudWatch metrics for traffic that's associated with TLS inspection configurations. Existing stateful traffic metrics don't reflect data for traffic that's decrypted and re-encrypted by your firewall policy's TLS inspection configuration. + Self-signed certificates aren't supported for inbound inspection. For more information about the certificates that Network Firewall supports, see [Using SSL/TLS certificates with TLS inspection configurations in AWS Network Firewall](tls-inspection-certificate-requirements.md). + TLS inspection of UDP-based transport protocols such as Quick UDP Internet Connections (QUIC) isn't supported. You can configure your applications so that they don't switch from TCP to UDP-based transport protocols. If you want to prevent TLS traffic from using the QUIC protocol, modify your application to deny traffic using QUIC or create a firewall stateful rule to block QUIC traffic. + TLS version 1.0 and prior SSL versions aren't supported. + Traffic encrypted using TLS v1.3 Encrypted SNI and Encrypted Client Hello extensions aren't supported. When Network Firewall can't find an SNI in the client hello, the service closes the connection with a `RST` packet. If this is an issue for your workloads, you can configure your TLS inspection configuration scope to exclude the workloads using TLS v1.3. + WebSockets inspection over HTTP2 isn't supported; Network Firewall drops this traffic. However, WebSockets over HTTP1.1 is supported. + If Network Firewall is deployed behind an Application Load Balancer, its TLS inspection can't inspect the inbound TLS traffic that's terminated at the Application Load Balancer. + When CA certificates are based on ECC (eliptic-curve cryptography) keys, the key usage extension needs to include the digitalSignature. # Logging for TLS inspection in AWS Network Firewall TLS logging You can now use the TLS log type to log TLS errors and outbound traffic that fails a TLS inspection server certificate revocation check. This is a new log type, in an addition to the existing alert and flow log types. You can enable TLS logging for your firewall's stateful engine, to log some categories of events related to TLS inspection. TLS logs report TLS errors and certificate revocation check failures for outbound traffic. For information about enabling logging, see [Logging network traffic from AWS Network Firewall](firewall-logging.md). **Log entries for TLS errors** TLS errors currently report connection resets that are due to SNI mismatches and naming errors. These are typically caused by problems with customer traffic or with the customer's client or server. For example, when the client hello SNI is NULL or doesn't match the subject name in the server certificate. For this type of error, the TLS logs include the source and destination IPs and ports, the SNI, and the TLS error message. In the following example TLS log entry, the error is in the client hello. ``` { "firewall_name": "firewall-tls-test", "availability_zone": "us-east-1d", "event_timestamp": 1719943304, "event": { "timestamp": "2024-07-02T18:01:44.412778Z", "src_ip": "10.0.2.53", "src_port": "59844", "dest_ip": "10.0.1.27", "dest_port": "443", "sni": "-", "tls_error": { "error_message": "Server name is not found in client hello." } } } ``` The following example TLS log entry indicates a server name mismatch. ``` { "firewall_name": "test-firewall", "availability_zone": "us-east-1d", "event_timestamp": 1721849698, "event": { "timestamp": "2024-07-24T19:34:58.337042Z", "src_ip": "10.0.2.22", "src_port": "44798", "dest_ip": "91.212.12.80", "dest_port": "444", "sni": "test.com", "tls_error": { "error_message": "SNI: test.com Match Failed to server certificate names: aaacertificateservices.comodoca.com/aaacertificateservices.comodoca.com/www.aaacertificateservices.comodoca.com " } } } ``` **Log entries for certificate revocation check failures** These entries report outbound traffic that fails the server certificate revocation check during TLS inspection. This log type requires the firewall to be configured with TLS inspection for outbound traffic, and for the TLS inspection to be configured to check the certificate revocation status. For information about configuring certificate revocation checking, see [Using SSL/TLS certificates with TLS inspection configurations in AWS Network Firewall](tls-inspection-certificate-requirements.md) and [Checking certificate revocation status](tls-inspection-certificate-requirements.md#tls-inspection-check-certificate-revocation-status). For revocation checks, the TLS logs report when servers that you're sending traffic to are failing the checks. The logs include the revocation check status, the action taken, source and destination IPs and ports, and the SNI that the revocation check was for. You can use this information to pinpoint the traffic that's experiencing failures and take measures to manage the problem. In the following example TLS log entry, the revocation check reports that the certificate has been revoked, either by an Online Certificate Status Protocol (OCSP) or a Certificate Revocation Lists (CRL) provider. The certificate is not valid anymore. For this case, the firewall acts according to the configuration that you've specified for these checks. For this example, the action is `DROP`. ``` { "firewall_name": "egress-fw", "availability_zone": "us-east-1d", "event_timestamp": 1708361189, "event": { "src_ip": "10.0.2.53", "src_port": "55930", "revocation_check": { "leaf_cert_fpr": "1234567890EXAMPLE0987654321", "status": "REVOKED", "action": "DROP" }, "dest_ip": "54.92.160.72", "dest_port": "443", "timestamp": "2024-02-19T16:46:29.441824Z", "sni": "revoked-rsa-dv.ssl.com" } } ``` In the following example, the revocation check status is `UNKNOWN`. This can happen for a number of reasons, such as when the check encounters an error retrieving the data from the provider, or the provider not having any record of the certificate. Whatever the reason, the firewall isn't sure whether the certificate is revoked. The firewall again acts according to the configuration that you've specified for these checks. ``` { "firewall_name": "egress-fw", "availability_zone": "us-east-1d", "event_timestamp": 1708361189, "event": { "src_ip": "10.0.2.53", "src_port": "55930", "revocation_check": { "leaf_cert_fpr": "1234567890EXAMPLE0987654321", "status": "UNKNOWN", "action": "DROP" }, "dest_ip": "54.92.160.72", "dest_port": "443", "timestamp": "2024-02-19T16:46:29.441824Z", "sni": "revoked-rsa-dv.ssl.com" } } ``` # Using SSL/TLS certificates with TLS inspection configurations in AWS Network Firewall Using SSL/TLS certificates with TLS inspection configurationsAdded unsupported certificate type Network Firewall doesn't support cross-signed root certificates in TLS inspection configurations. Network Firewall integrates with AWS Certificate Manager (ACM) to make it easy to manage the certificates that you're using to decrypt and re-encrypt your firewall's SSL/TLS traffic. To get started with TLS inspection configurations, you must first import or issue certificates to ACM, and then associate the certificates with your TLS inspection configuration. You can configure certificates for inbound or outbound inspection, or both. To view the maximum number of certificates that you can use, see [AWS Network Firewall quotas](quotas.md). This section discusses how to use SSL/TLS certificates with TLS inspection configurations. ## General requirements for TLS inspection General requirements The following are general requirements for the certificates that are used for TLS inspection. **Certificate chain order** Imported SSL/TLS certificates require all of the intermediate certificates in the certificate chain that's in the **.pem** file, beginning with the certificate authority (CA) that signed the certificate that you are importing. Typically, you'll find a file on the CA website that lists intermediate and root certificates in the proper chained order. Here's an example: ``` -----BEGIN CERTIFICATE----- Intermediate certificate 2 -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Intermediate certificate 1 -----END CERTIFICATE----- ``` **Supported certificates** Network Firewall supports all of the algorithms and key sizes that are supported by AWS Certificate Manager (ACM), and also supports wildcard certificates. However, Network Firewall doesn't support using self-signed certificates for inbound inspection. Using self-signed certificates can result in client-side errors, and using cross-signed certificates can result in asynchronous and synchronous failures. For information about ACM supported algorithms, key sizes, and wildcard certificates, see [ACM certificate characteristics](https://docs.aws.amazon.com/acm/latest/userguide/acm-certificate.html) in the *AWS Certificate Manager User Guide*. If a certificate that's associated with your TLS inspection configuration expires or is deleted, you experience client-side errors in the traffic that Network Firewall processes. Replace certificates that will expire soon to avoid client-side errors. ## Server certificates - Inbound SSL/TLS inspection Server certificates - Inbound SSL/TLS inspection To configure inbound TLS inspection, you must first issue or import a certificate in AWS Certificate Manager (ACM) for each domain that you want Network Firewall to inspect. After you issue or import the certificates in ACM, you can associate the certificates with your TLS inspection configuration. For more information about working with certificates in ACM, see [Request a public certificate](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) or [Importing certificates](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) in the *AWS Certificate Manager User Guide*. The following requirements are specific to the server certificates that are used for inbound inspection. **Certificate issuer** For server certificates for inbound inspection, Network Firewall supports the same certificate authorities (CAs) as Mozilla, except for those that issue cross-signed root certificates. If you import a certificate into ACM, use a certificate issued by a CA on the [Mozilla Included CA Certificate List](https://wiki.mozilla.org/CA/Included_Certificates). For more information about getting and installing a certificate, refer to the documentation for your HTTP server software and to the documentation for the CA. **Note** Network Firewall can't validate cross-signed root certificates, such as those issued by Let's Encrypt. AWS Certificate Manager public certificates are cross-signed but can be used for TLS inspection. Usage of cross-signed certificates can cause asynchronous failures in your firewall. **Deleted or expired certificates** Network Firewall doesn't support the Online Certificate Status Protocol (OCSP) MustStaple TLS extension. Network Firewall also doesn't validate the expiration status of server certificates that are associated with a TLS inspection configuration. Validate the status of your server certificates and use a valid certificate at all times. **Supported certificates** You can either generate or import a server certificate in ACM. ## CA certificate - Outbound SSL/TLS inspection CA certificate - Outbound SSL/TLS inspection To configure outbound TLS inspection, you must first import a certificate authority (CA) certificate into AWS Certificate Manager (ACM). After you import the CA certificate in ACM, you can associate the CA certificate with your TLS inspection configuration. Network Firewall uses the CA certificate to generate a server certificate, which the service uses to establish trust between the client and the server. For more information about working with certificates in ACM, see [Importing certificates](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html) in the *AWS Certificate Manager User Guide*. The following requirements are specific to CA certificates that are used for outbound SSL/TLS inspection. **Supported certificates** You can use CA certificates that are imported into ACM for outbound inspection—including private certificates—but you can't generate intermediate CA certificates using ACM. However, we don't support TLS traffic to or from destination servers that use a server certificate signed by a private CA. In other words, we do certificate verification of downstream server certificates to allow TLS traffic where server certificates are signed by public well-known roots contained on the [Mozilla Included CA Certificate List ](https://wiki.mozilla.org/CA/Included_Certificates). We also don't support certificates issued by AWS Private Certificate Authority. **Revoked certificates** For outbound TLS, you can enable certificate revocation checks, which allows Network Firewall to check revocation status with Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) on behalf of clients. For more information see [Checking certificate revocation status](#tls-inspection-check-certificate-revocation-status). ## Checking certificate revocation status Checking certificate revocation status For outbound inspection, Network Firewall can check if the server or intermediate certificate that the server presents in the TLS connection has a revoked or unknown status. When you enable this option, Network Firewall checks the revocation status using the Online Certificate Status Protocol (OCSP) and Certificate Revocation List (CRL) endpoints. These endpoints are specified in the certificate authority (CA) certificate that's downloaded from the server in the SSL/TLS connection. Network Firewall caches the CRL and OCSP responses. If the certificate has a revoked or unknown status, Network Firewall handles the outbound traffic based on the actions that you set when you configure the revocation status checks. **Actions** When the certificate has a revoked or unknown status, you can choose from the following actions. These actions configure how Network Firewall processes traffic when it determines that the certificate that's presented by the server in the SSL/TLS connection has an unknown or revoked status. + **Pass** – Allows the connection to continue, and pass subsequent packets to the stateful engine for inspection. + **Drop** – Network Firewall closes the connection and drops subsequent packets for that connection. + **Reject** – Network Firewall sends a TCP reject packet back to your client. The service closes the connection and drops subsequent packets for that connection. This option is available only for TCP traffic. Keep the following considerations in mind when turning on certificate revocation check: **Caching** Network Firewall caches the revocation check status to serve responses faster than the CRL and OCSP servers can. The cache duration depends on the revocation check status, which improves the accuracy of the certificate revocation status checks. **Latency** When you turn on certificate revocation checking for outbound TLS inspection, expect additional latency when you initially connect to a new domain over a firewall instance. This is specific to outbound TLS inspection only. We recommend that you conduct your own testing using your rulesets to ensure that the service meets your performance expectations. **Logging** You can get logs for certificate revocation check failures. To do this, configure TLS logging for your firewall's stateful engine. For additional information, see [Logging for TLS inspection in AWS Network Firewall](tls-inspection-logging.md). For information about enabling logging, see [Logging network traffic from AWS Network Firewall](firewall-logging.md). **Unsupported features** Revocation status checking doesn't include support for the following: + Configurations for salted or nonce OCSP responses. + Network Firewall supports OCSP checks using a different signer key, but doesn't support CRL checks using a different signer key. + Delegated OCSP checks. + Delta Certificate Revocation Lists (CRLs). + File Transfer Protocol (FTP) and Lightweight Directory Access Protocol (LDAP) CRL URLs. + OCSP and CRL checks requiring referenced parameters from issuer certificates. + OCSP stapling. For information about troubleshooting issues related to certificate revocation, see [Troubleshooting TLS inspection in AWS Network Firewall](troubleshooting-tls-inspection.md). ## Creating a certificate for inbound TLS inspection with AWS Private CA Creating a certificate for inbound TLS inspection with AWS Private CA You can use AWS Private CA to create certificates for inbound TLS inspection. This procedure shows you how to create a certificate that works with Network Firewall inbound inspection. **Prerequisites** Before you begin, verify that you have the following: + A certificate authority (CA) with ACTIVE status in AWS Private CA + OpenSSL installed on your system **To create a certificate for inbound TLS inspection** 1. Create an OpenSSL configuration file named `openssl_temp.cnf`. Use the following template and modify the values for your environment. The `req_ext` section must have `basicConstraints` enabled. Adjust the `pathlen` value based on your Public Key Infrastructure (PKI) structure. ``` [ req ] default_bits = 2048 prompt = no default_md = sha256 distinguished_name = dn req_extensions = req_ext [ dn ] C = US ST = Your-State L = Your-City O = Your-Organization OU = Your-Organizational-Unit CN = [ req_ext ] basicConstraints = critical, CA:TRUE, pathlen:0 keyUsage = critical, digitalSignature, keyEncipherment, keyCertSign, cRLSign extendedKeyUsage = critical, serverAuth, clientAuth subjectAltName = @alt_names [ alt_names ] DNS.1 = ``` 1. Generate a private key using OpenSSL. ``` openssl genrsa -out key.pem 2048 ``` 1. Create a Certificate Signing Request (CSR) using your configuration file. ``` openssl req -new -sha256 -key key.pem -nodes -out req.csr -config openssl_temp.cnf ``` 1. Sign the certificate with AWS Private CA. Replace the placeholder values with your actual ARN and region. Adjust the template ARN if your `pathlen` value differs. ``` aws acm-pca issue-certificate --certificate-authority-arn --csr fileb://req.csr --signing-algorithm SHA256WITHRSA --validity Value=365,Type="DAYS" --template-arn arn:aws:acm-pca:::template/BlankSubordinateCACertificate_PathLen0_CSRPassthrough/V1 --region --output json ``` 1. Export the signed certificate from AWS Private CA. Use the certificate ARN from the previous step. ``` aws acm-pca get-certificate --certificate-arn --certificate-authority-arn --region --output json | jq -r '.Certificate, .CertificateChain' ``` 1. Upload the certificate to AWS Certificate Manager (ACM). The command output provides two certificate sections in PEM format. Use the first section as the certificate body, the second section as the certificate chain, and the `key.pem` file from step 2 as the private key. ``` -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- ``` # TLS inspection configuration settings in AWS Network Firewall TLS inspection configuration settings When you configure TLS inspection configuration you provide the following settings. + **Name** – The identifier for the TLS inspection configuration. You assign a unique name to every TLS inspection configuration. You can't change the name of a TLS inspection configuration after you create it. + **Description** – Optional additional information about the TLS inspection configuration. Fill in information that might help you to remember the purpose of the TLS inspection configuration and how you want to use it. The description is included in TLS inspection configuration lists in the console and the APIs. + **Associate SSL/TLS certificates** – The certificates to associate with the TLS inspection configuration for inbound and outbound inspection. Network Firewall uses certificates to decrypt and re-encrypt the SSL/TLS traffic that's going to your firewall. + **Define scope** – Defines the scope of the traffic to decrypt based on source and destination addresses and port ranges in a scope configuration. For each scope configuration that you add, Network Firewall adds a mirrored scope configuration with reverse sources and destinations when it creates the TLS inspection configuration. This allows Network Firewall to decrypt—and subsequently inspect—traffic in both directions, which is required for TLS termination. + **Customer managed key** (Optional) – Network Firewall encrypts and decrypts the TLS inspection configuration, to protect against unauthorized access. By default, Network Firewall uses AWS owned keys for this. If you want to use your own keys, you can configure customer managed keys from AWS Key Management Service and provide them to Network Firewall. For information about this option, see [Encryption at rest with AWS Key Management Service](kms-encryption-at-rest.md). + **Certificate revocation status** (Optional) – Network Firewall checks if the certificate that's presented by the server in the TLS session is revoked or has an unknown status. If this is turned on, Network Firewall handles the outbound traffic based on the actions that you configure in the certificate revocation check. + **Tags** – A tag is an optional label that you assign to an AWS resource. You can use tags to search and filter your resources and to track your AWS costs. For more information about tags, see [Tagging AWS Network Firewall resources](tagging.md). # Using session holding with TLS inspection in AWS Network Firewall Session holding with TLS inspection **Before you use session holding** To use session holding, you must have TLS Inspection configuration and TLS Inspection enabled in your firewall policy. For information, see [Creating a firewall policy in AWS Network Firewall](firewall-policy-creating.md). Network Firewall session holding enhances TLS inspection security by controlling when TCP and TLS establishment packets reach destination servers. When enabled, Network Firewall holds these packets until it evaluates TLS Inspection rules for Server Name Indication (SNI). **Session holding behavior** You can enable session holding in your firewall policy when you have an associated TLS Inspection configuration. The behavior differs depending on whether session holding is enabled. Without session holding, Network Firewall immediately initiates TCP/TLS handshakes with downstream servers when client connections begin. This means the handshake between the firewall and downstream server occurs before SNI information is available. While deny rules can still block connections after evaluation, downstream servers receive the initial connection attempts. With session holding, Network Firewall waits for SNI information from the client's TLS handshake before initiating downstream connections. This lets the firewall evaluate TLS SNI-based rules first, preventing any connection attempts to blocked domains from reaching downstream servers. Alert logs based on TLS rules in this configuration will not contain the SNI that was accessed upon rule match. **Rule evaluation** Session holding affects how Network Firewall evaluates TLS.SNI and HTTP rules. Without session holding, Network Firewall evaluates TLS.SNI and HTTP rules simultaneously after establishing the downstream server connection. With session holding, Network Firewall evaluates TLS.SNI rules first while holding the client-side connection, then evaluates HTTP rules. When a connection passes a TLS rule, Network Firewall stops evaluating HTTP rules for that connection. **Tip** For best results with session holding, configure TLS rules that match on SNI in a deny list format. Use HTTP-based rules to process connections that aren't in the deny list. # Managing your TLS inspection configuration in Network Firewall Managing your TLS inspection configuration This section describes how to create, update, and delete a TLS inspection configuration in Network Firewall. To turn on TLS inspection for your firewall, create a TLS inspection configuration, add the TLS inspection configuration to a firewall policy, then associate the firewall policy with your firewall. You can only add a TLS inspection configuration to a new policy, not to an existing policy. However, you can replace an existing TLS inspection configuration with another TLS inspection configuration in a firewall policy. To add a TLS inspection configuration to a firewall policy or update an existing TLS inspection configuration, see [Managing your firewall policy](firewall-policy-managing.md). **Note** A TLS inspection configuration is only available for use by the account that you use to create it. It can't be shared across accounts. **Topics** + [ # Creating a TLS inspection configuration in Network Firewall ](creating-tls-configuration.md) + [ # Updating a TLS inspection configuration in Network Firewall ](updating-tls-configuration.md) + [ # Deleting a TLS inspection configuration in Network Firewall ](deleting-tls-configuration.md) # Creating a TLS inspection configuration in Network Firewall Creating a TLS inspection configuration This procedure explains how to create a TLS inspection configuration using Network Firewall. To follow this procedure, you must have at least one certificate in AWS Certificate Manager (ACM) that's accessible by your AWS account. **To create a TLS inspection configuration using the console** 1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, under **Network Firewall**, choose **TLS inspection configurations**. 1. Choose **Create TLS inspection configuration**. 1. In the **Associate SSL/TLS certificates** page, configure **Server certificates for inbound SSL/TLS inspection**, **CA certificate for outbound SSL/TLS inspection**, or both. 1. Choose **Next** to go to the TLS inspection configuration's **Describe TLS inspection configuration** page. 1. Enter a **Name** to identify this TLS inspection configuration. **Warning** You can't change the name after you create the TLS inspection configuration. 1. (Optional) Enter a **Description** for the TLS inspection configuration. 1. Choose **Next** to go to the TLS inspection configuration's **Define scope** page. 1. In the **Scope configuration** pane, choose the protocol, source, source port range, destination, and destination port range of the traffic that you want Network Firewall to decrypt. Network Firewall uses the associated certificates to decrypt the SSL/TLS traffic that matches the scope configuration. After Network Firewall decrypts the traffic, the service inspects the traffic according to your firewall policy's stateful rules. Network Firewall also automatically configures a reverse scope, ensuring that the service inspects the traffic in both directions. 1. For **Protocol**, choose the protocol to decrypt. Network Firewall currently supports TCP. 1. For **Source IP**, choose the source IP addresses and ranges to decrypt. You can decrypt by **Custom** IP addresses or by **Any IPv4 address**. 1. For **Source port**, choose the source ports and source port ranges to decrypt. You can decrypt by **Custom** port ranges or by **Any port**. 1. For **Destination IP**, choose the destination IP addresses and ranges to decrypt. You can decrypt by **Custom** IP addresses or by **Any IPv4 address**. 1. For **Destination port**, choose the destination ports and destination port ranges to decrypt. You can decrypt by **Custom** port ranges or by **Any port**. 1. Choose **Add scope configuration**. To add more scope configurations, adjust the settings in the **scope configuration** pane, then select **Add scope configuration**. 1. Choose **Next**. 1. (Optional) On the **Advanced settings** page, under **Customer managed key**, you can change the key that Network Firewall uses to decrypt and encrypt the TLS inspection configuration, to protect against unauthorized access. By default, Network Firewall uses AWS owned keys. If you want to use your own keys, you can configure customer managed keys from the AWS Key Management Service and provide them to Network Firewall. For information about customer managed keys, see [Encryption at rest with AWS Key Management Service](kms-encryption-at-rest.md). 1. (Optional) In the **Certificate revocation status** section, choose whether Network Firewall should check if the certificate that's presented by the server in the TLS connection has a revoked status. To enable this option, you must first associate a certificate authority (CA) certificate for outbound inspection in the **Associate SSL/TLS certificates** step. You can also configure the actions that Network Firewall takes on outbound traffic if the certificate is revoked or has an unknown status. 1. Choose **Next**. 1. (Optional) On the **Add tags** page, enter a key and optional value for any tag that you want to add to this TLS inspection configuration. Tags help you to organize and manage your AWS resources. For more information about tagging your resources, see [Tagging AWS Network Firewall resources](tagging.md). 1. Choose **Next**. 1. On the **Review and confirm** page, check the TLS inspection configuration settings. If you want to change anything, choose **Edit** for that section. This returns you to the corresponding step in the create TLS inspection configuration wizard. Make your changes, then choose **Next** on each page until you come back to the review and confirm page. 1. Choose **Create TLS inspection configuration**. Your new TLS inspection configuration is added to the list in the Network Firewall TLS inspection configurations page. If you've configured the inspection for certificate revocation checks on outbound traffic, you can log failures for these checks by enabling TLS logging. For information, see [Logging network traffic](firewall-logging.md). To use your TLS inspection configuration in a firewall policy, follow the procedures at [Managing your firewall policy](firewall-policy-managing.md). # Updating a TLS inspection configuration in Network Firewall Updating a TLS inspection configuration To change your TLS inspection configuration settings, use the following procedure: **To update a TLS inspection configuration** 1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, under **Network Firewall**, choose **TLS inspection configurations**. 1. In the **TLS inspection configuration** page, select the name of the TLS inspection configuration that you want to update. 1. On the TLS inspection configuration page, make your changes. You can't update the name of a TLS inspection configuration after creation, but you can change other details. If you want to update the name, you must create a new TLS inspection configuration. 1. Choose **Save** to save your changes. **How Network Firewall propagates your changes** When you make any changes to a firewall, including changes to any of the firewall's components, like rule groups, TLS inspection configurations, and firewall policies, Network Firewall propagates the changes everywhere that the firewall is used. Your changes are normally applied within minutes, but there might be a brief period of inconsistency when the changes have arrived in some places and not in others. For example, if you modify a rule group so that it drops an additional type of packet, for a firewall that uses the rule group, the new packet type might briefly be dropped by one firewall endpoint while still being allowed by another. This temporary inconsistency can occur when you first create a firewall and when you make changes to an existing firewall. Generally, any inconsistencies of this type last only a few seconds. # Deleting a TLS inspection configuration in Network Firewall Deleting a TLS inspection configuration To delete a TLS inspection configuration, perform the following procedure. **Deleting a TLS inspection configuration** When you delete a TLS inspection configuration, AWS Network Firewall checks to see if it's currently being referenced in a firewall policy. If it is, Network Firewall sends you a warning, and doesn't delete the TLS inspection configuration. Network Firewall is almost always able to determine whether a resource is being referenced, however, in rare cases it might not be able to do so. To be sure that the resource that you want to delete isn't in use, check all of your firewall policies before deleting it. TLS inspection configurations referenced in firewall policies can't be deleted. **To delete a TLS inspection configuration** 1. Sign in to the AWS Management Console and open the Amazon VPC console at [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. In the navigation pane, under **Network Firewall**, choose **TLS inspection configurations**. 1. In the **TLS inspection configuration** page, select the TLS inspection configuration that you want to delete. 1. Choose **Delete**, and confirm your request. Your TLS inspection configuration is removed from the list in the **TLS inspection configuration** page.