[issue13647] Python SSL stack doesn't securely validate certificate (as client)

[Dan Kaminsky]

Dan Kaminsky <dan at doxpara.com> added the comment:

On Fri, Dec 23, 2011 at 4:14 AM, Antoine Pitrou <report at bugs.python.org>wrote:

>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> > You need to check expiration date of the cert in question, and I
> > suppose invocation date as well.
> > You need to look at each of the CNs in the subject name, as well as
> > each of the DNSname types in the SAN extension.
> > You *absolutely must* make sure that each of the intermediate
> > certificates has Basic Constraints: CA set to True.  Otherwise a
> > certificate for foo.com can sign for bar.com (this keeps happening).
>
> I'm confident this is already done by OpenSSL (if requested by user,
> which means using CERT_REQUIRED or CERT_OPTIONAL in Python's ssl module
> - these map to OpenSSL's SSL_VERIFY_PEER).
>
> I guess it would be easy to check this by providing an outdated
> certificate - perhaps I'll give it a try.
>

Be sure to support SAN.  People forget that, and the API makes it a pain in
the butt (the validator doesn't even know who you're validating for).

>
> > > > A) Integrate the Mozilla CA pack into Python, updating it with each
> > > > security release.
> >
> > > I suggest you discuss this on python-dev:
> > > http://mail.python.org/mailman/listinfo/python-dev
> >
> > It's an ugly dependency, I know.  X.509 suffers from a "false
> > coherence" design, in which a couple of parties actively work to make
> > it look like it has a coherent trust model.  The best you can do is
> > try to borrow/leverage the work of one of those parties.
>
> I suppose distributing CA certificates is a practical solution for the
> user, *if* we are dedicated enough (e.g. release managers would have to
> agree with the burden of tracking changes, and possibly making emergency
> releases when a cert must be removed). That's the reason I suggest
> asking on python-dev; I don't feel like making that decision alone.
>

The CA set doesn't change *often*, but it does shift from time to time.

The right thing would be to use the in-built cert set if and only if the
system certs couldn't be checked.

>
> That said, system OpenSSL builds on Linux (and perhaps OS X) should have
> been compiled against a well-known system location of CA certificates
> maintained by the OS vendor. In this case, you can simply use
> SSLContext.set_default_verify_paths
> (
> http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_default_verify_paths)
> That doesn't help under Windows, though (where we build OpenSSL
> ourselves so that the ssl module can be bundled in installers).
>

Whatever you've got right now isn't good enough to either be on by default,
or warn by default.  I wouldn't even recommend warning if you didn't ship
with certs.

Technically, you could check the Windows certificate stores too, if you
wanted to write that code.

Before going to python-dev, what do you think is feasible,
implementation-wise?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13647>
_______________________________________