Recommended
Recommended
More Related Content
Similar to On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption
Similar to On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption (8)
More from vpnmentor
More from vpnmentor (13)
Recently uploaded
Recently uploaded (20)
On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption
- 12. Bleichenbacher’s Agack (CRYPTO 1998) • Oracle usually provided by a server: – Error message if ciphertext is invalid – Other side channels, like Iming • Allows to perform RSA secret key operaIon – Decrypt RSA-PKCS#1 v1.5 ciphertexts – Compute digital RSA signatures 12 CPKCS‘ „valid“ / „invalid“ CPKCS‘‘ „valid“ / „invalid“ ... CPKCS M = Dec(CPKCS)
- 13. Bleichenbacher’s Agack (CRYPTO 1998) • Oracle usually provided by a server: – Error message if ciphertext is invalid – Other side channels, like Iming • Allows to perform RSA secret key operaIon – Decrypt RSA-PKCS#1 v1.5 ciphertexts – Compute digital RSA signatures 13 CPKCS‘ „valid“ / „invalid“ CPKCS‘‘ „valid“ / „invalid“ ... CPKCS M = Dec(CPKCS)
- 14. Bleichenbacher agacks over and over 14 • Bleichenbacher (CRYPTO 1998) • Klima et al. (CHES 2003) • Jager et al. (ESORICS 2012) • Degabriele et al. (CT-RSA 2012) • Bardou et al. (CRYPTO 2012) • Zhang et al. (ACM CCS 2014) • Meyer et al. (USENIX Security 2014) • … Many different techniques to construct the required oracle
- 15. Bleichenbacher agacks over and over • Bleichenbacher (CRYPTO 1998) • Klima et al. (CHES 2003) • Jager et al. (ESORICS 2012) • Degabriele et al. (CT-RSA 2012) • Bardou et al. (CRYPTO 2012) • Zhang et al. (ACM CCS 2014) • Meyer et al. (USENIX Security 2014) • … AssumpIon: Bleichenbacher-like agacks remain a realisFc threat 15 Many different techniques to construct the required oracle
- 16. Bleichenbacher agacks over and over • Bleichenbacher (CRYPTO 1998) • Klima et al. (CHES 2003) • Jager et al. (ESORICS 2012) • Degabriele et al. (CT-RSA 2012) • Bardou et al. (CRYPTO 2012) • Zhang et al. (ACM CCS 2014) • Meyer et al. (USENIX Security 2014) • Aviram et al. (DROWN 2016) • … AssumpIon: Bleichenbacher-like agacks remain a realisFc threat 16 Many different techniques to construct the required oracle
- 30. PracFcal Impact 30 • PracFcal impact on TLS 1.3 rather limited – Typical Bleichenbacher-agacks take hours or days – Machine-to-machine communicaFon? • Nevertheless: – Backwards compaIbility must be considered (cf. Jager, Paterson, Somorovsky, NDSS 2013) – Future improvements of Bleichenbacher’s agack? • DROWN techniques: compute signature in one minute on a single CPU – Leverages new vulnerability in openSSL – All openSSL versions from 1998 to early 2015: – 26% of HTTPS servers were vulnerable
- 31. PracFcal Impact 31 • PracFcal impact on TLS 1.3 rather limited – Typical Bleichenbacher-agacks take hours or days – Machine-to-machine communicaFon? • Nevertheless: – Backwards compaIbility must be considered (cf. Jager, Paterson, Somorovsky, NDSS 2013) – Future improvements of Bleichenbacher’s agack? • DROWN techniques: compute signature in one minute on a single CPU – Leverages new vulnerability in openSSL – All openSSL versions from 1998 to early 2015: – 26% of HTTPS servers were vulnerable
- 32. PracFcal Impact 32 • PracFcal impact on TLS 1.3 rather limited – Typical Bleichenbacher-agacks take hours or days – Machine-to-machine communicaFon? • Nevertheless: – Backwards compaIbility must be considered (cf. Jager, Paterson, Somorovsky, NDSS 2013) – Future improvements of Bleichenbacher’s agack? • Use DROWN technique to forge signature in one minute on a single CPU – Leverages vulnerability in openSSL – All openSSL versions from 1998 to early 2015 – 26% of HTTPS servers were vulnerable
- 35. Agack on the QUIC protocol Server S QUIC TLS 1.0 RSA QUIC Bleichenbacher‘s Agack Full QUIC protocol • A can run Bleichenbacher’s agack before Lisa connects to S • One signature is equivalent to the secret key of S • PracIcal, even if agack takes weeks! Agacker A
- 39. Further difficulFes • Key separaFon not supported by major servers/browser implementaFons • CerFficates cost money (extended validaFon) • X.509 supports “sign/encrypt-only” certs – “Sign-only” certs for “signing” cipher suites (incl. TLS 1.3) – “Encrypt-only” keys for TLS-RSA cipher suites – Do browsers really check this? • Mozilla developer: “No. And no intenIon to change this, because of usability/compaIbility.”
- 40. Further difficulFes • Key separaFon not supported by major servers/browser implementaFons • CerFficates cost money (extended validaFon) • X.509 supports “sign/encrypt-only” certs – “Sign-only” certs for “signing” cipher suites (incl. TLS 1.3) – “Encrypt-only” keys for TLS-RSA cipher suites – Do browsers really check this? • Mozilla developer: “No. And no intenIon to change this, because of usability/compaIbility.”
- 41. Further difficulFes • Key separaFon not supported by major servers/browser implementaFons • CerFficates cost money (extended validaFon) • X.509 supports “sign/encrypt-only” certs – “Sign-only” certs for “signing” cipher suites (incl. TLS 1.3) – “Encrypt-only” keys for TLS-RSA cipher suites – Do browsers really check this? • Mozilla developer: “No. And no intenIon to change this, because of usability/compaIbility.”
- 42. Further difficulFes • Key separaFon not supported by major servers/browser implementaFons • CerFficates cost money (extended validaFon) • X.509 supports “sign/encrypt-only” certs – “Sign-only” certs for “signing” cipher suites (incl. TLS 1.3) – “Encrypt-only” keys for TLS-RSA cipher suites – Do browsers really check this? • Mozilla developer: “No. And we have no intenIon to change this, because of usability/compaIbility.”
- 43. Summary and recommendaFons • Removing RSA-PKCS#1 v1.5 from TLS is an excellent decision – Not sufficient to protect completely against weakness • TLS 1.3 is more “robust” than QUIC – But not immune – Signing ephemeral values is a good idea • Proper key separaIon is difficult in pracFce – Support in future versions of X.509? – Support by browsers? 43
- 44. Summary and recommendaFons • Removing RSA-PKCS#1 v1.5 from TLS is an excellent decision – Not sufficient to protect completely against weakness • TLS 1.3 is more “robust” than QUIC – But not immune – Signing ephemeral values is a good idea • Proper key separaIon is difficult in pracFce – Support in future versions of X.509? – Support by browsers? 44 Thank you!