Can a TLS 1.2 server/client get by with just TLS_RSA_WITH_AES_128_CBC_SHA?

16
votes

I'm updating an embedded TLS 1.0 implementation to TLS 1.2 (devices with 1MB of code space or less, and no OS). At this point, I have AES-128 and AES-256 CBC ciphers working with SHA-1 and SHA-256 digests for a minimal implementation. The library cannot negotiate an SSLv2, SSLv3, TLS 1.0 or TLS 1.1 connection.

I felt this would be sufficient, given that RFC 5246 states, "TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite."

Yet as I read various postings on security blogs, I'm seeing recommendations that would have users disable that suite, and (for example) only allow the ECDHE_RSA or DHE_RSA variants.

So my question is whether devices using our library will interoperate with modern web browsers (as a server) and modern https/smtps/pop servers (as a client). Are there TLS 1.2 clients/servers that fail to negotiate a TLS_RSA_WITH_AES_128_CBC_SHA connection?

2
ssltls1.2
Depends on what you define "get by". I'm not a security expert. But I can smell that "AES_128_CBC" is not secure enough. That said, I would feel more comfortable with something like "AES_256_GCM". If that's indeed the case, if you are the client, there is the risk the cipher is not supported by the server. If you are the server, you can support it. But you want to think twice about the security. – neurite
There are many email servers that don't support TLS 1.2 properly. – fcnorman

2 Answers

1
votes

I am not sure there are currently many servers supporting TLS that would fail negotiating TLS_RSA_WITH_AES_128_CBC_SHA with TLSv1.2 as it is THE mandatory cipher suite for TLSv1.2.

However there are things to keep in mind:

  • TLS_RSA_WITH_3DES_EDE_CBC_SHA is mandatory for TLSv1.0 and TLSv1.1 but due to security reasons it is no longer supported by every server,
  • Mozilla recommends (and it is not the only one) to favor AES128 instead of AES256,
  • Perfect Forward Secrecy (PFS), allowed by DHE or ECDHE is now a must-have feature.

So if I can provide you with 4 cipher suites (the same number than you have), I would say these ones from the strongest to the weakest:

  1. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  2. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  3. TLS_RSA_WITH_AES_128_GCM_SHA256
  4. TLS_RSA_WITH_AES_128_CBC_SHA

I would say that these 4 cipher suites bring enough security and compatibility with TLSv1.2 servers.

Now the question of supporting only TLSv1.2 is another question, but if you have enough space, I recommend you to add TLSv1.0 too (TLSv1.1 does not provide extra compatibility).

PS: The reason why AES128 is favored instead of AES256 is that some people think the extra security added by AES256 is (for now) worthless and that AES128 seems to be more resistant to timing attacks.

1
votes

"So my question is whether devices using our library will interoperate with modern web browsers (as a server) and modern https/smtps/pop servers (as a client). Are there TLS 1.2 clients/servers that fail to negotiate a TLS_RSA_WITH_AES_128_CBC_SHA connection?"

Yes there are plenty implementations that fail.

Most common:

  1. Clients that still send a SSL2.0 Client Hello
  2. Clients/Servers that only support PFS cipher suite
  3. Servers that still not support TLS 1.2
  4. Servers that no longer support TLS 1.2 - since those only support TLS 1.3

My recommendation is:

  • also support TLS 1.3 (not that hard to implement, I did it)
  • also support DHE

Or use a tool/site like https://www.ssllabs.com/ssltest/index.html and test the compatibility/security of your server until it's sufficient for you.