Bug in openssl s_client verification

[Clemens Lang]

Hi,

----- On 9 Jul, 2015, at 13:25, Jeffrey Walton noloader at gmail.com wrote:

> Emails to secure@ and security@ bounced. RFC 2142
> (https://www.ietf.org/rfc/rfc2142.txt) standardized security@, so its
> not clear to me why it bounced.

Apple controls the mail servers for this domain, and we haven't bothered
them to set up this alias. Since we don't have a dedicated security
group there is no separate mailing list where these addresses would go
to anyway.

Instead, the OpenSSL maintainers in MacPorts are the correct points of
contact here.

> ---------- Forwarded message ----------
> From: Jeffrey Walton <noloader at gmail.com>
> Date: Thu, Jul 9, 2015 at 7:20 AM
> Subject: Re: Fwd: Bug in openssl s_client verification
> To: secure at macports.org, security at macports.org
> Cc: Matt Caswell <matt at openssl.org>
> 
> + the Macports folks since this appears to be a problem with Macports:
> 
>    $ which openssl
>    /opt/local/bin/openssl
> 
> - the OpenSSL folks.
> 
> Sorry to everyone involved about the mixup.
> 
> When I use my copy of OpenSSL in /usr/local/ssl, the verification
> fails as expected.

Which versions of openssl are you using, which flags were used to configure
them, who built them, and how?


>> In fact, I get a "Verify return code: 0 (ok)" even using the wrong CA,
>> like Google CA (https://pki.google.com/):
>>
>> $ openssl s_client -servername 'www.delinat.com' -connect
>> www.delinat.com:443 -CAfile Google-CA.pem
> 
> Above, I used the wrong CA and it still verified. Google does not
> certify the server at www.delinat.com.
> 
> Credit to Dorian on Stack Overflow at http://stackoverflow.com/q/31311993.

See my comments on StackOverflow on why I don't think this is a problem.
OpenSSL's s_client always adds the default verification paths, even if
-CApath or -CAfile are given. It seems that on your /usr/local/ssl build
of OpenSSL, these paths happen to be empty or don't exist.

So the problem is just that OpenSSL's s_client has weird behavior when one
of these flags is passed (because you were assuming that would disable the
defaults, which is a reasonable expectation), but that's just not the case.

Consequently, that's not a security issue from our POV, at least not in the
OpenSSL libraries. It may be an issue in openssl s_client, but it's
probably a bad idea to trust its output for anything other than debugging
anyway.

-- 
Clemens Lang