Create a dummy certificate and build an ssl context like this:

ctx = ssl.SSLContext(ssl.PROTOCOL_TLSv1)
ctx.verify_mode = ssl.CERT_REQUIRED
ctx.load_verify_locations(cadata=dummy_certificate)

Then try to connect to a public service like this:

u = urllib.request.urlopen('https://www.google.com', context=ctx)
data = u.read()

Python will validate the server certificate even though it should reject it. Attached is a script to demonstrate this.

This happens with Python 3.4.3 on OSX 10.10.4. Running the same script in Ubuntu raises a certificate rejection exception as expected.

I think the only way to actually fix this, is to stop using the OpenSSL provided by OSX.

Do we know exactly why OS X's OpenSSL accepts it?

The fork of OpenSSL that Apple ships also looks at the CA list in the Keychain. IIRC that cannot be disabled. 

BTW. Annoyingly this fork uses a private API to access the keychain, which means we couldn't optionally use this behavior when not using Apple's binaries. 

--
On the road, hence brief. 

Op 17 jul. 2015 om 17:55 heeft Antoine Pitrou <report@bugs.python.org> het volgende geschreven:

> 
> Antoine Pitrou added the comment:
> 
> Do we know exactly why OS X's OpenSSL accepts it?
> 
> ----------
> nosy: +ned.deily, pitrou, ronaldoussoren
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue24646>
> _______________________________________

And the tradeoff for supplying private copies of newer OpenSSL libs with the Pythons installed by python.org OS X installers is that we would then need to solve the CA management problem for all users of those Pythons.  So far there hasn't been a good solution to that problem so we have elected to continue to use the least unattractive solution of continuing to use the Apple-supplied libs with the 10.6+ installer variants (Issue17128).  Eventually, we will have to bite the bullet and come up with s better solution as Apple will likely eventually stop shipping OpenSSL libs altogether.

For what it's worth, the El Capitan Beta's apparently don't ship with OpenSSL headers anymore though they do still ship with the dylibs.

> For what it's worth, the El Capitan Beta's apparently don't ship with
> OpenSSL headers anymore though they do still ship with the dylibs.

Hmm, I had tested installing existing python.org binary releases with the first DPs of 10.11 and I *thought* I had tested building from source, as well.  But, yes, it appears that the headers are no longer there, at least on the most recent DP I have installed.  I'm traveling and essentially "off-the-net" for another week but I will take a closer look at the situation then.

Using our own OpenSSL build should be saver in the long run anyway.  Apple provides enough API’s to reproduce the behaviour of Apple’s build in a cleaner way (by making the loading of system CA certs an explicit action). Problem is: that likely requires using API’s higher up in the API stack, which could cause problems when using os.fork without os.exec (the old “CoreFoundation crashes in child processes” problem).

Ronald

> On 18 Jul 2015, at 06:22, Ned Deily <report@bugs.python.org> wrote:
> 
> 
> Ned Deily added the comment:
> 
>> For what it's worth, the El Capitan Beta's apparently don't ship with
>> OpenSSL headers anymore though they do still ship with the dylibs.
> 
> Hmm, I had tested installing existing python.org binary releases with the first DPs of 10.11 and I *thought* I had tested building from source, as well.  But, yes, it appears that the headers are no longer there, at least on the most recent DP I have installed.  I'm traveling and essentially "off-the-net" for another week but I will take a closer look at the situation then.
> 
> ----------
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue24646>
> _______________________________________

It's a platform bug but Apple doesn't consider it a bug. Hynek has analyzed and reported it over a year ago: https://hynek.me/articles/apple-openssl-verification-surprises/

Ronald: Can you check if SecTrustSettingsCopyCertificates() or SecTrustCopyAnchorCertificates() are affected by the fork() issue?

I'll check, but they probably are because the use data structures from CoreFoundation.

BTW. I think someone (me?) should write down the problems with using higher levels in the API stack w.r.t. os.fork in a PEP-style document. This can then be used to decide whether or not we want to use such APIs in the stdlib (and if so, what should be changed to avoid crashes).

I'm slighlty in favour of using such APIs if that makes Python better on OSX, even if that introduces slight differences w.r.t. Linux (for example, multiprocessing could no longer use only os.fork).  The disadvantage is that it would no longer be possible to develop and test pre-forking code on OSX before deploying to Linux.

The attached program (which is pure C except for a call to NSLog) calls SecTrustCopyAnchorCertificates in a child process (and with a minor change the other function as well).

This doesn't crash for me. 

However, that doesn't really mean anything: We know from earlier bugreports that calling _scproxy._get_proxy_settings in a child process can crash, and that is something that only sporadicly happens for me (I cannot reproduce it with a trivial script).

Maybe this is something that was fixed in 10.10, but I'd be surprised at that (and that doesn't really help us as we support older OSX releases as well). I cannot test on other OSX releases at the moment, I'm at europython and don't have access to my test systems.

Ronald, FWIW, your test program seems to work without crashing on both 10.6 and 10.8; not surprisingly, it failed to compile on 10.5 (no 'errSecSuccess').

I think this bug is no longer relevant with Python 3.5 and newer. We no longer use system OpenSSL in our Python builds.

Ned, is that right?

We will no longer use the OS X system OpenSSL for 3.6.