This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2015年09月15日 01:31 by gbremer, last changed 2022年04月11日 14:58 by admin. 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 |
| 2022年04月11日 14:58:21 | admin | set | github: 69302 |
| 2018年02月25日 20:28:07 | christian.heimes | set | status: open -> closed resolution: rejected messages: + msg312854 stage: patch review -> resolved |
| 2017年09月12日 16:40:39 | Alex Gaynor | set | messages: + msg301975 |
| 2017年09月12日 16:17:07 | christian.heimes | set | messages: + msg301972 |
| 2017年09月10日 22:57:13 | gbremer | set | messages: + msg301838 |
| 2017年09月06日 15:10:51 | Alex Gaynor | set | nosy:
+ Alex Gaynor messages: + msg301479 |
| 2017年09月06日 15:03:20 | christian.heimes | set | messages: + msg301478 |
| 2016年09月15日 07:53:50 | christian.heimes | set | assignee: christian.heimes components: + SSL |
| 2016年09月08日 15:31:32 | christian.heimes | set | versions: + Python 3.7, - Python 2.7, Python 3.6 |
| 2015年09月16日 12:08:24 | gbremer | set | files:
+ verify_depth-3.5.patch messages: + msg250842 |
| 2015年09月16日 12:04:48 | gbremer | set | hgrepos: - hgrepo316 |
| 2015年09月15日 16:55:10 | gbremer | set | messages:
+ msg250782 versions: + Python 2.7 |
| 2015年09月15日 16:18:35 | berker.peksag | set | stage: patch review versions: + Python 3.6, - Python 2.7, Python 3.5 |
| 2015年09月15日 08:43:17 | vstinner | set | nosy:
+ vstinner messages: + msg250741 |
| 2015年09月15日 08:39:47 | vstinner | set | nosy:
+ christian.heimes |
| 2015年09月15日 02:31:56 | gbremer | set | files:
+ verify_depth.patch hgrepos: + hgrepo316 keywords: + patch |
| 2015年09月15日 01:31:16 | gbremer | create | |