
TLS verification vulnerability in LibreSSL 2.5.1-2.5.3 - liuw
http://seclists.org/oss-sec/2017/q2/145
======
erdeszt
Here's the referenced commit for the interested: [https://github.com/libressl-
portable/openbsd/commit/ddd98f8e...](https://github.com/libressl-
portable/openbsd/commit/ddd98f8ea741a122952185a36c1396c14c2fda74#diff-027facc0b7c35aa46b0e8fa7b467f1c4)

To be honest I'm kinda surprised that even after the 'goto fail' story people
still write code in this questionable style(I know this particular issue is
not stemming from the lack of curly braces, but still).

~~~
PhantomGremlin
_surprised that even after the 'goto fail' story people still write code in
this questionable style_

LibreSSL didn't spring into existence out of whole cloth. It started as a fork
of OpenSSL, which goes back to 1998.

The "questionable style" is from legacy code. It would be a massive effort to
revise the entire codebase. And if LibreSSL did that, it would make it harder
to import changes from OpenSSL and from other forks such as BoringSSL.

~~~
kbenson
> it would make it harder to import changes from OpenSSL

When it's a choice between making it easier to import changes or harder to
import _bugs_ , I know which one I think is more important when dealing with a
security library.

~~~
askmike
I don't think you see the amount of work that would go into refactoring a
project of this scale whilst keeping up with the latest patches from upstream.

~~~
kbenson
I do understand the the amount of work, but that wasn't the only argument
presented. It was also presented as making it harder to accept patches. Since
one of the goals of LibreSSL is to start applying security best practices, and
one of the reasons for its existence is the poor quality and recurrent
problems with OpenSSL, keeping compatibility with OpenSSL to make it easier to
accept patches should be _very_ low on the list of priorities.

Put another way, if you forked because upstream was crap, not changing because
it makes it easier to accept upstream patches is a poor reason not to change
something that might benefit from it.

~~~
treebeard901
I tend to agree, maybe with one exception. Would the end result of a LibreSSL
refactor introduce more bugs than leaving the current process in place (with
improvements)? It seems like we can't know the answer to that question until
it happens so speaking definitively about either option becomes questionable.

~~~
kbenson
Definitively, no, but the lack of of a definitive (or even _likely_ ) answer
still makes the it a poor choice, if not in the sense of "wrong" than in the
sense of "this is something that needs to be figured out based on your goals,
and until you do choices based on this will not be grounded on fact" so it's
poor in that it's not well grounded.

That said, the relatively poor history of OpenSSL and the relatively high
quality of software that comes out of the OpenBSD project leads me to think I
know what the likely outcome of refactoring code is in this particular
scenario.

~~~
treebeard901
That is certainly true and perhaps another advantage exists from a refactor of
LibreSSL: Finding unknown bugs in OpenSSL that may only be revealed during
refactoring.

------
notaplumber
The severity of this issue is being overplayed, some programs were returning 1
in callbacks, a lot of software in the wild interpreted it the way LibreSSL
did and hence the attempt at error sanitization. There are patches out for
OpenBSD 6.1, LibreSSL 2.5.4 contains the fix.

[https://www.openbsd.org/errata61.html](https://www.openbsd.org/errata61.html)

[https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.5.4-...](https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/libressl-2.5.4-relnotes.txt)

OpenBSD 6.1 users can now also run syspatch(8).

------
akerro
Who uses LibreSSL on production or in their apps?

~~~
DorothySim
Note that it is about TLS _client_ certificates so it's not as widespread as
it seems (unless you use these certs of course :) ).

~~~
adekok
EAP-TLS. Wifi authentication for many enterprises and universities.

Most of which won't be using LibreSSL, tho...

~~~
cesarb
Not to mention TLS VPNs like openvpn.

------
btrask
Does this affect users of libtls?

