You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When changing the context with set_context, the verify mode/callback is not updated from the new context, you need to call SSL_set_verify on the connection to update it.
This function is not currently exposed by Cryptography, so it will need to be added there too.
That method is on Context, not Connection; as previously mentioned, the context settings are used to initialize the connection, but if the context is changed with set_context later, the verification settings from the new context are not transferred to the connection.
To elaborate on this a bit further: set_context is commonly used in a callback set with set_tlsext_servername_callback in order to change the context based on which hostname the client requests using SNI; if you want to do client verification on some hostnames but not on others, you need to be able to call SSL_set_verify to change the verification settings on that connection.
We have some renewed interest in this from some folks in mitmproxy/mitmproxy#5019, it also looks like we wouldn't be the only ones for whom this would be useful. I'd be happy to re-add the bindings to cryptography and then update #844.
@alex, @reaperhulk et al: Is this something you would be willing to merge, or too much extra complexity for too little value? I don't have strong feelings, we can easily continue to work around this on our end if necessary.
Adding this to Connection + a single additional binding in cryptography seems reasonable to me given that you have people interested in actually using it.
Activity
mithrandi commentedon May 6, 2015
set_verify_depthshould probably be added at the same time.ihamburglar commentedon May 7, 2015
Sorry, what exactly does this do?
mithrandi commentedon May 7, 2015
That method is on
Context, notConnection; as previously mentioned, the context settings are used to initialize the connection, but if the context is changed withset_contextlater, the verification settings from the new context are not transferred to the connection.mithrandi commentedon May 7, 2015
To elaborate on this a bit further:
set_contextis commonly used in a callback set withset_tlsext_servername_callbackin order to change the context based on which hostname the client requests using SNI; if you want to do client verification on some hostnames but not on others, you need to be able to callSSL_set_verifyto change the verification settings on that connection.ihamburglar commentedon May 7, 2015
Ah gotcha.
Fixes pyca#255 -- Add verification methods to the Connection object
Fixes pyca#255 -- Add verification methods to the Connection object
Fixes pyca#255 -- Add verification methods to the Connection object
mhils commentedon Jan 5, 2022
We have some renewed interest in this from some folks in mitmproxy/mitmproxy#5019, it also looks like we wouldn't be the only ones for whom this would be useful. I'd be happy to re-add the bindings to cryptography and then update #844.
@alex, @reaperhulk et al: Is this something you would be willing to merge, or too much extra complexity for too little value? I don't have strong feelings, we can easily continue to work around this on our end if necessary.
reaperhulk commentedon Jan 6, 2022
Adding this to Connection + a single additional binding in cryptography seems reasonable to me given that you have people interested in actually using it.
add `SSL_set_verify` binding for pyca/pyopenssl#255
add `SSL_set_verify` binding for pyca/pyopenssl#255 (#6797)
add `Connection.set_verify`, fix pyca#255
add `Connection.set_verify`, fix pyca#255
pypi-cryptography_vectors: Autospec creation for update from version β¦
pypi-cryptography: Autospec creation for update from version 36.0.2 tβ¦
add `Connection.set_verify`, fix pyca#255
add `Connection.set_verify`, fix pyca#255
add `Connection.set_verify`, fix #255 (#1073)