Open jeremy-hiatt opened 5 years ago
It looks like those were dropped in #3548
@asvetlov it looks like an API design regression: we should probably separate ssl context and fingerprint.
Another thought: one arg to rule them all smells like a godobject antipattern. Maybe it's a wrong decision after all?
Following up on this...
I see a couple of options here:
SSLContext
as desired.I'm happy to submit a patch if we can reach agreement on the best path forward.
Yeah, Andrew and I discussed this privately and thought that it probably needs to be done on the stdlib side and is probably in the scope of https://www.python.org/dev/peps/pep-0543/ (which I notified @tiran about, I think he wanted to add come hook for an extra validation callback).
Personally, I think that it's probably mostly fine to extend SSLContext
but Andrew seems to dislike this idea.
Thanks for the update. I did some experimentation with the multiple inheritance route; unfortunately it doesn't look easy to create an object that looks like both a Fingerprint
and an SSLContext
. I think Andrew's instincts were correct there.
For now I can work around the issue by implementing a subclass of TCPConnector
and extending _get_fingerprint()
to check an additional attribute.
It's currently not possible to implement cert pinning with Python's ssl module. To implement it correctly, the pinned cert must be verified during the handshake. In case of an error, the handshake must be aborted before a client cert is verified and error must be signalled with a bad_certificate
alert.
@tiran is that because the client cert may contain sensitive data?
Long story short
It appears that 4.0 will remove all the SSL parameters from the
TCPConnector
class except for a singlessl
parameter (#2626). This appears to be quite limiting: for example, it would no longer be possible to supply a client certificate and simultaneously pin the expected server certificate. The former requires you to pass theSSLContext
configured with the client certificate as thessl
parameter, but for the latter you would have to pass aFingerprint
. Is there a recommendation for how this could be achieved?Expected behaviour
Should be possible to make a request with BOTH a client certificate and a pinned server certificate.
Actual behaviour
It appears this will be removed with no alternative offered in 4.0.
Steps to reproduce
N/A
Your environment
client