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.
IMPORTANT: HTTPS inspection is still in development and in beta. This feature is in testing and not recommended for production networks. It might end up breaking certain existing features and impact network traffic adversely. Please refrain from utilizing this as a production solution.
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.
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
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.
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.
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.
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.
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.
The additional overhead of decrypting and inspecting client traffic significantly reduces the security appliance’s throughput capabilities. The performance degrades only applies to inspected traffic.
Upload a signed certificate to dashboard
- Ensure the MX is online.
- Navigate to the Organization > Settings page
- In the HTTPS Inspection section, check the appropriate MX device and click Browse and upload certificate to 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.
To confirm that the certificate has been successfully uploaded, refresh the page. Device with certificates count will increase and Device without certificates count will decrease.
Enable HTTPS inspection
Note: Enabling or disabling HTTPS inspection for a policy or network terminates all affected, existing HTTPS flows.
- Group Policy Method: Enable HTTPS inspection on select clients by using group policies.
- 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.
Select Enable from the dropdown menu next to HTTPS inspection.
- Network-wide Method: Enable HTTPS inspection for all clients in the network.
Navigate to the Security & SD-WAN > Threat Protection page.
Set Inspect all traffic by default to Enabled
Configure Layer 3 and 7 whitelist options
Navigate to the Security & SD-WAN > Threat Protection page.
- L3 whitelist: Specify source IPs of clients that should be exempt from HTTPS inspection.
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.
Alerts and Events
You can enable alerts in Network-wide > Alerts page > HTTPS Inspection certificate error occurs. If a factory reset is performed, then an event is triggered until a certificate is uploaded. You will also see these events in the Network-wide > Event log > filter “HTTPS Inspection certificate error”.
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.