Given the recent influx of vulnerabilities to cipher suites and SSL3-TLS1.1 in the past several years, the limited list of supported ciphers that NSM can handle is now absurd. We're running two NS-9300's and would like to be able to put a dozen or so websites behind the SSL decryption capacity that the sensors advertise. At this point though, that feature should have the largest asterisk in the world attached.
The product supports none of the ciphers mandated by federal (or any SSL good practices site's) recommendation, so it's decryption ability is effectively useless.
What NEEDS to be supported are the TLS_ECDHE_ECDSA_* list of ciphers as that is the baseline config going forward.
To not support these and claim SSL decrypt capability going forward borders on false advertising.
Yes, there are plans to support perfect forward secrecy encryption in the near future. You would need to check with your Sales Representative for them to get confirmation from PM, but I believe this should be available on 8.4 or 9.0, so later on this year.
The difference between the current decryption feature and PFS is that as you know, PFS uses a randomly generated secret key per TLS conversation, whereas older encryption would use the server's secret key.
Because PFS uses randomly generated keys, the only way to inspect the traffic is to act as a TLS proxy.
Currently the sensor uses the server's private key to decrypt the matching conversation on the fly, without terminating the TLS connection, so it is completely invisible to the client or server.
Once the new version with the TLS proxy capabilities is out, you will import your keys to the sensors, who will then terminate the incoming PFS conversations, scan the clear traffic, and re-encrypt the traffic to your servers.
And best of all, this will not only allow you to scan the incoming PFS conversations, but because the sensor will be proxying the TLS conversations, it will also support outbound TLS scanning - which is great, because as we know malware usually uses TLS for outbound communications.
I am aware that McAfee had this on they roadmap a while ago, so as previously said, best option is to contact your Sales Rep to get the ETA for this feature.
just to follow up on David's post, I have a meeting with NSP product manager in 2.5 hours to discuss NSP roadmap for v9.1.
What I've been told so far is that v8.4 is a "cloud version" and we are going to v9.1 next; This will be "an everyone release" - not specifically a FIPS release according to our SAM.
I'll ask about SSL Decrypt & PFS during this call.
If you have any questions you would like me to ask or any features you would like to know about, reply to this post, I will ask them and post back here on the responses I get.
I followed up on this question during our session with the product manager yesterday. The SSL decryption feature is being looked at for improvements by year end, in particular the incorporation of ECDHE.
We were informed of improvements to be included in 9.1 - expected by month-end. This will be their longer-term stable release.
Currently the road-map spoken about suggests the inclusion of ECDHE in the following feature release - 9.2, tentatively scheduled for December.
He has suggested that I provide a list of the ciphers you are concerned about and he will confirm which are expected to be included. If you would reply to this with specifics, I will forward same on to him.
I neglected to ask about PFS as David had mentioned above, I will include this in my follow-up mail also.
Sorry for the delayed follow-up. The specific ciphers that we require (and I'm assuming virtually everyone going forward) are (in order):
I've just received word back from the Product Manager about cipher suites for SSL Decryption in upcoming versions of NSP, see below.
We have deferred outbound SSL functionality release for a couple of months, but when released it will support the following ciphers:
There has not been any change in Inbound SSL processing as of now. We expect to support these same ciphers in inbound SSL by the end of this year.