Opened 5 years ago
Last modified 4 years ago
#5445 enhancement new
validate against platform-trusted certificate authorities by default for HTTPS URLs in twisted.web.client.Agent
| Reported by: | glyph | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | web | Keywords: | |
| Cc: | jknight, ivank | Branch: | |
| Author: |
Description (last modified by glyph)
HTTPS client connections from Agent.request should use the platform's native list of certificate authorities as the trust root by default.
This ticket is only for fixing Agent to actually point at the certificate store API we come up with; there is another ticket for actually implementing that store which is really the hard part here.
Change History (7)
comment:1 Changed 5 years ago by DefaultCC Plugin
- Cc jknight added
comment:2 Changed 5 years ago by ivank
- Cc ivank added
comment:3 follow-up: ↓ 4 Changed 4 years ago by itamar
comment:4 in reply to: ↑ 3 Changed 4 years ago by glyph
Replying to itamar:
I am skeptical that this will happen anytime soon. A more realistic, short term goal is to do what requests does: ship the Mozilla CA pack, with a integration point which packagers can point at their own local CA storage location.
I agree, as my recent comments on the ticket related to hostname verification suggest; maybe we should have an interim ticket for doing that.
However, I think it's important to have realistic expectations here: aside from Linux, as I noted on the ticket for the hard part of this problem "local CA storage" is a database with an API to query it, not a filesystem location. Tools to manage trust don't necessarily keep a filesystem directory that we can list in sync.
comment:5 Changed 4 years ago by glyph
- Description modified (diff)
Update description to mention the other ticket, which is where the bulk of the work is and where the comments explaining what should be done are.
comment:6 follow-up: ↓ 7 Changed 4 years ago by exarkun
- Owner set to glyph
The ticket description could still do a better job of explaining what needs to be done. For example, as is, I might just say that it is already possible to point an Agent at a certificate store using WebClientContextFactory and the pyOpenSSL Context APIs. What do you think is necessary beyond that to resolve this ticket?
comment:7 in reply to: ↑ 6 Changed 4 years ago by glyph
- Description modified (diff)
- Owner glyph deleted
- Summary changed from certificate validation against natively-configured certificate authorities for HTTPS URLs in twisted.web.client.Agent to validate against platform-trusted certificate authorities by default for HTTPS URLs in twisted.web.client.Agent
Replying to exarkun:
The ticket description could still do a better job of explaining what needs to be done. For example, as is, I might just say that it is already possible to point an Agent at a certificate store using WebClientContextFactory and the pyOpenSSL Context APIs. What do you think is necessary beyond that to resolve this ticket?
Hmm. Good point. The issue here is that this always ought to be done by default; as it was phrased previously this was not clear at all.
I am skeptical that this will happen anytime soon. A more realistic, short term goal is to do what requests does: ship the Mozilla CA pack, with a integration point which packagers can point at their own local CA storage location.