0

Our company currently sniffs encrypted RSA traffic using a network tap. Would this still be possible using ECDH? I guess not.

Are there commercial alternatives, like placing an agent on the application server to receive all information the application on it receives?

Are there open source alternatives who could do the same job?

  • Sniffing is not the problem but decrypting the traffic would be. Meta data analysis would still be possible though. Unfortunately it is not clear from your question what the intend of the sniffing should be. Apart from that product recommendations are off-topic here. – Steffen Ullrich Nov 25 '16 at 14:07
  • You can sniff ECDH just like RSA with Wireshark. – Aria Nov 25 '16 at 14:09
4

I suppose that by "sniffing" you mean "obtaining the cleartext traffic".

Basically, SSL/TLS has been designing specifically to ward off attackers who want to do that kind of sniffing. When organisations want to do it nonetheless, there are two main methods, that both break the SSL security model:

  1. The sniffer may be configured with a copy of the server's private key. This is simple enough in practice (in particular, the sniffing apparatus can then be purely passive on the network), but it works only for a specific server whose private key is under control of the organisation. It won't work for arbitrary external servers (i.e. when employees do some Web browsing).

    This method works for cipher suites using RSA, DH or ECDH. Crucially, it does not work for cipher suites using DHE or ECDHE. Pay attention! This is an important and often overlooked point: ECDH and ECDHE are not the same thing. Many people talk of "ECDH" when they actually mean "ECDHE". The reason why knowing the server's private key does not allow passing sniffing of connection with DHE/ECDHE is basically called forward secrecy.

  2. The sniffer may do a full Man-in-the-Middle attack. In that model, the sniffer creates dynamically a fake certificate for the server that the client wishes to connect to. The client accepts that fake certificate because the corresponding root CA, which is entirely under the control of the sniffer, has been installed as a "trusted root" in the client system (this is where the SSL security model is bent: if you trust a CA that lies to you, then you're done for).

    This kind of MitM is active and thus more invasive in network configurations, but it will work with arbitrary target servers, and also with all cipher suites (RSA, DH, ECDH, DHE, ECDHE...). Many vendors sell appliances that can do such things.

    It shall be noted that this MitM system does not work with client certificates (but client certificates are quite rare in practice). More importantly, it is not hidden: users can notice that the certificate comes from a non-standard root CA.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.