Dan Kaminsky <d...@doxpara.com> added the comment: On Fri, Dec 23, 2011 at 4:14 AM, Antoine Pitrou <rep...@bugs.python.org>wrote:
> > Antoine Pitrou <pit...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue13647> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
