Home > Security and SD-WAN > Content Filtering and Threat Protection > HTTPS Inspection

HTTPS Inspection

Overview

This document aims to describe the configuration and behavior of the HTTPS inspection feature for MX devices. This feature enhances Advanced Security features by enabling them to inspect and act on HTTPS traffic. To learn more about Advanced Security features on the MX, check out our articles on Advanced Malware Protection (AMP), Intrusion Detection and Prevention (IDS and IPS), and Content Filtering.

Use Case

HTTPS inspection is ideal for use in networks with corporate-owned devices where end users are aware that their encrypted HTTPS traffic is inspected for the purpose of maintaining security.

Prerequisites

  • An MX Advanced Security license. HTTPS Inspection configuration options are not displayed in the dashboard unless an Advanced Security license is applied to the organization.

  • HTTPS inspection is supported on MX 15.15 firmware and newer. Once upgraded, contact Cisco Meraki Support to have this feature enabled.

  • A signed certificate from a Certificate Authority (CA) of your choice pushed to all clients affected by HTTPS inspection. Certificate distribution may come in the form of Active Directory, Meraki Systems Manager (SM), and others. To learn how to push certificates to clients with SM, see our article on Credentials Payload (Pushing Certificates).

How it Works, Traffic Flow and Caveats

Certificate Distribution

HTTPS inspection requires a certificate in order to decrypt and inspect client traffic. Contact a certificate authority of your choice for more information on obtaining a signed certificate. During configuration, the unencrypted certificate and private key are uploaded to the dashboard by an administrator. The certificate and private key are then securely distributed to each MX in the organization, regardless of whether it is running HTTPS inspection.

Traffic Flow

Without HTTPS inspection, a client typically establishes a secure connection directly to the intended server. With HTTPS inspection enabled, the security appliance looks for requests from clients to establish an HTTPS connection on TCP port 443. When a request is seen, the security appliance responds to the client’s request on behalf of the server and establishes an HTTPS session directly to the client. While this is happening, the security appliance also establishes an HTTPS session with the client’s intended server.

 

When the security appliance has secure connections to the client and server, traffic between the client and server can be intercepted by the MX, decrypted and inspected with Advanced Security features for signs of malicious activity.

HTTPS Inspection Traffic Flow 2.png

Caveats and Considerations

Keeping Track of Certificates

No changelog entry will be created when uploading the private key and certificate to the dashboard. Further, the uploaded certificate will not remain visible on the Organization > Settings page. A dashboard administrator must keep the certificate and keys safe for their own records.

 

TLS Support

HTTPS inspection on the security appliance relies on TLS 1.2. Changes to how keys are handled in TLS 1.3 mean that services that only allow TLS 1.3 will not work properly. Layer 3 and 7 whitelist rules should be used to disable HTTPS inspection in such circumstances.

 

Pinned Certificates

Some applications may be configured to expect specific certificates (pinned certificates) from their servers. The security appliance only presents clients with the signed certificate uploaded from the dashboard. As a result, some mobile apps may not establish HTTPS connectivity despite proper HTTPS inspection configuration. Layer 3 and 7 whitelist rules should be used to disable HTTPS inspection in such circumstances as well.

 

Throughput

The additional overhead of decrypting and inspecting client traffic significantly reduces the security appliance’s throughput capabilities. A reduction of 85-90% vs stateful firewall throughput spec may be seen. For example, an MX250 capable of 4 Gbps stateful firewall throughput may achieve 600 Mbps with HTTPS inspection enabled.

Configuration

  1. Upload a signed certificate to dashboard

    1. Ensure the MX is online.
    2. Navigate to the Organization > Settings page
    3. In the HTTPS Inspection section, select Choose certificate and upload the certificate from your computer to dashboard. Please make sure the certificate is in .pem format and contains the private key followed by the certificate.

image2.png

 

Confirmation is displayed when the certificate has been successfully uploaded.

image6.png

  1. Enable HTTPS inspection

Note: Enabling or disabling HTTPS inspection for a policy or network terminates all affected, existing HTTPS flows.

  1. Group Policy Method: Enable HTTPS inspection on select clients by using group policies.
    1. Find your existing group policy or create a new one on the Network-wide > Group policies page. Check out our article on Creating and Applying Group Policies for more details on setting up group policies and applying them to clients.
    2. Select Enable from the dropdown menu next to HTTPS inspection.

image1.png

  1. Network-wide Method: Enable HTTPS inspection for all clients in the network.
    1. Navigate to the Security & SD-WAN > Threat Protection page.

    2. Set Inspect all traffic by default to Enabled

image4.png

  1. Configure Layer 3 and 7 whitelist options

    1. Navigate to the Security & SD-WAN > Threat Protection page.

    2. L3 whitelist: Specify source IPs of clients that should be exempt from HTTPS inspection. 
    3. L7 whitelist: Specify destination hostnames that should be exempt from HTTPS inspection. Use wild cards by prefixing the hostname entry with an asterisk. For example, *.example.com will match www.example.com.  

Note: The L3 and L7 whitelist configurations apply to all clients affected by HTTPS inspection, including those with inspection applied via group policy.

 

https-inspection-whitelist-options.png

Verifying HTTPS Inspection is Working

Verifying that Advanced Security features are working on HTTPS traffic requires intentionally generating traffic that will be identified as malicious. The European Institute for Computer Anti-Virus Research (EICAR) hosts sample file downloads designed to trigger malware detection systems. To read more about these test files and find their download links, check out the EICAR website.

 

Attempting to download the HTTPS ‘eicar.com’ file on a client affected by a security appliance group policy with HTTPS inspection enabled serves as a test that Advanced Security features are properly inspecting HTTPS. Please note that Advanced Malware Protection (AMP) must be enabled in order for these test files to be detected.

 

Detected threats and the actions taken by the security appliance can be monitored on the Security & SD-WAN > Security center page. To learn more about the security center, check out our Security Center article to learn more about monitoring threats.

Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 8310

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community