Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
LibreSSL 3.2.0 – TLS 1.3 (openbsd.org)
127 points by laamalif on June 1, 2020 | hide | past | favorite | 10 comments


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.



Would be nice to patch openssl and python to skip expired certificates too when there is a newer one available.


I believe this was fixed in openssl 1.1.1 but there are millions of devices still on 1.0.x


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.


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-...

https://www.openbsd.org/papers/bsdcan2019-tls13.pdf


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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: