TLS inspection configuration for encrypted egress traffic and AWS Network Firewall
In the evolving landscape of network security, safeguarding data as it exits your virtual environment is as crucial as protecting incoming traffic. In a previous post, we highlighted the significance of ingress TLS inspection in enhancing security within Amazon Web Services (AWS) environments. Building on that foundation, I focus on egress TLS inspection in this post.
<p>Egress TLS decryption, a pivotal feature of <a href="https://aws.amazon.com/network-firewall/" target="_blank" rel="noopener">AWS Network Firewall</a>, offers a robust mechanism to decrypt, inspect the payload, and re-encrypt outbound SSL/TLS traffic. This process helps ensure that your sensitive data remains secure and aligned with your organizational policies as it traverses to external destinations. Whether you’re a seasoned AWS user or new to cloud security, understanding and implementing egress TLS inspection can bolster your security posture by helping you identify threats within encrypted communications.</p>
<p>In this post, we explore the setup of egress TLS inspection within Network Firewall. The discussion covers the key steps for configuration, highlights essential best practices, and delves into important considerations for maintaining both performance and security. By the end of this post, you will understand the role and implementation of egress TLS inspection, and be able to integrate this feature into your network security strategy.</p>
<h2>Overview of egress TLS inspection</h2>
<p>Egress TLS inspection is a critical component of network security because it helps you identify and mitigate risks that are hidden in encrypted traffic, such as data exfiltration or outbound communication with malicious sites (for example command and control servers). It involves the careful examination of outbound encrypted traffic to help ensure that data leaving your network aligns with security policies and doesn’t contain potential threats or sensitive information.</p>
<p>This process helps ensure that the confidentiality and integrity of your data are maintained while providing the visibility that you need for security analysis.</p>
<p>Figure 1 depicts the traffic flow of egress packets that don’t match the TLS inspection scope. Incoming packets that aren’t in scope of the TLS inspection pass through the stateless engine, and then the stateful engine, before being forwarded to the destination server. Because it isn’t within the scope for TLS inspection, the packet isn’t sent to the TLS engine.</p>
<div id="attachment_33707" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33707" src="https://infracom.com.sg/wp-content/uploads/2024/04/img1-2.png" alt="Figure 1: Network Firewall packet handling, not in TLS scope" width="780" class="size-full wp-image-33707">
<p id="caption-attachment-33707" class="wp-caption-text">Figure 1: Network Firewall packet handling, not in TLS scope</p>
</div>
<p>Now, compare that to Figure 2, which shows the traffic flow when egress TLS inspection is enabled. After passing through the <a href="https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-rules-engines.html" target="_blank" rel="noopener">stateless engine</a>, traffic matches the TLS inspection scope. Network Firewall forwards the packet to the TLS engine, where it’s decrypted. Network Firewall passes the decrypted traffic to the stateful engine, where it’s inspected and passed back to the TLS engine for re-encryption. Network Firewall then forwards the packet to its destination.</p>
<div id="attachment_33709" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33709" src="https://infracom.com.sg/wp-content/uploads/2024/04/img2-1.png" alt="Figure 2: Network Firewall packet handling, in TLS scope" width="780" class="size-full wp-image-33709">
<p id="caption-attachment-33709" class="wp-caption-text">Figure 2: Network Firewall packet handling, in TLS scope</p>
</div>
<p>Now consider the use of certificates for these connections. As shown in Figure 3, the egress TLS connections use a firewall-generated certificate on the client side and the target servers’ certificate on the server side. Network Firewall decrypts the packets that are internal to the firewall process and processes them in clear text through the stateful engine.</p>
<div id="attachment_33711" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33711" src="https://infracom.com.sg/wp-content/uploads/2024/04/img3-1.png" alt="Figure 3: Egress TLS certificate usage" width="780" class="size-full wp-image-33711">
<p id="caption-attachment-33711" class="wp-caption-text">Figure 3: Egress TLS certificate usage</p>
</div>
<p>By implementing egress TLS inspection, you gain a more comprehensive view of your network traffic, so you can monitor and manage data flows more effectively. This enhanced visibility is crucial in detecting and responding to potential security threats that might otherwise remain hidden in encrypted traffic.</p>
<p>In the following sections, I guide you through the configuration of egress TLS inspection, discuss best practices, and highlight key considerations to help achieve a balance between robust security and optimal network performance.</p>
<h2>Additional consideration: the challenge of SNI spoofing</h2>
<p>Server Name Indication (SNI) spoofing can affect how well your TLS inspection works. SNI is a component of the TLS protocol that allows a client to specify which server it’s trying to connect to at the start of the handshake process.</p>
<p>SNI spoofing occurs when an entity manipulates the SNI field to disguise the true destination of the traffic. This is similar to requesting access to one site while intending to connect to a different, less secure site. SNI spoofing can pose significant challenges to network security measures, particularly those that rely on SNI information for traffic filtering and inspection.</p>
<p>In the context of egress TLS inspection, a threat actor can use SNI spoofing to circumvent security tools because these tools often use the SNI field to determine the legitimacy and safety of outbound connections. If the threat actor spoofs the SNI field successfully, unauthorized traffic could pass through the network, circumventing detection.</p>
<p>To effectively counteract SNI spoofing, use TLS inspection on Network Firewall. When you use TLS inspection on Network Firewall, spoofed SNIs on traffic within the scope of what TLS inspection looks at are dropped. The spoofed SNI traffic is dropped because Network Firewall validates the TLS server certificate to check the associated domains in it against the SNI.</p>
<h2>Set up egress TLS inspection in Network Firewall</h2>
<p>In this section, I guide you through the essential steps to set up egress TLS inspection in Network Firewall.</p>
<h2>Prerequisites</h2>
<p>The example used in this post uses a prebuilt environment. To learn more about the prebuilt environment and how to build a similar configuration in your own AWS environment, see <a href="https://docs.aws.amazon.com/network-firewall/latest/developerguide/creating-tls-configuration.html" target="_blank" rel="noopener">Creating a TLS inspection configuration in Network Firewall</a>. To follow along with this post, you will need a working topology with Network Firewall deployed and an <a href="https://aws.amazon.com/ec2/" target="_blank" rel="noopener">Amazon Elastic Compute Cloud (Amazon EC2)</a> instance deployed in a private subnet.</p>
<p>Additionally, you need to have a certificate generated that you will present to your clients when they make outbound TLS requests that match your inspection configuration. After you generate your certificate, note the certificate body, private key, and certificate chain because you will import these into ACM. </p>
<h3>Integration with ACM </h3>
<p>The first step is to manage your SSL/TLS certificates through <a href="https://aws.amazon.com/certificate-manager/" target="_blank" rel="noopener">AWS Certificate Manager (ACM)</a>.</p>
<h4>To integrate with ACM</h4>
<ol>
<li>Obtain a certificate authority (CA) signed certificate, private key, and certificate chain.</li>
<li>Open the ACM console, and in the left navigation pane, choose <strong>Certificates</strong>.</li>
<li>Choose <strong>Import certificates</strong>.</li>
<li>In the <strong>Certificate details</strong> section, paste your certificate’s information, including the certificate body, certificate private key, and certificate chain, into the relevant fields.</li>
<li>Choose <strong>Next.</strong></li>
<li>On the <strong>Add Tags</strong> page, add a tag to your certificate:
<ol>
<li>For <strong>Tag key</strong>, enter a name for the tag.</li>
<li>For <strong>Tag value – optional</strong>, enter a <a href="https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html" target="_blank" rel="noopener">tag value</a>.</li>
<li>Choose <strong>Next.</strong></li>
</ol> </li>
<li>To import the certificate, choose <strong>Import</strong>.<br><blockquote>
<p><strong>Note</strong>: It might take a few minutes for ACM to process the import request and show the certificate in the list. If the certificate doesn’t immediately appear, choose the refresh icon. Additionally, the Certificate Authority used to create the certificate you import to ACM can be public or private.</p>
</blockquote> </li>
<li>Review the imported certificate and do the following:
<ol>
<li>Note the <strong>Certificate ID</strong>. You will need this ID later when you assign the certificate to the TLS configuration.</li>
<li>Make sure that the status shows <strong>Issued</strong>. After ACM issues the certificate, you can use it in the TLS configuration.<br>
<div id="attachment_33712" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33712" src="https://infracom.com.sg/wp-content/uploads/2024/04/img4-1.jpg" alt="Figure 4: Verify the certificate was issued in ACM" width="700" class="size-full wp-image-33712">
<p id="caption-attachment-33712" class="wp-caption-text">Figure 4: Verify the certificate was issued in ACM</p>
</div> </li>
</ol> </li>
</ol>
<h3>Create a TLS inspection configuration</h3>
<p>The next step is to create a TLS inspection configuration. You will do this in two parts. First, you will create a rule group to define the stateful inspection criteria. Then you will create the TLS inspection configuration where you define what traffic you should decrypt for inspection and how you should handle revoked and expired certificates.</p>
<h4>To create a rule group</h4>
<ol>
<li>Navigate to <strong>VPC > Network Firewall rule groups</strong>.</li>
<li>Choose <strong>Create rule group</strong>.</li>
<li>On the <strong>Choose rule group type </strong>page, do the following:
<ol>
<li>For <strong>Rule group type</strong>, select <strong>Stateful rule group</strong>. In this example, the stateless rule group that has already been created is being used.</li>
<li>For <strong>Rule group format</strong>, select <strong>Suricata compatible rule string</strong>.<br><blockquote>
<p><strong>Note</strong>: To learn how Suricata rules work and how to write them, see <a href="https://aws.amazon.com/blogs/opensource/scaling-threat-prevention-on-aws-with-suricata/" target="_blank" rel="noopener">Scaling threat prevention on AWS with Suricata</a></p>
</blockquote> </li>
<li>Leave the other values as default and choose <strong>Next.</strong></li>
</ol> </li>
<li>On the <strong>Describe rule group </strong>page, enter a name, description, and capacity for your rule group, and then choose <strong>Next</strong>.<br><blockquote>
<p><strong>Note</strong>: The capacity is the number of rules that you expect to have in this rule group. In our example, I set the value to 10, which is appropriate for a demo environment. Production environments require additional thought to the capacity before you create the rule group.</p>
</blockquote> </li>
<li>On the <strong>Configure rules</strong> page, in the <strong>Suricata compatible rule string </strong>section, enter your Suricata compatible rules line-by-line, and then choose <strong>Next</strong>.<br><blockquote>
<p><strong>Note</strong>: I don’t provide recommendations for specific rules in this post. You should take care in crafting rules that meet the requirements for your organization. For more information, see <a href="https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-best-practices.html" target="_blank" rel="noopener">Best practices for writing Suricata compatible rules for AWS Network Firewall</a>.</p>
</blockquote> </li>
<li>On the <strong>Configure advanced settings – optional</strong> page, choose <strong>Next</strong>. You won’t use these settings in this walkthrough.</li>
<li>Add relevant tags by providing a key and a value for your tag, and then choose <strong>Next</strong>.</li>
<li>On the <strong>Review and create</strong> page, review your rule group and then choose <strong>Create rule group</strong>.</li>
</ol>
<h4>To create the TLS inspection configuration</h4>
<ol>
<li>Navigate to <strong>VPC > Network Firewall > TLS inspection configurations</strong>.</li>
<li>Choose <strong>Create TLS inspection configuration</strong>.</li>
<li>In the <strong>CA certificate for outbound SSL/TLS inspection – new</strong> section, from the dropdown menu, choose the certificate that you imported from ACM previously, and then choose <strong>Next</strong>.<br>
<div id="attachment_33715" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33715" src="https://infracom.com.sg/wp-content/uploads/2024/04/img5-1.jpg" alt="Figure 5: Select the certificate for use with outbound SSL/TLS inspection" width="740" class="size-full wp-image-33715">
<p id="caption-attachment-33715" class="wp-caption-text">Figure 5: Select the certificate for use with outbound SSL/TLS inspection</p>
</div> </li>
<li>On the <strong>Describe TLS inspection configuration </strong>page, enter a name and description for the configuration, and then choose <strong>Next</strong>.</li>
<li>Define the scope—the traffic to include in decryption. For this walkthrough, you decrypt traffic that is on port 443. On the <strong>Define scope</strong> page, do the following:
<ol>
<li>For the <strong>Destination port range</strong>, in the dropdown, select <strong>Custom</strong> and then in the box, enter your port (in this example, <span>443</span>). This is shown in Figure 6.<br>
<div id="attachment_33716" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33716" src="https://infracom.com.sg/wp-content/uploads/2024/04/img6-1.jpg" alt="Figure 6: Specify a custom destination port in the TLS scope configuration" width="700" class="size-full wp-image-33716">
<p id="caption-attachment-33716" class="wp-caption-text">Figure 6: Specify a custom destination port in the TLS scope configuration</p>
</div> </li>
<li>Choose <strong>Add scope configuration </strong>to add the scope configuration. This allows you to add multiple scopes. In this example, you have defined a scope indicating that the following traffic should be decrypted:<br><table width="100%">
<tbody>
<tr>
<td width="25%">Source IP</td>
<td width="25%">Source Port</td>
<td width="25%">Destination IP</td>
<td width="25%">Destination Port</td>
</tr>
<tr>
<td width="25%">Any</td>
<td width="25%">Any</td>
<td width="25%">Any</td>
<td width="25%">443</td>
</tr>
</tbody>
</table> </li>
<li>In the <strong>Scope configuration</strong> section, verify that the scope is listed, as seen in Figure 7, and then choose <strong>Next</strong>.<br>
<div id="attachment_33717" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33717" src="https://infracom.com.sg/wp-content/uploads/2024/04/img7-1.jpg" alt="Figure 7: Add the scope configuration to the SSL/TLS inspection policy" width="700" class="size-full wp-image-33717">
<p id="caption-attachment-33717" class="wp-caption-text">Figure 7: Add the scope configuration to the SSL/TLS inspection policy</p>
</div> </li>
</ol> </li>
<li>On the <strong>Advanced settings </strong>page, do the following to determine how to handle certificate revocation:
<ol>
<li>For <strong>Check certificate revocation status</strong>, select <strong>Enable</strong>.</li>
<li>In the <strong>Revoked – Action</strong> dropdown, select an action for revoked certificates. Your options are to <strong>Drop</strong>, <strong>Reject</strong>, or <strong>Pass</strong>. A drop occurs silently. A reject causes a TCP reset to be sent, indicating that the connection was dropped. Selecting pass allows the connection to establish.</li>
<li>In the <strong>Unknown status – Action</strong> section, select an action for certificates that have an unknown status. The same three options that are available for revoked certificates are also available for certificates with an unknown status.</li>
<li>Choose <strong>Next.</strong></li>
</ol>
<blockquote>
<p><strong>Note</strong>: The recommended best practice is to set the action to <strong>Reject</strong> for both revoked and unknown status. Later in this walkthrough, you will set these values to <strong>Drop</strong> and <strong>Allow</strong> to illustrate the behavior during testing. After testing, you should set both values to <strong>Reject</strong>.</p>
</blockquote> </li>
<li>Add relevant tags by providing a key and value for your tag, and then choose <strong>Next</strong>.</li>
<li>Review the configuration, and then choose <strong>Create TLS inspection configuration</strong>.</li>
</ol>
<h3>Add the configuration to a Network Firewall policy</h3>
<p>The next step is to add your TLS inspection configuration to your firewall policy. This policy dictates how Network Firewall handles and applies the rules for your outbound traffic. As part of this configuration, your TLS inspection configuration defines what traffic is decrypted prior to inspection.</p>
<h4>To add the configuration to a Network Firewall policy</h4>
<ol>
<li>Navigate to <strong>VPC > Network Firewall > Firewall policies</strong>.</li>
<li>Choose <strong>Create firewall policy</strong>.</li>
<li>In the <strong>Firewall policy details</strong> section, seen in Figure 8, enter a name and description, select a stream exception option for the policy, and then choose <strong>Next</strong>.
<div id="attachment_33718" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33718" src="https://infracom.com.sg/wp-content/uploads/2024/04/img8.png" alt="Figure 8: Define the firewall policy details" width="740" class="size-full wp-image-33718">
<p id="caption-attachment-33718" class="wp-caption-text">Figure 8: Define the firewall policy details</p>
</div> </li>
<li>To attach a stateless rule group to the policy, choose <strong>Add stateless rule groups</strong>.</li>
<li>Select an existing policy, seen in Figure 9, and then choose <strong>Add rule groups</strong>.<br>
<div id="attachment_33719" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33719" src="https://infracom.com.sg/wp-content/uploads/2024/04/img9-1.jpg" alt="Figure 9: Select a stateless policy from an existing rule group" width="740" class="size-full wp-image-33719">
<p id="caption-attachment-33719" class="wp-caption-text">Figure 9: Select a stateless policy from an existing rule group</p>
</div> </li>
<li>In the <strong>Stateful rule group </strong>section, choose <strong>Add stateful rule groups</strong>.</li>
<li>Select the newly created TLS inspection rule group, and then choose <strong>Add rule group</strong>.</li>
<li>On the <strong>Add rule groups</strong> page, choose <strong>Next</strong>.</li>
<li>On the <strong>Configure advanced settings – <em>optional</em></strong> page, choose <strong>Next</strong>. For this walkthrough, you will leave these settings at their default values.</li>
<li>On the <strong>Add TLS inspection configuration – <em>optional</em></strong> section, seen in Figure 10, do the following:
<ol>
<li>Choose <strong>Add TLS inspection configuration</strong>.</li>
<li>From the dropdown, select your TLS inspection configuration.</li>
<li>Choose <strong>Next</strong>.<br>
<div id="attachment_33720" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33720" src="https://infracom.com.sg/wp-content/uploads/2024/04/img10-1.jpg" alt="Figure 10: Add the TLS configuration to the firewall policy" width="700" class="size-full wp-image-33720">
<p id="caption-attachment-33720" class="wp-caption-text">Figure 10: Add the TLS configuration to the firewall policy</p>
</div> </li>
</ol> </li>
<li>Add relevant tags by providing a key and a value, and then choose <strong>Next</strong>.</li>
<li>Review the policy configuration, and choose <strong>Create firewall policy</strong>.</li>
</ol>
<h3>Associate the policy with your firewall</h3>
<p>The final step is to associate this firewall policy, which includes your TLS inspection configuration, with your firewall. This association activates the egress TLS inspection, enforcing your defined rules and criteria on outbound traffic. When the policy is associated, packets from the existing stateful connections that match the TLS scope definition are immediately routed to the decryption engine where they are dropped. This occurs because decryption and encryption can only work for a connection when Network Firewall receives TCP and TLS handshake packets from the start.</p>
<p>Currently, you have an existing policy applied. Let’s briefly review the policy that exists and see how TLS traffic looks prior to applying your configuration. Then you will apply the TLS configuration and look at the difference.</p>
<h4>To review the existing policy that doesn’t have TLS configuration</h4>
<ol>
<li>Navigate to <strong>VPC > Network Firewall > Firewalls</strong></li>
<li>Choose the existing firewall, as seen in Figure 11.<br>
<div id="attachment_33721" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33721" src="https://infracom.com.sg/wp-content/uploads/2024/04/img11-1.jpg" alt="Figure 11: Select the firewall to edit the policy" width="740" class="size-full wp-image-33721">
<p id="caption-attachment-33721" class="wp-caption-text">Figure 11: Select the firewall to edit the policy</p>
</div> </li>
<li>In the <strong>Firewall Policy</strong> section, make sure that your firewall policy is displayed. As shown in the example in Figure 12, the firewall policy <strong>DemoFirewallPolicy</strong> is applied—this policy doesn’t perform TLS inspection.<br>
<div id="attachment_33722" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33722" src="https://infracom.com.sg/wp-content/uploads/2024/04/img12.jpg" alt="Figure 12: Identify the existing firewall policy associated with the firewall" width="740" class="size-full wp-image-33722">
<p id="caption-attachment-33722" class="wp-caption-text">Figure 12: Identify the existing firewall policy associated with the firewall</p>
</div> </li>
<li>From a test EC2 instance, navigate to an external site that requires TLS encryption. In this example, I use the site example.com. Examine the certificate that was issued. In this example, an external organization issued the certificate (it’s <strong><em>not</em></strong> the certificate that I imported into ACM). You can see this in Figure 13.<br>
<div id="attachment_33723" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33723" loading="lazy" src="https://infracom.com.sg/wp-content/uploads/2024/04/img13.png" alt="Figure 13: View of the certificate before TLS inspection is applied" width="402" height="484" class="size-full wp-image-33723">
<p id="caption-attachment-33723" class="wp-caption-text">Figure 13: View of the certificate before TLS inspection is applied</p>
</div> </li>
</ol>
<p>Returning to the firewall configuration, change the policy to the one that you created with TLS inspection.</p>
<h4>To change to the policy with TLS inspection</h4>
<ol>
<li>In the <strong>Firewall Policy</strong> section, choose <strong>Edit</strong>.</li>
<li>In the <strong>Edit firewall policy </strong>section, select the TLS Inspection policy, and then choose <strong>Save changes.</strong><br><blockquote>
<p><strong>Note</strong>: It might take a moment for Network Firewall to update the firewall configuration.</p>
</blockquote>
<div id="attachment_33724" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33724" src="https://infracom.com.sg/wp-content/uploads/2024/04/img14.jpg" alt="Figure 14: Modify the policy applied to the firewall" width="740" class="size-full wp-image-33724">
<p id="caption-attachment-33724" class="wp-caption-text">Figure 14: Modify the policy applied to the firewall</p>
</div> </li>
<li>Return to the test EC2 instance and test the site again. Notice that your customer certificate authority (CA) has issued the certificate. This indicates that the configuration is working as expected and you can see this in Figure 15.<br><blockquote>
<p><strong>Note</strong>: The test EC2 instance must trust the certificate that Network Firewall presents. The method to install the CA certificate on your host devices will vary based on the operating system. For this walkthrough, I installed the CA certificate before testing.</p>
</blockquote>
<div id="attachment_33725" class="wp-caption aligncenter">
<img aria-describedby="caption-attachment-33725" loading="lazy" src="https://infracom.com.sg/wp-content/uploads/2024/04/img15.jpg" alt="Figure 15: Verify the new certificate used by Network Firewall TLS inspection is seen" width="400" height="491" class="size-full wp-image-33725">
<p id="caption-attachment-33725" class="wp-caption-text">Figure 15: Verify the new certificate used by Network Firewall TLS inspection is seen</p>
</div> </li>
</ol>
<p>Another test that you can do is revoked certificate handling. Example.com provides URLs to sites with revoked or expired certificates that you can use to test.</p>
<h4>To test revoked certificate handling</h4>
<ol>
<li>From the command line interface (CLI) of the EC2 instance, do a curl on this page.<br><blockquote>
<p><strong>Note</strong>: The <span>curl -ikv</span> command combines three options:</p>
<ul>
<li><span>-i</span> includes the HTTP response headers in the output</li>
<li><span>-k</span> allows connections to SSL sites without certificates being validated</li>
<li><span>-v</span> enables verbose mode, which displays detailed information about the request and response, including the full HTTP conversation. This is useful for debugging HTTPS connections.</li>
</ul>
</blockquote>
<div class="hide-language">
<pre class="unlimited-height-code"><code>sh-4.2$ curl -ikv https://revoked-rsa-dv.example.com/ example.com?_gl=1*guvyqo*_gcl_au*MTczMzQyNzU3OC4xNzA4NTQ5OTgw</code></pre>
</div> </li>
<li>At the bottom of the output, notice that the TLS connection was closed. This is what it looks like when the Revoked – Action is set to <strong>Drop</strong>.
<div class="hide-language">
<pre class="unlimited-height-code"><code class="lang-text">* Trying 203.0.113.10:443...
- Connected to revoked-rsa-dv.example.com (203.0.113.10) port 443
- ALPN: curl offers h2,http/1.1
- Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
- TLSv1.2 (OUT), TLS handshake, Client hello (1):
- TLSv1.2 (IN), TLS handshake, Server hello (2):
- TLSv1.2 (IN), TLS handshake, Certificate (11):
- TLSv1.2 (IN), TLS handshake, Server key exchange (12):
- TLSv1.2 (IN), TLS handshake, Server finished (14):
- TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
- TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
- TLSv1.2 (OUT), TLS handshake, Finished (20):
- TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
- TLSv1.2 (IN), TLS handshake, Finished (20):
- SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
- ALPN: server did not agree on a protocol. Uses default.
- Server certificate:
- subject: CN=revoked-rsa-dv.example.com
- start date: Feb 20 21:15:12 2024 GMT
- expire date: Feb 19 21:15:12 2025 GMT
- issuer: C=US; ST=VA; O=Custom Org; OU=Custom Unit; CN=Custom Intermediate CA; emailAddress=custom-dev@amazon.com
- SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
- using HTTP/1.x
GET /?_gl=1*guvyqo*_gcl_au*MTczMzQyNzU3OC4xNzA4NTQ5OTgw HTTP/1.1
Host: revoked-rsa-dv.example.com
User-Agent: curl/8.3.0
Accept: */*
- TLSv1.2 (IN), TLS alert, close notify (256):
- Empty reply from server
* Closing connection
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (52) Empty reply from server
sh-4.2$- Modify your TLS inspection configuration to Reject instead:
- Navigate to VPC > Network Firewall > TLS inspection configuration, select the policy, and choose Edit.
- In the Revoked – Action section, select Reject.
- Choose Save.
- Test the curl again.
- The output should show that an error 104, Connection reset by peer, was sent.
- Connected to revoked-rsa-dv.example.com (203.0.113.10) port 443
- ALPN: curl offers h2,http/1.1
- Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
- TLSv1.2 (OUT), TLS handshake, Client hello (1):
- TLSv1.2 (IN), TLS handshake, Server hello (2):
- TLSv1.2 (IN), TLS handshake, Certificate (11):
- TLSv1.2 (IN), TLS handshake, Server key exchange (12):
- TLSv1.2 (IN), TLS handshake, Server finished (14):
- TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
- TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
- TLSv1.2 (OUT), TLS handshake, Finished (20):
- TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
- TLSv1.2 (IN), TLS handshake, Finished (20):
- SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
- ALPN: server did not agree on a protocol. Uses default.
- Server certificate:
- subject: CN=revoked-rsa-dv.example.com
- start date: Feb 20 21:17:23 2024 GMT
- expire date: Feb 19 21:17:23 2025 GMT
- issuer: C=US; ST=VA; O=Custom Org; OU=Custom Unit; CN=Custom Intermediate CA; emailAddress=custom-dev@amazon.com
- SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
using HTTP/1.x
GET /?_gl=1*guvyqo*_gcl_au*MTczMzQyNzU3OC4xNzA4NTQ5OTgw HTTP/1.1
Host: revoked-rsa-dv.example.com
User-Agent: curl/8.3.0
Accept: */*Recv failure: Connection reset by peer
- OpenSSL SSL_read: Connection reset by peer, errno 104
- Closing connection
- Send failure: Broken pipe
curl: (56) Recv failure: Connection reset by peer
sh-4.2$As you configure egress TLS inspection, consider the specific types of traffic and the security requirements of your organization. By tailoring your configuration to these needs, you can help make your network’s security more robust, without adversely affecting performance.
Performance and security considerations for egress TLS inspection
Implementing egress TLS inspection in Network Firewall is an important step in securing your network, but it’s equally important to understand its impact on performance and security. Here are some key considerations:
- Balance security and performance – Egress TLS inspection provides enhanced security by allowing you to monitor and control outbound encrypted traffic, but it can introduce additional processing overhead. It’s essential to balance the depth of inspection with the performance requirements of your network. Efficient rule configuration can help minimize performance impacts while still achieving the desired level of security.
- Optimize rule sets – The effectiveness of egress TLS inspection largely depends on the rule sets that you configure. It’s important to optimize these rules to target specific security concerns relevant to your outbound traffic. Overly broad or complex rules can lead to unnecessary processing, which might affect network throughput.
- Use monitoring and logging – Regular monitoring and logging are vital for maintaining the effectiveness of egress TLS inspection. They help in identifying potential security threats and also provide insights into the impact of TLS inspection on network performance. AWS provides tools and services that you can use to monitor the performance and security of your network firewall.
Considering these factors will help ensure that your use of egress TLS inspection strengthens your network’s security posture and aligns with your organization’s performance needs.
Best practices and recommendations for egress TLS inspection
Implementing egress TLS inspection requires a thoughtful approach. Here are some best practices and recommendations to help you make the most of this feature in Network Firewall:
- Prioritize traffic for inspection – You might not need the same level of scrutiny for all your outbound traffic. Prioritize traffic based on sensitivity and risk. For example, traffic to known, trusted destinations might not need as stringent inspection as traffic to unknown or less secure sites.
- Use managed rule groups wisely – AWS provides managed rule groups and regularly updates them to address emerging threats. You can use AWS managed rules with TLS decryption; however, the TLS keywords will no longer invoke for traffic that has been decrypted by the firewall, within the stateful inspection engine. You can still benefit from the non-TLS rules within managed rule groups, and gain increased visibility into those rules because the decrypted traffic is visible to the inspection engine. You can also create your own custom rules against the inner protocols that are now available for inspection—for example, matching against an HTTP header within the decrypted HTTPS stream. You can use managed rules to complement your custom rules, contributing to a robust and up-to-date security posture.
- Regularly update custom rules – Keep your custom rule sets aligned with the evolving security landscape. Regularly review and update these rules to make sure that they address new threats and do not inadvertently block legitimate traffic.
- Test configuration changes – Before you apply new rules or configurations in a production environment, test them in a controlled setting. This practice can help you identify potential issues that could impact network performance or security.
- Monitor and analyze traffic patterns – Regular monitoring of outbound traffic patterns can provide valuable insights. Use AWS tools to analyze traffic logs, which can help you fine-tune your TLS inspection settings and rules for optimal performance and security.
- Plan for scalability – As your network grows, make sure that your TLS inspection setup can scale accordingly. Consider the impact of increased traffic on performance and adjust your configurations to maintain efficiency.
- Train your team – Make sure that your network and security teams are well informed about the TLS inspection process, including its benefits and implications. A well-informed team can better manage and respond to security events.
By following these best practices, you can implement egress TLS inspection in your AWS environment, helping to enhance your network’s security while maintaining performance.
Conclusion
Egress TLS inspection is a critical capability for securing your network by providing increased visibility and control over encrypted outbound traffic. In this post, you learned about the key concepts, configuration steps, performance considerations, and best practices for implementing egress TLS inspection with Network Firewall. By decrypting, inspecting, and re-encrypting selected outbound traffic, you can identify hidden threats and enforce security policies without compromising network efficiency.
To learn more about improving visibility in your network with egress TLS inspection, see the AWS Network Firewall developer guide for additional technical details, review AWS security best practices for deploying Network Firewall, and join the AWS Network Firewall community to connect with other users.
If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, contact AWS Support.
<!-- '"` -->