4 ms·

LibreSSL 3.2.0 – TLS 1.3

127 points by laamalif 6y ago

tialaramex 6y ago
This item from their change list: > Use non-expired certificates first when building a certificate chain. .. Is relevant to the recent expiry of Sectigo's old "AddTrust" root. If your library cheerfully assembles a trust path with the expired root and then concludes the certificate isn't valid because the root is expired you're pointlessly inconvenienced compared to a library that can use the same raw materials to discover a working trust path with no expired certificates.
- notaplumber 6y ago
  Yes. https://github.com/libressl-portable/portable/issues/595#issuecomment-636512973 https://github.com/libressl-portable/portable/issues/595#iss...
- user5994461 6y ago
  Would be nice to patch openssl and python to skip expired certificates too when there is a newer one available.
  - mperham 6y ago
    I believe this was fixed in openssl 1.1.1 but there are millions of devices still on 1.0.x
    - EdwardDiego 6y ago
      Yeah, we're seeing it in coworkers still running OSX Mojave (albeit with older LibreSSL instead of OpenSSL) using the default curl. Catalina users seem okay though.
notaplumber 6y ago
To those wondering, LibreSSL has its own TLS 1.3 implementation. Client support shipped in LibreSSL 3.1.1. https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.1-relnotes.txt https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.1-... https://www.openbsd.org/papers/bsdcan2019-tls13.pdf https://www.openbsd.org/papers/bsdcan2019-tls13.pdf
- tialaramex 6y ago
  As those release notes mention (and the new ones do too) you don't get a TLS 1.3 API So you only benefit from features that already existed in TLS 1.2 (using the same API) or do not require an API such as the reduced round trips for initiating a new connection. In particular you can't use 0RTT "Early" data because the specification asks that only be supplied via a dedicated API in both clients and servers. The reason is that Early data might be replayed by an attacker in some cases despite all practical countermeasures and so your application software needs to make an explicit decision about whether it's acceptable to use Early data. Providing a separate API forces you to actually confront that decision and not get surprised by upgrading to TLS 1.3 and finding now you're subject to a replay attack.
asveikau 6y ago
As someone who uses OpenBSD on a few machines it strikes me that this is going into OpenBSD's -current branch so won't be released for another 6 months, with OpenBSD 6.8. As I parse more and look at the libressl site I see that similarly, this is a development release and the stable release, 3.1.2, matches OpenBSD 6.7.
deleted 6y ago
[deleted]
jedisct1 6y ago
This is great news! However, note that the OpenSSL API compatibility layer doesn't support TLS 1.3 yet. So, if you're using Nginx or something else that doesn't use the LibreSSL API, you're out of luck for now.
- notaplumber 6y ago
  This is simply not true. For a lot software you will get 1.3 automatically, for example mutt and irssi pick it up just fine. The existing APIs will work and LibreSSL will prefer TLS 1.3 over 1.2 if clients/servers support it. OpenSSL offers some additional APIs for certain TLS 1.3 features, but are hardly mandatory.

127 points by laamalif 6y ago

This item from their change list: > Use non-expired certificates first when building a certificate chain. .. Is relevant to the recent expiry of Sectigo's old "AddTrust" root. If your library cheerfully assembles a trust path with the expired root and then concludes the certificate isn't valid because the root is expired you're pointlessly inconvenienced compared to a library that can use the same raw materials to discover a working trust path with no expired certificates.

notaplumber 6y ago
Yes. https://github.com/libressl-portable/portable/issues/595#issuecomment-636512973 https://github.com/libressl-portable/portable/issues/595#iss...
user5994461 6y ago
Would be nice to patch openssl and python to skip expired certificates too when there is a newer one available.
- mperham 6y ago
  I believe this was fixed in openssl 1.1.1 but there are millions of devices still on 1.0.x
  - EdwardDiego 6y ago
    Yeah, we're seeing it in coworkers still running OSX Mojave (albeit with older LibreSSL instead of OpenSSL) using the default curl. Catalina users seem okay though.

notaplumber 6y ago

To those wondering, LibreSSL has its own TLS 1.3 implementation. Client support shipped in LibreSSL 3.1.1. https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.1-relnotes.txt https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-3.1.1-... https://www.openbsd.org/papers/bsdcan2019-tls13.pdf https://www.openbsd.org/papers/bsdcan2019-tls13.pdf

tialaramex 6y ago
As those release notes mention (and the new ones do too) you don't get a TLS 1.3 API So you only benefit from features that already existed in TLS 1.2 (using the same API) or do not require an API such as the reduced round trips for initiating a new connection. In particular you can't use 0RTT "Early" data because the specification asks that only be supplied via a dedicated API in both clients and servers. The reason is that Early data might be replayed by an attacker in some cases despite all practical countermeasures and so your application software needs to make an explicit decision about whether it's acceptable to use Early data. Providing a separate API forces you to actually confront that decision and not get surprised by upgrading to TLS 1.3 and finding now you're subject to a replay attack.

asveikau 6y ago

As someone who uses OpenBSD on a few machines it strikes me that this is going into OpenBSD's -current branch so won't be released for another 6 months, with OpenBSD 6.8. As I parse more and look at the libressl site I see that similarly, this is a development release and the stable release, 3.1.2, matches OpenBSD 6.7.

deleted 6y ago

[deleted]

jedisct1 6y ago

This is great news! However, note that the OpenSSL API compatibility layer doesn't support TLS 1.3 yet. So, if you're using Nginx or something else that doesn't use the LibreSSL API, you're out of luck for now.

notaplumber 6y ago
This is simply not true. For a lot software you will get 1.3 automatically, for example mutt and irssi pick it up just fine. The existing APIs will work and LibreSSL will prefer TLS 1.3 over 1.2 if clients/servers support it. OpenSSL offers some additional APIs for certain TLS 1.3 features, but are hardly mandatory.