I understand that Diffie Hellman is not a supported cipher in DC RUM. However, we have application teams and customers that are going to be required to use DH. Has anyone else run into this challenge? What is your path forward? Just to tell the teams we no longer can't monitor your application?
Solved! Go to Solution.
I Think I might have told this story somewhere else but it deserves repeating.
Around the turn of the millenia I had a discussion with the Swedish Police about a similar scenario where they intended to install customized crypto cards for all kinds of communication between PC's and servers. They posed the same question as you just did, how can we proceed to monitor?
After some discussion back and forth we came to the conclusion that not only was it expensive to procure and maintain the crypto cards, it also made them blind to anything going on in their network, which contradicted their explicit need to be able to trace and backtrack what went down when something "happened".
In the end they chose to do encryption only between floors and "cells" on a floor, so that they could be sure to intercept and record traffic when deemed necessary.
As a note, DH makes it impossible for any generally commercial tool to monitor and decode network traffic (could potentially do man-in-the-middle, but that is note very ethical).
What you are left with if all traffic goes the DH way is a more NPM oriented, very capable, platform that still can provide value as to what nodes that consume your network and capacity.
I suggest bringing up a conversation around this topic as soon as possible. The chances are 50/50 that they will opt for DH and then you will have to tell them that when they run into problems, you will not be able to help them.
Generally there is an inclusion of the reasons Diffie-Hellman (usually a high level overview and "this is by design with Diffie-Hellman and applies to all third party decryption, not just DC-RUM") can't be supported, and if Diffie-Hellman is absolutely required looking into monitoring with other tools, such as Synthetic and UEM
For deeper discussion is asking what is the threat model they are using to determine whether or not Diffie-Hellman is needed. The design intent of Diffie-Hellman is to protect the encrypted session content against unauthorized decryption (live or after the fact) even if the private keys are compromised. Unless their threat model does include a reasonable or serious risk of the private keys being compromised, the use of Diffie-Hellman ciphers may not be warranted. Also, if they have that much risk for private key compromise, mitigating that risk should be a much higher priority; compromised keys are far more dangerous in other ways than decrypting legitimate connections. Fake sites with the compromised keys ranks very highly on that list of potential dangers.
When Diffie-Hellman is used (warranted or not), no agentless monitoring solution is able to decrypt it, and all monitoring must use some form of agent that has access inside the encrypted session. Synthetic and UEM both meet this "agent" requirement.
Thanks Eric for the addition - my fingers got a bit tired 🙂
As of lately I've learned that a particular Firewall vendor goes around knocking doors on the business side and telling them that they are not safe with the "old crypto/ciphers" and they HAVE to buy their newest coolest HW wich incidentally happens to have DH features.
This is a very soft target from the outside as it is quite easy to troll the net and see who has DH and who has not.
The IT pit just have to accept it and when they bring up the arguments that myself and Erik points to, the businesside don't comprehend what they've bought and the effects or consequences - just that it's "safer" than what they had.
There's also the non-decrypting SSL analyzer, which attempts to do a bit more than plain network measurements for non decryptable traffic. It tries to detect request/response pairs based on SSL application data direction changes and glue individual hits into pages based on the SSL session ID. It won't always be able to assemble the pages correctly and there will be no URLs, but it may provide more value than just generic TCP monitoring.
Following ciphers are typical strong ciphers that AMD can decrypt:
If you can, put those ciphers on the server's preferred ciphers list ahead of the DH ciphers. This will instruct browsers and servers to negotiate usage of those ciphers first, so AMD would be able to decrypt the SSL traffic. When DH ciphers are left at the bottom of the cipher preference list, typical cipher negotiation will not choose them, unless the browser declares that it does not support the RSA key exchange (which may be the case when HTTP/2 is used instead of HTTP/1.1)
The SSL Decryption FAQ page provides several recipes for retaining transactional visibility in presence of the Diffie-Hellman encryption.
Please note that insisting on DH decryption is contradictory to the reason why DH is being adopted in the first place - it is adopted to prevent the possibility of decryption through the traffic interception, i.e. the way how AMD works (and any other network probe). So the recipes based on different approaches like agents and inline devices are the exact match and companion to the DH encryption (i.e. to the Perfect Forward Secrecy blueprint).