2

Assuming one has complete control the implementation of TLS 1.0 on both the client and the server side, are there any known vulnerabilities that can not be prevented at all? From what I have researched, there doesn't seem to be anything, not that I am advocating use of 1.0 over 1.2, I'm just curious.

Thanks.

Improve this question
3

I think that if:

  1. Both sides implement empty record protocol packets or the 1/n-1 split[1] to mitigate the BEAST attack
  2. Both sides send bad_record_mac alert rather than the decryption_failed alert in case of CBC padding error

Then TLS 1.0 is as secure as TLS 1.1. Then, if you also add:

  1. Both sides implement correct timing safe checking of MAC for MAC-then-encrypt, including lucky13, which is so difficult basically everyone [2][3] made a bad bug while trying to implement it and one of the best TLS implementers in the world punted on implementing it for the Golang TLS stack because it's too hard [4][5].

you have a system in which the TLS CBC ciphersuites are secure. Of course, the recommendation is to switch to AEAD.

1 - https://bugzilla.mozilla.org/show_bug.cgi?id=665814#c59

2 - https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/

3 - https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13

4 - https://github.com/golang/go/issues/7418#issuecomment-66091828

5 - https://www.imperialviolet.org/2013/02/04/luckythirteen.html

Improve this answer
2
  • I'm not certain those are the only issues — TLS is a beast — but I agree with the conclusion. – Matt Nordhoff Sep 27 '16 at 23:42
  • For example, some TLS CBC implementations were vulnerable to POODLE, even though TLS 1.0 required it to be fixed. And implementing RSA is its own story. – Matt Nordhoff Sep 28 '16 at 5:11

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.