Skip to main content
  • EN

Activities functionalities among others, with and without certificate installation, e.g. PAC or explicit proxy or traffic sent through GRE/IPSEC.

 

Hello good afternoon, thank you for your time and collaboration.

 

I have some doubts, I understand that when using the netskope client SSL decryption is by default (since part of the client setup is also preload SSL certificates on the client) and as indicated in the documentation for use cases with PAC or explicit proxy or even forwarding via GRE/IPSEC, workstations, endpoints, ie endpoints, must install Netskope certificates, this clearly to perform the correct SSL decryption and to perform inspection. Now, what happens in the case that the certificates are not installed or cannot be installed (for multiple reasons), what are the functionalities that are lost? I imagine being able to filter by activities, to delimit upload and download, to give an example and to correctly identify the applications, since seeing everything as SSL, it is not possible to correctly identify the applications, and could only be based on the information shown by the SSL Certificates of the websites and cloud applications, if so installing the Netskope certificate becomes mandatory, unless you tell me otherwise.

 

In relation to the above, what features are lost and what features remain functional with or without the installation of the certificate?

 

Thank you

 

I remain attentive

 

Best regards

If you do not have the Netskope certificate on the machine we cannot inspect that traffic. So we cannot inspect that traffic for Threat or DLP violations. That traffic will be merely filtered as in just Allow or Block based on your inline policies. If you have for example servers that you cannot put the Netskope certificate on, you will need to add those server ranges or IP's to the SSL Bypass.

It's not that you cannot inspect the traffic; but rather the origin browser will display an untrusted certificate warning (possibly blocking the connection entirely).  The traffic will be inspected unless the origin or destination part of an SSL Bypass policy.  

What is lost if you SSL Bypass?  You have a great list already developing in your question.

  • DLP
  • CTEP
  • Some UBA
  • Compromised Credential analysis
  • Malware
  • App Identification logs
  • App Instance identification

Are you already doing some SSL on your legacy platform?  Do the systems that your concerned about distributing the Netskope chain to already have the Root and Intermediate for that legacy platform?  If so, you may want to ask about the BYO certificate feature.  With that, you would be able to re-use the same parent certificates for the Netskope signing cert used for SSL.

 

[edited to remove ProxySG references]

Hello @qyost @zthompson , good afternoon, thank you.

 

I mention this, because, for example, in the case of an IP camera or a DVR, if these devices must be connected to certain external URLs via HTTPS, to transmit, to communicate with an APP and/or to download software and updates.

 

If these devices, at software level it is not possible to load a Netskope digital certificate, but if I can set an explicit Proxy, and I am using Netskope via PAC, explicit proxy and/or IPSEC/GRE tunnel, with this kind of cases, how I am going to have for sure SSL type communication errors, For these cases it will be necessary to bypass the IPs of these equipments or simply that they go out by the direct exit to Internet, the topic is that I will lose control when having to isolate it of Netskope.

 

What do you recommend, I imagine you have had to deal with similar situations.

 

I remain attentive

 

Best regards

 

For that type of connectivity, where you know the destination URL, I would create a bypass specific to the list of known sources and the explicit list of update URLs.   I'd also consider adding those source IPs to the eproxy's unauthenticated use configuration.

Hi @MetgatzNK , Hope you're doing well. If the answers posted by @qyost and @zthompson helps you on what you're looking. Please feel free to click a comment  "Accept as Solution". 🙂

@MetgatzNK The type of "bypass" matters, a Do Not Decrypt SSL policy would be recommended to still control the threat surface via Netskope for a device that doesn't play nice with decryption, this will still allow an allow/block without breaking the IOT type of device with limited SSL trust capabilities.

Reply


Terms & ConditionsCookie settings