4

I recently observed that Exchange Online has switched to a lower version of TLS protocol. Emails from Exchange Online to Gmail and other Office 365 tenants are now sent over TLS 1.0 instead of TLS 1.2, albeit with the same cipher suites (“ECDHE-RSA-AES128-SHA” and “TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384”, respectively).

I’m not an expert in cryptography. I’d like to know how much this change matters in terms of security, both theoretically and practically. Is there a reason for me to worry about it?

[Update Updates are now being deployed to fix this issue. Still I’d like to get an answer to my question.]

3

Protocol versions matter, even given the same cipher suite, because the suite specifies the primitives but not necessarily how they are to be used. For example, the critical difference between SSLv3 and TLS1.0 that makes the former vulnerable to POODLE is that TLS mandates validation of the padding, and SSLv3 does not. TLS 1.1 requires an explicit initialization vector (rather than the implicit IV used in TLS1.0 block ciphers), and changes how padding errors are handled; neither of these things are particular to any given ciphers.

Of course, just because a protocol requires something doesn't mean the implementer will do it correctly. Some network gear (like load balancers) was handling TLS1.0 connections but failing to validate the padding (in violation of the TLS spec, but not the SSL spec), making them also vulnerable to POODLE. Similarly, one of the things that made Heartbleed so bad was that OpenSSL allowed heartbeat messages to be sent before the handshake was completed, allowing an untrusted attacker to man-in-the-middle a connection and attack both sides during the handshake. (Of course, the buffer over-read at the core of Heartbleed was also an implementation failure, but the standard probably doesn't explicitly called out that you're supposed to only return the data that the other side sent you instead of arbitrary memory. It does specify when a heartbeat message is legal, though.)

Protocol versions can also add support for cipher suites. TLS 1.2 added support for authenticated encryption ciphers, enabling the addition of suites based on AES-GCM and AES-CCM. However, even if you're using the same cipher suites, you're more at risk when the protocol is older.

For more detail, you might want to ask on the Crypto SE. SSL/TLS is complicated and you may find people over there who can explain the relevant pieces more clearly.

  • FWIW RC4 is not CBC and thus not affected by SSL3 POODLE or TLS1.0 BEAST/Vaudenay -- it is equally broken in all released protocol versions. – dave_thompson_085 Sep 18 '16 at 13:25
  • @dave_thompson_085: True, but... nobody had mentioned anything about RC4, and it is reasonably well-known that RC4, the cryptographic primitive, is broken. The primitives, and indeed whole suites, actually mentioned in the question are not known to be broken the same way that RC4 is, so it didn't seem necessary to bring it up. – CBHacking Sep 18 '16 at 19:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.