| # |
Question |
Answer |
| 1 |
Can these settings (Advanced Settings) configured per Gateway/Policy Package or are these global settings? |
Some features can be overridden per Gateway via the Gateway Editor, such as client-side fail-mode and server-side fail-mode.
Certain features are global settings only, such as HTTPS Inspection session logs, certificate-pinned applications, and well-known update services.
Additionally, "Bypass under load" and "Learning Mode" are features that can be configured on a per-Gateway basis only. |
| 2 |
Can I control how often the trusted certificates will be updated? |
By default, the package automatically checks for updates every 24 hours. When a new package is uploaded by Check Point to the Download Center, it is automatically downloaded to the Security Management. The administrator must then install the policy to update the package on the Security Gateway. |
| 3 |
Can trusted CA package be automatically downloaded by gateways? |
No. By design, Trusted Certificates are managed by the administrator in the Security Management Console.
By default, the package automatically checks for updates every 24 hours. When a new package is uploaded to the Download Center, it is automatically downloaded to the Security Management. The administrator must then install the policy to update the package on the Security Gateway. |
| 4 |
How do we assign these outbound certificates? Per Rule/Policy Package? |
One outbound certificate can be configured as the default and used by all security gateways or clusters.
A different certificate can then be imported or created to override the global outbound certificate for a specific gateway. |
| 5 |
How about SNI support for inbound certificates. Is there a possibility? |
Yes |
| 6 |
For Incoming SSL Inspection , Can we use wildcard certificate to multiple servers ? |
Yes |
| 7 |
Do the inspection statistics require SmartEvent or the Monitoring blade? |
SmartEvent |
| 8 |
Where you see TLS version used ? |
In R82 version, we added to the 'inspect' log the TLS version and Cipher Suite that used in the TLS handshake of both sides: Client to Gateway and Gateway to Server. |
| 9 |
if we enable this session log feature, what is the impact to log size? |
Following performance tests conducted with and without session logs, we observed nearly zero impact of session logs in terms of CPU usage, disk space, and memory consumption of the fwd process. |
| 10 |
If our gateway's CPU usage reaches 90% while running cpsizeme for 48 hours with HTTPS inspection disabled, should we consider replacing it with a gateway that has double or more CPU capacity? Should Learning Mode be compatible with our gateway? |
Learning Mode is not intended to replace sizing. If the appliance is not suitable from the start, Learning Mode will likely indicate this and provide recommendations to address sizing issues before fully enabling inspection. |
| 11 |
To run TLS learning mode, must be the Mgmt AND Gateway running R82 or will it be fine, if only Mgmt is running R82 |
Both MGMT and GW with R82. |
| 12 |
Will there be any limitation in the SSL/TLS inspection in respect to VSX and virtual gateways ? |
No. |
| 13 |
Will learning mode also be able to use AI to recommend a and HTTPS Inspection policy tailored for my environment? |
No. Learning Mode does not modify the HTTPS Inspection policy in any way. |
| 14 |
Regarding the "learning mode": where is the evaluation of the traffic run? Locally on the gateway, as part of ThreatCloud or on a dedicated Infinity service?
Is there any requirement which the gateway has to fulfill to be able to use "learning mode"? |
Locally on the gateway. HTTPS Inspection must be enabled. Maestro/SP is not supported. |
| 15 |
Are there cpu measurements/statistics when full tls inspection is enabled? |
Various statistics are always gathered for HTTPS Inspection and shown in cpview. CPU usage prediction for full inspection is gathered only when Learning Mode is enabled. General CPU usage statistics, unrelated to HTTPS Inspection, can be found in cpview. |
| 16 |
Can you go back from full inspection to learning? |
Yes, but unless the feature's history is cleared, Learning Mode will resume its last state when re-enabled. |
| 17 |
Is there a minimum predicted success rate that we should be looking for before going to full inspection? |
The feature's current default is 80% success rate. In any case, a recommendation is provided based on the feature's heuristics. |
| 18 |
Can you define enabled and disabled tls versions for inbound https inspection? |
Our approach to HTTPS Inspection is to inspect as much traffic as possible. TLS versions can be blocked through protocol detection in the access policy, allowing inbound servers to have blocked rules within the access policy. |
| 19 |
How this learning mode - Deployment can help us to guide with building httpsi policy or issues with particular clients? |
Learning Mode does not deal with specific HTTPS Inspection policy issues. Certificate-pinned application packages and client-side fail-open would significantly help with client-side issues. We are continuously working on log improvements in SmartConsole to ensure clear visibility for any issue. |
| 20 |
Why HTTPS inspection is necessary; it's just to assess how much flow there is and whether there's anything else that can be gained from it. However, I also wanted to know if already https connection is secure from SSL why is this need still? |
TLS/SSL allows for a secure connection between the client and the server, but it doesn't prevent data leaks or malicious content to pass through the connection. |
| 21 |
Can you discover a bad actor using certificate pining? Does using option not represent a potential security risk? |
There is no full guarantee, similar to server-side fail-open, where a malicious server can trigger fail-open in multiple ways. For maximum security, both of these features should be disabled. However, to ensure high connectivity and usability, these features can be useful. |
| 22 |
Can we use more than one outbound certificate at the same SG. For example to do ssl inspection based on source (network, access role e.t.c.) with different certs? |
No. One outbound certificate per GW. |
| 23 |
Does this "bypass" for pinned application need to learn this per client. Or does it now bypass this (destination) for all clients instantly |
typically bypasses will be given to specific clients only, but after many clients experience the same issue, these bypasses can become global to all clients. |
| 24 |
Will we still need bypass rules or is the client failure "stored" for the application? What would be the (performance) impact, if we just configure for fail-open instead of crafting bypass rules for that applications? |
yes, its recommended to take action for each bypassed connection by the client side fail-open, either to add a rule to bypass that resource, or to block it by access policy if its unwanted |
| 25 |
How long are these decisions regarding client side issues being bypassed automatically because of failures remembered by the Gateway? |
it can range from few minutes up to a whole day depending on the frequency of the failure |
| 26 |
How the bypass decision is taken by the HTTP inspection? |
We bypass for a few reasons with HTTPS Inspection. Policy Bypass: This matches several rules as 'possible matches' based on source and destination IP addresses. We later determine the final match after categorization and verifying the SNI. If the matched rule indicates a bypass, we bypass it. Pre-Policy Bypass Features: We have features that bypass before policy matching, such as pinned application packages and bypassing well-known update services. Bypass Under Load: This feature bypasses regardless of policy matching when high load is detected. |
| 27 |
Would each user need to have failed connections to an application before the bypass starts working, or is it enough that one user has a failed connection before it starts bypassing failed applications globally for all users? |
typically bypasses will be given to specific clients only, but after many clients experience the same issue, these bypasses can become global to all clients. |
| 28 |
Can we generate a list of autonomous listed bypassed other via SmartConsole or by CLI? |
should be easily done by filtering logs to the relevant bypass reason, or by looking at the new HTTPS Inspection statistics view in Smart Event |
| 29 |
Does the firewall remembers the bypass for the same destinations? If there is a bypass created for a specific source/destination , would a new connection from a different source to the same destination also be affected by the previous "automatic" bypass? |
typically bypasses will be given to specific clients only, but after many clients experience the same issue, these bypasses can become global to all clients. |
| 30 |
Will the gateway learn the bypass for cert pinning specifically for this client or will it also use the learned information on other clients behind the same gateway? |
typically bypasses will be given to specific clients only, but after many clients experience the same issue, these bypasses can become global to all clients. |
| 31 |
Are these auto-bypass decisions being retained during upgrades? Do they survive a reboot? |
client side fail-open bypass do not survive upgrade or reboot, these live in memory and to a limited amount of time, while the bypasses from the certificate-pinned application allow-list should work regardless. |
| 32 |
Can you generate a report which URL's are automatically bypassed? |
should be easily done by filtering logs to the relevant bypass reason, or by looking at the new HTTPS Inspection statistics view in Smart Event |
| 33 |
What prevents malicious connection being bypassed due to previous client errors or something? |
There is no full guarantee, similar to server-side fail-open, where a malicious server can trigger fail-open in multiple ways. For maximum security, both of these features should be disabled. However, to ensure high connectivity and usability, these features can be useful. |
| 34 |
Today, we block all QUIC traffic. Is this the best approach for our security, or is there a way to allow QUIC traffic while maintaining security? |
No, QUIC traffic is encrypted and the only way to allow it while maintaining security is by inspecting it. |
| 35 |
How would we clear incorrectly as pinned flagged applications? |
this should ideally not happen, but for client side fail open, tables can be cleared with httpsi_util CLI tool, and for the certificate-pinned allow-list, please report to CP. |
| 36 |
Is there a list of the Check Point predefined certificate pinning applications? Didn't see a link in the UI element |
currently there is no publicly available list, you can enable the feature in detect mode to see any applications in your network. |
| 37 |
After a connection is bypassed, will inspection be attempted on the next connection to that bypassed connection? |
depends on the timing and frequency of that connection, one some cases, yes, a third connection can be inspected, but in other cases, it might be bypassed too. |
| 38 |
Would you suggest relying on the certificate-pinning detection and set client-side to still block connections ? |
this should be ideally the case, but realistically this would work only when we manage to add more certificate-pinned applications to the allow-list. |
| 39 |
Is it in general recommended to always activate logging for all HTTPS Inspection rules? Or does this have a huge performance impact for example? |
Yes, it is recommended to enable logging for HTTPS Inspection rules. It won't significantly impact performance and will provide great visibility. |
| 40 |
Can we specify a specific application bypass and not only a category in R82? For instance, inspect Social Networking but don’t inspect Facebook. |
this can be done by having two rules, one for bypassing Facebook, and another one below it to inspect social networks. |
| 41 |
How is Client-side fail open decision made? |
works by remembering whenever a connection fails, and on the second attempt, the GW will detect that connection and bypass it to prevent the failure from happening again. |
| 42 |
The shown examples are for outbound HTTPSi for cert-binded applications. Does this also applies for inbound traffic as well (clients from public Internet try to access https web app which requires client user certificate auth)? |
no, client side fail-open shouldn't provide bypass to inbound connections. |
| 43 |
learning mode will use the httpsi policy ?
meaning can I adjust the HTTPSi so learning mode will be learning on the wanted rules? |
Apart from bypassing certain connections that are meant to be inspected, Learning Mode does not interfere with HTTPS Inspection's logic or policy. |
| 44 |
If you create a bypass in the rule base, can you differentiate between the cert pinned app or using the browser? |
in most cases no, it depends on APPI capabilities. |
| 45 |
If I block access to Netflix in the policy and allow access to the Dropbox, will the bypass for certificate-pinned applications still give access to Netflix? |
no, these features cannot modify access policy decisions, only the decision to inspect or bypass. |
| 46 |
Will this help monitor whatsup as an example? |
assuming whatsapp is a certificate-pinned application, our new features will allow whatsapp to work more seamlessly by bypassing it, inspection will not work. |
| 47 |
Is the updateable object "HTTPS services - bypass" still recommended in the https-policy, if this new r82-feature "well-known-pinned-cert-bypass" is enabled? |
as the well-known-pinned-cert-bypass
becomes better, the need for the updateable object would go down significantly. |
| 48 |
the HTTPS inspection advanced setting is "per policy or global" |
Global settings apply to all security gateways. Most configurations can be overridden for a specific gateway via the gateway editor. |
| 49 |
Is it possible to view the content of the Certificate-pinned applications? Similar to URL categorization lookup? |
currently not, you can enable "Detect" mode to see any matching application in your network, but there is no way for viewing all the contents |
| 50 |
The "load" that "bypass under load" is helping isn't necessarily caused by HTTP Inspection, correct? It can happen for many other reasons...? |
yes, any load on the fw cores would trigger the bypass. |
| 51 |
What is the suggested GW size to use https inspection, considering bypass under load could potentially cause issues. |
We need to size the gateway for HTTPS Inspection. Bypassing under load is disabled by default and does not cause any issues; it only bypasses when necessary. If the appliance size is insufficient for handling TLS inspection, it may lead to numerous issues due to high load. |
| 52 |
Is there a plan to use ssl decryption on a different container in the gateway resources, where we do need to use bypass under load feature. or maybe dynamic resource allocation, because not only SSL but also IPS is effected by this |
Nice idea! We will consider how to leverage resource management. |
| 53 |
Why Bypass under load configuration window is not same as same functionality at IPS? |
It is a product decision. we view the thresholds as an implementation detail. |
| 54 |
Do I need both gw and mgmt to R82 for the new nice logging and statistics? Or does mgmt is enough? |
both gw and mgmt. (session logs is required) |
| 55 |
With the Bypass under load are we looking for per core or do we take a the shared load of all core's? |
similar to IPS bypass, average of FW cores. |
| 56 |
What is the best way to determine what will be the impact on my gateway if i enable HTTPS inspection? |
to use Learning mode, and/or to enable full inspection with client side fail open, the certificate pinned application allow list, and bypass under load all enabled, and then disable them later based on your security policy |
| 57 |
Httpsi bypass for cpu is counting single cpu core or average? |
average on FW cores |
| 58 |
This seems to be the same principal as IPS bypass |
correct. |
| 59 |
Do you provide additional details on which traffic or connection raised the resources and put SSL into bypass? We need analysis on the reason of this also |
Load can be caused by many factors; we only measure the load and bypass it if connectivity is at risk. |
| 60 |
Can you give us same examples for "server side fail mode"? |
Examples of server-side fail modes include categorization issues, failed probe connections, or no matching cipher suite. |
| 61 |
In overload CPU and Memory mode when GW stops inspecting, traffic will be blocked and wait in queue? |
the goal of the bypass under load feature is to reduce load on the GW when a peak is detected, and to prevent packets to drop, if the GW reaches 100% memory or very high CPU rate even when entering bypass mode, packets will be dropped |
| 62 |
Are there plans to have new hardware architecture to offload https inspection? |
We are constantly looking for opportunities to enhance performance, including through hardware offload. Once such a case is chosen as a solution, we will publicly announce it. |
| 63 |
I was thinking our new HTTPSi will be more optimized (better performance) in R82 than before; I didn't see this message in the today's content, can you tell us more about this ? |
The performance of HTTPS Inspection was improved in R82.00. |
| 64 |
Is Maestro supported with HTTP/3 ? Or only Security Gateway / Cluster ? |
Yes, it is supported in all listed environments |
| 65 |
Client or network based, which kind of interception should be used in which case. Is there a white paper available? |
It is up to the administrator to decide based on the organization's needs. We support both options. |
| 66 |
So QUIC is mostly now for APPI/URLF enforcement but not yet full TP ? |
QUIC is supported for TP but not when Deep-Inspection is enabled (by default). If ZPH is not in use you can change configuration to make it work with Deep-Inspection |
| 67 |
In HTTPSi learning mode, is there a minimum predicted success rate that we should be aiming for before going to full inspection? |
The feature's current default is 80% success rate. In any case, a recommendation is provided based on the feature's heuristics. |
| 68 |
Any limitations regarding appliance or Open Server? |
No. |
| 69 |
Do we need to buy a different blade for this feature ? |
No. you need to buy Threat prevention blades. |
| 70 |
To clarify one point, HTTP/3 cannot be deep packet (so nor IPS, AV etc.) inspected in vanilla R82? That feature is planned for first R82 Jumbo? |
Deep-Inspection for HTTP/3 is planned to be in jumbo and not first one. Currently the only limitation is ZPH blade and if ZPH is not in use you can change configuration to make it work with Deep-Inspection. |
| 71 |
Can we downgrade QUIC also in lower version than R82 by blocking QUIC? |
Yes, browsers should initiates a new connection over HTTP/2 or HTTP/1 |
| 72 |
Can AI be used to size and report on performance with https enabled? |
We are constantly thinking about how to integrate AI into our new features, and we welcome any ideas 🙂 |
| 73 |
What is about SSL policy improvement regarding SSL inspection when the gateway acts as explicit proxy ? (as I know with R81.20, all traffic will come from the gateway. which means I can build the policy only with destination and not with source ip ... |
If you’re using the gateway as an explicit proxy, all outbound traffic will originate from the gateway. Not sure I understand the policy issue and this question might be better articulated on CheckMates. |
| 74 |
Should we consider something before upgrading to R82, when already using Https Inspection in production environment and with multiple rules bypass/inspect working? |
No, it is safe to upgrade without any additional preparation. |
| 75 |
Are TLS 1.3 flows inspected automatically or is there an additional config needed? |
Your gateway needs to be in USFW mode. See: https://support.checkpoint.com/results/sk/sk167052 |
| 76 |
Does this mean we can write a bypass based on server configuration (e.g. certificate pinning)? |
As shown here, it actually will detect these types of sites are encountered and automatically bypass. |
| 77 |
If your R81.20 environment is already running HTTPS inspection, can you still see the recommendations or statistics that you would see if you started in Learning mode? |
no, this is limited to R82 gateways. There's no use enabling Learning Mode on a system which is already running HTTPS Inspection properly. |
| 78 |
Do we have a FILE SIZE limit of a FULL HTTPS INSPECTION ? I know that in other Harmony products I have heard limitations of 10mb Files. If we do.. what is the largest file size it will scan? |
The limit is specifically for Threat Emulation functionality and isn’t related to HTTPS Inspection. 15mb is the default, but it can be increased. Pretty sure you can also do it on Harmony Endpoint as well (to 100MB). |
| 79 |
How exactly learning mode and inspect mode behave in production environment. I mean to say what if we enable https inspection for inbound and outbound whole network. |
In Learning Mode, even if you configure inspection for the entire inbound and outbound network, only some connections will actually be inspected. Full inspection of all connections occurs only when Full Inspection is enabled. |
| 80 |
What disruption should be expected in learning mode? Enabling learning mode inspects 30% of traffic, but if the traffic is live production, that would impact that communication correct? |
Learning Mode is meant to be used during feature deployment and is not intended to replace full HTTPS Inspection. Once the learning period is complete, a recommendation will be provided on how to fully enable the feature. Connections that are fully inspected during Learning Mode are inspected as if Full Inspection is enabled, but this applies only to certain connections, not all. |
| 81 |
Before enabling learning mode, should certificates be deployed on all internal endpoints or is this not required for learning mode...just full inspection mode? |
You still need to deploy CA certificates as before. It is recommended to enable Learning Mode after fulfilling all prerequisites for HTTPS Inspection, so that Learning Mode's recommendations are as accurate as possible. |
| 82 |
Can I use Zone within the HTTPS Policy? |
|
| 83 |
For confirmation; During learning mode, only 30% of the traffic is analyzed for TLS inspection implementation? |
Learning Mode adjusts the deployment rate in several rounds, up to 30%, allowing measurements to be taken at different times of day and on different days. It is recommended to configure the HTTPSi policy to inspect all connections when enabling Learning Mode. |
| 84 |
Is there plans to move some of the decryption/resource consumption to an end point agent instead of at the firewall? |
This is already done with Harmony Browser/Endpoint/SASE. |
| 85 |
At the end of learning mode, will exceptions be generated by the gateway so we can tailor the HTTPS inspection policy or is learning mode just to see how the hardware will perform under full inspection mode? |
Currently, Learning Mode is used to assess the performance and connectivity impact under full inspection mode. It samples CPU usage and the HTTPS Inspection success rate. If either metric falls outside acceptable limits, the feature will recommend additional preparations before fully enabling HTTPS Inspection. |
| 86 |
Will the new TLS Inspection feature be available for SMB appliances? |
I assume this functionality (or most of it) will be available on SMB once R82 is made available there. That’s not planned until next year. |
| 87 |
What happen till the time the inspection is happening, if the inspection was not performed on time will it start dropping the packets or it will still continue.
Also, is there any way we can use PAC file like proxy gateway |
HTTPS Inspection actually terminates the connection on the gateway and initiates a new connection to the destination so inspection can be performed.
Using a Check Point gateway as an EXPLICIT proxy (where you’d use a proxy.pac file) is not recommended. We offer no functionality to distibute PAC files. |
| 88 |
I have seen in the appliance-comparison-chart that CheckPoint has included an estimative for the throughput the new appliance series can support with SSL Inspection activated. For the old appliances I use the "not official" rule of considering half of the estimated throughput. |
Yes I suspect with the improvements in current software releases and additional improvements to come, we’ll be able to provide more information on datasheets. |
| 89 |
how good or safe that is from security stand point and if we want to inspect the files everything and wanted to bypass only which one is needed instead of checkpoint to take action or decide which one to be inspected? |
You can create exceptions in the policy for specific files/sites if desired/needed. |
| 90 |
How long is an inspection failure cached on the gw? |
from few minutes to a day, depending on how many times the bypass was needed. |
| 91 |
How does the gateway handle HSTS? Does it understand and fail open on HSTS sites? |
in most cases the gateway will try not to bypass connections from browsers.
you might get a detect log saying that you need to deploy the outbound CA on your client/browser. |
| 92 |
is tis setting applicable to CMA/domain level or firewall level ? |
Please provide more details in your question. |
| 93 |
I don't see the "Application" policy on the sidebar. So, is the HTTPS Inspection policy supposed to contain anything we currently have in the Application policy? |
No, it only speaks to HTTPS Inspection configuration. Note that HTTPS Inspection happens before the Access Policy. |
| 94 |
the dynamic bypass feature would work if e.g. the server certificate is not in trusted CAs ? |
If the root CA of the server certificate is not trusted, or the server certificate itself is untrusted, this is not related to the new bypass features. This use case has already been addressed in released versions - you can detect it via a log or reject the connection with an untrusted certificate. The bypass features are designed to solve client-side issues, not server-side ones. We exclude the use case where the organization's outbound CA is not deployed in the browser, ensuring this case is not bypassed. However, we do send a log to inform the admin. |
| 95 |
the settings on bypass like DETECT/Inactivate/bypass that settings are applicable to Domain/CMA level and not on individual gateway level what i understand? |
Yes, these are domain level settings, though there are a couple of gateway specific settings, as shown. |
| 96 |
Is there a feature to inspect flows without decrypting them? Is there any related documentation? |
We already do this to the extent that is possible without decrypting. Web traffic is categorized by SNI (where it isn’t encrypted). https://support.checkpoint.com/results/sk/sk163594 |
| 97 |
How are known certificate pinned applications identified by the gateway? How does the gateway know it's the application and not e. g. a browser request? |
browsers and applications typically have different characteristics. some collisions might happen though. |
| 98 |
Is bypass under load configurable? Can we modify it to other values other than 80 / 95 and 80/99? |
yes, same as IPS bypass under load. |
| 99 |
Changing from learning to inspect, will generate related rules inbound/outbound from traffic reviewed during learning time? |
No, Learning Mode does not modify the HTTPS Inspection policy in any way. But you’ve raised a great initiative for future development. 🙂 |
| 100 |
Is there any thought to building a Check Point maintained list (like the others we do) for positive reputation pinned applications to by-pass? It seems like that would be a great object to have as a base-line for many environments. |
We maintain a new list of pinned applications in R82.00, which we use to bypass those applications. However, the content of the list is not publicly available, though each bypass is logged in SMC. |
| 101 |
when the HTTPS inspection is automatic bypassed...is SNI still scanned? |
It should be, yes, as that does not require HTTPS Inspection. |
| 102 |
"Note that HTTPS Inspection happens before the Access Policy." Inspection happens before a matched rule in Access rule to verify if the traffic is even authorized? |
Access and HTTPS Inspection policies work together in two iterations: first, they iterate through all rules that are 'possible matches' based on source and destination IP addresses, and then they perform a final match using categorization and verified SNI. If a connection is matched as 'block,' it will be blocked unconditionally. |
| 103 |
We have tons of pre-existing SSL Bypasses. How can we re-evaluate previously bypassed traffic? |
you can enable client side fail-open and the certificate-pinned application allow-list and remove those existing bypass rules and then monitor the logs to see what client side fail open bypasses. |
| 104 |
On my prior question, to clarify, I mean like the 'financial services' and 'healthcare' groups, create a 'pinned-applications' group that is repeatable and known to break due to TLS 1.3 (Netflix, MS Store, etc.) |
currently there is no group to include certificate-pinned applications to be used in the rulebase, only a global checkbox is available. |
| 105 |
I saw that you wrote that the R82 will be available to SMB too. Is that correct? will we be able to have the same Gaia for the entire Quantum Gateways family, Force and Spark together? |
Yes, the R82 version for SMB will be released alongside the Gaia version. The SMB version will be an embedded version, while Gaia is designed for open servers |
| 106 |
so with R82 and the global setting for bypass certificate-pinned applications, the out of the box user experience is improved? If we have don't some manual bypass rules on r81.40 for instance, can we start removing some of the rules? |
Yes, the pinned application package will provide seamless bypassing. Consequently, some bypass rules can be removed from the HTTPS Inspection policy. |
| 107 |
Sorry, I meant if we do have manual https inspection bypass rules in place, can we start removing them with r82? |
its a good opportunity to re-evaluate your rules by disabling/removing them and enabling client side fail open and the certificate-pinned allow list and to monitor for bypass logs to check if the services fail or work fine. |
| 108 |
Maestro security group support all the R82 Https Inspection features? |
Learning mode is not supported in Maestro security group. the rest of the features work. |
| 109 |
If I have Harmony Endpoint I can inspect the certificate-pinned application on the client, right? |
no, certificate-pinned applications cannot be inspected by design. |
| 110 |
What percentage of the clients activate HTTPs inspection? |
Learning Mode continuously changes the deployment rate in a number of rounds, to be able to perform measurements at different days and different times of day. |
