Confirmation on HTTPS decryption

[Micahel_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, @Micahel_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.

[Sid]

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...

[DSCOPE]

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]

@DSCOPE 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. 

[Chris_M]

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.

[eeanlee82]

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.

[Sid]

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.

[PhilipDAth · 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.

[JamesA]

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_C]

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   

[GreenMan]

The Umbrella integration for MX is available, in Beta, now - with all the cautions that entails.   You will need to be running MX r15 to access it, will need Advanced Security license in your Organization and will need Support to enable it for you.    You will, of course, require an appropriate Umbrella subscription too.   More information available here:  https://documentation.meraki.com/MR/Other_Topics/Integrating_Cisco_Umbrella_with_Meraki_Networks

I don't have a date at which this would become a 'generally available' feature, but I would not expect it to be imminent.

[shauno]

It's unfortunate as there's a huge increase in malware/etc using HTTPS to bypass basic filtering.

SSL inspection is a big gap for the MX-line, certainly it'd be a very welcome feature!

[ccnewmeraki]

Completely agree. This is really essential and it makes a mockery of many of the features that the MX line claims it can do.

 - The advertised "Intrusion Prevention/IDS" feature (powered by SNORT) can't prevent any exploits from SSL enabled servers.

- Neither can the anti-malware feature (the MX will happily let you download a virus executable from an SSL enabled website

- The google search filtering doesn't work as they have moved to SSL.

- The "URL logging" feature (in beta) is completely unable to show the URLs for SSL websites. So we can't even view a history of a users google searches.

The majority of the web uses SSL now, and the MX appliance is therefore not fit for the purposes it advertises.

I've not heard anything about SSL Intercepting Proxy servers stopping working with a new version of TLS, do you have a link or some more information on that?

[GreenMan]

Have a look here: https://tools.ietf.org/id/draft-camwinget-tls-use-cases-00.html

[ccnewmeraki]

Interesting link.

I found that Symantec is selling a security appliance that can decrypt the draft standard of TLS 1.3, so the measures must still allow some implementations of MITM: https://www.symantec.com/theme/secure-decryption

I disagree with the assumption that because TLS 1.3 exists that this isn't worth looking into. Many big websites, e.g. PayPal have only just moved over to TLS 1.2 this year, which can be proxied. TLS 1.2 is not due to be depreciated at any point in the immediate future. Plus an SSL Proxy could be implemented with the existing transparent proxy software that the MX already runs on (squid), with some configuration changes.

I feel there is a huge missed opportunity here. The Meraki Systems Manager agent could massively simplify the deployment of a trusted SSL certificate to the client PCs and devices. It could be a complete security solution, at the moment it has a giant hole of 50% of the web through the middle of it (and growing).

[GreenMan]

I think the Symantec article you highlight is a little light on detail, on precisely what it can do (and what it can't).   Fundamentally, if clients are required to fully verify the chain of trust, certificate-wise, with the target server (which is one of the TLS1.3 pre-reqs, as I understand it) then support for new TLS 1.3 cipher suites alone will not solve the conundrum.   Of course, the adoption rate of TLS1.3 is always open to debate.

[ccnewmeraki]

@GreenMan - It is making some pretty specific claims on this link:
https://www.symantec.com/products/ssl-visibility-appliance

"Enable the secure inspection of TLS 1.3 encrypted traffic"
"Enables the inspection of all ports and protocols of traffic including TLS 1.3 draft versions 18 - 21"

@BlakeRichardson - The Fortigate routers I linked to were $900 and $1800, so it is possible to get SSL inspection on products that are comparable in cost to the Meraki MX Security Appliances.

[Uberseehandel]

---

@ccnewmeraki wrote:

TLS 1.2 is not due to be depreciated at any point in the immediate future.

---

That isn't what depreciated means.

[GreenMan]

Just an update for those interested:
https://www.sslsupportdesk.com/encryption-protocol-tls-1-3-released/

[Ryan_C]

GreenMan IT seems like every other vendor has some sort of HTTPS decryption. Sophos XG, SonicWall, Fortinet even Cisco ASA 5506-X with FirePower all seem to be able to do this. As more traffic becomes SSL if I want to be honst to customers on features I think I have to point them back to the ASA line vs MX. With new products due out soon has there been any update on decryption?  

[meraki-user]

It's clearly a typo for the word "deprecated."

[BlakeRichardson]

@Micahel_Horne You are correct unless you use a vendor that provides an appliance capable of DPI-SSL however the cost for this sort of things is high and its not always perfect.

While TCP security is being improved the bad guys are also making use of the "invisibility" this gives them. This is why we can't rely fully on security appliances and we must be using good antivirus software.

[ccnewmeraki]

@BlakeRichardson By 'cost' do you mean price or performance?

Fortigate's entry-level NGFW 115 firewall range achieve throughput of 100 Mbps with SSL Inspection on low end Intel Atom CPUs:
https://www.forcepoint.com/sites/default/files/resources/files/datasheet_forcepoint_ngfw_appliances_...

Their NGFW 321 doesn't specify the CPU used but it has a lower power draw than a Meraki MX84 and it achieves 150 Mbps throughput with SSL Inspection enabled.
https://www.forcepoint.com/sites/default/files/resources/files/datasheet_forcepoint_ngfw_300_series_...

[BlakeRichardson]

@ccnewmeraki Sorry I was meaning price not performance. One firewall I manage has a DPI SSL  maximum throughout of 1Gbps so for most people that would be more than enough.

[DHAnderson]

@ccnewmeraki;

Fortinet firewalls have FPGAs or custom chips to do the heavy lifting in their SSL inspection.

[PhilipDAth]

>Fortinet firewalls have FPGAs or custom chips to do the heavy lifting in their SSL inspection.

@DHAnderson I think that is a great approach that Fortinet are using - if you think SSL inspection has any value.

[DHAnderson]

@PhilipDAth 

When I had a client who had their own servers running an online grocery e-commerce service, they had Fortinet firewalls.

I am installing Meraki MX firewalls for my clients that are not running web servers. 

[wrespawn]

Is this on all MXs (i.e MX84 and higher)? I've been considering and actively testing replacing our sonicwalls with Meraki devices. If none of the higher tier devices are able to filter SSL traffic this throws a big wrench into my plans. 

[GreenMan]

Correct - SSL decryption is not currently supported on any of the MX models. Sorry this adversely affects your plans.

[ccnewmeraki]

Cisco have announced some interesting products that can detect malware in encrypted traffic without decrypting it:

https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption

The whitepaper says it's going to be in Cisco IOS XE 16.6 & it provides a list of models gaining the functionality:

https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/enterprise-network-securi...

Are any of these features moving over to the Meraki MX series?

[MRCUR]

@ccnewmeraki I really, really hope the MX team is working on getting this capability into the MX line with AMP. It'd be nice if eventually we could get to a place where Cisco & Meraki can launch these new features in tandem between the traditional Cisco products and the Meraki line.