13

Does standard AES with RSA (reported by Opera as TLS v1.0 256 bit AES (1024 bit RSA/SHA)) provide perfect forward secrecy?

Which SSL3.0 and TLS1.0 ciphers do provide forward secrecy?

Which ciphers in openssl provide forward secrecy and are regarded as secure?

Andrei Botalov
  • 5,317
  • 10
  • 46
  • 73
Hubert Kario
  • 3,748
  • 4
  • 27
  • 35

2 Answers2

16

Cipher suites which provide perfect forward secrecy are those which use a Diffie-Hellman key exchanged, signed by the server -- but the server key may be of type RSA. Consider the TLS standard: there are two cipher suites which use AES with a 256-bit key, SHA-1 for integrity check, and a RSA server key:

  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA

Only the latter provides perfect forward secrecy. In the former, the key exchange is done by encrypting a random value with the RSA server keys, something which can be unraveled later on by an attacker who could steal a copy of the server private key.

Information provided by Opera does not seem to be sufficient to distinguish between those two cipher suites.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 2
    Note, apart from standard DHE suites there are also the elliptic curve versions named [...]_ECDHE_[...]. Opera might not give you all the information but maybe it allows to disable the ciphersuites without forward secrecy. According to Google you can do that in Tools \ Preferences \ Advanced Tab \ Security Item \ Security Protocols \ Details. It is possible that some SSL sites do not work anymore after this, but to my knowledge DHE is very common. – pepe Jul 19 '11 at 23:23
  • 3
    Opera does distinguish between them, DH versions are reported as `TLS v1.0 256 bit AES (1024 bit DHE_RSA/SHA)` – Hubert Kario Jul 20 '11 at 04:55
  • @pepe: I'm more interested in making sure that my server provides only ciphers with perfect forward secrecy – Hubert Kario Jul 20 '11 at 04:57
  • Well then that's no problem, just set the ciphers we named in your server configuration. For compatibility you might want to set them as preferred ciphers and still allow other mechanisms depending on what the client supports. Preferred use of DHE may even be the default already, I'm not sure.. – pepe Jul 20 '11 at 09:37
  • 2
    @Hubert: in TLS, the client announces what cipher suites it supports (ordered list: preferred client suite comes first), and then the server chooses the cipher suite that will be used. Normally, the suites that the server will use can be configured (it depends on the server TLS implementation). Also, traditionally, the server follows the client order of preference, but, then again, some servers may be configured to enforce their order of preference. – Thomas Pornin Jul 20 '11 at 12:14
  • @pepe: Unfortunately DH isn't really common, probably because IE doesn't support it. – Hubert Kario Aug 13 '11 at 13:35
  • @Hubert: IE supports DHE, with a 'E' as "ephemeral" (the DH parts are dynamically generated and the server signs them; the server certificate contains the signature key, often RSA-based). What IE does not support is "static DH" in which the server certificate contains a Diffie-Hellman public key directly. – Thomas Pornin Aug 13 '11 at 16:10
  • @Thomas: Yes, I was thinking about DHE and I'm quite sure that at least IE6 and Windows XP libraries don't support DHE, newer versions or newer versions working on Vista or 7 may support it. – Hubert Kario Aug 13 '11 at 17:35
  • 1
    @Hubert: If you have to use Windows for accessing the Internet, try using a version that is not 10 years old. MS implemented significant structural security advances since XP. – pepe Aug 13 '11 at 23:33
  • @pepe: please, don't troll. If you're not trolling: it's still supported by MS and it's still used by millions of people. I can't force them to change the OS. If I want my site to be accessible by them (that's "only" 10% of traffic, most of which are corporate clients) I have to allow usage of 3DES or RC4 without DH. – Hubert Kario Aug 14 '11 at 12:11
  • @Hubert: I forgot that you were talking about server side, that obviously limits your options. For intranet and client side I stand by my point. The extended XP security support was not originally intended by MS and if you have to use Windows, you should not use such antiques. I only use XP for "App-VMs" since it is much smaller. – pepe Aug 14 '11 at 13:49
  • @Hubert: IE6 _does_ support DHE cipher suites; I tested it with a Win2000 client (if it works with Win2k it should work with XP). However, it can use it only if the server key has type DSS (not RSA), and, moreover, it has a bug which makes it fail if the server sends an empty record (recent versions of OpenSSL send empty records as a workaround for a potential but esoteric weakness related to CBC; IE 6.0 chokes on empty records) but OpenSSL has an option to avoid empty records: SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS. See: http://www.openssl.org/~bodo/tls-cbc.txt – Thomas Pornin Aug 15 '11 at 15:05
  • @Thomas: So it both does and doesn't. Considering that standard DSS limits key sizes to 1024bit, the DHE in IE6 is unusable in any secure deployment. Also, don't later versions of IE (or system crypto library) also support DHE *only* with DSS by a chance? – Hubert Kario Aug 15 '11 at 16:56
3

In addition to the traditional Diffie-Hellman cipher suites you can also use those based on Elliptic Curve DH key exchange, they provide Perfect Forward Secrecy as well.

Suitable ciphers are listed in RFC4492.

emboss
  • 4,338
  • 1
  • 16
  • 17
  • Curious why this was downvoted? Is it wrong that EC can provide PFS? – AviD Jul 21 '11 at 09:10
  • @AviD: Wondering too. No, it's the DH in ECDH that provides the same goodies that DH does, PFS being one of them. – emboss Jul 21 '11 at 10:08
  • Possible duplicate of http://security.stackexchange.com/questions/5474/forward-secrecy-with-https-and-aes#comment8871_5476 – Andrei Botalov Apr 09 '12 at 18:31
  • Elliptic Curve DH *is not* Diffie Hellman. The former uses elliptic curves, the latter integer logarithms. And considering that the ECDH is at least 10 times faster than DH, it's good to know of its existence. – Hubert Kario May 12 '12 at 19:53
  • @HubertKario You've got to be kidding me? http://security.stackexchange.com/questions/14731/what-is-ecdhe-rsa ? – emboss Jun 10 '12 at 23:23
  • 1
    @emboss: ECDH is using elliptic curves, EDH is using modulo arithmetic multiplicative group of integers. They achieve the same result (forward secrecy) but using slightly different methods. In effect, ECDH is fast, EDH is not. This difference alone warrants voting up this answer. (And the previous comment was supposed to be an answer to @AndreyBotalov) – Hubert Kario Jun 11 '12 at 00:13
  • @HubertKario OK, now I get it! Sorry for the confusion :) – emboss Jun 11 '12 at 00:35
  • 1
    "The ECDHE_ECDSA and ECDHE_RSA key exchange algorithms provide forward secrecy protection in the event of server key compromise, while ECDH_ECDSA and ECDH_RSA do not." This answer doesn't mention that and says about ECDH in general. – Andrei Botalov Jun 11 '12 at 10:36
  • 1
    @HebertKario "No, it's the DH in ECDH that provides the same goodies that DH does" is also incorrect. Either DHE or ECDHE is needed. DH and ECDH don't provide forward secrecy – Andrei Botalov Jun 11 '12 at 10:44