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

Created on 2015-09-15 01:31 by gbremer, last changed 2018-02-25 20:28 by christian.heimes. This issue is now closed.

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 (10)
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 (vstinner) * (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.
msg312854 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2018-02-25 20:28
Both Alex and I agree that verify depth is not the right solution to solve your problem. I'd rather not add more APIs unless they are useful for general audience. OpenSSL has a good default for verify depth.
History
Date User Action Args
2018-02-25 20:28:07christian.heimessetstatus: open -> closed
resolution: rejected
messages: + msg312854

stage: patch review -> resolved
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:17vstinnersetnosy: + vstinner
messages: + msg250741
2015-09-15 08:39:47vstinnersetnosy: + christian.heimes
2015-09-15 02:31:56gbremersetfiles: + verify_depth.patch
hgrepos: + hgrepo316
keywords: + patch
2015-09-15 01:31:16gbremercreate