classification
Title: SSL_set_verify_depth not exposed by the ssl module
Type: enhancement Stage: patch review
Components: Library (Lib), SSL Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: Alex Gaynor, christian.heimes, gbremer, haypo
Priority: normal Keywords: patch

Created on 2015-09-15 01:31 by gbremer, last changed 2017-09-12 16:40 by Alex Gaynor.

Files
File name Uploaded Description Edit
verify_depth.patch gbremer, 2015-09-15 02:31 Patch for 2.7
verify_depth-3.5.patch gbremer, 2015-09-16 12:08 Patch for 3.5 review
Messages (9)
msg250718 - (view) Author: Grant Bremer (gbremer) * Date: 2015-09-15 01:31
The SSL_set_verify_depth OpenSSL method is not currently exposed by the ssl module. The context object would seem to be the proper place for it as an instance method.
msg250741 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2015-09-15 08:43
+    if (depth < 0 || depth > 100) {

Why 100 and not 10 or 1000?

SSL_CTX_set_verify_depth() is unable to check the depth?

The patch lacks unit tests and documentation.

The patch is for Python 2.7, it would be better to write a patch for the default branch (future Python 3.6).
msg250782 - (view) Author: Grant Bremer (gbremer) * Date: 2015-09-15 16:55
I had thought that I had found documentation that the max depth is 100 and anything higher is ignored -- and as I read that back to me, I believe I read an example passage and interpreted it incorrectly. I'll remove that.

We primarily use Python 2.7, so I started there. I'll submit another patch with changes on the 3.5 branch and add tests.
msg250842 - (view) Author: Grant Bremer (gbremer) * Date: 2015-09-16 12:08
Attached is a patch for the 3.5 branch. The test is minimal -- we are relying on the underlying OpenSSL library and its context to manage the data. I have removed the data validation from the set function -- OpenSSL seems happy to accept negative numbers for depth, even if that is a non-sensical value. I have started on the documentation, and can do a more comprehensive job if the code section is good or mostly good. I'll do the same for the 2.7 patch.
msg301478 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2017-09-06 15:03
The patch looks fairly simple, but what is your use case? I don't like to clobber the SSLContext with additional features. I have never been in a situation that required me to change the verify depths for chain building. Why do you want to restrict or enlarge the verify depths? OpenSSL's default verify depths is sensible.
msg301479 - (view) Author: Alex Gaynor (Alex Gaynor) Date: 2017-09-06 15:10
+1 on making sure we have a concrete use case before expanding the API
msg301838 - (view) Author: Grant Bremer (gbremer) * Date: 2017-09-10 22:57
The use case is for an internal PKI implementation where verification should be, needs to be limited to certificates signed by the PKI CA and no higher to, say, a larger realm which would not be appropriate.
msg301972 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2017-09-12 16:17
Grant,

I'm not sure I follow you. Do I understand correctly that you want to call SSL_CTX_set_verify_depth(ctx, 1), in order to enforce that a peer cert is directly signed by your CA?

That doesn't sound like a good use of SSL_CTX_set_verify_depth(), because it only works for a simple case without an intermediate CA. Most real-world cases have one or more intermediate CAs.
msg301975 - (view) Author: Alex Gaynor (Alex Gaynor) Date: 2017-09-12 16:40
For the use case of "I want to trust this CA, but I don't want to trust any of it's sub CAs" I think there's a simpler solution than expanding our API:

Create your own cross-sign of the root you want, and add a pathLenConstraint: 0 to the basicConstraints extension.

By create a cross-sign, I mean a new certificate with the same subject/SPKI/SKI/other-extensions, but instead of being self-signed, sign it under some random private key you throw away. And then use that as your trust root, instead of the original certificate.

This should work fine for validation.
History
Date User Action Args
2017-09-12 16:40:39Alex Gaynorsetmessages: + msg301975
2017-09-12 16:17:07christian.heimessetmessages: + msg301972
2017-09-10 22:57:13gbremersetmessages: + msg301838
2017-09-06 15:10:51Alex Gaynorsetnosy: + Alex Gaynor
messages: + msg301479
2017-09-06 15:03:20christian.heimessetmessages: + msg301478
2016-09-15 07:53:50christian.heimessetassignee: christian.heimes
components: + SSL
2016-09-08 15:31:32christian.heimessetversions: + Python 3.7, - Python 2.7, Python 3.6
2015-09-16 12:08:24gbremersetfiles: + verify_depth-3.5.patch

messages: + msg250842
2015-09-16 12:04:48gbremersethgrepos: - hgrepo316
2015-09-15 16:55:10gbremersetmessages: + msg250782
versions: + Python 2.7
2015-09-15 16:18:35berker.peksagsetstage: patch review
versions: + Python 3.6, - Python 2.7, Python 3.5
2015-09-15 08:43:17hayposetnosy: + haypo
messages: + msg250741
2015-09-15 08:39:47hayposetnosy: + christian.heimes
2015-09-15 02:31:56gbremersetfiles: + verify_depth.patch
hgrepos: + hgrepo316
keywords: + patch
2015-09-15 01:31:16gbremercreate