Is there any solution or plan to support diffie hellman crypto?
The way Diffie–Hellman works you can't decrypt it even if you have the private keys. This isn't a limitation of how WTD has implemented decryption, it's just the way Diffie–Hellman works. In this situation we normally get a internal re-encrypted feed using a cipher that can be encrypted. At least this way, external data is still using perfect forward secrecy. Not ideal, but as I said, this isn't a limitation of WTD as such, it's how DH based ciphers work.
Hope that helps.
That was our understanding as well, we wanted to hear from RSA if there is any solution that is being worked on for the road map as we do see the industry moving more and more towards DHE.
There's not a lot that can be done directly. PFS (Perfect Forward Secrecy) using DHE for example, means it's just not possible to decrypt the traffic in it's current state. TLS 1.3 forces PFS based ciphers so there won't be an option to select a decryptable (if you will) cipher suite.
Some options discussed have been around getting the sessions keys from the server connections. This is doable by writing plugins for various web servers, but the last thing you really want to do is to start having to complicate the process by writing plugins for a bunch of different web servers, application servers and other endpoints (node.js for example). Some platforms don't expose the information you need, it all becomes a bit of mess very quickly. Then you have situations where the TLS session is terminated on a load balancer or some other "hardware" based device where there is no option to write a plugin. An agent based approach for an issue like this won't really ever be the correct approach.
Other data security tools which monitor packets (regardless of the vendor, think IPS, IDS, DDOS detection, etc) will have the same issues as WTD in this situation.
This isn't anything new, most of the customers who use WTD today are dealing with external traffic which is using PFS. Apple's App Transport Security (ATS) requirement forces (there are some exceptions) the use of a PFS cipher so any IOS traffic being monitored by WTD today needs to be managed.
The solution going forward will be same as what most customers are doing today. That is, keep the highest level of security for external traffic. Have all external communications using PFS based ciphers. Terminate those connections on a load balancer or other like device. Have the internal connections in the trusted zones between the load balancer and web endpoints use a non PFS based connection. This will allow WTD (and other devices) to continue to be able to do it's job.
Sorry for essay, but I wanted to include some of the discussions and reasoning used around this specific issue.
Retrieving data ...