7 ms·

Since there were so many TLS security bugs due to it's complexity, is there any push to replace it with something simpler and with less choices and attack surfa

Since there were so many TLS security bugs due to it's complexity, is there any push to replace it with something simpler and with less choices and attack surface? Google gave us HTTP/2/3, but don't seem to care about fixing TLS.

nemothekid 5y ago
>Google gave us HTTP/2/3, but don't seem to care about fixing TLS. Google is working on BoringSSL / Tink, which I believe is API compatible, but supports a lot less features. However I think a better way forward might be RustTLS, an implementation which is memory-safe. There is already support in Curl[1], showing there is a path forward for usage in languages other than Rust. [1] https://daniel.haxx.se/blog/2021/02/09/curl-supports-rustls/ https://daniel.haxx.se/blog/2021/02/09/curl-supports-rustls/
- whydoyoucare 5y ago
  LibreSSL is an alternative from OpenBSD.
mrb 5y ago
TLS the protocol has been simplified in version 1.3, with the goal of reducing complexity to improve security. OpenSSL the implementation was forked a few times also with the goal of improving security. Notable forks: LibreSSL, BoringSSL. PS: for all those confused why OpenSSL skipped version 2, it seems it's because FIPS builds identified themselves as version 2 (thanks to poster below!) Also the changelog explains the new version naming scheme: """ Switch to a new version scheme using three numbers MAJOR.MINOR.PATCH. Major releases (indicated by incrementing the MAJOR release number) may introduce incompatible API/ABI changes. Minor releases (indicated by incrementing the MINOR release number) may introduce new features but retain API/ABI compatibility. Patch releases (indicated by incrementing the PATCH number) are intended for bug fixes and other improvements of existing features only (like improving performance or adding documentation) and retain API/ABI compatibility. """ Quoted from: https://www.openssl.org/news/changelog.html https://www.openssl.org/news/changelog.html So there won't be a 3.0.0a, 3.0.0b, etc. They want to make it clear it will be 3.0.1, 3.0.2, etc
- geofft 5y ago
  It's also because the FIPS builds of OpenSSL 1.x identified themselves as 2.x.
  - mrb 5y ago
    I didn't know! Yeah that seems to be the main reason
wolf550e 5y ago
TLS 1.3 is much better than TLS 1.2, and has fewer options and knobs (e.g. no need to choose cipher suites), but it is not what a modern protocol designed from scratch would look like. For that you should look at WireGuard, or the general Noise Protocol Framework. For custom protocols, libsodium would be a popular modern approach. If you need compatibility with TLS, try locking down TLS to only version 1.3, or if you can't do that, lock it down to only TLS 1.2 with tls_ecdhe_rsa_with_aes_128_gcm_sha256.
- chasil 5y ago
  This has been useful advice for many years, although restricting to AEAD is best when possible. https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ https://hynek.me/articles/hardening-your-web-servers-ssl-cip...
nwjsmith 5y ago
Google employ at least one OpenSSL committer and have their own simpler version of the library, BoringSSL.
jborean93 5y ago
IIRC HTTP3/QUIC mandates TLS[1][2] so it itself still relies on TLS. It seems like it's set on TLS 1.3 as a baseline and I would hope the negotiation of the protocol is future compatible but I will admit I haven't fully read the RFCs. [1] https://datatracker.ietf.org/doc/html/rfc9000#section-1 https://datatracker.ietf.org/doc/html/rfc9000#section-1 [2] https://datatracker.ietf.org/doc/html/rfc9001 https://datatracker.ietf.org/doc/html/rfc9001

nemothekid 5y ago

>Google gave us HTTP/2/3, but don't seem to care about fixing TLS. Google is working on BoringSSL / Tink, which I believe is API compatible, but supports a lot less features. However I think a better way forward might be RustTLS, an implementation which is memory-safe. There is already support in Curl[1], showing there is a path forward for usage in languages other than Rust. [1] https://daniel.haxx.se/blog/2021/02/09/curl-supports-rustls/ https://daniel.haxx.se/blog/2021/02/09/curl-supports-rustls/

whydoyoucare 5y ago
LibreSSL is an alternative from OpenBSD.

mrb 5y ago

TLS the protocol has been simplified in version 1.3, with the goal of reducing complexity to improve security. OpenSSL the implementation was forked a few times also with the goal of improving security. Notable forks: LibreSSL, BoringSSL. PS: for all those confused why OpenSSL skipped version 2, it seems it's because FIPS builds identified themselves as version 2 (thanks to poster below!) Also the changelog explains the new version naming scheme: """ Switch to a new version scheme using three numbers MAJOR.MINOR.PATCH. Major releases (indicated by incrementing the MAJOR release number) may introduce incompatible API/ABI changes. Minor releases (indicated by incrementing the MINOR release number) may introduce new features but retain API/ABI compatibility. Patch releases (indicated by incrementing the PATCH number) are intended for bug fixes and other improvements of existing features only (like improving performance or adding documentation) and retain API/ABI compatibility. """ Quoted from: https://www.openssl.org/news/changelog.html https://www.openssl.org/news/changelog.html So there won't be a 3.0.0a, 3.0.0b, etc. They want to make it clear it will be 3.0.1, 3.0.2, etc

geofft 5y ago
It's also because the FIPS builds of OpenSSL 1.x identified themselves as 2.x.
- mrb 5y ago
  I didn't know! Yeah that seems to be the main reason

wolf550e 5y ago

TLS 1.3 is much better than TLS 1.2, and has fewer options and knobs (e.g. no need to choose cipher suites), but it is not what a modern protocol designed from scratch would look like. For that you should look at WireGuard, or the general Noise Protocol Framework. For custom protocols, libsodium would be a popular modern approach. If you need compatibility with TLS, try locking down TLS to only version 1.3, or if you can't do that, lock it down to only TLS 1.2 with tls_ecdhe_rsa_with_aes_128_gcm_sha256.

chasil 5y ago
This has been useful advice for many years, although restricting to AEAD is best when possible. https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/ https://hynek.me/articles/hardening-your-web-servers-ssl-cip...

nwjsmith 5y ago

Google employ at least one OpenSSL committer and have their own simpler version of the library, BoringSSL.

jborean93 5y ago

IIRC HTTP3/QUIC mandates TLS[1][2] so it itself still relies on TLS. It seems like it's set on TLS 1.3 as a baseline and I would hope the negotiation of the protocol is future compatible but I will admit I haven't fully read the RFCs. [1] https://datatracker.ietf.org/doc/html/rfc9000#section-1 https://datatracker.ietf.org/doc/html/rfc9000#section-1 [2] https://datatracker.ietf.org/doc/html/rfc9001 https://datatracker.ietf.org/doc/html/rfc9001