Re: SSL_CTX_set_verify uses the "wrong" certificate chain (cross signed certificate )

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I just had a big laugh Reading this. I never had to dig into openssl before so I unfortunately had to try to understand your API with eventmachine as an example. Silly me.
 
On the other hand I suppose if we do not call this it would pick the "default" trust store from the system which seems to be the case here because it can find /usr/lib/ssl/certs/2e5ac55d.0 . 

Actually the part responsible for this lookup is not part of the openssl library but from the ruby callback function registered through SSL_set_verify  which as you said tries to verify each certificate in isolation ( with a configured store this time )

So I suppose openssl skip the part that is supposed to build the chain when no store is configured.

Do whatever it takes to never rely on this code again.  Even abandon Ruby if that's what it takes...

 Hopefully we do not have a lot of code relying on eventmachine so we'll see if we can improve the library or move away from it.

Thanks so much for your time, explanation and responsiveness.


On Sun, 3 Oct 2021, 17:37 Viktor Dukhovni, <openssl-users@xxxxxxxxxxxx> wrote:
On Sun, Oct 03, 2021 at 01:54:44PM +0200, Alex Robuchon wrote:

> Thanks for the detailed answer.
>
> From strace I can see that I'm using /lib/x86_64-linux-gnu/libssl.so.1.1
>
> When I use the eventmachine lib that uses the wrong cert chain I can see
> with strace :

Run as far away from eventmachine as you can.  The very first thing you
see in the code is a compiled in default "private key" (for all the
world to share).

    https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L30-L123

Though applications can override these, and supply actual private keys,
it does not get better from there...  The comments in the code show the
author punting on understanding the OpenSSL API and just guessing what
to do.

Indeed the code creates SSL_CTX objects without specifying either the
default or explicit trust stores.

The real disaster is in:

    https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L675-L698

with a completely broken SSL verification callback, that completely
ignores all errors from the chain construction and signature
verification code, and just attempts to "verify" each certificate in
*isolation*.

    https://github.com/eventmachine/eventmachine/blob/5cac87805f26b5cdc29eca713871c3374131d786/ext/ssl.cpp#L693-L697

This means:

    * No verification of chain signatures
    * No verification of path constraints
    * No verification of name constraints
    * No hostname checks.
    * ...

This code was written by someone too clueless to know what they're
doing and too lazy to bother to learn.  DO NOT USE IT.

Do whatever it takes to never rely on this code again.  Even abandon
Ruby if that's what it takes...

--
    Viktor.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux