Hi, ----- On 9 Jul, 2015, at 13:25, Jeffrey Walton [email protected] 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 <[email protected]> > Date: Thu, Jul 9, 2015 at 7:20 AM > Subject: Re: Fwd: Bug in openssl s_client verification > To: [email protected], [email protected] > Cc: Matt Caswell <[email protected]> > > + 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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
