"My understanding is that when we build an osx release, we bundle openssl."

Well, no, we don't exactly do that today.  We have recently been doing that for the 10.5 installer because the 10.5 system version of OpenSSL is so old as to be unusable for PyPI downloads (and pretty much everything else).  But the much more commonly used 10.6+ installer dynamically links with the latest (but deprecated) system OpenSSL libs shipped with OS X, libs that are old but usable and still receiving Apple security fixes on current systems.  The main reason for doing that is that this solution uses the Apple-provided system and user keychains for certificate management.  There are other drawbacks, though, and we have an open issue to deal with that.  (The python.org Pythons are not affected by the lack of headers since the libs are still shipped in OS X 10.11.)  What I think this issue should address is making it easier to build Python on 10.11 (and earlier systems) with newer versions of OpenSSL.  It should be easier to use OpenSSL libs supplied by popular third-party distributors like Homebrew and MacPorts.  Without having thought through all the details, I'm thinking it might be best to provide a configure-time check and option, possibly with standard options for the system,  Homebrew (default path), MacPorts (default path), and user-built SSL headers/libs.  It would also be good to provide something which will build the handful of important missing and/or newer third-party libs needed on OS X by the interpreter and standard library, like SSL libs, liblzma, and Tk.  But that's a separate issue.