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?

I am not sure there are currently many servers supporting TLS that would fail negotiating <code>TLS_RSA_WITH_AES_128_CBC_SHA</code> with <code>TLSv1.2</code> as it is THE mandatory cipher suite for <code>TLSv1.2</code>. However there are things to keep in mind: <ul> <li> <code>TLS_RSA_WITH_3DES_EDE_CBC_SHA</code> is mandatory for <code>TLSv1.0</code> and <code>TLSv1.1</code> but due to security reasons it is no longer supported by every server,</li> <li>Mozilla recommends (and it is not the only one) to favor <code>AES128</code> instead of <code>AES256</code>,</li> <li>Perfect Forward Secrecy (PFS), allowed by DHE or ECDHE is now a must-have feature.</li> </ul> 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: <ol> <li><code>TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256</code></li> <li><code>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</code></li> <li><code>TLS_RSA_WITH_AES_128_GCM_SHA256</code></li> <li><code>TLS_RSA_WITH_AES_128_CBC_SHA</code></li> </ol> I would say that these 4 cipher suites bring enough security and compatibility with <code>TLSv1.2</code> servers. Now the question of supporting only <code>TLSv1.2</code> is another question, but if you have enough space, I recommend you to add <code>TLSv1.0</code> too (<code>TLSv1.1</code> does not provide extra compatibility). PS: The reason why <code>AES128</code> is favored instead of <code>AES256</code> is that some people think the extra security added by <code>AES256</code> is (for now) worthless and that <code>AES128</code> seems to be more resistant to timing attacks.

Can a TLS 1.2 server/client get by with just TLS_RSA_WITH_AES_128_CBC

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?

What version of TLS is used by client?

1. Click on: Start -> Control Panel -> Internet Options 2. Click on the Advanced tab 3. Scroll to the bottom and check the TLS version described in steps 3 and 4: 4.

How do I know if TLS 1.2 is compatible?

Browse to Tools → Internet options → Advanced. 2. Under Security section, you will see a list of SSL and TLS protocols supported. Enable Use TLS 1.2 if present.

How do I know if a client supports TLS version?

If the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client\Enabled is present, value should be 1. Check if TLS 1.2 is set as the default secure protocol in WinHTTP for Windows versions Windows Server 2008 R2, Windows Server 2012, and Windows 7.

Is TLS 1.2 Vulnerable?

Many of the major vulnerabilities in TLS 1.2 had to do with older cryptographic algorithms that were still supported. TLS 1.3 drops support for these vulnerable cryptographic algorithms, and as a result it is less vulnerable to cyber attacks.

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:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
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.

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

Tags:

ssl

tls1.2

tomlogic

People also ask

1 Answers

Jyo de Lys

Recent Activity

Donate For Us