I am trying to understand the impact of sharing the private key with a third party for snooping SSL traffic. Below are my thoughts, please correct and add if some more impacts are there:

  • One clear impact is that I will not be able to use the key exchange algorithms like DH, DHE and ECDHE because they generated a new key each time and hence if I use them then my designated third party will not be able to decrypt the SSL traffic.
  • Since algorithms like DH, DHE and ECDHE will not used, so it means that I will not be able to get benefit of Perfect Forward Secrecy.
  • I will not be able to upgrade to the ECDSA based certificates, again because a new key would be used each time and hence decryption by third party will not be possible.
  • Since DH based ciphers are faster in computation than RSA so I think there could be little performance impact. But could it be significant?

I know basically I would be weakening my cipher suite so that third party can snoop. I don't see any other impact.

  • The ephemeral keyexchanges DHE-* and ECDHE-* provide PFS and can't be decrypted using static privatekey. 'Static' DH and ECDH (including ECDH authenticated by ECDSA) could be, but almost no one uses kECDH and no one at all uses kDH -- partly because it needs a certificate for the DH key, and the all-but-universal cert request scheme PKCS10 can't handle that. Oct 10, 2016 at 18:46

1 Answer 1


If you can really trust the third party that it keeps your private key secret and uses it only for passively sniffing and decoding the encrypted traffic (like within an IDS) then you are probably right about the impact.

But of course this third party can also use this private key for active interceptions (i.e. modify traffic) or for impersonating your site, because the private key and the public certificate together is all what is needed to do this. And you probably might not detect when their are doing this or when they give your private key away (voluntarily or not, i.e. if they get hacked) so that others can do it.

Also note that weakening the cipher suite might have some unintended side effect because browsers like chrome will complain about it (but still connect) but some applications (like iOS9 apps) will fail to connect at all because they expect ciphers with forward secrecy.

Since DH based ciphers are faster in computation than RSA so I think there could be little performance impact.

I don't know where you got this from. DH key exchange is much slower than RSA and while ECDH is much faster than DH it is still slower than RSA. See the benchmarks at the SSL/TLS & Perfect Forward Secrecy article from Vincent Bernat.

  • Thank you for inputs. I trust third party, actually part of my application performance monitoring team so I am not concerned about them doing something with the private key. From your 3rd para - do you have any reference or could you please elaborate on it? I think we I am doing away with the DH related ciphers so key exchange so RSA would be used, and all old and new browsers do support RSA, so there should not be an impact on end users. Do you have idea about ECDSA based certificates, how authentication and key exchange will happen in this case? Aug 23, 2015 at 14:52
  • I have updated my question with one new impact I could think of. Could you please have a look. Aug 23, 2015 at 14:52
  • @hagrawal: see edited response. Aug 23, 2015 at 15:07
  • 1
    @hagrawal: The RSA key size in the certificate has no effect on the time used for DHE/ECDHE key exchange. With DHE/ECDHE key exchange the RSA key is only used for identification of the server, not for computing the key. And the benchmark definitely did not use a 2048 bit ECC key for ECDHE. Aug 23, 2015 at 18:50
  • 1
    @hagrawal: ECDSA is similar to RSA only that an ECC key will be used for identification and not an RSA key. And again this has no effect on the performance of the DHE/ECDHE key exchange because it is not used in the key exchange. Aug 23, 2015 at 18:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .