Confirmation on HTTPS decryption

[MICHAEL HORNE]

Hello All,

Reading the documentation has led me to understand that the decryption of HTTPS traffic for Content filtering / inspection is not possible and and filtering on for HTTPS traffic will be based only on the host name only.

Can someone just confirm that SSL decryption is not possible?

Many thanks,

Michael

[GreenMan]

That is correct, @MICHAEL HORNE Whilst having this capability currently has advantages, note that it is highly intensive and will decrease throughput on any device performing the necessary decryption+re-encryption. It's my understanding too that, as TLS 1.3 becomes adopted, the 'device-in-the-middle' approach, which such inspection relies upon, will be unavailable.

[Sid3]

SSL decryption is something Sonicwall has been bragging about as well. Surprising that Meraki hasn't added to their "cloud" traffic analysis. Must need additional processing horsepower within the firewall itself...

[jack]

I actually switched quite a few clients over to Meraki from Sonicwall thinking that Meraki's feature set would be more enriched/advanced.

I was mistaken.

[BlakeRichardson]

@jack The main network I manage uses a Sonicwall and I cannot recommend they use Meraki MX because of its lack of features, Also Sonicwall ONLY make firewall so you know their focus is 100% on firewalls.

Sonicwall has GMS which is centralised administration but its not as nice looking as Meraki.

[CMetsch]

Part of the problem for decryption is where does it take place? If it takes place in the cloud, then that'll violate privacy, especially for HIPPA and PCI compliance. If its on the devices itself, which may be possible, then the result can be fed to the cloud. Again, it depends on what the data is being sent to the cloud to enable this feature.

[DHAnderson]

The SSL decryption on my Sonicwall was processor based, not FPGA or custom hardware based. Enabling that feature slowed the network to a crawl.

[eeanlee]

Is this still something Meraki won't consider? I just assumed this would be included into the MX line and am amazed that it isn't. +1 to feature request, please.

[Sid3]

Agreed. This will likely be one of the reasons we move away from the MX.

[DHAnderson]

SSL inspection helps solve a problem and I agree the further upstream you can block malware, the better. That said SSL inspection will always be invasive, expensive to do at high speeds, and troublesome with Browsers that are getting better at detecting MITM attacks.

A more balanced approach might be to do inspection where one easily can. The Firewall can inspect unencrypted traffic, and the endpoint protection can inspect traffic after it has been unencrypted on the client. This solution also scales nicely.

[Philip D'Ath · Accepted solution]

Just to update this old thread; https inspection is now available in beta.

https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/HTTPS_Inspection

[ccnewmeraki]

Brilliant news.

However i'm not sure why it specifies "Changes to how keys are handled in TLS 1.3 mean that services that only allow TLS 1.3 will not work properly."

Given all the links online that suggest TLS1.3 can actually be inspected with a full man-in-the-middle setup, why can't meraki's implementation handle it? There's a link to a Symantec whitepaper on how it works in this thread.

"With TLS 1.3 in place, if a device wants to look at the certificate it must intercept the session and decrypt it to see that information. And to do that, the network security device must fully support TLS 1.3."
https://www.fortinet.com/blog/business-and-technology/tls-is-here-what-this-means-for-you.html

It sounds like if the device implements a full MITM SSL proxy, it is possible to still do SSL-interception after TLS 1.3 comes along, but some devices are still attempting to do selective interception, which isn't compatible.

[jaime.pedraza]

No body has talked about the performance implications of enabling it:

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

[GreenMan]

This was highlighted previously as being a result of enabling the capability - and I believe other vendors show a similar impact on performance, when performing SSL decrypt.

[ryan@abs-solutions.com]

With the performance hit on the MX line what is the time line for umbrella integration like they have for wireless, not just using it as open dns