2

Is there a way to explicitly configure OpenSSL to allow AES (or in general, block ciphers) only for clients that use a TLS version >= 1.1?

This would protect against the BEAST attack, while still allowing the use of ciphers more secure than the ancient RC4.

The suggested workaround for OpenSSL (enforce the server's cipher preference order; prefer AES-GCM over RC4 over AES-CBC) excludes all clients that don't support the GCM cipher suites, even though they are perfectly capable of securely using AES-CBC due to the fixes in TLS 1.1.

It seems that many popular sites have opted to just use RC4 for everything, which doesn't seem like a really good idea (RC4 has many known weaknesses, and many TLS implementations have workarounds even for TLS <= 1.1). I wonder if a server-side "use AES, but only if it's safe"-flag could improve the situation.

Community
  • 1
lxgr
  • 4,114
  • 3
  • 29
  • 37
  • 1
    Even most 1.0 clients have workarounds for BEAST. So for a webapplication I'd go with AES-CBC even with TLS 1.0. Clients which are so old and unpatched that they're vulnerable to BEAST, are probably vulnerable to dozens of remote code execution vulnerabilities. – CodesInChaos Sep 09 '13 at 17:09
  • I definitely agree; however, at least one popular SSL setup security validation/certification service didn't (for quite a while, they used to penalize any vulnerable cipher suites in their checks). Meanwhile, they've changed their opinion and now penalize RC4 instead... Also, Google seems to trust RC4 more than AES-CBC - at least, that's what they select for Google Chrome in my experience. – lxgr Sep 09 '13 at 17:15

1 Answers1

4

From a cursory look in OpenSSL's source code, no, the library is not up to what you want. The cipher suite selection appears to be done in ssl3_choose_cipher() (in ssl/s3_lib.c) and that function works with a list of "supported cipher suites". The list is pruned depending on the negotiated version (OpenSSL won't select a cipher suite which is not supported for the version which will be used), but the list does not contain version-specific preferences.

Programmatically, it would be possible to make an input filter on incoming data, which recognizes a ClientHello message, and dynamically adjusts OpenSSL settings based on the maximum version announced in that message. This would be a rather terrifying hack, which would "just work". However, you won't have that with configuration only.

At least the protocol supports what you wish to obtain. This would not be true in the opposite direction: since the client announces in one message the maximum version it accepts and the list of cipher suites it supports, there is no way for the client to say "AES-CBC, but only for TLS 1.1+".

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480