1

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.

hagrawal
  • 215
  • 2
  • 11
  • The _ephemeral_ keyexchanges DH*E*-\* and ECDH*E*-\* 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. – dave_thompson_085 Oct 10 '16 at 18:46

1 Answers1

2

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.

Community
  • 1
Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • 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? – hagrawal Aug 23 '15 at 14:52
  • I have updated my question with one new impact I could think of. Could you please have a look. – hagrawal Aug 23 '15 at 14:52
  • @hagrawal: see edited response. – Steffen Ullrich Aug 23 '15 at 15:07
  • Thank. But in that benchmark 2048 bits were used for both RSA and ECDHE. However ECDHE can achieve same level of security for example 90 bit of security with far more less number of key size bits. Check this - https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm#Key_and_signature-size_comparison_to_DSA. I am not sure about DH so I can agree that it could be slower than RSA, but as per best of my knowledge ECDHE is the fastest. – hagrawal Aug 23 '15 at 18:41
  • Do you have any idea on how authentication works on ECDSA? – hagrawal Aug 23 '15 at 18:49
  • 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. – Steffen Ullrich Aug 23 '15 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. – Steffen Ullrich Aug 23 '15 at 18:52
  • As per the screen shot in the link it is showing the ECDHE with 2048 bit key size is used. I tried browsing more but only to have more confusion, this https://securitypitfalls.wordpress.com/2014/10/06/rsa-and-ecdsa-performance/ suggests RSA has better performance and this http://nmav.gnutls.org/2011/12/price-to-pay-for-perfect-forward.html suggests ECDHE. – hagrawal Aug 23 '15 at 19:14
  • So, you mean in case of ECDSA, ECC key will be sent in ServerKeyExchange message? I know that this key will be used to encrypt the pre-master secret but does this ECC key contribute in authentication? – hagrawal Aug 23 '15 at 19:17
  • @hagrawal: please read [How does SSL/TLS work?](http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) to learn how key exchange and authentication with certificates work and which part the keys of the certificate play in this area. This is not the place to explain this again. And once you've understand this you will maybe also understand that effectively both benchmarks you cite conclude that with the current setup of certificates RSA key exchange is faster than DHE and ECDHE. Apart from that, the screenshot you probably refer to means ECDHE with RSA 2048. – Steffen Ullrich Aug 23 '15 at 20:22
  • I have read it and also this https://msdn.microsoft.com/fr-fr/library/cc783349%28v=ws.10%29.aspx. But I don't think (or at least as per me) authentication is better explained, it not clear on how authentication is done in case RSA and ECDSA. It is clear at both the places that digital certificates play a major role, but RSA/ECDSA part is not well explained. – hagrawal Aug 23 '15 at 20:26
  • @hagrawal: sorry, but if you don't understand the authentication based on these extensive write-ups then small comments here will probably not help either. You might then better ask a new question and specifically highlight the parts you don't understand. – Steffen Ullrich Aug 23 '15 at 20:28
  • Thank you for your inputs. I would be trying for few more stuff and if that doesn't help then I would open a new question specially for role of RSA and ECDSA while authentication in SSL handshake. – hagrawal Aug 23 '15 at 21:48